Firmware is not the same as driver. Your AMD card will perform very poorly without the firmware.

https://media.kasperskycontenthub.com/w … nswers.pdf

The risk level is very low for that sort of exploit, especially compared to something like Firefox or Chrom{e,ium}, but the motherboard hardware controllers contain blobs and some of them can be rather complex.

Sounds like a compositor issue, check ~/.xsession-errors for clues.

If the backlight problem is now fixed then please mark the thread [SOLVED]. If you want to continue with the screen corruption issue then open a new thread, thanks.

Oh really? In which case sorry for the misinformation. I've never actually tried xdm.

EDIT: hold on, did you source ~/.profile before the exec dwm line? Nothing in that file will be read after an exec statement.

And ~/.xsessionrc isn't really intended as a replacement for ~/.xsession, it is an adjunct to that file.

Devuan's display managers should automatically start whatever is set as the x-session-manager alternative with no need for further configuration, or /etc/alternatives/x-window-manager otherwise.

How did you install dwm? Is it the Devuan package or did you compile it yourself?

If you're also experiencing the flicker in the console then it's nothing to do with the compositor or the DDX driver.

FWIW your X.Org log shows that X.Org's builtin modesetting driver is being used for your Intel iGPU.

I really don't know anything about NVIDIA (I would never give money to that company) so I can't help with that, sorry.

Popcon is opt-in — the installer asks the user but the default reply is "no".

Mozilla's guide to enabling better privacy is here: https://support.mozilla.org/en-US/kb/ho … onnections

They're a bunch of deceptive bastards though because that page makes no mention of their Beacon API, disable that in about:config.

Not necessarily, Firefox are moving towards enabling DoH by default: https://support.mozilla.org/en-US/kb/fi … over-https

Looks like nano was trying to write to a backup for the brightness file, not sure why. It works on my system if I ensure that it's saving to the actual backlight file.

Note that the max_brightness and actual_brightness files can't be changed so that result is expected (sysfs doesn't work like normal filesystems, it is virtual in nature and just exposes kernel values to user space).

No idea why my tee & echo suggestions didn't work though. At a guess it's because you don't have a kernel module loaded for your video card.

You're already loading non-free firmware from Devuan for your Intel wireless card. Your UEFI firmware, CPU management engine and hard drive controller are all running blobs anyway. There is no escape...

That's an interesting find but I'm pretty sure that the backlight will be controllable once you have a video driver loaded.

AMD cards require KMS and that needs a kernel driver.

That's an unusual way to modify the file but it should work (it did when I tried it in my Alpine Linux box). What actually happened when you tried? Did you see any error messages?

Do my suggested echo commands work?

Looks like the amdgpu module is available but not loaded. Without a loaded kernel module your system will fall back to the VESA driver, which will offer poor performance and may be the reason why you're having trouble with the backlight.

Try adding radeon.cik_support=0 amdgpu.cik_support=1 as a kernel command line parameter to force the amdgpu module for your card.

Also check that you have installed the firmware-amd-graphics package, that will be needed for full performance.

Your configuration file is forcing the wrong driver for your card, it needs amdgpu(4) rather than radeon(4).

No need to be embarressed, everybody makes mistakes :-)

If you share the problem and your solution here it may be useful if others also make the same mistake.

I really don't know anything about LUKS but if your theory is correct then you can try to enable an early KMS start by adding the name of your video card kernel module to the list at /etc/initramfs-tools/modules and then update the initramfs to include it:

# update-initramfs -u -k all

This has come up a few times recently, for example: http://dev1galaxy.org/viewtopic.php?pid=22481#p22481

I think the desktops now rely on a systemd user service to initialise PA but you can get the same effect by adding this line to a file at ~/.xsessionrc:

start-pulseaudio-x11

There is an XDG autostart file for PA but perhaps LXQt doesn't run those automatically, I don't use LXQt so I'm not sure about the specifics.

If you're not using ifupdown then disable the networking service:

# update-rc.d networking disable

At least I think that's how you disable a sysvinit service, @community please correct me if I'm wrong here.

Run

# apt update
# apt upgrade

Then answer "yes" when it asks.

See also http://dev1galaxy.org/viewtopic.php?id=3564

The devscripts package supplies /usr/bin/checkbashisms to perform that function.

That is available as a package: https://pkginfo.devuan.org/stage/beowul … 5.0-3.html

Do you have pulseaudio installed? If so just install and run pavucontrol to set the default output device.

If you don't have pulseaudio installed then golinux's link has all the information you need to configure pure ALSA to set the default device.

As you appear to have an Intel sound card you can try this, it works for all the laptops I have ever owned:

# tee /etc/modprobe.d/alsa.conf <<<'options snd-hda-intel index=1'
# update-initramfs -u -k all

Then reboot.

If that doesn't work remove /etc/modprobe.d/alsa.conf, rebuild the initramfs again and post the output of

aplay -Ll

^ That's two ells, one upper case and one lower case.

I've added another port to the OP — it's called oksh and was created by Brian Callahan (also known as ibara), who is an OpenBSD developer.