I’m considering developing a new gstreamer plugin designed to manage GstNavigation events across different Window Systems, particularly for X11 and Wayland. The plugin would identify the current system either through environment variables or by extracting information from the element parameter.
I have a couple of inquiries: firstly, does it seem reasonable to create such a plugin? Secondly, what would be a suitable name for the encapsulated element? “GstWindowSystemNavigation” feels lengthy; perhaps “GstNaviSink” could be a more concise option?
Additionally, I’m uncertain about how permission issues related to root permissions for creating a uinput device might be handled in gstreamer, especially for Wayland. Any insights on this matter would be appreciated.
Generally, the input event handling of a window system is tied to, well, a window. As that window is generally internal to an element (or an external window id is provided by an application which is parented to the internal window), the input handling for a specific window implementation (X11, Wayland, etc) generally live in the elements themselves. As such, for an internally-created window, it does not make sense to have the input handling be an external entity. If you are passing in an external window handle (not recommended anymore), then you may be able to manually provide your own navigation events if the element implementation does not already support GstNavigation.
Some elements will already handle input events directed at their window already and don’t need any external code for GstNavigation.
I intended a more general scenario, where events are simulated at a system level rather than for a specific window. For instance, the events handler in ximagesrc transmits events to the active display of the X server, not a specific window. To replicate this for pipewiresrc, I must duplicate event-handling code from ximagesrc (for X11) and establish a new handler for Wayland. Many gstreamer-based remote desktop projects (Selkies, Mako etc), redundantly create their own navigation akin to what ximagesrc currently accomplishes. I proposed consolidating this common code shared among projects and GStreamer elements into a separate element, allowing people to expand it with additional devices and logic.