Re: Accessing the time, compatible with motion time-stamps
On Thu, Jun 23, 2022 at 4:07 PM Simon Ser wrote: > > Hi, > > On Wednesday, June 22nd, 2022 at 06:03, Campbell Barton > wrote: > > > - zwp_tablet_tool_v2_listener.motion > > callback doesn't take time-stamps. > > > > Is there a way to access the time that is compatible with > > pointer_listener.motion in situations where callbacks don't provide a > > time? > > You can use the zwp_tablet_tool_v2.frame event, sent right after each > group of tablet tool events. It carries a timestamp. > > Simon Thanks, I realize now I wasn't using the tablet API correctly, regarding motion-tilt etc. There are still a handful of cases where it would be useful to access the time value according to wayland. For example, "enter" callbacks don't take a time argument. - wl_data_device_listener.enter - wl_pointer_listener.enter In these cases an event is generated in the client application that could use the time. -- - Campbell
Dynamically loading libwayland complications
Hi, recently I was looking into dynamically loading libwayland to be able to support both X11 and Wayland, without requiring libwayland. For our project is currently a requirement for adopting Wayland. While I did manage to get this working, use of variadic arguments adds quite some complexity that could be avoided. >From what I can tell there is no portable way to wrap `wl_proxy_marshal_flags` see [0], Using GCC's `__builtin_apply` does work but this isn't available in CLANG so I'd prefer to avoid it. The only portable way I found to handle this was to create a header that needs to be included before any of the headers generated by wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which can be replaced by a reference to a function pointer instead of requiring the function to exist and link at build time. This is quite messy and means it's not practical to create an isolated dynamic loader for libwayland-client. There are a few possible solutions to this but they involve additions to wayland API. - Make wl_argument_from_va_list public, so wrapper functions can always construct `wl_argument` from `va_list` and forward that to the `wl_argument` version of functions. - Have va_list versions of all functions (similar to printf/vprintf). - The ability to retrieve the number of arguments a function expects would also allow wrappers to forward `va_args`, although it's fairly obscure. - Support for wayland-scanner generating code that doesn't call variadic functions. This is more of a workaround, but would at least mean that projects could call into alternative versions of the functions. As far as I can see, exposing `wl_argument_from_va_list` is the most straightforward solution. Would the Wayland project consider tweaks to the API that make dynamically loading libwayland libraries possible? [0]: https://stackoverflow.com/questions/72781222 -- - Campbell
Re: Dynamically loading libwayland complications
On Tuesday, 28 June 2022 19:00:26 PDT Campbell Barton wrote: > Hi, recently I was looking into dynamically loading libwayland to be > able to support both X11 and Wayland, without requiring libwayland. > For our project is currently a requirement for adopting Wayland. Simplify your problem by dynamically loading a plugin that links to libwayland, instead of dynamically loading libwayland. > From what I can tell there is no portable way to wrap > `wl_proxy_marshal_flags` see [0], > Using GCC's `__builtin_apply` does work but this isn't available in > CLANG so I'd prefer to avoid it. > The only portable way I found to handle this was to create a header > that needs to be included before any of the headers generated by > wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which > can be replaced by a reference to a function pointer instead of > requiring the function to exist and link at build time. How is this different from any other function from libwayland, variadic or not? If your code isn't linking to libwayland, then it can't call any of those functions. Therefore, you must be using a code generator that is calling something other than those functions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: Dynamically loading libwayland complications
On Wed, Jun 29, 2022 at 12:38 PM Thiago Macieira wrote: > > On Tuesday, 28 June 2022 19:00:26 PDT Campbell Barton wrote: > > Hi, recently I was looking into dynamically loading libwayland to be > > able to support both X11 and Wayland, without requiring libwayland. > > For our project is currently a requirement for adopting Wayland. > > Simplify your problem by dynamically loading a plugin that links to > libwayland, instead of dynamically loading libwayland. Right, this is an option, but a much bigger change on our end. > > From what I can tell there is no portable way to wrap > > `wl_proxy_marshal_flags` see [0], > > Using GCC's `__builtin_apply` does work but this isn't available in > > CLANG so I'd prefer to avoid it. > > > The only portable way I found to handle this was to create a header > > that needs to be included before any of the headers generated by > > wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which > > can be replaced by a reference to a function pointer instead of > > requiring the function to exist and link at build time. > > How is this different from any other function from libwayland, variadic or > not? > If your code isn't linking to libwayland, then it can't call any of those > functions. Therefore, you must be using a code generator that is calling > something other than those functions. Those functions are defined locally, when wayland is present - function pointers are set which the local functions call into. The complication with variadic functions is there isn't a portable way of forwarding the arguments to the dynamically loaded wayland versions as none of them take a `va_list`. They all take either `...` or `wl_argument`. As the function to convert `va_list` into `wl_argument` is private, I don't think there is a way to forward a `va_list` currently. > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel DPG Cloud Engineering > > > -- - Campbell
