Setting Text Scaling in dconf causes it to not be removable in Accessibility menu on Gnome 45

[rlad78]

I recently rebased from Fedora Siverblue 39 to uBlue Silverblue Surface 39. Upon restarting, I noticed my text was way too large and an Accessibility menu was now on the right side of my top bar. I tried the following:

• Toggling the Large Text option in the top bar Accessibility menu
• Toggling the Large Text option in Settings -> Accessibility -> Seeing
• Toggling the Large Text option in the top bar Accessibility menu in GDM when logged out
• Restarting my system after doing any of these

The setting is defined here:

surface/system_files/silverblue/usr/etc/dconf/db/local.d/01-ublue-surface

Lines 1 to 2 in d5b585a

	[org/gnome/desktop/interface]
	text-scaling-factor=1.25

I had to change the setting back with:

gsettings set org.gnome.desktop.interface text-scaling-factor 1.0

You can read more about this bug with text scaling in Gnome 45 here.

[castrojo]

Ok I've PRed that fix and noticed the tlp comments in that upstream bug, so I've PRed a fix to switch back to the default for that. Your comments mention other issues, would you mind filing them so we can fix them?

I got a bunch of positive feedback at KubeCon when people learned we have them so hopefully going to have more dedicated maintainers for the surface images, also feel free to PR fixes if you have them!

[rlad78]

@castrojo thanks for the quick turnaround on this! Apologies if I came across a bit crass in the upstream issue. I've read through what you guys have done with uBlue and the impressive automation system around it. Really appreciate the work you all have put into this project. I was just a little frustrated at the time because, without the linux-surface patches, my laptop fails to resume from suspend.

Honestly, the only other reason I didn't want to recommend this to other Surface users is because of the sheer amount of variance between the different Surface devices. For one example, some models have a detachable or unique keyboard that requires its own driver. In order to use disk encryption on these models, you have to load the specific driver modules from the surface kernel in your initramfs so that you can type in your passphrase during the boot process (see here for details).

To be fair, a lot of the quirkiness between the devices is up to the user to research and resolve. I just can't predict how rebasing to a new image will affect their system, which is why I didn't want to recommend it as a simple workaround. I'm running a Surface Laptop Go, which is relatively simple when it comes to Surface devices. If a Surface Book 2 user has initramfs regeneration enabled through rpm-ostree initramfs --enable --arg=/etc/make/keyboard/work, I would like to think rebasing to the uBlue Surface image wouldn't mess any of that up, but if it does, that user might not be able to decrypt their disk in order to bring up the system.

With the text scaling issue being fixed and tlp being removed though, I'm tempted to retract my statement and recommend rebasing to uBlue Surface as a potential workaround. My fear of causing issues for other Surface users might have made me a bit over-critical. At least for the Surface Laptop Go, I haven't run into any other issues.

Edit: I just noticed you guys are already working on including the initramfs modules!

[castrojo]

Yeah no worries, most of our effort has been on the base images and we're now starting to get to other parts of the project. I find Surfaces challenging too (I can't even figure out which one to get!)

I think it's just a matter of test coverage, as people report different devices we can set it up to work ootb on as many as we can. And for the weird edge cases we can probably at least get them most of the way there. Keep filing as you see them and we'll keep iterating, thanks for your patience!