Regarding trackpad issues: for me it’s working consistently, except when using ZFSBootMenu, in that case it neither works or gets detected at all, I suspect it’s due to the kernel not properly cleaning up the i2c bus state before kexecing the new kernel
Issue is no longer present for me. I believe it was only “resolved” with a workaround, but it works.
Has anyone with the dGPU tried using visual studio code running in wayland?
On my system, running visual studio code in wayland keeps the dGPU active instead of suspended, increasing power consumption.
For me it just acts like any other electron and chrome app. Wakes dGPU up for a few seconds when I launch or close it. All other times the dGPU remains in sleep.
Is anyone else on KDE having a problem with their lock screen going to a black screen if you try moving the mouse (waking it up) right at the moment it tries to lock? When this happens to me the only way to get back to a usable desktop is to kill -9 the process kscreenlocker_greet.
1 Like
Yes, this exact issue. The way I’ve gotten around it is using the fingerprint scanner to unlock the screen.
I had a similar problem happen due to issues with the fingerprint unlock process. I ended up having to use loginctl on another terminal to unlock the system. The problem went away (I think/guess/hope) when I deleted my fingerprint login profile.
Same with Arch and KDE, I just type my password and hit enter it’ll return to desktop
You can also Ctrl+alt+F3 then Ctrl+alt+f2
That’s what I see when I run it in XWayland. But for some reason, when running in Wayland (environment variable ELECTRON_OZONE_PLATFORM_HINT=wayland), it keeps the dGPU active.
It looks like electron apps using the dGPU instead of the iGPU is a common enough issue: Force integrated GPU · Issue #9842 · electron/electron · GitHub
I tried --force_low_power_gpu, but it doesn’t seem to work for VS code.
For now, I’ll have to use --disable-gpu to disable gpu accel. in VS code.
Hi all. Did the commonly advised thing and disabled secure boot in the BIOS to install Arch. It’s all working now, but doesn’t boot if I re-enable secure boot.
Do I have to leave this off permanently, or is there a way to get it to cooperate with what I’ve installed? Thanks.
You would need to roll your own keys if you want to use Secure boot
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
First question is…why do you even want to enable it without setting it up? What’s your use case?
Yep, that’s a fair question. The answer is I’m not really sure, but it sounded like something that should be switched on. I’m not that familiar with the more involved aspects and features of the BIOS these days.
My drive is encrypted and I’m hoping to get to the point that I can use the fingerprint reader to unlock it on boot, instead of having to type in the pass phrase every time, and I’ve got the vague notion in my head that secure boot needs to be enabled for the TPM stuff (something else I’m not familiar with) to work, which I will probably need.
Or something like that.
That’s the problem, nowadays the word “security” is way overused, so you really need to do you own research instead of blindly believing what you have been told.
My understanding is that secure boot protects a device against running malicious code during boot, before other protective measures can be taken. Whether or not this matters will depend on your threat model.
I leave it off.
Ideally? Yes. Realistically? Probably not worth the effort.
This is accurate. The point of Secure Boot is that all of the boot items (like initramfs and grub configurations, etc) have to be signed by a key that is trusted within the UEFI configuration. If any of the boot item signatures don’t pass validation, then the boot will fail out.
Not only would you need to configure the UEFI system to enable Secure Boot, you also have to create a key-pair, mark it trusted, sign all of those files, and ensure that the BIOS/UEFI system is protected with a strong password. Not doing all of these things reduces the benefit of this protection. Its not a protection if one can just go disable it because you didn’t secure your BIOS login…
While I don’t think most people are going to be hit by something that Secure Boot would prevent, it really is up to you and what your particular threat landscape is. If you’re just a person with a laptop, it’s likely not worth the effort… If your a CEO working at a company worth millions/billions, then yes, it’s absolutely worth the extra layer of defense; having your system popped at that level is WAY more impactful than having an IT guy enable these features for you.
Everything in security is about layers, risk and threat models. It’s up to you to determine what you’re willing to do, and what level of risk you’re willing to accept.
I think full-disk encryption is more important than secure boot (in this example). It can’t be bypassed in BIOS and it’s more likely you’ll forget your laptop somewhere where FDE can help to prevent data-loss.
If you do want to enable Secure Boot, the Arch Wiki has a good primer on the topic (I know it was linked already), but you may need to more googling to get all of the way through the process. It’s not easy, and you’ll have to maintain the process as new kernel updates are released as you have to keep signing all of the boot files. I think there’s a suggestion for a pacman hook that can help in this.
Fair call, y’all. Thank-you for the feedback. Not going to stress about secure boot.
Secure Boot is really not that good and essentially forces you to use Windows or Ubuntu. In fact that’s it’s sole purpose.
1 Like
Firefox fails to use a dedicated GPU 
When I run Firefox, it usually works fine using an integrated GPU. Both 3D render and video decoding are working fine, but if I try to run it with “DRI_PRIME=1”, I get the next error:
$ DRI_PRIME=1 firefox
[GFX1-]: glxtest: ManageChildProcess failed
[GFX1-]: No GPUs detected via PCI
And it starts to use the CPU to decode video 
Does anyone know what the issue maybe?
P.S. Steam games and Minecraft uses dGPU with “DRI_PRIME=1” no problem