Fedora - changes in pp_table don't persist after restart

[admetus@sopuli.xyz]

I also said pp out aloud and chuckled like a little boy.

[electrolisa@lemmy.blahaj.zone]

My knowledge here is limited so I apologise if I'm not being helpful, but at least in case of Arch there's a special kernel flag (amdgpu.performancemask iirc) to allow OC of your graphics card, are you passing one in your setup?

[werecat@lemmy.world]

Yes I do otherwise I wouldn't be able to OC.

I have to enable it after every Kernel update.

[werecat@lemmy.world]

I'm sorry but I don't believe you. Maybe you just misunderstand what I've meant.

If you minimize it and press Super key, is it shown or it's completely gone?

[ryannathans@aussie.zone]

Completely gone, only exists as an icon on my top bar

I can click show, get a window, and click hide and it goes away fully

I have it start on boot so my profiles auto apply when I start various apps

Would a screenshot be more convincing?

[werecat@lemmy.world]

I also had it start on boot but I never could minimize it to be non-intrusive and from what I've researched it's apparently very known issue in GNOME.

I don't have this issue with LACT.

[Guest]

Udev is the best way to add persistent values for pretty much everything in the sysfs. That being said, it can be a bit obtuse when first learning about it. Here are some tips

udevadm test /sys/path/to/device will tell you if your rule is running and what the state is at each step. You'll want to look at this before you start so you can see when your rule should run

udevadm info /sys/path/to/device will tell you what the PROPERTIES of a device are. These are usually set by hwdb files to inform userspace programs about the details of a device.

udevadm info /sys/path/to/device --attribute-walk will tell you about the ATTRIBUTES of a device and all it's parent devices. These correspond to the character file endpoints you are setting currently. You'll want to use these to write your match rules and set the values.

udevadm monitor can be used to watch for udev events to let you know if you should match on add, change, and/or remove.

Udev rules work as a cascading match system and they run in numerical and directory order. E.g. /usr/lib/udev/rules/60-keyboard.rules| will run before /etc/udev/rules.d/62-keyboard.rulesbut after/etc/udev/rules.d/60-keyboard.rules`

For user defined rules you will want to put them in /etc/udev/rules.d/ and keep in mind any state that needs to be set before or after your rule.

Matching happens with == or !=, setting attributes is done with =, +=, -=, or :=. := is really cool because you can use that to block changes from downstream rules. E.g. MODE:="666" will make the matched attribute r/w from unprivileged users, even if a later rule tries to set 400.

Udev rules will run in order in a file, but each rule must be a single line. Each attribute will also be set in order of the rule if setting multiple attributes in a rule. Multiple rules can be useful if you need to set attributes on multiple levels of a device, or in sibling directories.

For a complete breakdown of everything, see the udev manual: https://man.archlinux.org/man/udev.7

I also have a guide on one of my (currently out of tree) drivers that has some examples. https://github.com/ShadowBlip/ayn-platform?tab=readme-ov-file#changing-startup-defaults

Let me know if you have questions.

[Guest]

You need to have this extension or similar to be able to minimize to tray on gnome: https://extensions.gnome.org/extension/615/appindicator-support/

[evil_shrubbery@lemm.ee]

Grow up (enough) and adjusting your pp becomes a chore.

[ryannathans@aussie.zone]

That'd do it, standard inclusion with my distro