91d78daac4
Summary: The SCHED_RESET_ON_FORK results in threads (not only processes) to have the scheduling policy reset to default. This means that the libinput thread is not real time, but this was actually intended. To solve this problem KWin does start without the RESET_ON_FORK flag during startup. Once createInput has been called the scheduling is adjusted again and RESET_ON_FORK is added again. This results in the libinput thread and all threads Qt starts in between (e.g. dbus) to gain real time policy. But it is still not leaked to other processes or to threads in KWin which don't need it. Other options considered: just don't use RESET_ON_FORK and instead manually reset on fork. This would mean all threads in KWin gain real time, but we don't need this. It's only interesting for the main (rendering, Wayland thread) and the input thread. Also the danger to leak into another process is too high. Keeping the capability till the libinput thread is created and adjust the thread itself. This option was discarded as I don't want KWin to have any capabilities when the QApplication is started. Test Plan: ps -eL -o class,rtprio,cmd,comm | grep kwin_wayland Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D8065 |
||
|---|---|---|
| .. | ||
| connection.cpp | ||
| connection.h | ||
| context.cpp | ||
| context.h | ||
| device.cpp | ||
| device.h | ||
| events.cpp | ||
| events.h | ||
| libinput_logging.cpp | ||
| libinput_logging.h | ||