feat: implement shim mode, rewrote / major refactor of config system #23

Merged
JoshStrobl merged 4 commits from fix/builtin-modechange-test into main 2026-01-02 01:30:40 +01:00
Owner

This commit introduces a new "shim mode" for Budgie Desktop Services display configuration. The intent of this shim mode is enable external applications such as wdisplays to directly modify the compositor state and directly update our configuration (by virtue of our service listening for event changes for the wlr output heads). This shim configuration uses an absolute positioning system rather than our relative positioning system for non-shim mode (which we'll use for Budgie 11 via Budgie Display Configurator).

To facilitate this, there is now check in SysInfo for BUDGIE_SESSION_VERSION as that was newly introduced for Budgie 10.10. When the version starts with 10.10 (so can be 10.10.1, or even our preview builds), we turn on shim mode and do the following:

  1. Apply our config immediately, as we did before. This is from the shim file and calls to Batch System.
  2. During our batch system calculation, skip our relative positioning logic in favor of the absolute positioning. There is now a new action type to facilitate this.
  3. During the lifecycle of the application, changes to the head should trigger a stateChanged event, which triggers our global Output State class checkAndEmitSignals. This function does some recalculation and re-emit itself, and when in shim mode it'll then update our config objects and immediately save.

The process is also now a QGuiApplication, at least for now. The reason for this is QGuiApplications under Wayland are exposed to the QtWayland QPA platform, which handles the wayland events in a non-blocking way and makes it easier for us to set up a connectionthread via KWayland. This seems to enable to event loop to not get stuck on the queue or dispatches, whatever devilry was basically causing our application to not receive any Wayland events!

Another change was to our built-in detection and ensuring that against built-in monitors we just always try to apply a custom mode since the display (e.g. on my Thinkpad) doesn't have good EDID and only reports one mode and not any other mode capabilities (reports 4k, no 1440p, 1080, etc.).

Fixes #15

Fixes #22

This commit introduces a new "shim mode" for Budgie Desktop Services display configuration. The intent of this shim mode is enable external applications such as wdisplays to directly modify the compositor state and directly update our configuration (by virtue of our service listening for event changes for the wlr output heads). This shim configuration uses an absolute positioning system rather than our relative positioning system for non-shim mode (which we'll use for Budgie 11 via Budgie Display Configurator). To facilitate this, there is now check in SysInfo for BUDGIE_SESSION_VERSION as that was newly introduced for Budgie 10.10. When the version starts with 10.10 (so can be 10.10.1, or even our preview builds), we turn on shim mode and do the following: 1. Apply our config immediately, as we did before. This is from the shim file and calls to Batch System. 2. During our batch system calculation, skip our relative positioning logic in favor of the absolute positioning. There is now a new action type to facilitate this. 3. During the lifecycle of the application, changes to the head should trigger a stateChanged event, which triggers our global Output State class checkAndEmitSignals. This function does some recalculation and re-emit itself, and when in shim mode it'll then update our config objects and immediately save. The process is also now a QGuiApplication, at least for now. The reason for this is QGuiApplications under Wayland are exposed to the QtWayland QPA platform, which handles the wayland events in a non-blocking way and makes it easier for us to set up a connectionthread via KWayland. This seems to enable to event loop to not get stuck on the queue or dispatches, whatever devilry was basically causing our application to not receive any Wayland events! Another change was to our built-in detection and ensuring that against built-in monitors we just always try to apply a custom mode since the display (e.g. on my Thinkpad) doesn't have good EDID and only reports one mode and not any other mode capabilities (reports 4k, no 1440p, 1080, etc.). Fixes #15 Fixes #22
This commit introduces a new "shim mode" for Budgie Desktop Services display configuration. The intent of this shim mode is enable external applications such as wdisplays to directly modify the compositor state and directly update our configuration (by virtue of our service listening for event changes for the wlr output heads). This shim configuration uses an absolute positioning system rather than our relative positioning system for non-shim mode (which we'll use for Budgie 11 via Budgie Display Configurator).

To facilitate this, there is now check in SysInfo for BUDGIE_SESSION_VERSION as that was newly introduced for Budgie 10.10. When the version starts with 10.10 (so can be 10.10.1, or even our preview builds), we turn on shim mode and do the following:

1. Apply our config immediately, as we did before. This is from the shim file and calls to Batch System.
2. During our batch system calculation, skip our relative positioning logic in favor of the absolute positioning. There is now a new action type to facilitate this.
3. During the lifecycle of the application, changes to the head should trigger a stateChanged event, which triggers our global Output State class checkAndEmitSignals. This function does some recalculation and re-emit itself, and when in shim mode it'll then update our config objects and immediately save.

The process is also now a QGuiApplication, at least for now. The reason for this is QGuiApplications under Wayland are exposed to the QtWayland QPA platform, which handles the wayland events in a non-blocking way and makes it easier for us to set up a connectionthread via KWayland. This seems to enable to event loop to not get stuck on the queue or dispatches, whatever devilry was basically causing our application to not receive any Wayland events!
ngompa approved these changes 2026-01-01 21:55:46 +01:00
ngompa left a comment
Owner

This is a lot of code, but it looks rather simple and reasonable.

This is a _lot_ of code, but it looks rather simple and reasonable.
EbonJaeger left a comment
Owner

As Neal said, there is a lot here, so I didn't do a super deep dive. I did notice a couple of formatting things. Also curious about the use of TitleCase for property names instead of camelCase. Are we doing that everywhere, and I just haven't noticed? xD

As Neal said, there is a lot here, so I didn't do a super deep dive. I did notice a couple of formatting things. Also curious about the use of TitleCase for property names instead of camelCase. Are we doing that everywhere, and I just haven't noticed? xD
@ -0,0 +150,4 @@
head->setHorizontalAnchoring(horizontalAnchor);
head->setVerticalAnchoring(verticalAnchor);
}
} else {
Owner

Extra indent.

Extra indent.
JoshStrobl marked this conversation as resolved
@ -0,0 +186,4 @@
// Set primary output if specified
auto primaryOutput = StoredPrimaryOutputIdentifier();
if (!primaryOutput.isEmpty()) {
qDebug() << "Primary output:" << primaryOutput;
Owner

Missing indentation.

Missing indentation.
JoshStrobl marked this conversation as resolved
Author
Owner

Dunno why clang-format isn't fixing those 🫠

Dunno why clang-format isn't fixing those 🫠
Author
Owner

Also curious about the use of TitleCase for property names instead of camelCase. Are we doing that everywhere, and I just haven't noticed? xD

No it should probably be lowerCamelCase. I'll get those fixed 👍

> Also curious about the use of TitleCase for property names instead of camelCase. Are we doing that everywhere, and I just haven't noticed? xD No it should probably be lowerCamelCase. I'll get those fixed 👍
JoshStrobl deleted branch fix/builtin-modechange-test 2026-01-02 01:30:40 +01:00
Sign in to join this conversation.
No description provided.