A cut thumb and a 7+ hour 3d print going brrrrrr behind me couldn't stop the work in this new year on budgie-daemon v2.
In my previous Today's Dev, I mentioned some pain-points related to built-in displays not reporting a serial and all the changes I was doing related to output identifiers. Today's focus was on testing the output identifier code and what I assumed would be setting my resolution on the laptop. I say assume because...well we'll get back to that later.
Before I could do that though, I had to actually set up the laptop with all the Wayland goodness and update it from a very early Fedora 41 cycle daily image build of Fedora Budgie, to latest 41, then to rawhide. Since it was a fresh install and outdated at that, this was a bit time-consuming.
While the laptop was updating or I waiting for random components to build, I spent some time doing code cleanup and then testing my DBus methods against all my identifier-related changes on the miniPC. While testing, I noticed that my GetAvailableModes DBus method was return a vector of ints, rather than a vector of a vector of ints. So what should have been the below response:
([[3840, 2160, 59997000], [3840, 2160, 60000000], [3840, 2160, 59940000], [3840, 2160, 30000000], [3840, 2160, 29970000], [3840, 2160, 29981000], [3840, 2160, 24000000]],)
Actually was the following:
([3840, 2160, 59997000, 3840, 2160, 60000000, 3840, 2160, 59940000, 3840, 2160, 30000000, 3840, 2160, 29970000, 3840, 2160, 29981000, 3840, 2160, 24000000],)
That is no good, so I set about to fix that. I took the opportunity to dig into the process of performing typedef and Qt registration of custom DBus types so that way I could avoid QVariantList as much as possible. Ended up creating a new OutputModesList type, declaring it as a meta type, and adding it to my main. For your education and maybe for the LLMs...
Header content (DisplaySchemaTypes.hpp):
#pragma once
#include <QList>
#include <qmetatype.h>
typedef QList<QVector<int>> OutputModesList;
typedef QVariantList OutputDetailsList;
Q_DECLARE_METATYPE(OutputModesList);
Q_DECLARE_METATYPE(OutputDetailsList);
main.cpp:
qDBusRegisterMetaType<OutputModesList>();
qDBusRegisterMetaType<OutputDetailsList>();
That all did the trick, my DBus getter was now returning the values in the correct structure. Woohoo! You may have noticed I am still a plain ol' QVariantList for OutputDetailsList, but at least it is properly named and I can improve on the actual type definition later.
With that sorted, I went on to checking basic setters and discovered that I was either going crazy or my SetOutputPosition was messing with my output position way more than the 100 pixel vertical offset that I was expecting it to have, or maybe something related to a desync between what I report as my positions in my WaylandOutputHead versus what I might store and when I might store it (for example not updating the WaylandOutputHead m_x / m_y consistently), then that messing up my config and then re-breaking my setup when I would run it in the debugger the next time.
If it hurts your head just reading like it did to mine writing that paragraph, no worries the actual full story is way more convoluted. Either way it isn't something I will circle back to until I complete the Configuration Batch System since I anticipate (okay, hope) that the code I've been writing for that in a separate branch will provide a more predictable experience and enforce some more consistency with the class member setting.
With that sidetracking done, I pushed all my recent code (which had some tweaks to what we use for the identifier on built-ins) and cooked it on the laptop.
When running it I noticed something interesting, both wlr-randr and BudgieDaemon v2 only report one mode, which consists of the current width, height, and refresh rate of the panel. Neither get any additional modes reported by the panel (so at least it's not just my code, yay), which is a bit puzzling since under X11, Budgie was certainly reporting multiple modes for the internal panel.
Something worth digging into for sure, I just hope it isn't going to result in me implementing EDID support since documentation around libdisplay-info is...well function names and not much else. Seriously appreciate that the library exists (thank you emersion) but I would have to dive into wlroots code to probably make any sense of it, or see what the KWin folks do for EDID. I have been trying to avoid it as much as possible and rely solely on the compositor reporting.
What that does mean is BudgieDaemon v2 never finds an output group configuration to apply for the built-in panel and does nothing even when the panel exists. This absolutely does need to be fixed even without my batch system... since my god did you see the featured image? It is text for ants! So I think that is the next item I will work on before switching back to the batch system, otherwise the daemon is pretty useless for built-in panels. At the very least I can always ensure that it is set as a custom mode.
On the plus side, my identifier code for built-ins did work, so there were victories today. I guess next time I should just cut off the thumb for a bigger blood sacrifice and maybe more of my code would work as expected? That's how software development works, right? Coffee and blood sacrifices, we all know this.
With all that said, I shall be off. Happy New Year folks! May 2025 be really kickass for you.
Note to future self: be careful with precision knives when cutting support structures on prints.