Skip to content

Handle input on a thread

Carlos Garnacho requested to merge wip/carlosg/input-thread into master

From the main commit:

backends/native: Add input thread inside MetaSeatImpl
This (now) doesn't change anything in regards to the API that the UI
thread should access from the MetaSeatImpl. The MetaInputDeviceNative,
MetaInputSettings and MetaKeymap objects are now considered owned by
the input thread, as well as all of libinput objects.
The MetaEventSource now dispatches events in a GMainContext that is
the thread default to this thread, and all UI-thread-accessible API
(seat and virtual input device API) will be handled in a serialized
manner by that same input thread.
The MetaSeatImpl itself is still considered to be owned by the caller
thread, and all the signals that this object emits will be emitted in
the GMainContext that is default at the time of calling
The MetaInputSettings configuration changes will likewise be handled
in the input thread, close to libinput devices.

Before that, an insane number of refactors to accommodate this. There's scares, there's joy, there's tears, MetaSeatImpl and MetaInputSettings argue, but get together again around the third act. they end up riding towards a gorgeous sunset. Will they live happily ever after?

Edited by Carlos Garnacho

Merge request reports