This is a preparatory step to add signals later for watching file changes.

I don't think I understand. What for?
If it's full output configuration going via the disk that would go against the main part of kscreen architecture.

In D26026#578484, @davidedmundson wrote:

This is a preparatory step to add signals later for watching file changes.

I don't think I understand. What for?
If it's full output configuration going via the disk that would go against the main part of kscreen architecture.

It's not for the full output configuration but only certain settings communicated from KScreen KCM to its daemon and which are not communicated through KWayland / XCB. For now I do/plan it for:

• Output retention
• If the refresh rate is automatically chosen or set by user explicitly.
• If the resolution is automatically chosen or set by user explicitly.
• If the rotation value is automatically chosen or set by user explicitly.

Example rotation: Default is "Automatic". That means if KScreen daemon detects orientation change via sensor it will send new configuration with updated rotation value for internal screen to KWin via KWayland. User now selects "Manual", then KScreen daemon ignores future orientation changes and not send new configuration via KWayland.

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.

I move forward with this approach and revisit later to work on a better solution. Maybe with the libkscreen dbus process.