SavvyBeardedFish

joined 1 year ago
[–] [email protected] 4 points 1 week ago* (last edited 1 week ago) (1 children)

If all nodes are connected through ethernet to each other (or at least one common node) you could go for OpenWRT's 'Dumb AP' setup as well

Edit: Already mentioned here; https://feditown.com/comment/1980836

[–] [email protected] 8 points 1 week ago* (last edited 1 week ago) (2 children)

Maintainer has been absent for some time so kernel v6.11 and v6.12 isn't supported OOTB, to get it to work with kernel v6.11 you need to pull the fix from: !48

[–] [email protected] 7 points 1 month ago (2 children)

If I remember correctly the default sudo timeout is set to 5 minutes on Yay, you should be able to increase it to something more reasonable

[–] [email protected] 1 points 2 months ago (1 children)

Additionally you can try and force use amdgpu rather than radeon, by setting the kernel flags:

radeon.cik_support=0 radeon.si_support=0 amdgpu.cik_support=1 amdgpu.si_support=1 amdgpu.dc=1

Source

[–] [email protected] 1 points 2 months ago (2 children)

Device initalization failed according to the Xorg logs;

  1. Dump your firmware version
  2. Dump your kernel version
  3. Dump your kernel logs (dmesg or journalctl -k)
[–] [email protected] 12 points 2 months ago (8 children)

Question is gonna be whether they can scale their DUV process, or if they have to get to EUV (without ASML) the next couple of years

[–] [email protected] 6 points 3 months ago

No bios update, but you most likely received both microcode updates (which is what will fix/mitigate the Intel issue, the bios is only to ensure everybody gets the microcode update) and firmware updates (from linux-firmware)

Of course non-mainlined (i.e. not in the linux kernel) firmware is a bit more iffy, luckily it's getting slowly better with OEMs using fwupd for those scenarios

[–] [email protected] 11 points 3 months ago (1 children)

Could it be an issue with the Nvidia drivers, boot with acpi=off and then install the (proprietary) nvidia drivers and then reboot to see if it boots normally now?

[–] [email protected] 6 points 5 months ago* (last edited 5 months ago) (2 children)

Running: swaymsg for_window "[app_id=mpv] opacity 0.5"

Works as expected on my end, are you missing just executing for_window?

Note, you can also add multiple rules in the same execution, e.g.

for_window {
    [app_id=mpv] opacity 0.85
    [app_id=LibreWolf] opacity 0.85
}

Also, note that app_id of LibreWolf is capitalized in that manner. You can get that information [app_id, shell etc] by running swaymsg -t get_tree

[–] [email protected] 6 points 7 months ago (2 children)

Feel like most people still do the scripting in Bash for portability reasons, and then just run Fish as the interactive shell

[–] [email protected] 17 points 7 months ago (2 children)
[–] [email protected] 1 points 8 months ago (1 children)

Nice, then you should be able to run vkcube to verify whether your GPU is activated properly.

You can do several "iterations" here as well.

  1. Install Mangohud so you can visibly see if your GPU is activated correctly
  2. Run mangohud vkcube-wayland - Does it use your Nvidia GPU?
  3. Run mangohud vkcube - Does it use your Nvidia GPU?

If Step 2 nor 3 shows your Nvidia GPU you can try and force it with: mangohud vkcube-wayland --gpu_number 0

view more: next ›