thread-watcher: Watch real-time thread from main loop in addition to signal handler
It seems like the kernel is blocking timer signals from getting emitted
in some cases when it is stuck, so we ned to watch for stalls from a
different thread than the stalled thread.
This commit adds code to watch from the main loop.
RTKit requires mutter to set a hard rlimit on how long its thread will
use CPU before going back to the kernel. This limit is about 12 frames.
Unfortunately, amdgpu seems to have a bug at the moment where it will
cause the thread to stall longer than that when the screen is locked.
It also seemingly stalls during some games.
Rather than let the display server get slayed, this commit adds a
roundtrip through the kernel to reset the clock when things are stalled,
and tells mutter to switch away from using real-time threads.
Now that mutter can use a realtime thread its very important that
it doesn't stall for too long, since that can result in the kernel
killing it. Ironically, a main reason mutter could stall is
kernel bugs.
When a stall happens, we need a way to see why. This commit adds
a new function, "meta_print_backtrace" to print backtrace of the
current process and the kernel (if possible).
A future commit will use this new function.
4f6c918...
by
=?utf-8?q?Florian_M=C3=BCllner?= <email address hidden>
backends/eis-client: Do not add device before adding EIS regions
When a device is added, libei does not allow adding additional regions
for that particular device, as it is already advertised to the EI
client.
As a result, mutter currently effectively only adds the first region to
a device, but not the others.
This makes input in multi monitor sessions only possible on one monitor,
as the EI client cannot look up the other regions, since they were not
advertised to it.
Fix this situation by not adding and resuming the device, when a shared
device is used.
Instead, for shared devices, always add all regions first, and then
after that, add and resume the device.
