I observe that the IDs used to denote some wl_buffer protocol objects created
by a server-side factory in the $WAYLAND_DEBUG trace, differ between the moment
they're first announced in the callback event and the later use-sites when the
objects are passed to subsequent Wayland protocol method invocations.
For example, using weston-simple-dmabuf-egl normally uses "non-immediate"
allocation of wl_buffers through the zwp_linux_dmabuf_v1 protocol extension.
One distinguishing feature of this non-immediate technique is that the ID of
the newly-built protocol object is not known at the time the method to request
creation is made. The compositor is expected to supply it later in an
asynchronous event.
This all works fine, but I notice in the log output that the ID of the newly
built object is different at point it's first announced to the client:
[2902569.971] ->
[email protected]_synchronization(new id
zwp_linux_surface_synchronization_v1@10, wl_surface@3)
[2902570.062] -> [email protected]_params(new id
zwp_linux_buffer_params_v1@11)
[2902570.076] -> [email protected](fd 8, 0, 0, 1024,
16777216, 2)
[2902570.095] -> [email protected](256, 256, 875713112,
1)
[2902572.072] -> [email protected]_params(new id
zwp_linux_buffer_params_v1@12)
[2902572.105] -> [email protected](fd 10, 0, 0, 1024,
16777216, 2)
[2902572.124] -> [email protected](256, 256, 875713112,
1)
[2902572.240] -> [email protected]_params(new id
zwp_linux_buffer_params_v1@13)
[2902572.249] -> [email protected](fd 12, 0, 0, 1024,
16777216, 2)
[2902572.262] -> [email protected](256, 256, 875713112,
1)
...
[2902576.893] [email protected](new id
wl_buffer@2372643520)
[2902576.901] -> [email protected]()
[2902576.906] [email protected](new id
wl_buffer@2372643856)
[2902576.913] -> [email protected]()
[2902576.918] [email protected](new id
wl_buffer@2372644240)
[2902576.924] -> [email protected]()
So, here are the ID's of the buffers built using the non-immediate mode:
* wl_buffer@2372643520 (0x8d6baac0)
* wl_buffer@2372643856 (0x8d6bac10)
* wl_buffer@2372644240 (0x8d6bad90)
These ID's look suspicious to begin with. They do not have ID's in the usual
range of server-allocated object ID's (these are supposed to begin at
0xff000000).
But then later when the application uses these objects as parameter to
subsequent requests, the ID's are printed differently:
[2902577.702] -> [email protected](wl_buffer@4278190080, 0, 0)
...
[3183676.812] -> [email protected](wl_buffer@4278190081, 0, 0)
...
So here, those are:
* wl_buffer@4278190080 (0xff000000)
* wl_buffer@4278190081 (0xff000001)
Those ID's are in the expected range for server-allocated protocol objects.
Despite this discrepancy, the application clearly works fine; the right
contents appear on-screen.
Is there some quirk that causes object ID's passed as parameters to events to
be mis-printed?
-Matt
