|
[RESOLVED] No display backlight control with Liquorix 5.18/5.19 kernels, but works with backported Debian 5.18 kernels
Maybe there's some magic "apci_backlight=" boot flag that the Liquorix kernel needs? This is with MX 21 AHS.
Edited inxi result: :: Code ::
System: Kernel: 5.18.0-4mx-amd64 [5.18.16-1~mx21+1] x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: BOOT_IMAGE=/boot/vmlinuz-5.18.0-4mx-amd64 root=UUID=<filter> ro quiet splash init=/lib/systemd/systemd Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.16.1 vt: 7 dm: LightDM 1.26.0 Distro: MX-21.1_ahs_x64 Wildflower April 9 2022 base: Debian GNU/Linux 11 (bullseye) Machine: Type: Laptop System: Dell product: Dell G15 5515 v: 1.4.0 serial: <filter> Chassis: type: 10 v: 1.4.0 serial: <filter> Mobo: Dell model: 00VT1V v: A04 serial: <filter> UEFI: Dell v: 1.4.0 date: 07/20/2021 CPU: Info: 8-Core model: AMD Ryzen 7 5800H with Radeon Graphics bits: 64 type: MT MCP arch: Zen 3 family: 19 (25) model-id: 50 (80) stepping: 0 microcode: A50000C cache: L2: 4 MiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 102206 Graphics: Device-1: NVIDIA GA107M [GeForce RTX 3050 Ti Mobile] vendor: Dell driver: nvidia v: 510.85.02 bus-ID: 01:00.0 chip-ID: 10de:25a0 class-ID: 0300 Device-2: AMD Cezanne vendor: Dell driver: amdgpu v: kernel bus-ID: 05:00.0 chip-ID: 1002:1638 class-ID: 0300 Device-3: Microdia Integrated_Webcam_HD type: USB driver: uvcvideo bus-ID: 1-4:3 chip-ID: 0c45:6720 class-ID: 0e02 Display: x11 server: X.Org 1.20.14 compositor: xfwm4 v: 4.16.1 driver: loaded: amdgpu display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9") Monitor-1: eDP res: 1920x1080 hz: 120 dpi: 142 size: 344x193mm (13.5x7.6") diag: 394mm (15.5") OpenGL: renderer: AMD RENOIR (LLVM 14.0.5 DRM 3.46 5.18.0-4mx-amd64) v: 4.6 Mesa 22.0.5 direct render: Yes Boot Mode: UEFI The laptop's a bit too recent to run on standard Bullseye Mesa and 5.10 kernels.... Back to top |
|||||
|
Do you have a link to the git repository for MX Linux's linux kernel?
In the meantime, I looked over the latest Debian patches and only noticed one thing that might make a difference. Can you verify if MX Linux's kernel boots with nvidiafb? Debian removes this framebuffer driver through dfsg patches [1], but Liquorix keeps it enabled. Try blacklisting it [2] and see if your backlight support is restored. Also, interestingly, Debian recently enabled the Nvidia WMI EC Backlight control [3], and in the linked bug report, they said that Liquorix is doing backlight correctly [4]. Most likely that module is correct, and we need to disable nvidiafb backlight support, or the nvidiafb module entirely. [1] salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/debian/dfsg/video-remove-nvidiafb-and-rivafb.patch [2] wiki.archlinux.org/title/Kernel_module#Blacklisting [3] salsa.debian.org/kernel-team/linux/-/merge_requests/520 [4] bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017972 Back to top |
|||||
|
One other thing you can check, apparently it's common for desktop environments to use the wrong backlight control is multiple are provided. For example in this thread: forums.developer.nvidia.com/t/ubuntu-22-04-flickering-screen-and-brightness-not-working-on-dell-g15-rtx-3060/222392/4
Because the person reporting an issue had also amdgpu backlight support, gnome preferred that even though it was not functional. You may be experiencing something similar. Back to top |
|||||
|
I don't maintain any git for the MX rebuilds of the upstream Debian kernels. I just edit config/defines to use the releases's gcc version, also templates.extra.in for the same thing, and also tack on an mx on the end of the kernel ABI in defines. Also I bump up the context switch frequency to 1000 Hz in config/config, and increment debian/changelog with the backport mx release version and a list of my changes.
About the Nvidafb stuff...I thought this new laptop was doing everything with the amdgpu driver unless I invoked the Nvidia driver with the Prime commands to do the openGL rendering, like with the PRIME wrapper script that MX 21 ships: :: Code :: $ nvidia-run-mx inxi -G
Graphics: Device-1: NVIDIA GA107M [GeForce RTX 3050 Ti Mobile] driver: nvidia v: 510.85.02 Device-2: Advanced Micro Devices [AMD/ATI] Cezanne driver: amdgpu v: kernel Device-3: Microdia Integrated_Webcam_HD type: USB driver: uvcvideo Display: x11 server: X.Org 1.20.14 driver: loaded: amdgpu resolution: 1920x1080~120Hz OpenGL: renderer: NVIDIA GeForce RTX 3050 Ti Laptop GPU/PCIe/SSE2 v: 4.6.0 NVIDIA 510.85.02 I'll have to read that bug report---so much to do, now that we found out that the 5.19.2+ kernel broke a lot of out-of-tree Realtek wi-fi driver builds. Back to top |
|||||
|
Did you get a chance to look at the contents of /sys/class/backlight? That's where the backlight control files live. You can even change the contents of the files to verify if things are working or not, especially if you have multiple backlight controls.
Back to top |
|||||
|
I got behind on packaging for MX, so I've been catching up ever since on the machine. I did figure out how to get the display to stick at full brightness on Liquorix instead of at barely visible, so I can easily see what terminal commands show. I'll try rebooting soon.
On a Debian kernel, it's what we expect: :: Code :: $ ls /sys/class/backlight
amdgpu_bl0 Ah, hah! On Liquorix, it is :: Code ::
$ ls /sys/class/backlight amdgpu_bl0 nvidia_wmi_ec_backlight So that seems simple to blacklist. Back to top |
|||||
|
And....that fixed it!
Apparently, that bug is affecting this machine with its particular BIOS. There is an BIOS update available, but I can't get the machine to see the .exe file on the pendrive from the UEFI setup, or even the fat32 pendrive, for that matter. :: Code ::
System: Kernel: 5.19.0-4.1-liquorix-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 parameters: audit=0 intel_pstate=disable hpet=disable rcupdate.rcu_expedited=1 BOOT_IMAGE=/boot/vmlinuz-5.19.0-4.1-liquorix-amd64 root=UUID=<filter> ro quiet splash init=/lib/systemd/systemd Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm 4.16.1 vt: 7 dm: LightDM 1.26.0 Distro: MX-21.2_ahs_x64 Wildflower April 9 2022 base: Debian GNU/Linux 11 (bullseye) Machine: Type: Laptop System: Dell product: Dell G15 5515 v: 1.4.0 serial: <filter> Chassis: type: 10 v: 1.4.0 serial: <filter> Mobo: Dell model: 00VT1V v: A04 serial: <filter> UEFI: Dell v: 1.4.0 date: 07/20/2021 ... Info: Processes: 372 Uptime: 8m wakeups: 776 Memory: 30.72 GiB used: 2.27 GiB (7.4%) Init: systemd v: 247 runlevel: 5 default: 5 tool: systemctl Compilers: gcc: 10.2.1 alt: 10 Client: shell wrapper v: 5.1.4-release inxi: 3.3.06 Boot Mode: UEFI Back to top |
|||||
|
Great! Glad you figured it out.
This bug with backlight definitely should come to the attention of the major desktop environment developers. I'm sure there's many others out there having issues like this and have no idea how to proceed or what even causes backlight behavior to change between kernels. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||