Bug 1663613 - ASUS ROG laptop: LCD backlight control does not work with nouveau driver (does work with nvidia binary driver)
Summary: ASUS ROG laptop: LCD backlight control does not work with nouveau driver (doe...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-05 13:02 UTC by sapoliakaran
Modified: 2019-02-01 01:58 UTC (History)
17 users (show)

(edit)
Clone Of:
: 1665505 1665750 (view as bug list)
(edit)
Last Closed: 2019-02-01 01:41:58 UTC


Attachments (Terms of Use)
Outout from lsmod > lsmod.txt (5.31 KB, text/plain)
2019-01-06 11:02 UTC, sapoliakaran
no flags Details
lsmod output after update restored display brightness toggle (5.35 KB, text/plain)
2019-01-06 13:48 UTC, sapoliakaran
no flags Details
journalctl output (411.69 KB, text/plain)
2019-01-07 11:01 UTC, sapoliakaran
no flags Details
journalctl output with nouveau driver instead of nvidia driver (473.10 KB, text/plain)
2019-01-11 00:20 UTC, sapoliakaran
no flags Details

Description sapoliakaran 2019-01-05 13:02:01 UTC
Description of problem: 
In Fedora 29, with kernel 4.19.13-300.fc29.x86_64, the keys for changing keyboard backlight brightness and display brightness do not work. Neither does the gnome software slider option to change display brightness work. My laptop is an ASUS ROG GL502VMK. The key combinations are Fn+ F3/F4 - for backlight brightness decrease/increase and Fn+ F4/F5 - for display brightness decrease/increase. Key combinations on many recent ROG series ASUS laptops are the same, so many more users might be affected. 

Clicking on the key combinations does display the Gnome indicator showing the measure of increase or decrease. That is, the keyboard backlight gnome indicator and the display brightness gnome indicators pop up on using the key combinations, but no actual change happens. The volume change key combinations work smoothly though. For reference, they are Fn+ F11/F12.


Version-Release number of selected component (if applicable):
4.19.13-300.fc29.x86_64

How reproducible:
Reproducible every time. 

Steps to Reproduce:
1.Use the keyboard keys to increase/decrease keyboard backlight or display brightness.

Actual results:
Nothing happens, keyboard backlight stays fixed, and so does the display brightness. On my device they were fixed from when I installed Fedora 29 to keyboard backlight = off and display brightness = 100%

Expected results:
Keyboard backlight and display brightness should increase/decrease on using mentioned keyboard key combinations.

Additional info:
uname -a
Linux localhost.localdomain 4.19.13-300.fc29.x86_64 #1 SMP Sat Dec 29 22:54:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ls -l /sys/class/backlight
total 0
lrwxrwxrwx. 1 root root 0 Jan  5  2019 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0

screenfetch
           /:-------------:\          x@localhost.localdomain
        :-------------------::        OS: Fedora 29 TwentyNine
      :-----------/shhOHbmp---:\      Kernel: x86_64 Linux 4.19.13-300.fc29.x86_64
    /-----------omMMMNNNMMD  ---:     Uptime: 1h 31m
   :-----------sMMMMNMNMP.    ---:    Packages: 1700
  :-----------:MMMdP-------    ---\   Shell: zsh 5.6.2
 ,------------:MMMd--------    ---:   Resolution: 1920x1080
 :------------:MMMd-------    .---:   DE: GNOME 
 :----    oNMMMMMMMMMNho     .----:   WM: GNOME Shell
 :--     .+shhhMMMmhhy++   .------/   WM Theme: Adwaita
 :-    -------:MMMd--------------:    GTK Theme: Adwaita [GTK2/3]
 :-   --------/MMMd-------------;     Icon Theme: Adwaita
 :-    ------/hMMMy------------:      Font: Cantarell 11
 :-- :dMNdhhdNMMNo------------;       CPU: Intel Core i7-7700HQ @ 8x 3.8GHz [62.0°C]
 :---:sdNMMMMNds:------------:        GPU: GeForce GTX 1060/PCIe/SSE2
 :------:://:-------------::          RAM: 2441MiB / 15990MiB
 :---------------------://

Comment 1 Steve 2019-01-06 02:35:07 UTC
> My laptop is an ASUS ROG GL502VMK.

Could you attach the output from:

$ lsmod > lsmod-1.txt

> 4.19.13-300.fc29.x86_64

What is the last Fedora kernel for which the brightness keys worked as expected?

For the record, this commit, which includes a patch to add support for ASUS keyboard backlight toggling, went into 4.19-rc1:

Merge tag 'platform-drivers-x86-v4.19-1' of git://git.infradead.org/linux-platform-drivers-x86
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.19.y&id=899fbc33fd775b9dfa363db28f322272920a2196

Comment 2 sapoliakaran 2019-01-06 11:02 UTC
Created attachment 1518761 [details]
Outout from lsmod > lsmod.txt

Attaching the output requested by Steve.

Comment 3 sapoliakaran 2019-01-06 13:34:36 UTC
I installed Fedora 29 (Workstation Edition) 3 days back. So this is the very first time I am running it and the problem was from the beginning. On installation the system was on version 4.18.16-300.fc29.x86_64 and then it updated to version 4.19.13-300.fc29.x86_64. The problems were on both versions of the kernel.

Comment 4 sapoliakaran 2019-01-06 13:45:02 UTC
I received some system updates today which changed the lsmod output quite a bit. After the update, the display brightness toggles are working both on the keyboard and through the GNOME brightness slider. The keyboard backlight toggle key combinations are still not working though. I am attaching the new lsmod output in the attachments.

Comment 5 sapoliakaran 2019-01-06 13:48 UTC
Created attachment 1518796 [details]
lsmod output after update restored display brightness toggle

The lsmod output after the recent system update which restores display brightness toggle functionality for both the GNOME slider and the keyboard buttons combination

Comment 6 Steve 2019-01-06 17:05:12 UTC
Thanks for your followup reports and for attaching the lsmod output, which shows that four ASUS kernel modules are being loaded.[1]

What do you show for this:

$ ls -1F /sys/class/leds/*

NB: You can list all of the ASUS kernel modules with this:

$ locate --all $(uname -r) '*[^g]asus*'

One of these modules might be needed:

$ modinfo asus-laptop | egrep 'description|alias'
$ modinfo asus_atk0110 | egrep 'description|alias'

[1] $ grep asus lsmod-2.txt 
asus_nb_wmi            28672  0
asus_wmi               32768  1 asus_nb_wmi
sparse_keymap          16384  1 asus_wmi
rfkill                 28672  9 asus_wmi,bluetooth,cfg80211
asus_wireless          16384  0
hid_asus               20480  0
video                  45056  1 asus_wmi
wmi                    28672  4 intel_wmi_thunderbolt,asus_wmi,wmi_bmof,mxm_wmi

Comment 7 Steve 2019-01-06 18:00:49 UTC
(In reply to Steve from comment #6)
...
> What do you show for this:
> 
> $ ls -1F /sys/class/leds/*
...

If you see "asus::kbd_backlight", try these:

# Light on the leds (full power)
$ sudo echo 100 > /sys/class/leds/asus::kbd_backlight/brightness

# Light off the leds
$ sudo echo 0 > /sys/class/leds/asus::kbd_backlight/brightness

Source:

How to control keyboard backlight using hotkeys
https://unix.stackexchange.com/questions/152980/how-to-control-keyboard-backlight-using-hotkeys

Comment 8 sapoliakaran 2019-01-06 21:00:20 UTC
The outputs as requested in comment #5 are:

➜  ~ ls -1F /sys/class/leds/*
/sys/class/leds/asus::kbd_backlight@
/sys/class/leds/asus::kbd_backlight_1@
/sys/class/leds/asus::lightbar@
/sys/class/leds/asus-wireless::airplane@
/sys/class/leds/input4::capslock@
/sys/class/leds/input4::numlock@
/sys/class/leds/input4::scrolllock@
/sys/class/leds/input6::capslock@
/sys/class/leds/input6::compose@
/sys/class/leds/input6::kana@
/sys/class/leds/input6::numlock@
/sys/class/leds/input6::scrolllock@
/sys/class/leds/phy0-led@


➜  ~ locate --all $(uname -r) '*[^g]asus*'
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/hid/hid-asus.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/hwmon/asus_atk0110.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-pc39.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/media/rc/keymaps/rc-asus-ps3-100.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/platform/x86/asus-laptop.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/platform/x86/asus-nb-wmi.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/platform/x86/asus-wireless.ko.xz
/usr/lib/modules/4.19.13-300.fc29.x86_64/kernel/drivers/platform/x86/asus-wmi.ko.xz
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus/laptop.h
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus/nb
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus/wireless.h
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus/wmi.h
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/asus/nb/wmi.h
/usr/src/kernels/4.19.13-300.fc29.x86_64/include/config/hid/asus.h

➜  ~ modinfo asus-laptop | egrep 'description|alias'
description:    Asus Laptop Support
alias:          acpi*:ATK0101:*
alias:          acpi*:ATK0100:*


➜  ~ modinfo asus_atk0110 | egrep 'description|alias'        
alias:          acpi*:ATK0110:*



The outputs of commands suggested in comment #6 are:

➜  ~ sudo echo 100 > /sys/class/leds/asus::kbd_backlight/brightness
zsh: permission denied: /sys/class/leds/asus::kbd_backlight/brightness

➜  ~ sudo echo 0 > /sys/class/leds/asus::kbd_backlight/brightness
zsh: permission denied: /sys/class/leds/asus::kbd_backlight/brightness

Comment 9 Steve 2019-01-06 23:50:35 UTC
(In reply to sapoliakaran from comment #8)
> The outputs as requested in comment #5 are:
> 
> ➜  ~ ls -1F /sys/class/leds/*
> /sys/class/leds/asus::kbd_backlight@
> /sys/class/leds/asus::kbd_backlight_1@
...

Thanks for posting that. The fact that there are two could be related to the problem.

Could you attach the output from:

$ journalctl -b --no-hostname > journalctl-1.log

Comment 10 Steve 2019-01-07 05:06:55 UTC
A web search found someone with an "Asus rog gl502vs" reporting both "asus::kbd_backlight" and "asus::kbd_backlight_1".[1]

Could you post the output from:

$ ls -l /sys/class/leds

And try these commands:

$ sudo echo 3 > /sys/class/leds/asus::kbd_backlight_1/brightness
$ sudo echo 0 > /sys/class/leds/asus::kbd_backlight_1/brightness

[1] https://bbs.archlinux.org/viewtopic.php?id=230593

Comment 11 sapoliakaran 2019-01-07 11:01 UTC
Created attachment 1518961 [details]
journalctl output

Comment 12 sapoliakaran 2019-01-07 11:42:22 UTC
Outputs requested in comment #10

➜  ~ ls -l /sys/class/leds
total 0
lrwxrwxrwx. 1 root root 0 Jan  7  2019 asus::kbd_backlight -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.1/0003:0B05:1837.0002/leds/asus::kbd_backlight
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 asus::kbd_backlight_1 -> ../../devices/platform/asus-nb-wmi/leds/asus::kbd_backlight_1
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 asus::lightbar -> ../../devices/platform/asus-nb-wmi/leds/asus::lightbar
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 asus-wireless::airplane -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ATK4002:00/leds/asus-wireless::airplane
lrwxrwxrwx. 1 root root 0 Jan  7  2019 input4::capslock -> ../../devices/platform/i8042/serio0/input/input4/input4::capslock
lrwxrwxrwx. 1 root root 0 Jan  7  2019 input4::numlock -> ../../devices/platform/i8042/serio0/input/input4/input4::numlock
lrwxrwxrwx. 1 root root 0 Jan  7  2019 input4::scrolllock -> ../../devices/platform/i8042/serio0/input/input4/input4::scrolllock
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 input6::capslock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1837.0001/input/input6/input6::capslock
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 input6::compose -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1837.0001/input/input6/input6::compose
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 input6::kana -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1837.0001/input/input6/input6::kana
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 input6::numlock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1837.0001/input/input6/input6::numlock
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 input6::scrolllock -> ../../devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:0B05:1837.0001/input/input6/input6::scrolllock
lrwxrwxrwx. 1 root root 0 Jan  7 16:02 phy0-led -> ../../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/leds/phy0-led

➜  ~ sudo echo 3 > /sys/class/leds/asus::kbd_backlight_1/brightness
zsh: permission denied: /sys/class/leds/asus::kbd_backlight_1/brightness

➜  ~ sudo echo 0 > /sys/class/leds/asus::kbd_backlight_1/brightness
zsh: permission denied: /sys/class/leds/asus::kbd_backlight_1/brightness

Comment 13 Steve 2019-01-07 14:53:58 UTC
Thanks for the additional info. There is a USB device called "ROG MacroKey" that also has a backlight:

$ grep -n 'usb 1-8' journalctl-1.log
773:Jan 07 21:32:14 kernel: usb 1-8: new full-speed USB device number 3 using xhci_hcd
775:Jan 07 21:32:14 kernel: usb 1-8: New USB device found, idVendor=0b05, idProduct=1837, bcdDevice= 0.01
776:Jan 07 21:32:14 kernel: usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
777:Jan 07 21:32:14 kernel: usb 1-8: Product: ROG MacroKey
778:Jan 07 21:32:14 kernel: usb 1-8: Manufacturer: ASASTeK COMPUTER INC.

And that device name is created before the laptop keyboard backlight device name:

$ grep -n 'backlight_1' journalctl-1.log
1085:Jan 07 16:02:23 kernel: asus-nb-wmi asus-nb-wmi: Led asus::kbd_backlight renamed to asus::kbd_backlight_1 due to name collision

NB: The timestamps are misleading because the system clock was set in between:

$ grep -n 'localtime' journalctl-1.log
982:Jan 07 16:02:20 systemd[1]: RTC configured in localtime, applying delta of 330 minutes to system time.

Comment 14 Steve 2019-01-07 15:11:13 UTC
I suggest changing the bug summary to something like this:

"ASUS ROG laptop: asus-nb-wmi: Led asus::kbd_backlight renamed to asus::kbd_backlight_1 due to name collision"


For the record, this is the make and model:

$ grep -n 'DMI:' journalctl-1.log 
71:Jan 07 21:32:14 kernel: DMI: ASUSTeK COMPUTER INC. GL502VMK/GL502VMK, BIOS GL502VMK.305 07/03/2017

ROG GL502VM | ROG - Republic Of Gamers | ASUS USA
https://www.asus.com/us/ROG-Republic-Of-Gamers/ROG-GL502VM/

Comment 15 sapoliakaran 2019-01-08 11:35:26 UTC
Thank you Steve. Will change the bug summary. Hope we find a solution and patch it, so new adopters with similar hardware would have a smoother experience.

Comment 16 sapoliakaran 2019-01-10 16:00:43 UTC
After some searching i found this to work for the keboard backlight problem: https://ask.fedoraproject.org/en/question/129529/solved-macbook-pro-late-2011-82-backlit-keyboard-not-working/

So if I $ echo 2 > /sys/class/leds/asus::kbd_backlight_1 , the keyboard backlight lights up. I know for a fact that there are three levels of brightness in this physical keyboard, so 3 would be the maximum possible value. So, like many other distros, manual scripts seem the only answer here.

Another update: I reinstalled Fedora Worksation 29 (moved back to Manjaro in between to check whether the issue happens there too. Manjaro does not suffer from name collision somehow. Keyboard backlight wroks great there. Nouveau display brightness is a problem there too though). This time around, I did not install the proprietary NVIDIA display drivers for my GTX 1060 on this laptop. Last time, when after a kernel update, the brightness controls were active again for the keyboard and GNOME settings, I was using the NVIDIA drivers. But now i am using the open source nouveau driver.

When i try the same for display backlight using: $ echo 20 > /sys/class/backlight/acpi_video0/brightness, no changes happen in the physical brightness. Only brightness value in the file changes. Changing brightness using the GNOME brightness slider has the same effect.

I don't know the details, whether this issue is a kernel issue or a symlink issue or a driver issue. Guidance would be helpful.

Comment 17 Steve 2019-01-10 21:09:24 UTC
Thanks for your detailed report.

> So if I $ echo 2 > /sys/class/leds/asus::kbd_backlight_1 , the keyboard
> backlight lights up. I know for a fact that there are three levels of
> brightness in this physical keyboard, so 3 would be the maximum possible
> value. So, like many other distros, manual scripts seem the only answer here.

That should all "just work", but there could be more than one bug here. The source code appears to clamp out-of-range brightness values to the nearest limit (0 or max_brightness).*

What do you show for these?

$ cat /sys/class/leds/asus::kbd_backlight/max_brightness
$ cat /sys/class/leds/asus::kbd_backlight_1/max_brightness

* v4.19.13:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/platform/x86/asus-wmi.c?h=v4.19.13#n505

Comment 18 Steve 2019-01-10 21:54:20 UTC
(In reply to sapoliakaran from comment #16)
...
> ... But now i am using the open source nouveau driver.
> 
> When i try the same for display backlight using: $ echo 20 >
> /sys/class/backlight/acpi_video0/brightness, no changes happen in the
> physical brightness. Only brightness value in the file changes. Changing
> brightness using the GNOME brightness slider has the same effect.
> 
> I don't know the details, whether this issue is a kernel issue or a symlink
> issue or a driver issue. Guidance would be helpful.

The attached log shows:

Jan 07 16:02:28 systemd-backlight[788]: Failed to get backlight or LED device 'backlight:acpi_video0': No such device

What do you show for these?

$ ls -l /sys/class/backlight/
$ ls -lH /sys/class/backlight/*

Comment 19 Steve 2019-01-10 22:22:58 UTC
(In reply to sapoliakaran from comment #16)
...
> But now i am using the open source nouveau driver.
...

Could you attach a log file for that case:

$ journalctl -b --no-hostname > journalctl-2.log

For the attachment description, say something like this:

"journalctl output with nouveau driver instead of nvidia driver"

For the record:

$ grep taint journalctl-1.log 
Jan 07 16:02:26 kernel: nvidia: loading out-of-tree module taints kernel.
Jan 07 16:02:26 kernel: nvidia: module license 'NVIDIA' taints kernel.
Jan 07 16:02:26 kernel: Disabling lock debugging due to kernel taint
Jan 07 16:02:26 kernel: nvidia: module verification failed: signature and/or required key missing - tainting kernel

Comment 20 sapoliakaran 2019-01-11 00:19:57 UTC
For comment #17
$ cat /sys/class/leds/asus::kbd_backlight/max_brightness
3

$ cat /sys/class/leds/asus::kbd_backlight_1/max_brightness
3

For comment #18
ls -l /sys/class/backlight/
total 0
lrwxrwxrwx. 1 root root 0 Jan 11 03:55 acpi_video0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/backlight/acpi_video0

ls -lH /sys/class/backlight/*
total 0
-r--r--r--. 1 root root 4096 Jan 11 00:56 actual_brightness
-rw-r--r--. 1 root root 4096 Jan 11 00:56 bl_power
-rw-r--r--. 1 root root 4096 Jan 11 00:56 brightness
lrwxrwxrwx. 1 root root    0 Jan 11 05:47 device -> ../../../0000:01:00.0
-r--r--r--. 1 root root 4096 Jan 11 00:56 max_brightness
drwxr-xr-x. 2 root root    0 Jan 11 05:47 power
lrwxrwxrwx. 1 root root    0 Jan 11 05:09 subsystem -> ../../../../../../class/backlight
-r--r--r--. 1 root root 4096 Jan 11 00:56 type
-rw-r--r--. 1 root root 4096 Jan 11 00:56 uevent

Comment 21 sapoliakaran 2019-01-11 00:20 UTC
Created attachment 1519960 [details]
journalctl output with nouveau driver instead of nvidia driver

Comment 22 sapoliakaran 2019-01-11 00:27:43 UTC
Comment on attachment 1519960 [details]
journalctl output with nouveau driver instead of nvidia driver

Do note that I also currently have the kernel parameter of "acpi_backlight=none" added in the GRUB_CMDLINE_LINUX value in /etc/default/grub. I was testing with all the given flags in https://wiki.archlinux.org/index.php/backlight#Kernel_command-line_options
to see if something makes the functionality run. IF that can affect the journalctl log, then let me know. I will remove that parameter, and run grub-mkconfig, reboot and generate the journalctl output again. I have tried these kernel parameters mentioned in it: acpi_backlight=vendor, acpi_backlight=native. None of these three, including the one mentioned earlier produce any result. I'll try the last option acpi_backlight=video too, but i don't hope to see any changes.

Comment 23 Steve 2019-01-11 02:02:10 UTC
Thanks for the "ls -l" output and for attaching journalctl-2.log.

journalctl-2.log does not have the "No such device" error that is in journalctl-1.log (Comment 18).

The kernel command-line in journalctl-2.log does not show an "acpi_backlight" parameter, so that is fine:

$ grep 'Command line' journalctl-2.log
Jan 11 06:24:40 kernel: Command line: BOOT_IMAGE=/vmlinuz-4.19.13-300.fc29.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8


FYI, the kernel 4.19 command-line parameters are documented here:
https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html

Comment 24 Steve 2019-01-11 02:53:04 UTC
The log has messages for the systemd service that manages backlights.* Could you post the output from this:

$ head -v /var/lib/systemd/backlight/*

That directory is documented here:

$ man systemd-backlight@.service

* Snippet:
$ grep -in 'systemd\[1\]:.*backlight' journalctl-2.log
1193:Jan 11 00:54:50 systemd[1]: Created slice system-systemd\x2dbacklight.slice.
1194:Jan 11 00:54:50 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
1196:Jan 11 00:54:50 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:acpi_video0.
1206:Jan 11 00:54:53 systemd[1]: Starting Load/Save Screen Backlight Brightness of leds:asus::kbd_backlight...
1208:Jan 11 00:54:53 systemd[1]: Started Load/Save Screen Backlight Brightness of leds:asus::kbd_backlight.

Comment 25 Steve 2019-01-11 04:47:22 UTC
The log shows a Fedora package called "brightnessctl" being installed.* Did that command have any effect?

From the source code**, the package installs some udev rules (90-brightnessctl.rules) that change permissions and groups on the brightness files. I suggest removing the package after testing with it, so that it doesn't cause confusion about what is going on. If the permissions and groups are wrong, that should be considered a separate bug.

* $ grep -m 1 brightnessctl journalctl-2.log 
Jan 11 01:01:25 dbus-daemon[943]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service' requested by ':1.587' (uid=0 pid=3984 comm="sudo dnf install brightnessctl " label="unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023")

** https://github.com/Hummer12007/brightnessctl

Comment 26 Hans de Goede 2019-01-11 09:25:44 UTC
Hi all,

I've lost track a bit with all the comments here, so to be sure:

(In reply to sapoliakaran from comment #4)
> I received some system updates today which changed the lsmod output quite a
> bit. After the update, the display brightness toggles are working both on
> the keyboard and through the GNOME brightness slider.

Ok, so you can control the display brightness now and the only problem is the keboardbacklight brightness not working now, correct?  Or did this change again in a later comment?

If both are still broken please open a new bug for the keyboard backlight issue (since most debugging done here seems to be about the display brightness).

Steve, for future reference, keyboardbacklight control is done only through:
/sys/class/leds. /sys/class/backlight is only for display backlight brightness control.
Also the 2 use completely separate code-paths, so next time for bugs where issues with both are reported in a single bug, please ask the reported to split the bug.

Now about the keyboard backlight issue, the hid-asus driver should not register its keyboard backlight interface when there is a wmi one,
drivers/hid/hid-asus.c uses the following check for this:

static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
{
        u32 value;
        int ret;

        if (!IS_ENABLED(CONFIG_ASUS_WMI))
                return false;

        ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS2,
                                       ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
        hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
        if (ret)
                return false;

        return !!(value & ASUS_WMI_DSTS_PRESENCE_BIT);
}

So I guess this check is not working in this case and we need to debug this.

sapoliakaran can you create a:

/etc/modprobe.d/hid-asus.conf

file with the following content:

options hid_asus dyndbg

And then regenerate your initrd:

sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

And then reboot and after reboot run:

dmesg | grep WMI

And copy and paste the output here please?

Regards,

Hans

Comment 27 Steve 2019-01-11 14:44:28 UTC
(In reply to Hans de Goede from comment #26)
...
> Ok, so you can control the display brightness now and the only problem is
> the keboardbacklight brightness not working now, correct?  Or did this
> change again in a later comment?

With nvidia, display brightness can be controlled (Comment 4).
With nouveau, display brightness cannot be controlled: "But now i am using the open source nouveau driver." (Comment 16)

> If both are still broken please open a new bug for the keyboard backlight
> issue (since most debugging done here seems to be about the display
> brightness).

Thanks for looking at this bug. The bug summary refers to a keyboard backlight issue, so I suggest a separate bug for the display brightness issue.

> Now about the keyboard backlight issue, ...

Please clarify whether you want this bug to be about the keyboard backlight issue or about the display brightness issue.

Comment 28 Hans de Goede 2019-01-11 14:48:07 UTC
(In reply to Steve from comment #27)
> Please clarify whether you want this bug to be about the keyboard backlight
> issue or about the display brightness issue.

I would prefer a new clean bug for the keyboard backlight issue (which I believe I will be able to fix soon) and then update the summary of this bug.

Comment 29 Steve 2019-01-11 14:58:06 UTC
(In reply to Hans de Goede from comment #28)
> (In reply to Steve from comment #27)
> > Please clarify whether you want this bug to be about the keyboard backlight
> > issue or about the display brightness issue.
> 
> I would prefer a new clean bug for the keyboard backlight issue (which I
> believe I will be able to fix soon) and then update the summary of this bug.

OK. What do you want the bug summaries to say?

Comment 30 Hans de Goede 2019-01-11 15:05:59 UTC
New bug:  ASUS ROG laptop: asus-nb-wmi: Led asus::kbd_backlight renamed to asus::kbd_backlight_1 due to name collision
This bug: ASUS ROG laptop: LCD backlight control does not work with nouveau driver (does work with nvidia binary driver)

Also (for this bug) what is the output of: "ls /sys/class/backlight" with the nvidia driver loaded (so with working LCD backlight control) ?

Note with a laptop like this using the nvidia driver probably is a good ideas anyways (if you need decent GPU performance under Linux), I don't really like to advice this, but nouveau support for recent nvidia GPUs is not so great.

Comment 31 Steve 2019-01-11 15:24:00 UTC
(In reply to Hans de Goede from comment #30)
> New bug:  ASUS ROG laptop: asus-nb-wmi: Led asus::kbd_backlight renamed to
> asus::kbd_backlight_1 due to name collision
> This bug: ASUS ROG laptop: LCD backlight control does not work with nouveau
> driver (does work with nvidia binary driver)

Thanks. I will open a new bug, but I cannot change the summary for this bug. So we don't have two bugs with the same summary, I will wait until the summary for this one is changed.

Comment 32 Steve 2019-01-11 15:39:45 UTC
(In reply to Hans de Goede from comment #28)
...
> I would prefer a new clean bug for the keyboard backlight issue (which I
> believe I will be able to fix soon) and then update the summary of this bug.

Bug 1665505 - ASUS ROG laptop: asus-nb-wmi: Led asus::kbd_backlight renamed to asus::kbd_backlight_1 due to name collision

Comment 33 sapoliakaran 2019-01-11 15:55:34 UTC
Reply to comment #23
Thank you for the heads-up Steve. Yes, that is the document I was refering to for manipulating kernel parameters.
Any changes I make complicates matters further, so I am going back to the defaults, which were:
1.No kernel paramerters for backlight (removed the acpi_backlight= values I was trying)
2.Removed brightnessctl (Yes I tried playing with it. This tool has the same effect as all earlier experiments. It just changes the value in /sys/class/brightness/acpi_video0/brightness. No actual brightness change happens).

Nothing else, hopefully, remains that I changed in order to get the display backlight working.

Reply to comment #24
$ head -v /var/lib/systemd/backlight/*
==> /var/lib/systemd/backlight/pci-0000:00:14.0-usb-0:8:1.1:leds:asus::kbd_backlight <==
0

==> /var/lib/systemd/backlight/pci-0000:01:00.0:backlight:acpi_video0 <==
45

Reply to comment #26
Hello Hans. Yes, originally, when I posted the bug(which was two bugs together, you're right) I was using the nvidia driver. After an update the display brightness issue got patched but the keyboard brightness issue remained. This happened during the course of this bug report. Later, in trying to understand the issue, i reinstalled Fedora 29 workstation, all same configurations, no changes, other than that I did not install the nvidia driver this time. This time around I stuck with the nouveau driver. So yes, Steve understood it exactly in comment #27.

In short:
1. Using nvidia driver,display brightness keys work.
2. Using nouveau driver, display brightness keys do not work.
3. Keyboard backlight keys do not work. But direct manipulation of /sys/class/leds/asus::kbd_backlight_1/brightness works ( refer comment #16).

You guys figured it out correctly, sorry for the mess.

About the requested output:
$ dmesg | grep WMI
[   12.849610] asus_wmi: ASUS WMI generic driver loaded
[   13.146847] asus_wmi: BIOS WMI version: 9.0
[   13.148801] input: Asus WMI hotkeys as /devices/platform/asus-nb-wmi/input/input14

Reply to comment #30
Let me install the nvidia drivers again and return with the outputs.

The reason I intend to use nouveau with the laptop is that the nvidia drivers cause the fans to keep revving up, processor to work on higher clocks mostly and the battery to die quick, very quick actually. Even when the laptop is only booted and no application is running, with the nvidia driver, there is a tendency of the systems to keep running at higher clock and with higher fan speed. It is annoying and eats up battery. With the nouveau driver on the other hand, even with this problem of 100% brightness and no way to dial it down, the system is quieter, cooler and giving me atleast 30 mins more than the nvidia driver. Dialing down the brightness will surely help me extend battery life and avoid excessive heating and processing for no reason. Either ways, any of these drivers are in no ways even near to the battery life windows 10 offers and the almost silent fans with it. I was shocked at the level of difference on the same hardware. Not complaining, but I shifted from Manjaro to Fedora to see if battery life improves. Read somewhere that fedora kernel has default enabled features which were set through tlp or other utilities only earlier. Also the news of the power usage reductions on Thinkpads. Will surely consider a thinkpad or some other more linux compatible laptop next time. But anyways the end goal was to have a better battery life when I am simply coding on this laptop in linux and to get rid of the useless fan rev ups and constant heating.

Comment 34 Steve 2019-01-11 21:07:16 UTC
(In reply to sapoliakaran from comment #33)
...
> The reason I intend to use nouveau with the laptop is that the nvidia
> drivers cause the fans to keep revving up, processor to work on higher
> clocks mostly and the battery to die quick, very quick actually.
...

That might be configurable. See "nvidia-smi [-pl, --power-limit=POWER_LIMIT]".
https://developer.download.nvidia.com/compute/DCGM/docs/nvidia-smi-367.38.pdf

Comment 35 sapoliakaran 2019-01-11 21:36:29 UTC
I did try that. Killing turbo boost and limiting CPU cycles to upper bounds. Did have very noticeable performance impacts. Didn't quite like it. Read somewhere nouveau drivers are generally better at battery life. Shifted back. Now just trying to stop this screen from burning my eyes.

Comment 36 sapoliakaran 2019-01-11 21:54:54 UTC
Oh! Sorry, confused it with CPU throttling. Will look into nvidia-smi

Comment 37 sapoliakaran 2019-01-12 00:27:10 UTC
Replying to comment #30
$ ls /sys/class/backlight
nvidia_0

Comment 38 Steve 2019-01-12 16:00:10 UTC
(In reply to sapoliakaran from comment #37)
> Replying to comment #30
> $ ls /sys/class/backlight
> nvidia_0

Thanks. That explains the systemd-backlight "No such device" error message. Evidently, systemd tries again and finds "backlight:nvidia_0":

$ less -N journalctl-1.log
...
   1198 Jan 07 16:02:28 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
   1199 Jan 07 16:02:28 systemd-backlight[788]: Failed to get backlight or LED device 'backlight:acpi_video0': No such device
   1200 Jan 07 16:02:28 systemd[1]: systemd-backlight@backlight:acpi_video0.service: Main process exited, code=exited, status=1/FAILURE
   1201 Jan 07 16:02:28 systemd[1]: systemd-backlight@backlight:acpi_video0.service: Failed with result 'exit-code'.
   1202 Jan 07 16:02:28 systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0.
...
   1205 Jan 07 16:02:28 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:nvidia_0...
...
   1210 Jan 07 16:02:28 systemd-backlight[789]: Saved brightness 1 too low; increasing to 5.
   1211 Jan 07 16:02:28 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:nvidia_0.
...

Comment 39 sapoliakaran 2019-01-12 21:03:39 UTC
But under /sys/class/backlight only acpi_video0 is accessible when using nouveau driver

Comment 40 sapoliakaran 2019-01-12 21:48:50 UTC
Replying to comment #33
A side note, but it is the CPU i was talking about. Installing the nvidia binary makes the CPU clock up frequently and the CPU fans to fire more often and obviously the battery  to drain more. Nothing to do with this issue, just an observation.

Comment 41 Steve 2019-01-13 03:00:30 UTC
(In reply to sapoliakaran from comment #40)
> Replying to comment #33
> A side note, but it is the CPU i was talking about. Installing the nvidia
> binary makes the CPU clock up frequently and the CPU fans to fire more often
> and obviously the battery  to drain more. Nothing to do with this issue,
> just an observation.

Thanks for bringing that up. There appears to be yet another problem:

$ grep -i 'fans' journalctl-2.log
Jan 11 00:54:54 kernel: asus_wmi: Number of fans: 0

What do you show for this:

$ find /sys/devices/platform/asus-nb-wmi/ -name '*hwmon*' -o -name '*fan*'

That "Number of fans" message comes from asus-wmi.c:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/platform/x86/asus-wmi.c?h=v4.19.13#n2139

Comment 42 Steve 2019-01-13 03:29:16 UTC
(In reply to Steve from comment #41)
...
> Jan 11 00:54:54 kernel: asus_wmi: Number of fans: 0
...

A web search for "asus GL502VMK disassembly" found photos that show two internal fans.

Comment 43 sapoliakaran 2019-01-13 15:52:49 UTC
Replying to comment #41
➜  ~ find /sys/devices/platform/asus-nb-wmi/ -name '*hwmon*' -o -name '*fan*'
/sys/devices/platform/asus-nb-wmi/hwmon
/sys/devices/platform/asus-nb-wmi/hwmon/hwmon2

Yes, it has two fans. One for the CPU and the other for the GPU.

Comment 44 Steve 2019-01-13 18:08:03 UTC
(In reply to sapoliakaran from comment #43)
> Replying to comment #41
> ➜  ~ find /sys/devices/platform/asus-nb-wmi/ -name '*hwmon*' -o -name '*fan*'
> /sys/devices/platform/asus-nb-wmi/hwmon
> /sys/devices/platform/asus-nb-wmi/hwmon/hwmon2
> 
> Yes, it has two fans. One for the CPU and the other for the GPU.

Thanks:

Bug 1665750 - ASUS ROG laptop: asus_wmi: Number of fans: 0

Comment 45 Hans de Goede 2019-01-21 21:25:12 UTC
Hi,

(In reply to sapoliakaran from comment #37)
> Replying to comment #30
> $ ls /sys/class/backlight
> nvidia_0

Ok, so this means that your backlight is connected to the NVIDIA GPU and not controller by some other piece of hardware. So nouveau should register a backlight for it. I've asked 2 colleagues who work on nouveau to take a look at this bug. Note they are very busy, so I hope they can find some time for this.

Regards,

Hans

Comment 46 Hans de Goede 2019-01-22 19:02:44 UTC
I've heard back from the nouveau developer with a potential fix for this and I've also found a fix for the kbd-backlight issue.

I've done a kernel scratch-build with the patch added, you can find this scratch-build here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=32193596

Here are some generic instructions for installing and testing kernels directly from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please give this kernel a test run, without the binary nvidia driver or any special kernel commandline options and let us know if it fixes both issues.

If things are not fixed please provide the output of these 3 commands:

ls /sys/class/backlight
ls /sys/class/leds
dmesg

While running the new kernel.

Comment 47 sapoliakaran 2019-01-22 23:31:31 UTC
(In reply to Hans de Goede from comment #46)
This solves the issue! The LCD brightness/backlight controls are working now in nouveau, both from the keyboard and otherwise. And the keyboard backlight controls are also working. Thank you :-)

Comment 48 Hans de Goede 2019-01-23 19:48:03 UTC
Thank you for testing I've added the necessary patches to the Fedora kernel packages, so the next official Fedora kernel build will pick them up and then this issue should be resolved.

Comment 49 sapoliakaran 2019-01-24 03:27:02 UTC
For my own knowledge I would also like to read and understand the changes made to the kernel to solve this issue. Where can I view the commits made? 
I tried finding source code links from the scratch build page: https://koji.fedoraproject.org/koji/taskinfo?taskID=32193596
but couldn't locate any.

Comment 50 Hans de Goede 2019-01-24 07:08:12 UTC
(In reply to sapoliakaran from comment #49)
> For my own knowledge I would also like to read and understand the changes
> made to the kernel to solve this issue. Where can I view the commits made? 
> I tried finding source code links from the scratch build page:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=32193596
> but couldn't locate any.

This is the commit fixing the LCD backlight issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=15f77c4ade3364106a3a397f0a8d6fce9d6a6326

This is the commit fixing the keyboard backlight issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b692c55e58d06ba9b17c66784cab5a95ba5be9b

Comment 51 Steve 2019-01-24 15:36:04 UTC
(In reply to sapoliakaran from comment #49)
> ... Where can I view the commits made? ....

Hans already answered your specific question, so this is a more general answer.

The kernel source code is in git repositories (repos) at https://www.kernel.org/ (follow the "browse" links to get started).

The two most useful kernel git repos are:

mainline:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/

stable:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/

I suggest clicking on the "refs" tab in both to get an idea how they differ (both "Branch" and "Tag" refs are listed -- you may need to scroll to see everything).

After that, click on the "log" tab to see a long list of commits.

For more about git, see:
https://git-scm.com/
$ dnf -C list git\*

There are several books on git. This is a good intro:
"Pragmatic version control using Git" by Travis Swicegood.

Comment 52 Fedora Update System 2019-01-29 12:38:50 UTC
kernel-headers-4.20.5-200.fc29 kernel-4.20.5-200.fc29 kernel-tools-4.20.5-200.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-aabdaa013d

Comment 53 Fedora Update System 2019-01-29 12:41:53 UTC
kernel-tools-4.20.5-100.fc28 kernel-4.20.5-100.fc28 kernel-headers-4.20.5-100.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4002b91800

Comment 54 Fedora Update System 2019-01-30 01:58:47 UTC
kernel-4.20.5-200.fc29, kernel-headers-4.20.5-200.fc29, kernel-tools-4.20.5-200.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-aabdaa013d

Comment 55 Fedora Update System 2019-01-30 03:01:28 UTC
kernel-4.20.5-100.fc28, kernel-headers-4.20.5-100.fc28, kernel-tools-4.20.5-100.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4002b91800

Comment 56 Fedora Update System 2019-02-01 01:41:58 UTC
kernel-4.20.5-100.fc28, kernel-headers-4.20.5-100.fc28, kernel-tools-4.20.5-100.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 57 Fedora Update System 2019-02-01 01:58:58 UTC
kernel-4.20.5-200.fc29, kernel-headers-4.20.5-200.fc29, kernel-tools-4.20.5-200.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.