![]() ![]() ClutterInputDevice and ClutterInputDeviceTool (representing input devices and drawing tablet tools) are consequently morphing into immutable objects, all changes underneath (e.g. In order to do so, all the information derived from them must be independent of the input thread state. The main goal of the input thread is to provide the main thread with ClutterEvents, with the fact that they are produced in a distinct thread being irrelevant. ![]() specifying what barriers or constraints are in effect, or virtual input), but these synchronization points are either scarce, or implicitly async already. There is of course some involvement from the main thread (e.g. For this to work seamlessly the thread needs a certain degree of independence, it needs to produce ClutterEvents and know where will the pointer end up without any external agents. The input thread takes the first step out of that process. Process several ClutterEvents across the stage actors, let them queue state changesĪll in the course of a frame.Dispatch several libinput events, convert them to ClutterEvents.The main thread context is already a busy place, in the worst case (and grossly simplified) we: Polishing these interactions so the backend code stays more self-contained has been a very significant part of the work involved. Emission of wl_touch.cancel had strange hooks into libinput event handling, as the semantics of CLUTTER_TOUCH_CANCEL varied slightly.Pointer constraints were done by hooking a function that could impose the final pointer position.This space-saving peculiarity comes straight from XIEvent and XIQueryDevice. We still forwarded input axes in a compact manner, that requires querying the input device to decode event->motion.axes positions into CLUTTER_INPUT_AXIS_PRESSURE.Some examples, no special notoriety or order: ![]() However, in terms of input, the Clutter API barrier did still exist for the most part, it was still heavily influenced by X11 design, and was pretty much used as it was initially designed. Slowly over time, and still ongoing, we’ve been refactoring Mutter so all the code that talks to the underlying layers of your OS lives together in src/backends, taking this code away from Clutter and Cogl. Later on, Mutter merged its own copies of Clutter and Cogl, but the API barrier stayed essentially the same at first. It was unavoidable that both sides were involved. In the rise of Wayland, that reliance on an external toolkit drove many of the design decisions around input management, usually involving adding support in the toolkit, and the necessary hooks so Mutter could use or modify the behavior. Mutter wasn’t always a self-contained compositor toolkit, in the past it used to rely on Clutter and Cogl libraries for all the benefits usually brought by toolkits: Being able to draw things on screen, and being able to receive input. Weaver, public domain ( Source) A trip down memory lane Come around and gather, in this article we will talk about how Mutter got an input thread in the native backend. ![]()
0 Comments
Leave a Reply. |