- This topic has 7 replies, 6 voices, and was last updated Nov 14-1:48 pm by seriousness.
-
Posts
-
hughtmccullough
I have installed antiX 21 64bit on an HP Elitebook 8730w laptop. I am using IceWM. Most things are working well. However, I am stuck with one problem. It is the same using both the 4.9 and the 5.10 kernels.
The Brightness Up and Down keys don’t work. I have scripts in /etc/acpi that work fine from a terminal. The brightness control in the Control Centre also works. So, the brightness control itself works. However, I can’t get the fn f9 and fn f10 keys to work.
I tried using xev, showkey -s, and showkey -k. In all of these pressing the fn f9 and fn f10 keys did nothing. There was no response.
I tried using acpi_listen with the same result.
I have other partitions on the laptop with other Debian based Linux OSs on them and they work fine. Using showkey -s gives me 0xe0 0x4c, 0xe0 0xcc, oxe0 0x54 and 0xe0 0xd4 for the press and release of the two keys respectively. showkey -k gives 224 for brightness up and 225 for brightness down.
acpi_listen gives video/brightnessdown BRTDN 00000087 00000000 and video/brightnessup BRTUP 00000086 00000000 K.Clearly the hardware works but either the appropriate keyboard driver is not installed in antiX 21 or I cannot find a way to invoke it.
I tried playing with the acpi_os_name and acpi_osi= grub entries as suggested in other places in the forum but this didn’t help.
Can anyone give me a way of trying to get the system to look for these keys and report an event when they are pressed?
caprea
Some more to try, please look here under Kernel command-line options
https://wiki.archlinux.org/title/Backlight#Kernel_command-line_options
afghan
Try adding these to your WM keys file. I use iceWM so I add it to my ~/.icewm/keys file. You can also access it from antiX Control Centre
key "XF86MonBrightnessDown" backlight-brightness -5 key "XF86MonBrightnessUp" backlight-brightness +5Do “man icewm-keys” for more details.
- This reply was modified 1 year, 3 months ago by afghan.
Beware of people who knows nothing; they are the ones that won't know that they know nothing.
blur13
Not so much a solution as a workaround. Similiar to previous posters solution. In the keys file I’ve set
key “Super+q” backlight-brightness +5
key “Super+a” backlight-brightness -5You wont have a problem having those keys recognized and they are easier to reach than the function keys.
Thank you all for your answers.
caprea, As the backlight control itself was actually working OK and the problem was with the function key events not being recognised, I didn’t pursue the backlight options any further.
afghan, I knew about those lines but they didn’t work because the function keys weren’t being recognised as XF86MonBrightnessDown and XF86MonBrightnessUp and therefore couldn’t be used to trigger backlight-brightness.
blur13, This did work, although I tried it with different keys. I almost left it there but I didn’t want to let it beat me.
After much research, I eventually solved the problem and I am putting some notes here in case they help anyone with similar problems.
The secret weapon was an application called evtest which is in the repositories. Running evtest with no arguments gave the following:
/dev/input/event0: AT Translated Set 2 keyboard
/dev/input/event1: SynPS/2 Synaptics TouchPad
/dev/input/event2: Sleep Button
/dev/input/event3: Lid Switch
/dev/input/event4: Power Button
/dev/input/event5: Video Bus
/dev/input/event6: ST LIS3LV02DL Accelerometer
/dev/input/event7: HDA Intel Front Mic
/dev/input/event8: HDA Intel Line
/dev/input/event9: HDA Intel Line Out
/dev/input/event10: HDA Intel Front Headphone
/dev/input/event11: HP WMI hotkeys
/dev/input/event12: PS/2 Generic Mouse
/dev/input/event13: CKA7216Two of these are relevant to the keyboard, event 0 and event 11.
According to the source code for the HP WMI kernel module, it should report the brightness down and brightness up keys. However, the keycodes that are listed in the code are 0x02 and 0x03. So, of course if you try to reassign these using setkeycodes, you end up reassigning the “1” and “2” keys – not very helpful. So, I’m not sure how that module is meant to work for those two keys. All of the other keys are fine!
Also, when using evtest with event 11:
sudo evtest /dev/input/event11,
the brightness keys are correctly listed in the information as having codes 224 (down) and 225 (up) but actually pressing the function keys in the listen mode doesn’t register anything.
Using evtest with event 0 i.e.
sudo evtest /dev/input/event0
gives the clue. This time the brightness keys are not listed in the information but actually pressing the keys in the listen mode shows that they have EV_MSC hex codes of 92 and 97 but no EV_KEY codes.
The final step in the puzzle is then to write a script that runs on start up with the lines:
setkeycodes 0x0097 225
setkeycodes 0x0092 224Those keycodes then correctly produce the acpi events listed in my first post. An event file can be placed in /etc/acpi/events containing, for brightness down:
event=video/brightnessdown BRTDN 00000087 00000000 K
action=/etc/acpi/brightdown.shand a similar one for brightness up.
The script brightdown.sh just contains code to reduce the brightness using one of various methods. backlight-brightness, mentioned by afghan and blur13, is an example.
It looks to me as if the HP WMI kernel module is a bit broken but I don’t know enough to make a proper judgment on that and this work around produces exactly the right functionality.
I hope this ramble through what I did is useful for anyone coming after me and I am happy to answer any questions (if I know the answer).
Since finding the solution, I have found that there was a much easier way to get the information. It is contained in the file:
/lib/udev/hwdb.d/60-keyboard.hwdb
If only the operating system had read this file and implemented it, it would have saved me a lot of bother.
anticapitalista
Since finding the solution, I have found that there was a much easier way to get the information. It is contained in the file:
/lib/udev/hwdb.d/60-keyboard.hwdb
If only the operating system had read this file and implemented it, it would have saved me a lot of bother.
And us.
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
seriousness
/lib/udev/hwdb.d/60-keyboard.hwdb
If only the operating system had read this file
less /lib/udev/hwdb.d/60-keyboard.hwdb # This file is part of systemd.This might be the reason…
- You must be logged in to reply to this topic.
