Anyway thank you very much

"Simply putting the .EXE file on a FAT32 USB was all it took to get the BIOS update flashed. That Dell support provides a .rcv file also is what made this so confusing. "

So the UEFI firmware is all updated, but the TPM is still out of whack.

Given the opportunity, I'm trying to get the whole system buttoned up with a non-Microsoft key so that SecureBoot will work better, and then sign the UKI.

Not trying to do a downgrade/package regression.

If I run sbctl to create new keys without using Microsoft's key, that'll lock me out, right? So I have to back up the EFI variables before doing that. Then I can remove the Platform Key and create a new set of keys that'll get stored as PCR values.

Just gotta read through the Secure Boot Wiki entry.

I guess efitools is the way to go to pull the Secure Boot variables that the computer was shipped with.

But when I download efitools and run the command to pull the EFI variables:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done
Variable PK has no entries
Variable KEK, length 3906
Variable db, length 8533
Variable dbx, length 22138

It looks like the Platform Key is missing? Where is the platform key stored?

EDIT: actually now i think about it, the app is still working and can function without the gui if configured correctly so i guess the gui is optional technically

This has worked flawlessly until recently.

Does it still work w/ the LTS kernel? (if you can get a working setup we can look for differences, maybe the HW is captured by a different kernel module now)

But you'd have to replicate the failing setup to analyze what's going wrong.

Here's what happens when udev evaluates those rules:

$ udevadm test /sys/class/power_supply/BAT0
...
Loading udev rules files done.
BAT0: sd-device: 'uevent' sysattr contains invalid characters, refusing: DEVTYPE=power_supply\nPOWER_SUPPLY_NAME=BAT0\nPOWER_SUPPLY_TYPE=Battery\nPOWER_SUPPLY_STATUS=Charging\nPOWER_SUPPLY_PRESENT=1\nPOWER_SUPPLY_TECHNOLOGY=Li-poly\nPOWER_SUPPLY_CYCLE_COUNT=44\nPOWER_SUPPLY_VOLTAGE_MIN_DESIGN=15440000\nPOWER_SUPPLY_VOLTAGE_NOW=16236000\nPOWER_SUPPLY_POWER_NOW=28656000\nPOWER_SUPPLY_ENERGY_FULL_DESIGN=52500000\nPOWER_SUPPLY_ENERGY_FULL=54590000\nPOWER_SUPPLY_ENERGY_NOW=26580000\nPOWER_SUPPLY_CAPACITY=49\nPOWER_SUPPLY_CAPACITY_LEVEL=Normal\nPOWER_SUPPLY_TYPE=Battery\nPOWER_SUPPLY_MODEL_NAME=LNV-5B11M90028@\320\nPOWER_SUPPLY_MANUFACTURER=Celxpert\nPOWER_SUPPLY_SERIAL_NUMBER= 2026
...

There's a trailing \320 character on my battery's POWER_SUPPLY_MODEL_NAME property which causes it to be refused.

There's an open issue with systemd with a submitted patch that I believe should address my problem here.  I'll wait until that makes its way into Arch's systemd package and confirm if so.

Idea: an AUR repo, to upload directly built packages

Idk why people re-invent ideas, and at some point they are creating problems to solutions.

Edit:

bindl = , XF86AudioMute, exec, wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle
# Audio Input Mute (Microphone toggle)
bindl = , XF86AudioMicMute, exec, wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle

Do the wpctl commands do what you expect?

I'm pretty sure 5GHz is faster'm pretty sure 5GHz is faster

The band has only indirect impact on the performance, heavily depending on the physical environment.
802.11a is however for sure not faster than anything specified in the last 25 years.
You'll now be using ac or ax, maybe n.

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

The eDP is the internal panel and typically wired to the IGP, but disabling the IGP in the BIOS would usually re-wire the eDP to the GPU (though it's common that the output name changes)

Uh, my bad. In my mind eDP sounded like external Display Panel/Port/Pasta or something? Oops. That's right, I tried this in the past with supergfx. It would rewire the eDP to the GPU and yes, it worked ok.