anyone else having issues with the last update?

[skyfishgoo]

my understanding was just changing the setting file (either method) doesn't work past a reboot because plasma keeps putting the [$d] back into the file which screws things up again.

but if others have tried that and it works, then it seems a rather simple workaround... one and done.

[claydoh]

my understanding was just changing the setting file (either method) doesn't work past a reboot because plasma keeps putting the [$d] back into the file which screws things up again.

but if others have tried that and it works, then it seems a rather simple workaround... one and done.

It did work for me, but as mentioned, I did not see it on my LTS-LTS upgrades. Only fresh install and a Questing upgrade. My upgraded PC's config even has those [$d] in the kwinrc.

BUT: the proper fix is just waiting for an updated Frameworks 6.24.1 bugfix release. Which has no ETA yet afaik. The benefits of the new LTS status for Plasma 6.6, Frameworks 6.24, and KDE Gear 25.12

[skyfishgoo]

so what is the purpose of those [$d] strings?

is this some new way of managing settings that nest in other variable (from where) that we cant control

i don't like it.

[Snowhog]

my understanding was just changing the setting file (either method) doesn't work past a reboot because plasma keeps putting the [$d] back into the file which screws things up again.

AI Overview

In KDE's configuration system, the [$d] flag stands for default. It tells the configuration parser to ignore the local setting entry, stop searching lower-priority configuration tiers, and fall back to the application or system-wide default value.

What [$d] Means

• Ignore Local Setting: It treats the key as if it has no explicit user override.

• Fallback Trigger: It instructs KWin to use the built-in default behavior for that specific property.

• System Settings Interaction: It often appears when a user tries to toggle or reset a feature back to the system's baseline configuration layer.

How to Fix or Change It

If an effect like translucency keeps resetting or behaving unexpectedly due to this flag, you can explicitly force it to a standard boolean state:

• Edit your ~/.config/kwinrc file using a text editor (like Kate or Nano).

• Locate the [Plugins] section.

• Change translucencyEnabled[$d] to either true or false depending on your preference (e.g., translucencyEnabled=false).

Also see https://www.reddit.com/r/Kubuntu/com...s_after_every/

[skyfishgoo]

i get it, so the intention is that unless the user has changed the value, the key is defined by the default, probably owned by root somewhere.

but when user DOES change the value, it is supposed to write a new value to the settings file and replace the [$d] with the user setting.

THIS seems to be the part that has not been working in these bug reports, as the [$d] remains in the file, or nothing is written at all.

[skyfishgoo]

update.

a patched version has been posted on the bug report, and i can confirm that with the new package installed there are no issues after a reboot.

linux-firmware/now 20240318.git3b128b60-0ubuntu2.29+lp2163303 amd64 [installed,local]


do i leave this package with the bug report number in the package name installed or do i revert back to the older repository package and wait for this to come down in discover?

fyi discover currently says i'm up to date and i've released the apt-mark hold on the older package

[claydoh]

do i leave this package with the bug report number in the package name installed or do i revert back to the older repository package and wait for this to come down in discover?

I would keep if for now, a new updated package *should* bump the version number to replace this, the build number 0ubuntu2.29 should rise to 2.30 or similar irrc, so *should* replace this temporary package. I'd keep an eye on the bug report to see if an updated package is built and offered in -Proposed for proper and official testing, which would indicate it is coming to the standard archive soon.

[skyfishgoo]

thanks, that's confirms what they said as welll... but they said it might be a while

any thoughts on how this package might impact my ability to upgrade from 24.04 to 26.04 when the upgrade become available?

[claydoh]

I can't say for sure. The versioning there is definitely higher so theoretically things should be fine for upgrades, but i'd revert it directly before upgrading just to be safe.

[skyfishgoo]

well i intend to take a snapshot before upgrading so i'll take one with this package and one with the older package and apt-mark hold so it doesn't show up in dolphin

if one upgrade path doesn't work, perhaps the other one will.

[skyfishgoo]

the fix has been posted to the noble-proposed repository

you can add the repository by running sudo software-properties-qt

and checking the Pre-Release updates box on the Updates tab, then close the window

once the new firmware packages are in installed you can go back in and uncheck the box

[claydoh]

It looks like they are pushing out the updated linux-firmware packaging layout to Noble along with a kernel update, so I guess that the full fix is in.

[skyfishgoo]

yup all done.

on the new kernel, with the new split firmware suite of packages and just rebooted... all is well in kubuntu land again.

ready for the 26.04.1 upgrade now.

[vanadiumboy]

It works right again. I plugged in my AMD RX 6800 16 GB