
Today I continued work on budgie-daemon v2's Display Configuration Batch system. I cleaned up my DisplayConfigurationBatchSystem to no longer hold references to each output serial's Batch class, rather I have that in the DisplayConfigurationCalculation. Another key change I made was no longer having the system scrap the calculation and make a new one, rather I have it call a reset function that clears out some of the various computed properties of the calculation class, and I also have one calculation (rather than it being an `std::optional`). Hooked up a new outputRemoved slot on the batch system to WaylandOutputManager, so we can now call the calculation reset if an output is removed while the user is configuring heads.

The `calculate` method of DisplayConfigurationCalculation is looking much nicer as well. Since we have references to all the Batch class instances with their actions, I am able to iterate over each of the batches, cherry-pick the actions (which are now in a QMap of the action type to the action itself) when creating the QRect for the output properties, have it fallback to the WaylandOutputManager if we don't have a SetMode action (so basically "keep it the same as what is is now" for width / height / refresh), etc.

Still need to write a lot of the trickier bits of the method, but good progress made on it today and I'm much happier with _this_ version of the implementation than my previous ideas.



As detailed in [yesterday's Today's Dev](/todays-dev/21), plan for today was to work on the Display Configuration Batch system. Started working out the logic for the `DisplayConfigurationCalculation::calculate` and very quickly realized that there was some streamlining to do on how I store actions. Mulled over that for a while, did some dishes and cooking to let my brain do its own background cookin on some ideas. Came to the conclusion that instead of a QList of actions, I'll have a map of the _type_ of action to the action itself stored on the batch, since you can't have several of a specific type anyways.

It should also greatly simplify generating the QRects for each of the outputs since I need to know both any available SetMode action as well as any Transform action to know basically what should be the width and height (will vary based on the transform if any). To do it during the calculation would require a bunch of action iteration or storing the actions temporarily in a manner that would basically be a QMap anyways.

So plan is to continue hacking on the calculation logic tomorrow, will be interesting to see how close or far to my initial idea for the system the end result is.

But for now, off to prep for the release of the early access of Path of Exile 2!


Today was entirely focused on continuing to polish the definition work on the Display Configuration Batch system. Carved out the definition for the batch actions, cleaned up some extraneous class definitions for Enabling / Disabling Batch classes, and did an initial pass at the DisplayConfigurationCalculation class definition.

Right now my current line of thinking is reflected in the following breakdown:

You have _one_ `DisplayConfigurationBatchSystem`. It is expected that the applications which would integrate this batch system (for example Budgie Control Center) would use a D-Bus method to perform a reset of the system when loading the view that'd show displays. Maybe there could be other ways of clearing it like if you were to suspend your system or something, but I am not too worried about automatically clearing it at this time.

This class would hold a `QMap` of our output serials to `DisplayConfigurationBatch` classes, so there would be at most one for each output serial. Adding a batch for the same serial would clear out any existing one. It would also hold a reference to a `DisplayConfigurationCalculation`, assuming that either `apply` or `test` are called to call our internal `createCalculation` function on the batch system.

This calculation class would be responsible for...well the calculation obviously. It would aggregate all batch system actions, filter out duplicate ones that would have added earliest (for example setting an anchor, then changing it later, this would filter out the first one), calculate the global space and positions for each output, etc.

To accomplish this, our DisplayConfigurationBatch createCalculate would call the `DisplayConfigurationCalculation::addAction`, then at the end call its `calculate` function. `addAction` would add it to a QList of buffered actions. `calculate` would process these and add them to a new QList just called `m_actions`.

Doing some investigating work today, I came across [QRect](https://doc.qt.io/qt-6/qrect.html) and [QSize](https://doc.qt.io/qt-6/qsize.html). QRect seems pretty dope: it enables us to define coordinates (x, y), dimensions (width, height), and keeps it all in a nice container that we could use during our calculation to determine and avoid intersections (it has functions like `intersected` and `intersects`). For rotation, I could basically just call `transpose` to swap width and height (e.g. 90deg or -90deg rotations). I could use several `united` calls to get the bounding rectangle between two, which would be handy for iterating over output rects to get the global space (total height and width of all the outputs, with proper handling of mirrored outputs).

All extremely handy stuff, so my current thinking is having a QRect of the global space, then a QMap of each output to their own QRect.

For `DisplayConfigurationBatch`, you create it for a specific serial with one of two types: `DisplayConfigurationBatchType::Enable` or `DisplayConfigurationBatchType::Disable`. If you set it to `Enable`, you will be allowed to add actions.

`DisplayConfigurationBatchAction` contains basically all the possible properties (as members) for every possible type of an action. Maybe not the best way to do it but it can be cleaned up later after I get some feedback on it.

Current types are:

- SetGamma
- SetMirrorOf
- SetMode
- SetPositionAnchor
- SetScale
- SetTransform

Each of these map to a different constructor, all taking the relevant args for their given type. I won't get into all of them...because why...but here are a couple examples:

```
DisplayConfigurationBatchAction mode(QSize *dimensions, int refresh, QObject *parent = nullptr);
DisplayConfigurationBatchAction setPositionAnchor(
  QString *serial,
  DisplayConfigurationHorizontalAnchor horizontal,
  DisplayConfigurationVerticalAnchor vertical,
  QObject *parent = nullptr
);
```

In the first one, you might see that I am using QSize instead of specifying width and height separately. Not sure that'll stick around but figured I'd change things up a bit.

For setPositionAnchor, it takes a couple different anchor types (one for horizontal and another for vertical).

I already described anchoring in a previous Today's Dev, but to here are the current literal enum values:

```
enum DisplayConfigurationVerticalAnchor {
    Above,
    Top,
    Middle,
    Bottom,
    Below
};

enum DisplayConfigurationHorizontalAnchor {
    Left,
    Right,
    Center,
};
```

So yea, sorted out all the definitions. Bit of thinking involved I'd say. Started working on implementing some of the actual methods, starting with `DisplayConfigurationBatchSystem` but a lot of it is placeholder / TODOs until I carve more of the methods out.

And guess what I'll be working on tomorrow? :)


Speedrunning this one today. Skipped yesterday since it was my birthday.

I switched out calls to `std::cout` and `std::cerr` with [Qt logging functions](https://doc.qt.io/qt-6/qtlogging.html).

Fired off an email to the amazing folks at [Jetbrains](https://jetbrains.com) as Buddies of Budgie is in their open source program. As part of being in that program, Jetbrains generously provides licenses that the organization can use for their software such as [CLion](https://www.jetbrains.com/clion/) and [RustRover](https://www.jetbrains.com/rust/). These licenses last a year at a time and it only takes an email or two towards the end of the licenses to request for it to be extended. While I'm at it, I always mention _how_ the team is leveraging their products. As a couple examples, Campbell (serebit) has been using CLion for Magpie v1 (Budgie's C++ Wayland compositor leveraging wlroots) and RustRover for [Magothy](https://codeberg.org/serebit/magothy) (hardware profiling tool). I have been using CLion for budgie-daemon v2 and [Koto's Qt6 port](https://github.com/JoshStrobl/koto/tree/qt6). In my experience, CLion has been damn near flawless for C++ development where many others would struggle (whether that be with highlighting, LSP, linting, the debugger tooling), especially with Koto.

If you lead an open source community and think Jetbrains tooling would be useful for you, I'd encourage you to check out their [Open Source support](https://www.jetbrains.com/community/opensource/) page. Not an ad here, I just don't want you to waste time fucking with tooling, spend it on being productive instead.

Started working on the Display Configuration Batch system (_can I just call it DCB from now on?_), almost entirely around the class definitions currently. Trying to get a feel of how it'll look at an abstract definition level before writing the actual code. Nothing to show for it yet.

That's it for today. Maybe lost the speedrun. Not sorry.


Today was a pretty productive day when it came to budgie-daemon v2. I started out the morning by implementing the updating of our active DisplayGroup (config bits) in the DBus setters, e.g. calling the DBus Setter for SetPosition will update the position for that output in the group, then flush the updated serialized config to disk.

After that, I took on the work of moving the daemon from [sdbus-cpp](https://github.com/Kistler-Group/sdbus-cpp/blob/master/docs/using-sdbus-c++.md) to [QtDBus](https://doc.qt.io/qt-6/qtdbus-index.html), enabling me to take advantage of native Qt types like QString. I started out by taking a look at `qdbusxml2cpp-qt6` for generating the adaptors based on my XML schema. I had to mark up my XML schema with annotations, which either aren't documented or I'm blind, so ended up using a couple LLMs for that. Gemini kept messing up on my GetAvailableModes method which returns an array (a) of width (i), height (i), and width (i) -- together declared as `a(iii)`. The annotation value is `QList&lt;QList&lt;int&gt;&gt;` and not `QList<QList<int>>` which Gemini kept asserting was correct, Claude got it right though and it was very much a "today I learned" on the encoding there.

Once the annotations were sorted, the DisplaysAdaptor generated without issue. I took the opportunity to rename stuff from generic `server` to `DisplayService`, since in reality we will have multiple adaptors for different interfaces, before starting work on refactoring my existing sdbus-cpp display code to be a class that has the ref to the generated adaptor (as opposed to inheritance).

I tried the inheritance route but it kept exposing both the adaptor Object path (`/org/buddiesofbudgie/BudgieDaemonX/Displays`) as well as an internal Object path that was something like `local.budgiedaemonv2.buddiesofbudgie.org.bd.DisplayService`. I didn't want to start overriding the adaptor by specifying in my class `Q_CLASSINFO("D-Bus Interface", "org.buddiesofbudgie.BudgieDaemonX.Displays")` since I figured that was very much **not** the way to go about it, and ended up settling on my `DisplayService` class inheriting from `QObject` itself and then creating the `DisplaysAdaptor` during construction.

Porting over the code to the class methods was trivial and frankly not worth talking about.

Once that was sorted I updated my `main.cpp` to register the object and service once the `WaylandOrchestator::ready` signal was emitted. Everything seems to work just as well as when I was using `sdbus-cpp`, and memory usage seems to be basically identical as well.

Quite happy with the result! Next up will be working on the Display Configuration Batch system, which I expect to be a longer running task.


Today was a good day for all the config code in budgie-daemon v2. In [yesterday's Today's Dev](/todays-dev/17), I discussed my plans for changing up a fair bit of this code to ensure that when we do not have a config or a matching group, we generate a new "active group" and make sure that gets flushed to disk (with the intent to not overwrite any other groups in the config of course).

Excluding the code for updating the active DisplayGroup when performing DBus setter method calls, everything works and the config basically mirrors my hand-written TOML config.

To accomplish it, I first set out to change the DisplayConfig, DisplayGrouping, and DisplayGroupOutputConfig structs into classes, with respective private or protected members and appropriate setters and getters (to ensure more predictable behavior that messing with the struct members directly). I no longer have utils for generating those structs from TOML values, but rather have class constructors that take in the `const toml::value&` and a method `toToml` for converting the class back into a `toml::ordered_value`. This helped with tidying up the config code in general. While I was at it, I moved them to using QString, QList, and QStringList types for various members.

In our `DisplayGroup`, we now have a method that is called when we have no matching DisplayGroup for the current Wayland output management / heads state, `createDisplayGroupForState`. This method:

1. Creates a new `DisplayGroup`
2. Sets the name to an auto-generated name that is basically a comma-separated list of the output serials, then appended with `(Auto Generated)`. For example: `0x32394658, 0x41505846 (Auto Generated)`
3. Sets the output serials to a `QStringList` of all of our head serials from the manager.
4. Sets it as the preferred group
5. Sets the primary output to the first output. This will almost certainly change in the future.

After this, it'll generate the DisplayGroupOutputConfig for each of the outputs and add those to the DisplayGroup.

With this created group from the state, we set it as the active group then immediately call our new `saveState` which will create a config (or simply add to it if we already had one but no matched group) and write it to disk. I won't go into the implementation detail for that stuff, feel free to [check the commit](https://github.com/BuddiesOfBudgie/budgie-daemon-v2/commit/3635d0b64f3199057dcfa5b7167025c662fd4e61) if you are interested. Instead, I'd rather just show you the config it generates 😀

```
[preferences]
automatic_attach_outputs_relative_position = "none"

[[group]]
name = "0x32394658, 0x41505846 (Auto Generated)"
preferred = true
output_serials = ["0x32394658", "0x41505846"]
primary_output = "0x32394658"

[[group.output]]
serial = "0x32394658"
width = 3840
height = 2160
refresh = 60000000
position = [0, 0]
scale = 1.0
rotation = 0
adaptive_sync = false
disabled = false

[[group.output]]
serial = "0x41505846"
width = 3840
height = 2160
refresh = 60000000
position = [3840, 0]
scale = 1.0
rotation = 0
adaptive_sync = false
disabled = false
```

There still some work I _may_ need to do related to the positioning code, since it is defining the position for `0x41505846` as `3840` on `x` when in reality it is `0x32394658`, but I am doubtful a "normal" user would get impacted by that since they have never exactly been using an old implementation of `budgie-daemon v2` with an existing config before, and in all likelihood the positions would be correct on first boot without the config, and if they are not then that is something the user would fix via display configuration...and therefore the correct state would get dumped to the config. So I might be overthinking that issue.

Either way, good progress on that today. Tomorrow I'll work on ensuring the active DisplayGroup state is updated when changes are performed over DBus, then crack on with the goals listed in yesterday's post.


Light one today that was mostly spent in my own head and some pseudocode. Since I would like to start getting the daemon in the state where internally someone can just clone and run it without having to do manual work related to the config, I wanted to take some time to parse through my existing config code and figure out how I'd like to accomplish the saving / mirroring of the current output / application state (when changes are intentional) in the codebase.

I have pretty much settled on keeping an internal ref to the currently matching `DisplayGroup`, if there is one to begin with. When there isn't, we will create one based on the state of the outputs from our `WaylandOutputOrchestrator`, immediately assign that as the default, and then flush the config to disk.

My current line-of-thinking is we will only save to disk / modify our DisplayGroup (beside when there is no default) when a call is made over DBus. To me, that indicates a clear intent by the end user through _some_ tooling to perform a display change. I am going to ignore changes to modes / heads / outputs otherwise since there is no telling if the end user is using some other tool that doesn't integrate with our daemon, if it's a hardware or software problem elsewhere, or they're simply plugging / unplugging hardware.

If it were the case they were plugging in another display, chances are they're going to set it up so it is always in a specific position or with a specific resolution, in which case they would probably end up using our tooling.

Once I end up writing the Display Configuration Batch system, then I expect to only perform the flushing to disk on successful apply (we get an event for that). Otherwise you may end up in a situation where your config is messed up and it is a manual effort to recover.

Maybe there are some weird edge cases to figure out and fix, but I'll leave that to the academics and instead get more actionable feedback when it starts being put to use. So will write that out all that config code and additional bits tomorrow (it's not much really given I already have more of the serialize code as it is).

After that, my goals are pretty clear IMO:

1. Move us off sdbus-cpp and onto QtDBus. sdbus-cpp is absolutely fantastic and I highly recommend it if you aren't integrating the Qt event loop and similar bits into your C++ application or having to contend with multiple distributions with varying varsions, so please don't take the switch as some grand endorsement of one solution over another :)
2. Implement Display Configuration Batch System (alongside Set Mirror and Set Position Anchor)
3. Shift to implementing Budgie's (WIP) global shortcuts protocol so I (and hopefully others) can start actively dogfooding Budgie on Magpie v1
4. Implement gamma control (mainly for night mode to be honest)

Happy Friday all!


In [yesterday's Today's Dev](/todays-dev/15), I got configuration applying working again as well as functional setters for my DBus Server. Today, I planned on starting to mind-map a solution for a configuration change batching system.

Massive image below, I would suggest opening in a new tab and zooming in.

![](/images/todays-dev/2024/11/bd-lab-config-batch-system.png)

My _current_ line of thinking (almost certainly subject to change as I work on this) is that it all centers around a singular WaylandOutputConfigurationBatch. You create new events starting with enabling or disabling an output, which is no different than currently. If you are enabling / keeping an output enabled, you will have available the following events:

- Set Gamma: This would use [wlr-gamma-control-unstable](https://wayland.app/protocols/wlr-gamma-control-unstable-v1) for creating per-output gamma controls.
- Set Mirror Of: This event would enable you to set the specified "child" output as a mirror of a "parent" one. In reality, the way you accomplish this is just by having one output in the same coordinate space as another so they overlap.
- Set Mode: Set the resolution & refresh rate mode.
- Set Position: Probably keep this for now but plan to deprecate.
- Set Position Anchor: This event would facilitate positioning a given output (child) relative to another (parent), with horizontal and vertical anchoring. I would prefer this to replace the Set Position event already, though realistically I think both will stick around for a bit so others on the team can tinker, even though that'll make "positioning" fun. Calculating the change and end position of an output should be much simpler when it is explicitly anchoring another.
- Set Scale: Pretty self-explanatory on this one?
- Set Transform: Varying degrees of valid rotation. Uses `wl_output::transform` so there are specific values. [Doc here](https://wayland.app/protocols/wayland#wl_output:enum:transform) if you are interested.

I would expect that the change calculation would:

1. Process each output's gamma, mode, and scale events. We would make the respective zwlr output configuration head call and also calculate on our own the end-result resolution based on mode selected and scale.
2. Aggregate all position anchoring events. Calculate the total global coordinate space used by all the outputs. This will be based on the total resolution of all the chosen / current modes * scale factors - mirror events (eliminate this mode from coordinate calculation). From then, create a tree of parent to children, find left most output, calculate offsets based on that monitor.
3/ Create position calls for those heads, for those in mirror set it to coordinate space of related monitor.

Perform test or apply. If you were to test first, we would probably do some sort of result saving, so that way we don't need to re-perform the calculation on apply. If there is any event before apply, we would invalidate the result and just re-calculate on apply as if you never performed a test, assuming you don't test again. In which case around and around we gooooooo.

So that's where my head is at. Ping me on my Bluesky or Mastodon (shown below) if you have any better ideas, I'd love to hear them.


In [yesterday's Today's Dev](/todays-dev/14), I got most of the TOML-based configuration bits working against excluding the actual applying due to a segfault when trying to use the `QtWayland::zwlr_output_configuration_head_v1` returned from the configuration Object after enabling a given head (output / display). I also got the D-Bus server running again with getters returning expected data.

Today, I implemented a new `WaylandOutputConfigurationHead` class that inherits from the QtWayland one referenced above, with some camelCased methods that map to the respective method in the inherited class (e.g. `setPosition` -> `set_position`). Fixed up some `wl_display_dispatch_pending` calls for the non-pending named function and got configuration applying to work again! 🎉 Big deal after all the refactoring and work I have done.

Fired up D-Feet and started testing out my setter methods. I have validated that the following work, with some tinkering certainly needed:

1. `SetCurrentMode` - Setting the mode of an output to a different one works. I was able to change the resolution of my left-side monitor to 2560x1440. I then promptly changed it back because oh my god compared to 4k, 1440p feels so small!
2. `SetOutputPosition` - Tested changing the Y position of my left-hand monitor. It worked. Not really much to say about that one.
3. `SetOutputEnabled` - This worked when turning the monitor off but my reference to wl_registry kinda exploded for some reason when trying to turn the monitor back on, so not sure about that one yet. Could be a problem in the daemon or in the compositor. Might have to test on Magpie v1 (as opposed to current testing with labwc) to learn more.

Now that I got all of that working, I intend on starting mind-mapping a solution (using the [Excalidraw plugin](https://github.com/zsviczian/obsidian-excalidraw-plugin) within [Obsidian](https://obsidian.md/) -- highly recommend both by the way) for a configuration change batching system. There is almost certainly a better name for it, it's by no means a new idea. Effectively all my current DBus setters like setting mode, position relative to another head, etc. are all individual calls. I would like to change it so configuration changes are layered on top of each other, then firing off a "test" or "apply" event would condense all those events down (eliminating any extraneous events) into one WaylandOutputConfiguration with the changes necessary for each head.

To describe it to a "Josh before his morning coffee", I want you to imagine your typical display configuration graphical software. You have rectangles, typically with labels in them describing the displays. At first, this is based off the current state of those heads (their position, resolution, refresh rate, adaptive sync, enabled / disabled, etc.). If you want to change the resolution and position of your monitors all in one go, you'd probably set their resolution so the rectangles change size, then move them around, then click apply. You're not changing the resolution, clicking apply, moving one monitor, clicking apply, moving another monitor, clicking apply. Oh god now you've gone insane, you're closing out of the software and making a strongly worded social media post.

To make it more sane, I would want it so you'd break it down by changes to each head, request a new instance for batch configuration, send all of those over the wire, then apply it all at once. Creating a new instance would invalidate any existing one. I'm already doing something sorta similar with my config applying, I just have the luxury of being able to pre-define all my necessary config calls like setPosition ahead-of-time because I have the config. So I would expect to transform that into using the batch config system before moving on to my DBus changes (including probably the move to QtDBus).

So to the literal drawing board I shall go tomorrow!


With budgie-daemon v2 compiling and linking, today I tasked myself with hunting down the output head segfault I was getting and continuing forwards with the million other tasks I have.

The segfault fix was dead simple. My construction of my `WaylandOutputHead` was simply incorrect as I wasn't specifying the `new` operator. Derp.

So sorted that out, started digging into why my `WaylandOrchestrator` `ready` event wasn't firing. That was also pretty simple, during the construction of my `WaylandOrchestator` I was performing all the logic for getting the display, registry, adding the listener, and performing the dispatch. Well if the dispatch completes before you have the chance to connect up any callbacks for the emitted signal, guess what? You're not gonna obviously get any callbacks called for something that happened in the past. Duh, time doesn't work that way 😄

So I split out all that into an `init` method that I call after the construction of the orchestrator and setting up of connections.

Voila, all sorted.

After that, I cleaned up all the logging noise I wrote, a dead commented out function that was already implemented and used as a reference, then shifted my focus over to getting the DBus Server up and running for validating the state of my WaylandOrchestrator / Manager.

Right now, I just have the DBus Server set to start in a callback once the orchestrator is ready, however I did take a look at the [Qt6 Threads Technologies](https://doc.qt.io/qt-6/threads-technologies.html) documentation to get some ideas on what to do for multi-threading. In all likelihood, I will shift the logic of the DBus Server starting to be in a class inheriting from `QRunnable`, that way I can use `QThreadPool` to manage the threads.

Related, a topic that raised in the Buddies of Budgie standup last Saturday was the notion of using QDBus instead of sdbus-cpp. Some distributions have "too new" of a version of sdbus-cpp, as they don't have `dnf` in their repo possibly holding it back, so that would make including of budgie-daemon v2 more problematic. Furthermore, as I am already using QObject-based classes, QStrings, QStringList, etc. the integration with QDBus would be more natural.

Neither of the things above I will tackle immediately but something I will circle back to once I get configuration out of the way.

_Anyways_, the DBus Server was easy enough to get up and running. I already had functional code for that before I started the whole refactoring and it was already implmented as a class.

Fired off all my existing getter methods for the available output heads, available mode for a given head, and the currently used mode for a head. They all worked without issue. Yay!

With that out of the way, it was time to start validation of the TOML-based configuration system and more importantly, all the `QtWayland::zwlr_output_configuration_head_v1` bits I switched to. I already knew the file parsing itself was going to be fine, as I literally use that pre-refactoring version on a daily basis for applying my config, just whether or not the new QtWayland bits worked is another question.

Integrated that into a WaylandOrchestrator `ready` event callback, a separate callback from the DBus Server setup because this is exactly the cool stuff I adopted Qt6 in this specific project for. Commented out the actually applying of any configs just in case, and ran it.

_Unfortunately_, configuration doesn't seem to work and I hit a segfault with something in the QtWayland bits. Almost certainly my code, so will need to take a look at that tomorrow, then take the lessons learned from that and apply it to all my DBus Server setters. Before ending today, I swapped over all my refresh rate code to use Hz so I am not converting it to and from MHz everywhere, and I started hooking up `finished` events in various places so when modes or outputs disappear I can start handling that (config bits TBD).


But hey, pretty good day for development!



In [Today's Dev #10](/todays-dev/10), I ended the post by mentioning that I was still getting the linker issues in the QtWayland code having undefined references to the related generated C client code and header. Keep in mind, this was also something that my friend Neal and I looked at for several hours on Today's Dev #3 as well.

Well I asked in the KDE KWin Matrix room (since they seem to be the most in-depth example of QtWayland and the KDE folks are always super cool and helpful) and asked if anyone could help a guy out. [David](https://blog.david-redondo.de/) and [Xaver](https://zamundaaa.github.io/) were kind enough to jump in and take a look at my budgie-daemon v2 code. After some back and forth, David stripped the project down to literally just a `main.cpp` file and directly added the generated qtwaylandscanner sources.

That is when he noticed that it wasn't including the C/H files at all! Yea, that'd do it. Kinda hard to have a reference to functions if the files aren't being added. But why?

My CMakeLists.txt project definition specified `LANGUAGES CXX` which means it will only accept files of that given type. It does **not** warn about files it will not include. I was under the impression it'd be leveraged for checking if the tooling required for CXX was available (e.g. clang++ or g++). Nope. Not at all. But hey, today several of us learned! Removing that languages restriction did the trick!

**Finally** got it to compiling, noticed no events were coming in, fixed my `WaylandOutputManager` not actually setting the properties of `QtWayland::zwlr_output_manager_v1`, re-added the necessary `wl_` calls for dispatch and roundtrip, and started successfully getting events including a new `WaylandOutputHead`.

Just need to start fixing these segfaults! Hopefully won't be as painful as the linker shenanigans, right? 😄

This is what I would call a "failed successfully". This different kind of failure is one I seriously welcome. Massive thank you to David and Xaver for their help 👏


Well, I was expecting some sort of long post for today talking about all the cool things I did with Koto during the planned stream for today. Unfortunately, that didn't happen. Instead, everything failed and it sucked.

You see, I had decided a long while back to use my Intel Arc A770 over Oculink to my Minisforum MiniPC to use AV1 encoding for streaming. That way, my AMD hardware in the MiniPC wouldn't have to spend a bunch of compute on the stream in addition to whatever I was streaming, typically coding. Otherwise, I'd risk framedrops and stuttering, or things just freezing in general. It happened back in the day when I was streaming Solus stuff on Twitch and quickly learned to limit my all-core workloads.

So anyways, this Oculink-based solution "just worked". I needed to add `i915.force_probe=56a0` to my cmdline (added it via grubby as well) just to make sure it was really loading, and used the `i915` option `enable_guc=2` as well. But no struggles, no framedrops, AV1 encoding at the perfect bitrate. Chef's kiss.

Well one day, it just stopped working. What day? I have no idea. I don't stream every day or every week (my bad), so over the course of a few weeks _something_ on my system changed and suddenly, it just doesn't work. Reinstalling a bunch of packages, intel-media-sdk, using an older kernel, using a newer kernel, nada. Thought last night it might by the dock itself, so plugged in an old NVIDIA GTX 1060 I had laying around and that showed up! So okay, I'll just yoink the NVIDIA RTX 4070 from my desktop (now just used for gaming), install the NVIDIA driver from RPM Fusion alongside the cuda bits, and I should be golden. Right?

That's what I thought at first too. I had to disable Secure Boot to get the module to load and not fall back to nouveau, but it showed up in OBS Studio and I was able to configure it to be the same as what I had for AV1 on my Intel Arc. Set bitrate to 8000 Kbps. Turned off Look-ahead and Adaptive Quantization, set Multipass Mode to Single pass. Tested out with recording and hey 60fps, everything is good.

Fired up the stream and immediately tanked to 45FPS. Okay I didn't hit that "go live" button yet, no problem. Stopped streaming, changed preset to P4: Medium quality, dropped bitrare to 6000Kpbs (still perfectly fine for AV1), tried again and it was 60FPS. Weird that a GPU theoretically much beefier than my A770 was struggling and the A770 wasn't breaking a sweat, but hey NVIDIA always sucked under Linux so chalk it up to that right?

Cool well anyways, let's go live.

Start moving around windows and talking. 25FPS. Constant buffering in the stream itself.

Shit.

Okay well I have one last option then otherwise I'm up shit creek without a paddle. Switch video encoder to OpenH264 so it uses my MiniPC's CPU encoder. I'll just be careful to not have too much open and ensure I don't do all-core workload of compiling and limit it.

YouTube doesn't take the encoder change at all. Understandable, switching codecs would probably not go well, but it's all I had. Frames were going out but YouTube kept saying "no data".

I don't think it's the first time I have ever cancelled a stream. There may have been some Solus ones from years and years ago that I may have. None that I can recall. But the Intel, NVIDIA, and YouTube gods didn't bless today. I guess I didn't pay my Intel tax (haven't bought anything after 12th gen), NVIDIA tax (bad Josh for only getting a 4070), nor did I get YouTube Premium. Mea cupla my trillion dollar company overlords, I will do better next time.

Guess I'll be setting up some unlisted streams throughout the week and testing out the integrated media encoder in the AMD Radeon 780M in my minipc, at least until I am able to figure out what the heck is going on with my Intel Arc detection. Hopefully the AV1 encoder in that will be sufficient, or god forbid I have to stream it at 1080p instead of 1440p or 4K. Oh no the humanity! /s

But for today, that's enough of complex technology. I think I will do some much needed pruning of my chili plants instead.



Short Today's Dev this time around. Brain is cooked and want to chill before tomorrow's [Koto development stream](https://www.youtube.com/watch?v=GxQO1-6wGEo). Neal Gompa, contributor to infinite things, has been helping the team test our Wayland support by creating a (currently internal) repository of Wayland session files. This has our session files for magpie (v1), labwc, KWin, and as of today [Miriway](https://github.com/Miriway/Miriway/).

Tested Budgie Desktop under Miriway and unfortunately there were some issues, but it wasn't as broken as I thought it'd be.

1. It does not seem to support zwlr_output_manager_v1, which means my displays end up getting duplicated and I can't fix that with my budgie-daemon v2 (before the refactoring, I have a binary and config I apply with it). Apparently they have their own config but it'd be nice if they just supported the protocol and had the file be the backing storage for the configuration.
2. It does not seem to support ext_workspace_manager_v1, which I think ends up breaking libxfce4windowing and results in windows not having information reported about them, thus just showing up as a generic icon. Hopefully this'll get fixed when [ext-workspace](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40) gets merged and everything moves to that.
3. Noticed some applications like Discord and Visual Studio Code crash as well, so had to swap back to labwc to finish this blog post. Some teething pains for sure, maybe XWayland related, and when I have the time I'll see about getting some useful information and filing it with the Miriway folks. That said, layer shell support does work as expected. Budgie Panel shows up in the correct location, popovers from the panel correctly position, and Raven renders without issue!

The experience of being able to just drop-in replace one compositor for another, assuming both support the required protocols, and things "just" work is nice to see in practice. With labwc and magpie v1, that is to be expected since both are based on wlroots, but seeing it from Miriway for the parts it does support, is refreshing and a bit inspiring. I'm excited to see where Miriway goes and hopefully as the ecosystem evolves, Budgie Desktop will able to run well on it. The more choice for consumers of Budgie Desktop, the better!


Today's development was once again focused back onto budgie-daemon v2. In my [Today's Dev #7](/todays-dev/7), I left off with saying that my next step would be to implement a function on my output orchestrator or manager that'd create dummy head configurations to avoid protocol errors. Well, I did that, and more!

The first thing I did was move my `configure` method out of my `WaylandOutputHead` class and into the `WaylandOutputManager` to facilitate multi-head configuration happening in one batch (this is good for the first start of the application since we'll read our config and apply any matching display group configuration wholesale).

I was able to simplify the creation of my WaylandOutputConfiguration class to pass in the `QtWayland::zwlr_output_configuration_v1` that I was creating in that `configure` function and cleaned up that class to now have:

- `applySelf`: Dumb name that literally just calls `apply()` on the `QtWayland::zwlr_output_configuration_v1` without any sort of conflict or recursion. Better name suggestions welcome. No applyMcApplyingface.
- `enable`: Now takes the `WaylandOutputHead` so we can enable that specific head. This replaces the mistaken `setHead` that'd basically only allow for one head to ever exist on a config, which was simply not the correct approach.
- `disable`: Now takes the head as well. Does what it says on the tin.
- `release`: Another dumb name that just calls `destroy()`. "destroys" the config which is needed before you perform the display dispatch pending. That one took a bit to make sense the first go-around with the display configuration.

Did some further cleanup of using zwlr types as part of the constructors instead of wl_registry + id + version. Nothing particularly notable but now the constructors don't look like ass, so that makes me very happy.

Okay, so things are a bit saner now. Times to make sure I carry over that sanity to the DBus Server methods, right?

Started out by implementing `applyNoOpConfigurationForNonSpecifiedHeads` function on my `WaylandOutputManager`. Better names welcome, feel free to ping me on my Bluesky or Mastodon. This method takes in the `WaylandOutputConfiguration` we are wanting to apply head enable / disable configurations to, and a `QStringList` of the serials of the heads we don't want it to touch. Any serial not in that list will then enabled or disabled (no actual change is made) to avoid protocol errors. So instead of plastering 8 lines of code everywhere, it's just one function call.

Went through all my existing DBus Server methods and now each one of them uses my not-terrible code (IMO):

- `SetCurrentMode`: Attempts to set the provided output serial to the provided width, height, and refresh rate. This will find any matching mode on the head, if one doesn't exist it creates a custom mode.
- `SetOutputPosition`: Sets the provided output serial to provided x and y coords. Surprised you on that one, right? /s
- `SetOutputEnabled`: Sets the provided output serial to being on or off. Monitor turns on, monitor turns off. Can't explain that.

There _will_ be more but that is something I will circle back to...well once everything else works **again**.

Lastly, I updated the display configuration (like literally the logic for apply the config file for the displays) to use all the new C++ classes and methods. Trust me, it's way cooler than it sounds. The code looks great now.

Tried to compile and still getting those damn linker issues. I think I might prod some gems in the KDE community about it tomorrow to see if they can spot any stupidity being done on my part. Once I can get it compiled and linking, I'm going to move on to debug printing what my `WaylandOrchestrator` thinks is my output state. Once that's all validated I'll hook it up via Qt's signal / slot fanciness to apply the configuration. Then we'll be back to square one before all the refactoring and Qt6-ifying.

That's it for today! Happy Friday!