D8065: Ensure libinput connection thread uses real time scheduling

Martin Flöser noreply at phabricator.kde.org
Sat Sep 30 08:10:46 UTC 2017


graesslin created this revision.
graesslin added reviewers: KWin, Plasma.
Restricted Application added a project: KWin.
Restricted Application added subscribers: kwin, plasma-devel.

REVISION 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

REPOSITORY
  R108 KWin

BRANCH
  libinput-rr

REVISION DETAIL
  https://phabricator.kde.org/D8065

AFFECTED FILES
  input.cpp
  libinput/connection.cpp
  libinput/connection.h
  main_wayland.cpp

To: graesslin, #kwin, #plasma
Cc: plasma-devel, kwin, bwowk, ZrenBot, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170930/4f8b8af2/attachment.html>


More information about the Plasma-devel mailing list