> -----Original Message----- > From: Derek Foreman <[email protected]> > Sent: Wednesday, August 25, 2021 3:54 PM > To: Hoosier, Matt <[email protected]>; wayland- > [email protected] > Subject: Re: Discrepancies in object IDs printed by $WAYLAND_DEBUG > output > > CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments > unless you trust the sender and know the content is safe. > > > On 2021-08-25 3:08 p.m., Hoosier, Matt wrote: > > 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. > > > This happens because internally the id is replaced with a pointer to the > object > for the next steps in event queuing, and the debug printing code runs too > late to see the original ids. > > > This is a timely complaint, as I wrote a patch for this just yesterday: > > https://urldefense.com/v3/__https://gitlab.freedesktop.org/wayland/wayla > nd/-/merge_requests/172__;!!EJc4YC3iFmQ!Eph6m9- > gz6SOpNOFygfXEu3p4Mc03jqKztjF1slUZHBatS5WVR6pkxqADKUehzk_zA$ > > > Thanks, > > Derek
Ah, makes sense. Thanks. > > > > 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
