> > Hi, > > On 11/3/20 3:51 PM, Rhys Perry wrote: > > On Tue, 3 Nov 2020 at 14:43, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >> > >> Hi, > >> > >> Note I restored the Cc list again, please use Reply-to-all. > >> > > > > Yeah, sorry about that again. I have a hotkey set for reply and am > > using it out of habit. > > > >> On 11/3/20 3:25 PM, Rhys Perry wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 11/3/20 2:35 PM, Rhys Perry wrote: > >>>>>>>>>> (please use reply-all so that the mailing list gets the emails as well) > >>>>>> > >>>>> > >>>>> Oh, my mistake. I didn't actually know the difference between the two. > >>>>> Sorry for any confusion this might cause in the future. > >>>>> > >>>>>> > >>>>>>>> [...] > >>>>>>>>>> Can you see any messages generated by the hp-wmi driver when these key presses occur? > >>>>>>>>> > >>>>>>>>> Not that I know of, unless there is some sort of debug mode that can be enabled > >>>>>>>>> > >>>>>>>>>>>> Now, this is not that interesting at first, I obviously just need to > >>>>>>>>>>>> map a keycode. The confusing part is that for both the brightness up > >>>>>>>>>>>> AND the brightness down key I get the same code (e02b). I am not to > >>>>>>>>>>>> sure how to debug this behavior but I would appreciate if someone > >>>>>>>>>>>> helped investigate this issue. > >>>>>>>>>>>> I am not sure if this is relevant, but my RFKILL key does not work > >>>>>>>>>>>> either (but does not show anything in journal). > >>>>>>>>>> > >>>>>>>>>> Could you please run `evtest` and see if you have a "HP WMI hotkeys" input device? > >>>>>>>>>> If so, please select it, and then press the function keys and see if any events appear. > >>>>>>>>> > >>>>>>>>> After running`evtest` there is a device called "HP WMI hotkeys" (on > >>>>>>>>> /dev/input/event16). However, after selecting it and pressing the > >>>>>>>>> brightness keys no events appear. > >>>>>>>>> > >>>>>>>>>> Furthermore, you could install `acpid`, start it (something along the lines of > >>>>>>>>>> `sudo systemctl start acpid`), then run `acpi_listen` and see if you get anything > >>>>>>>>>> when you press the keys. > >>>>>>>>> > >>>>>>>>> After starting the service and running`acpi_listen`, no events appear > >>>>>>>>> when pressing the brightness keys > >>>>>>>>> > >>>>>>>>>>>> Here is a link to acpidump: > >>>>>>>>>>>> https://www.dropbox.com/s/ulyltq0gz35s79l/acpidump?dl=0 > >>>>>>>>>>>> ::: Rhys Perry ::: > >>>>>>>>> [...] > >>>>>>>> > >>>>>>>> Could you test other function keys like volume up/down, etc.? > >>>>>>>> > >>>>>>> After running some tests with evtest I have found out: > >>>>>>> - Brightness keys: "AT Translated Set 2 keyboard" (although same keycode) > >>>>>>> - Volume keys: "AT Translated Set 2 keyboard" > >>>>>>> - Media keys: "AT Translated Set 2 keyboard" > >>>>>>> - RFKILL key: (none, although there is a device called "HP Wireless hotkeys") > >>>>>> > >>>>>> Please install the `evemu` program suite, and run `evemu-record /dev/input/event...` > >>>>>> for the AT keyboard, HP WMI hotkeys, and HP Wireless hotkeys; in each run press the > >>>>>> brightness up/down, volume up/down keys in any fixed order you like, and then send > >>>>>> the output of each run (including the part that is initially printed before > >>>>>> receiving any events). Could you also run `acpi_listen` at the same time and > >>>>>> see if any key presses are registered there? If yes, what was the output? > >>>>>> > >>>>> > >>>>> Ok, here you go: > >>>>> "AT Translated Set 2 Keyboard": https://0x0.st/idpK.txt > >>>>> "HP Wireless hotkeys": https://0x0.st/idpP.txt > >>>>> "HP WMI hotkeys": https://0x0.st/idpN.txt > >>>>> `acpi_listen`: https://0x0.st/idpb.txt > >>>> > >>>> Can you also run evemu-record for the "Video Bus" > >>>> input device and check if you get events there for the > >>>> brightness up/down key presses? On modern laptops events > >>>> for the brightness keys are typically delivered there. > >>>> > >>> > >>> I ran evemu-record for my "Video Bus" devices (of which I had two) and > >>> there was nothing on those either. I quickly ran over every single > >>> input device and I can confirm that "AT Translated Set 2 Keyboard" is > >>> the only one that responds to brightness keys. > >> > >> Hmm, ok, weird. > >> > >> Usually at least something is generating events for this. Often > >> we have the problem that we get the brightness keys reported > >> by multiple input devices, this is a new problem. > >> > >> Can you try adding: > >> > >> wmi.debug_event=1 > >> > >> To your kernel commandline and then after rebooting do: > >> > >> cat /proc/cmdline > >> > >> To check that it really is there and then do: > >> > >> dmesg -w > >> > >> To monitor kernel messages and then press the brightness > >> up/down hotkeys and see if you get any new messages ? > >> > > > > Nope, exactly the same as before: > > ``` > > [ 42.501517] atkbd serio0: Unknown key pressed (translated set 2, > > code 0xab on isa0060/serio0). > > [ 42.501524] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known. > > [ 42.512377] atkbd serio0: Unknown key released (translated set 2, > > code 0xab on isa0060/serio0). > > [ 42.512383] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known. > > [ 43.160730] atkbd serio0: Unknown key pressed (translated set 2, > > code 0xab on isa0060/serio0). > > [ 43.160738] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known. > > [ 43.171970] atkbd serio0: Unknown key released (translated set 2, > > code 0xab on isa0060/serio0). > > [ 43.171978] atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known. > > ``` > > Ok bummer, so it looks like only get the one event and need to catch > that (we can use i8042_install_filter() from some driver for that) and > then when we catch it probably make some ACPI call to figure out what > is going on. I took a quick peek at the acpidump you provided, but it is > huge. One thing which did stand out is that ssdt14.dsl (after disassembling) > has: > > Method (GHKS, 0, NotSerialized) > { > Debug = "GetHotkeyState-----" > > > Method (SHKS, 1, Serialized) > { > Debug = "SetHotkeyState-----" > > Which may or may not be related ... But I'm afraid I do not have > the time to investigate that avenue further. > That looks promising (I think). I don't have any experience working with this sort of stuff, so is there a place you recommend I start? > One last thing to try (I guess) is adding the following to your kernel > commandline and see if that changes things: > > acpi_backlight=video > > Possible other values to try are "vendor" "native" and "none" > Just tried all of those, sadly it's still not working. > Regards, > > Hans > Yours Thankfully, Rhys Perry > p.s. > > I think you mentioned this before, but what was the exact model of your laptop again? > HP Pavilion cx-0598na. It has an i5-8300H and a 1050Ti
