About fixing the untyped new_id issue

[Pekka Paalanen]

On Mon, 28 Sep 2020 07:33:34 +0200
Jan Bruns <code at abnuto.de> wrote:

> Hallo.
> 
> Here's an untested wip/low quality patch that probably solves the new_id 
> issue of libwayland.
> 
> The problem:
> 
> The wayland-scanner tool generates code that reflects a protocol 
> different from the protocol XML defintion.

Hi,

sorry, no, it does not.

Whenever XML defines an argument of type "new_id" but without the
attribute "interface", then the argument shall expand into three
parameters instead of just one, so that is carries the three necessary
items to the compositor: the new protocol object id, the interface name
string, and the interface version.

This is how it is designed to work, but never properly documented.

There is no code bug to be fixed here, just documentation to be written.

> Wherever a protocol-XML describes argument-lists that contain objects of 
> unknown type to be created (args with type="new_id", but without 
> interface="..."), the scanner-tool adds additional arguments about 
> object type information (not only to the C API, but also to the 
> wire-protocol. For example, registry.bind() gets a "usun"-signature, 
> whereas the XML clearly defines a "un" signature).
> 
> This is presumably caused by the "fully managed"-style of the libwayland 
> C API, that hides things like object-id management from applications and 
> compositors, combined with the relativley unclear separation of 
> libwayland exports vs. libwayland C-header based API. And it also is a 
> very rare special case, so that fixing this issue must have been very 
> unattractive over the years. For the core protocol, there's only 
> registry.bind(), and most popular additional protocols are not affected 
> at all.
> 
> The suggested fix is to correct the scanner tool and the core protocol 
> xml in parallel. This way, the effective wire protocol doesn't depend on 
> wether or not the patch was applied, the C API remains the same (at 
> least for the mainstream protocol XMLs), and even the binary libwayland 
> .so files could remain unchanged for the changes to take effect (because 
> the point of change happens in header files included by 
> applications/compositors).

What you suggest would almost certainly break all Wayland language bindings
aside from libwayland's C bindings, as they already have built in the
assumption you propose to remove, and they process wayland.xml
themselves with their own tools to produce their bindings. It is
possible this breakage is limited to build time, but it is still an
unacceptable break.

This does not seem to have anything to do with the FreeBSD thread.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200928/3b0ddd6b/attachment.sig>