D26026: refactor: let Control be a QObject

[Roman Gilg]

romangg added a comment.


  That being said thinking about it some more having a file watcher can lead to races for example in the following case:
  
  - User changes auto rotation and resolution at the same time while device is held in a position unequal to current rotation
  - KWin receives updated configuration (I)
  - KScreen daemon receives auto rotation change through file watcher before resolution change through KCM -> KWin -> daemon
  - KScreen sends updated configuration (II) with different rotation to KWin
  - KWin sends new configuration (i) and afterwards receives configuration (II)
  - KWin applies (II) and sends (II)
  - KScreen receives first new configuration (I) and then (II)
  
  In this case the resolution would not be set.
  
  I'm unsure how to solve this best. I really don't want to send all auxiliary KScreen data through the KWin connection. Simple solution would be a small delay on control changes waiting for potential KWin changes. A likely better solution might be to introduce this libkscreen dbus out of process service found on RandR backend to the KWayland backend and then send auxiliary data through there but not to the compositor.

REPOSITORY
  R104 KScreen

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

To: romangg, #plasma
Cc: davidedmundson, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20191215/84c3801d/attachment.html>