Description of problem: If I leave the laptop idle long enough to go into lock screen, the brightness level icon comes on screen and starts fluctuating between 7 and 8 (the highest 2 levels). This cannot be stopped even after logging back in from lock screen. How reproducible: Every time Steps to Reproduce: 1. Install Fedora 22 2. Boot up and log in 3. Wait for lock screen Actual results: Brighness (backlight) levels start automatically going up and down Expected results: Brightness stays stable and does not change until expected (on battery, battery low, or I manually change for example). Additional info: Laptop is an older MSI VR420 (MS-1422). This happens after fresh install of Fedora 22 and after latest updates. The only way to stop this is to set the following and rebuild grub.cfg. /etc/default/grub: GRUB_CMDLINE_LINUX="acpi_backlight=vendor rhgb quiet" The system logs (journalctl -f) show this being spammed while this is happening: Oct 08 21:39:00 mobile-pc1.local pkexec[3824]: ddreggors: Executing command [USER=root] [TTY=unknown] [CWD=/home/ddreggors] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 8] Oct 08 21:39:00 mobile-pc1.local pkexec[3830]: ddreggors: Executing command [USER=root] [TTY=unknown] [CWD=/home/ddreggors] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 8] Oct 08 21:39:00 mobile-pc1.local pkexec[3836]: ddreggors: Executing command [USER=root] [TTY=unknown] [CWD=/home/ddreggors] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 7] Oct 08 21:39:00 mobile-pc1.local pkexec[3842]: ddreggors: Executing command [USER=root] [TTY=unknown] [CWD=/home/ddreggors] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 8] I am not logged in as root, nor am I purposely running gnome as root. I am not sure why the USER=root here unless that is ecpected. I am also not sure why it is deciding to run that command repeatedly and change my brightness.
What's the output of "monitor-sensor" and "systemctl status iio-sensor-proxy.service" when that happens? > I am not logged in as root, nor am I purposely running gnome as root. I am not > sure why the USER=root here unless that is ecpected. That's expected, the helper runs as root. > I am also not sure why it > is deciding to run that command repeatedly and > change my brightness. Likely the automatic brightness handling. After gathering the information at the top of this comment, you can try disabling the automatic brightness in the Power settings. Also let us know more information, like, does it happen all the time? Is the ambient brightness changing? What laptop you're using?
> What's the output of "monitor-sensor" and > "systemctl status iio-sensor-proxy.service" when that happens? monitor sensors was not installed, I had to install the 'iio-sensor-proxy' package to get it. After installing I ran monitor sensor as my self and as root... it just hangs. The output of the systemctl command is as follows: [root@mobile-pc1 ~]# systemctl status iio-sensor-proxy.service ● iio-sensor-proxy.service - IIO Sensor Proxy service Loaded: loaded (/usr/lib/systemd/system/iio-sensor-proxy.service; static; vendor preset: disabled) Active: inactive (dead) I tried turning on and running monitor-sensor and monitor-sensor still just hangs. > you can try disabling the automatic brightness in the Power settings I have tried "Dim when inactive" as that the only automatic option for brightness I see under power settings. This did not stop it either. > does it happen all the time? As mentioned in description above, it only begins after inactivity and the laptop goes to lock screen. After that it will not stop no matter what you do, even logging back in it remains this way (brightness fluctuating and OSD brightness icon stays on screen). > Is the ambient brightness changing? No, this happens when inside under bright lights that do not change. > What laptop you're using? As mentioned in description above I have an MSI VR420 (model MS-1422)
(In reply to David Dreggors from comment #2) > > What's the output of "monitor-sensor" and > > "systemctl status iio-sensor-proxy.service" when that happens? > > > monitor sensors was not installed, I had to install the 'iio-sensor-proxy' > package to get it. After installing I ran monitor sensor as my self and as > root... it just hangs. It doesn't hang, it waits for events. If it wasn't installed, then it's not automatic brightness that's the problem. <snip> > > you can try disabling the automatic brightness in the Power settings > > > I have tried "Dim when inactive" as that the only automatic option for > brightness I see under power settings. This did not stop it either. Support for automatic brightness is in F23, not F22, my mistake. > > does it happen all the time? > > As mentioned in description above, it only begins after inactivity and the > laptop goes to lock screen. After that it will not stop no matter what you > do, even logging back in it remains this way (brightness fluctuating and OSD > brightness icon stays on screen). Might be a bug in the kernel driver for the backlight, or in gnome-settings-daemon. I think that the driver probably doesn't have enough backlight states for us to do the fade out. > > What laptop you're using? > > As mentioned in description above I have an MSI VR420 (model MS-1422) Sorry, I missed that.
Is there anything else I can provide? I can give output of any command you think might help track down this bug.
(In reply to David Dreggors from comment #0) > Additional info: > Laptop is an older MSI VR420 (MS-1422). > This happens after fresh install of Fedora 22 and after latest updates. The > only way to stop this is to set the following and rebuild grub.cfg. > > /etc/default/grub: > GRUB_CMDLINE_LINUX="acpi_backlight=vendor rhgb quiet" What's the output of 'ls -l /sys/class/backlight' both with and without setting acpi_backlight=vendor ?
with acpi_backlight=vendor: [root@mobile-pc1 ~]# ls -l /sys/class/backlight total 0 without acpi_backlight=vendor: [root@mobile-pc1 ~]# ls -l /sys/class/backlight total 0 lrwxrwxrwx. 1 root root 0 Oct 19 10:38 acpi_video0 -> ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0
(In reply to David Dreggors from comment #7) > with acpi_backlight=vendor: > > [root@mobile-pc1 ~]# ls -l /sys/class/backlight > total 0 Ok, so, using acpi_backlight=vendor means we don't have a backlight device thus we don't do anything. > without acpi_backlight=vendor: > > [root@mobile-pc1 ~]# ls -l /sys/class/backlight > total 0 > lrwxrwxrwx. 1 root root 0 Oct 19 10:38 acpi_video0 -> > ../../devices/pci0000:00/0000:00:02.0/backlight/acpi_video0 This should work though. I have a few more questions: (In reply to David Dreggors from comment #0) > If I leave the laptop idle long enough to go into lock screen, the > brightness level icon comes on screen and starts fluctuating between 7 and 8 > (the highest 2 levels). Are you saying that the brightness level icon (the one in the middle of the screen) shows up without you pressing any keys? > This happens after fresh install of Fedora 22 and after latest updates. Did past fedora releases work correctly? This all sounds like a kernel bug to me. I recommend you read this blog post and try the steps there: http://hansdegoede.livejournal.com/13889.html
> Are you saying that the brightness level icon (the one in the middle of the screen) shows up without you pressing any keys? Correct, the only thing that happens is that the laptop is idle long enough to go to lock screen. Not meaning to sound harsh here, but again I gave this info already in the description... "If I leave the laptop idle long enough to go into lock screen, the brightness level icon comes on screen and starts fluctuating between 7 and 8 (the highest 2 levels)." Meaning I had not moved the mouse or touched any keys for a long enough period that the session times out and goes to lock screen. > Did past fedora releases work correctly? This is my first time ever loading Linux on this laptop. It has never had any other distro or any version of this distro before now so I cannot really answer that question.
(In reply to David Dreggors from comment #9) > > Are you saying that the brightness level icon (the one in the middle of the screen) shows up without you pressing any keys? > > Correct, the only thing that happens is that the laptop is idle long enough > to go to lock screen. Not meaning to sound harsh here, but again I gave this > info already in the description... I was just trying to confirm that the icon shows up, because that hints at a kernel bug indeed since we only show the brightness icon OSD when we receive brightness key events. Since you didn't physically press the keys, your laptop's firmware is faking them which needs to be fixed in the kernel. > > Did past fedora releases work correctly? > > This is my first time ever loading Linux on this laptop. It has never had > any other distro or any version of this distro before now so I cannot really > answer that question. Ok. Please try the suggestions in http://hansdegoede.livejournal.com/13889.html and let us know what if anything there makes brightness adjustment work for you.
I tried them, only one of the kernel options changes anything. I think there is a misconception here though. *IF* I do press the keys to adjust brightness all works as expected (before the issue occurs). As long as I do not let the screen timeout I have no issues. Nothing happens if I *do not* press brightness up or down, conversely the expected behavior happens if I *do* press up or down. Adding the grub kernel options one by one some of these completely break the backlight adjustment completely and I cannot adjust, but removing the option allows me to adjust. The only issue here is when screen timeout happens.
Please run $ /usr/libexec/gnome-settings-daemon --replace --debug > /tmp/gsd-debug.txt 2>&1 & and let the bug reproduce. Then grab that file and attach it here.
Created attachment 1084813 [details] GSD Debug file Attached gsd-debug.txt as requested
Right, we're getting brightness key presses... Does this happen if instead of waiting for idle you just run this on a terminal: $ xset dpms force off ? (it turns your monitor off, but wiggling the mouse should turn it on again)
yes, after running that command the screen goes black and instantly comes back on with on screen display showing brightness going up and down by itself again.
To be clear, this is after new login and the issue was not happening before I ran that command. Also, it should be added that if I never log in and leave the laptop in the user selection (login) screen it will never see this issue even if the screen times out. This only happens when I log in and allow the screen to timeout.
Adding Hans de Goede who knows the lower bits much better than I do.
Hi, OK, see the issue here seems to be that as soon as the laptop screen goes off, something starts generating brightness up / down key events to which gnome then (rightfully) responds. So lets go over this step by step. First of all David, can you try booting with "video.brightness_switch_enabled=0" on the kernel commandline (and nothing else backlight related) and see if that fixes things ? If not then can you please do: 1) "dnf install evemu" 2) Run "sudo evemu-record" that should get you a list of available input devices, please copy and paste that list to a comment here in bugzilla 3) Select the first device, then press your brightness up/down keys. write down if any events are generated by those keys from that input device. 4) Repeat 3) with the next device, until you've no more devices left. Note that it is possible for more then one device to generate events for the brightness keys, so please try them all. 5) Post a list here with which device(s) generate events for brightness hotkey presses 6) For each device which generate(s) events for brightness hotkey presses do the following: 6a) start evemu-record, select that device 6b) Run xset dpms force off 6c) Write down if this device now is generating events 6d) Reboot so that your laptop is back in a normal state 7) As said do 6) for each device which generates events on pressing the brightness hotkeys. If none of these devices generate events by themselves after the "xset dpms force off" repeat 6 for the other devices until you've found one which generates unsolicited events after the "xset dpms force off"; or until you run out of devices to try. 8) Get back to me here in bugzilla with all requested information. Regards, Hans
"video.brightness_switch_enabled=0" did not help... moving on to next steps: > 1) "dnf install evemu" INSTALLED > 2) Run "sudo evemu-record" that should get you a list of available input devices, please copy and paste that list to a comment here in bugzilla [ddreggors@mobile-pc1 ~]$ sudo evemu-record Available devices: /dev/input/event0: Lid Switch /dev/input/event1: Sleep Button /dev/input/event2: Power Button /dev/input/event3: Power Button /dev/input/event4: AT Translated Set 2 keyboard /dev/input/event5: SynPS/2 Synaptics TouchPad /dev/input/event6: Video Bus /dev/input/event7: BisonCam, NB Pro /dev/input/event8: HDA Intel Mic /dev/input/event9: HDA Intel Headphone Select the device event number [0-9]: > 5) Post a list here with which device(s) generate events for brightness hotkey presses Device: /dev/input/event4: AT Translated Set 2 keyboard Events: (repeats endlessly until ctrl+c) E: 0.000001 0011 0000 0001 # EV_LED / LED_NUML 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.090186 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.090186 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.090186 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +90ms E: 0.092988 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.092988 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.092988 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 0.228325 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.228325 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 0.228325 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +136ms E: 0.231095 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.231095 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 0.231095 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms NOTE: If I press only brightness up, it only repeats the KEY_BRIGHTNESSUP, same goes for brightness down. If I press one, then the other (up then down) it repeats both forever. I have to reboot to get back in normal state after each test. Device: /dev/input/event6: Video Bus Events: (one per key press) E: 15.971110 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 15.971110 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +15797ms E: 15.971129 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 15.971129 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 24.408062 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 24.408062 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +8437ms E: 24.408083 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 24.408083 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms NOTE: Even though I do not see repeated key press events shown in evemu-record for this device (or any other besides keyboard), I see the on screen display icon for brightness going up and down repeatedly and I see screen flickering brighter and dimmer. I still have to reboot for every test. > 6) For each device which generate(s) events for brightness hotkey presses do the following: > 6a) start evemu-record, select that device > 6b) Run xset dpms force off > 6c) Write down if this device now is generating events Device: /dev/input/event4: AT Translated Set 2 keyboard YES events are generating as above with keypress and yes they are repeating endlessly Device: /dev/input/event6: Video Bus NO no events generated even though I see on screen brightness icon and I see screen brightness changing > 8) Get back to me here in bugzilla with all requested information. DONE :-)
Hi, (In reply to David Dreggors from comment #19) > > 8) Get back to me here in bugzilla with all requested information. > DONE :-) Good, thanks, and it seems that we are actually getting somewhere. Can you (as root) edit: /lib/udev/hwdb.d/60-keyboard.hwdb Then search for MSI, you should then see something like this: # some MSI models generate ACPI/input events on the LNXVIDEO input devices, # plus some extra synthesized ones on atkbd as an echo of actually changing the # brightness; so ignore those atkbd ones, to avoid loops evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:* KEYBOARD_KEY_f7=reserved KEYBOARD_KEY_f8=reserved Change this to: evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* evdev:atkbd:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:* KEYBOARD_KEY_f7=reserved KEYBOARD_KEY_f8=reserved Note I changed the last "match" line to match any MSI laptop, by dropping the ":pn*N033" bit. Then do: sudo udevadm hwdb --update And then reboot and try to reproduce the problem again, hopefully it will be gone now. Also please do: grep '.*' /sys/class/dmi/id/*_* 2> /dev/null > dmi.log And attach dmi.log here. Thanks. Hans
> Then search for MSI, you should then see something like this I found that section but mine already seems to match that with the exception that on my laptop the lines start with keyboard not evdev: # some MSI models generate ACPI/input events on the LNXVIDEO input devices, # plus some extra synthesized ones on atkbd as an echo of actually changing the # brightness; so ignore those atkbd ones, to avoid loops keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:* KEYBOARD_KEY_f7=reserved KEYBOARD_KEY_f8=reserved Note the line you asked me to change already drops the ":pn*N033" bit.
Created attachment 1085145 [details] dmi.log
Hi, (In reply to David Dreggors from comment #21) > > Then search for MSI, you should then see something like this > > I found that section but mine already seems to match that with the exception > that on my laptop the lines start with keyboard not evdev: > > # some MSI models generate ACPI/input events on the LNXVIDEO input devices, > # plus some extra synthesized ones on atkbd as an echo of actually changing > the > # brightness; so ignore those atkbd ones, to avoid loops > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:* > KEYBOARD_KEY_f7=reserved > KEYBOARD_KEY_f8=reserved > > Note the line you asked me to change already drops the ":pn*N033" bit. No it does not look closer, but it seems that MICRO-STAR is also written differently in your dmi info, please try adding a 4th line like this: keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* Then do the hwdb update, and reboot, after this evemu-record should no longer show brightness key events for the atkbd device, and hopefully your problem will be gone. Regards, Hans
Added: keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* Ran command: sudo udevadm hwdb --update I then rebooted as asked and the problem persists :-(
Hmmm, oddly it seems that tapping the left shift key breaks the repeated brightness up and down. When I tap the shift key I see the event fire for left shift: E: 4.002468 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +660ms E: 4.108143 0004 0004 0042 # EV_MSC / MSC_SCAN 42 E: 4.108143 0001 002a 0000 # EV_KEY / KEY_LEFTSHIFT 0 E: 4.108143 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +106ms and all of the spamming of brightness up and down stops. However I do not think this is a "stuck" key issue as I never see the shift key events registered until I tap it, and if I open terminal to run commands or gedit to type results of commands while it is happening my text is no in CAPS as would be expected if shift was stuck.
Just a quick addition, tapping shift works even for lock screen. The issue was originally noticed because idle timeout going to lock screen would cause this issue to start. It still does that now even with changes, but now I see that I can tap shift and it all stops (until screen times out or I tap brightness buttons again anyway).
(In reply to David Dreggors from comment #24) > Added: > keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* > > Ran command: > sudo udevadm hwdb --update > > I then rebooted as asked and the problem persists :-( Have you tried running evemu-record on the "AT Translated Set 2 keyboard" again ? What happens if you press the brightness hotkeys while running evemu-record on the "AT Translated Set 2 keyboard" after applying the hwdb modification ? If this still generates brigthness key events we did something wrong wrt updating the hwdb. Note it may still be generating "EV_MSC / MSC_SCAN 248" events, but it should not be generating any EV_KEY / KEY_BRIGHTNESS... events.
> Have you tried running evemu-record on the "AT Translated Set 2 keyboard" again ? Sorry yes I had and yes it is. I thought that was obvious when I showed the fact that I caught the shift key that I was running the evemu-record command. I guess by not pasting the surrounding events it was confusing. Along with the KEY_LEFTSHIFT event getting captured I also capture the KEY_BRIGHTNESS... events. As noted when I press shift (left or right does not matter) it stops the KEY_BRIGHTNESS... events from firing on the "AT Translated Set 2 keyboard" device in the evemu-record cli. Here is what I see currently up until I press shift a couple of times: E: 9.040784 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +104ms E: 9.057172 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.057172 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 9.057172 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +17ms E: 9.059826 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.059826 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 9.059826 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 9.302843 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 9.302843 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 9.302843 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +243ms E: 9.305523 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 9.305523 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 9.305523 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 9.324945 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 9.324945 0001 0036 0001 # EV_KEY / KEY_RIGHTSHIFT 1 E: 9.324945 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +19ms E: 9.427670 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 9.427670 0001 0036 0000 # EV_KEY / KEY_RIGHTSHIFT 0 E: 9.427670 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +103ms E: 9.513062 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.513062 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 9.513062 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +86ms E: 9.515848 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.515848 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 9.515848 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 9.672387 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 9.672387 0001 0036 0001 # EV_KEY / KEY_RIGHTSHIFT 1 E: 9.672387 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +157ms E: 9.723273 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 9.723273 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 9.723273 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +51ms E: 9.725957 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 9.725957 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 9.725957 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 9.775414 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 9.775414 0001 0036 0000 # EV_KEY / KEY_RIGHTSHIFT 0 E: 9.775414 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +50ms E: 9.930938 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.930938 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 9.930938 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +155ms E: 9.933562 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 9.933562 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 9.933562 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 9.997772 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 9.997772 0001 0036 0001 # EV_KEY / KEY_RIGHTSHIFT 1 E: 9.997772 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +64ms E: 10.103721 0004 0004 0054 # EV_MSC / MSC_SCAN 54 E: 10.103721 0001 0036 0000 # EV_KEY / KEY_RIGHTSHIFT 0 E: 10.103721 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +106ms
Also, here is what I have in the file and the command I ran: [ddreggors@mobile-pc1 ~]$ sudo awk '/VR420/{print}' /lib/udev/hwdb.d/60-keyboard.hwdb keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* [ddreggors@mobile-pc1 ~]$ sudo udevadm hwdb --update [ddreggors@mobile-pc1 ~]$
I think I see the issue: # some MSI models generate ACPI/input events on the LNXVIDEO input devices, # plus some extra synthesized ones on atkbd as an echo of actually changing the # brightness; so ignore those atkbd ones, to avoid loops keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:* keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* Note the line you had me add differs from the 3 above it (MICRO-STAR vs Micro-Star). The case is different.
Hi, (In reply to David Dreggors from comment #30) > I think I see the issue: > > # some MSI models generate ACPI/input events on the LNXVIDEO input devices, > # plus some extra synthesized ones on atkbd as an echo of actually changing > the > # brightness; so ignore those atkbd ones, to avoid loops > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U-100*:pvr* > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*U100*:pvr* > keyboard:dmi:bvn*:bvr*:bd*:svnMICRO-STAR*:pn*N033:* > keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* > > > > Note the line you had me add differs from the 3 above it (MICRO-STAR vs > Micro-Star). The case is different. That is deliberate as the "System Vendor" string in your dmi.log file shows your board has it in lower case, can you try changing the line to just: keyboard:dmi:bvn*:bvr*:bd*:* That should match pretty much anything, and then again see if the EV_KEY / KEY_BRIGHTNESSDOWN events are now gone ? Regards, Hans
[root@mobile-pc1 ~]# vim /lib/udev/hwdb.d/60-keyboard.hwdb [root@mobile-pc1 ~]# grep -A1 VR420 /lib/udev/hwdb.d/60-keyboard.hwdb #keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* keyboard:dmi:bvn*:bvr*:bd*:* [root@mobile-pc1 ~]# udevadm hwdb --update [root@mobile-pc1 ~]# reboot and after reboot I logged in and again waited for timeout and it still happens: ################################ # Waiting for events # ################################ E: 0.000001 0011 0000 0001 # EV_LED / LED_NUML 1 E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms E: 0.021673 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.021673 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.021673 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +21ms E: 0.024609 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.024609 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.024609 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 0.173840 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.173840 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 0.173840 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +149ms E: 0.176720 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.176720 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 0.176720 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 0.334733 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.334733 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.334733 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +158ms E: 0.337517 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.337517 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.337517 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 0.496735 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.496735 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 0.496735 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +159ms E: 0.499574 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.499574 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 0.499574 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 0.663778 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.663778 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.663778 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +164ms E: 0.666490 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.666490 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.666490 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms E: 0.819158 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.819158 0001 00e1 0001 # EV_KEY / KEY_BRIGHTNESSUP 1 E: 0.819158 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +153ms E: 0.821926 0004 0004 0248 # EV_MSC / MSC_SCAN 248 E: 0.821926 0001 00e1 0000 # EV_KEY / KEY_BRIGHTNESSUP 0 E: 0.821926 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +2ms E: 0.970868 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.970868 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 E: 0.970868 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +149ms E: 0.973722 0004 0004 0247 # EV_MSC / MSC_SCAN 247 E: 0.973722 0001 00e0 0000 # EV_KEY / KEY_BRIGHTNESSDOWN 0 E: 0.973722 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +3ms ^C
Hi, (In reply to David Dreggors from comment #32) > [root@mobile-pc1 ~]# vim /lib/udev/hwdb.d/60-keyboard.hwdb > [root@mobile-pc1 ~]# grep -A1 VR420 /lib/udev/hwdb.d/60-keyboard.hwdb > #keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn*VR420:* > keyboard:dmi:bvn*:bvr*:bd*:* > [root@mobile-pc1 ~]# udevadm hwdb --update > [root@mobile-pc1 ~]# reboot > > > > and after reboot I logged in and again waited for timeout and it still > happens: > > ################################ > # Waiting for events # > ################################ > E: 0.000001 0011 0000 0001 # EV_LED / LED_NUML 1 > E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms > E: 0.021673 0004 0004 0247 # EV_MSC / MSC_SCAN 247 > E: 0.021673 0001 00e0 0001 # EV_KEY / KEY_BRIGHTNESSDOWN 1 Ok so we need to get rid of the second line here, the one with EV_KEY / KEY_BRIGHTNESS*, we should be able to remove that through hwdb, but for some reason it is not working. Do you perhaps have a 60-keyboard.hwdb file under /etc/udev/hwdb.d ? If so remove that one. Also can you try editing the part of 60-keyboard.hwdb just above the part you've been editing sofar ? You should see the following there: keyboard:dmi:bvn*:bvr*:bd*:svnMicro-Star*:pn* KEYBOARD_KEY_a0=mute # Fn+F9 KEYBOARD_KEY_ae=volumedown # Fn+F7 KEYBOARD_KEY_b0=volumeup # Fn+F8 KEYBOARD_KEY_b2=www # e button KEYBOARD_KEY_df=sleep # Fn+F12 KEYBOARD_KEY_e2=bluetooth # satellite dish2 KEYBOARD_KEY_e4=f21 # Fn+F3 Touchpad disable KEYBOARD_KEY_ec=email # envelope button KEYBOARD_KEY_ee=camera # Fn+F6 camera disable KEYBOARD_KEY_f6=wlan # satellite dish1 KEYBOARD_KEY_f7=brightnessdown # Fn+F4 KEYBOARD_KEY_f8=brightnessup # Fn+F5 KEYBOARD_KEY_f9=search Remove these 2 lines from there: KEYBOARD_KEY_f7=brightnessdown # Fn+F4 KEYBOARD_KEY_f8=brightnessup # Fn+F5 Then run udevadm hwdb --update && reboot, that should definitely remove the brightness events from the atkbd, which in turn will hopefully fix the loop.
> Do you perhaps have a 60-keyboard.hwdb file under /etc/udev/hwdb.d ? No > Remove these 2 lines from there: Done > Then run udevadm hwdb --update && reboot Done That does seem to do the trick, after reboot I can still use the keyboard (Fn+F4/Fn+F5) to set brightness and it does not get stuck cycling between them as before. Also, after screen timeout it does not get stuck cycling between up/down as before either. This appears to stop all troubles.
(In reply to David Dreggors from comment #34) > > Do you perhaps have a 60-keyboard.hwdb file under /etc/udev/hwdb.d ? > > No > > > > Remove these 2 lines from there: > > Done > > > > Then run udevadm hwdb --update && reboot > > Done > > > That does seem to do the trick, after reboot I can still use the keyboard > (Fn+F4/Fn+F5) to set brightness and it does not get stuck cycling between > them as before. Also, after screen timeout it does not get stuck cycling > between up/down as before either. > > This appears to stop all troubles. Good, so that means that at least we've been searching the problem in the right place, now we just need to figure out why our previous attempts did not work. Can you attach an unmodified copy of your 60-keyboard.hwdb here? Then I'll try to come up with a version which should only disable the sending of brightness key events from the atkbd on your model, and ask you to test that.
Created attachment 1091443 [details] 60-keyboard.hwdb I am pretty sure this is back to original... sadly I did not make a backup before editing. However I only comment, never removed lines and I have removed all lines I added as far as I can tell.
Created attachment 1091444 [details] 60-keyboard.hwdb
Sorry uploaded wrong one... new one uploaded.
Created attachment 1092158 [details] 60-keyboard.hwdb Hi, I believe this 60-keyboard.hwdb should do the trick, can you copy this to /lib/udev/hwdb.d, do a: "sudo udevadm --debug hwdb --update" And if the output of that does not report any errors, reboot and see if things still work ? Regards, Hans
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This issue still exists in Fedora 24, this should not be closed. Can this be re-opened and just updated to Fedora 24? This issue was never resolved in F23 and is still here in F24.
Hi, Re-opening per comment 41. David, can you please test the attachment from comment 39, as asked a while back. We're very close to actually fixing this. If you can confirm that that version fixes this, then I can submit a patch to the upstream udev hwdb to get a proper fix in place. To test, save the attachment to /lib/udev/hwdb.d (overwriting the existing 60-keyboard.hwdb) , then run: "sudo udevadm --debug hwdb --update" and then reboot Afte rebooting run evemu-record on "AT Translated Set 2 keyboard" and check that it does not report brightness up/down keypresses ? Thanks & Regards, Hans
I will test and get back to you by EOD. Very sorry for the late reply.
That seems to do the trick. I replaced the file and ran "sudo udevadm --debug hwdb --update", after reboot I checked it with the "evemu-record" command and selected "AT Translated Set 2 keyboard" and waited for screen to blank. All was well, it *did not* record those events. I *did not* see the screen brightness go up and down, and I *did not* see the OSD brightness indicator automatically come on and go up and down as I saw before.
> David, can you please test the attachment from comment 39, as asked a while > back. We're very close to actually fixing this. Hans, you mentioned being very close to fixing this is there any update on this?
Ugh, it has been a month, sorry about that and thanks for the final feedback / testing. With your feedback all I need todo is turn the changes into a proper patch and submit upstream, but I've been buried in work (I'm switching teams within RH and I'm currently in the in-between fase where I get to do work for both teams). I just double checked and this bug is still on my work-todo list, it just got a pile of higher priority items stacked on top. I'll do me best to get around to this in the next couple of weeks.
Understood, and thanks for the update. In the mean time I (or anyone else that needs this) can use the file you attached to resolve it.
Once more sorry for the delays in dealing with this. Patch submitted upstream: https://github.com/systemd/systemd/pull/4696 Moving this to bug to the systemd component, so that the systemd team can cherry pick the patch into the Fedora packages.
(In reply to Hans de Goede from comment #48) > Patch submitted upstream: > https://github.com/systemd/systemd/pull/4696 https://github.com/systemd/systemd/commit/3f59367e6fae0 > Moving this to bug to the systemd component, so that the systemd team can > cherry pick the patch into the Fedora packages. Ack.
Fixed in rawhide with systemd-232-11.fc26, reassigning to 25 which also needs the fix.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.