Archlinux and the Linux 3.1 update

[jyaworski]

Upon using the function buttons, a notification about undefined-group/action is displayed on every key.

[nbigaouette]

I'll take a look when I'll update my eee this week.

[ghthor]

@nbigaouette Did you ever take a look into this? I just started using my eeepc again and I'm tinkering around right now trying to find a out what is causing this. I think the kernel now supplies key-down and key-up events so everything still works because all actions were bound to the key-down events but the scripts don't know what to do with the new key-up events that come out of the kernel.

[nbigaouette]

I did took a look back then after updating. I have not seen any issue though. I did switched from KDE to GNOME and now to XFCE (mostly due to storage limitation...) KDE and GNOME are catching the key events and can control themselves the functionality. I'm not so sure about XFCE so I'll take a deeper look.
Note that even with kernel 3.3.6 I don't get any unknown/undefined. I'll need more info from you, at least what eee model?

[ghthor]

My device is the 1005PEB and I am using XFCE also. Here is my output from acpi_listen while pressing the keys starting from the right and proceeding left.

F12 (Volume Up)
hotkey ASUS010:00 00000015 00000001
button/volumeup VOLUP 00000080 00000000 K

F11 (Volume Down)
hotkey ASUS010:00 00000014 00000001
button/volumedown VOLDN 00000080 00000000 K

F10 (Volume Mute)
hotkey ASUS010:00 00000013 00000003
button/mute MUTE 00000080 00000000 K

F9
hotkey ASUS010:00 00000012 00000002
button/prog1 PROG1 00000080 00000000 K

F8
hotkey ASUS010:00 00000030 00000002
video/switchmode VMOD 00000080 00000000 K

F7
hotkey ASUS010:00 00000016 00000005
video/displayoff DOFF 00000089 00000000 K

F6 (brightness up)
hotkey ASUS010:00 00000025 00000000

F5 (brightness down)
hotkey ASUS010:00 00000024 00000001

F4
hotkey ASUS010:00 00000038 00000002

F3
hotkey ASUS010:00 00000037 00000007

F2 (wifi)
hotkey ASUS010:00 00000010 00000003
button/wlan WLAN 00000080 00000000 K

F1 (sleep)
button/sleep SBTN 00000080 00000000

This key ins't producing an XF86* keysym

hotkey ASUS010:00 00000016 00000005
video/displayoff DOFF 00000089 00000000 K

All the other keys are producing XF86* keysyms so this package may have become obsolete.

Edit: Added in the corresponding F* keys to each acpi_listen output

[nbigaouette]

1005PEB? It's not supported... See https://github.com/nbigaouette/acpi-eeepc-generic/wiki/How-to-add-support-for-a-new-model
Copy /etc/acpi/eeepc/models/acpi-eeepc-1005PE-events.conf to /etc/acpi/eeepc/models/acpi-eeepc-1005PEB-events.conf and try again, adapting the entries in it to your keyboard. Send me the resulting conf file and I'll include it.

Brightness is controlled by the BIOS, so nothing should be done. I think the wifi/bluetooth toggle is the same.

[ghthor]

All keycodes from 1005PE == 1005PEB. I forgot that I had even made a copy of the 1005PE config file.

[nbigaouette]

Ok, I'll copy it in the repo.

[nbigaouette]

Is there something else not working that needs to be fixed with the 1005PEB?

[ghthor]

I don't think this is specific to my model, but I don't have any other models to test with. When I press a key, VOLUP for example, acpid registers 2 events.

hotkey ASUS010:00 00000015 00000001
button/volumeup VOLUP 00000080 00000000 K

acpi-eeepc-generic is responding to the hotkey ASUS010:00 00000015 00000001 event and then sends a notification about the second event having an undefined group/action. So, I guess the kernel module is now generating the button/volumeup VOLUP 00000080 00000000 K event which x.org can bind to a virtual keycode.

Because x.org can now bind all these keys(At least for my model) to virtual keycodes the acpid response portion of this package seems obsolete.

[nbigaouette]

Ok I can understand that two events will confuse the package.
On my 1000 I don't get two events generated, only one per key: I don't get the VOLUP for example, only the 00000015.
Could that be a bug with the eeepc_laptop module? On that your model, being newer, has more feature than mine?

[ghthor]

I guess it could be a bug with the eeepc_laptop module. Does your model generate keycodes that can be bound to keysyms by x.org?

[nbigaouette]

Some do, some don't...
The 4 shortcuts at the top all do except the second (XF86ScreenSaver, XF86Launch2, XF86Launch3).
F1 (sleep): no
F2 (wifi): XF86WLAN
F5, F6 (brightness): no
F7: NoSymbol
F8: no
F9: XF86Launch1
F10, F11, F12: XF86AudioMute, XF86AudioLowerVolume, XF86AudioRaiseVolume

[ghthor]

That is very similar to what I have.

Readings from
$ xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
F1 (sleep): nothing
F2 (wifi): 246 XF86WLAN
F3: 191 XF86Tools
F4: 192 XF86Launch5
F5, F6 (brightness): nothing
F7: 253 NoSymbol
F8: 235 XF86Display
F9: 156 XF86Launch1
F10: 121 XF86AudioMute
F11: 122 XF86AudioLowerVolume
F12: 123 XF86AudioRaiseVolume

[ghthor]

I'll look into the eeepc_laptop module to understand what the intended behavior is and why acpi_listen has 2 events for some of the key presses.

[nbigaouette]

Great, thanks!

[ghthor]

Ok after wading through the kernel module code this is what I've found. The eeepc-laptop module calls [1] sparse_keymap_report_event [2] which then calls into input_event,input_report_key. I think this is what produces the output that acpi_listen receives, but I'm not sure.

I noticed that wmi and asus_wmi modules were being loaded and I thought this conflict may have been the problem. The reason they were being loaded was because the kernel was trying to load eeepc_wmi which depends on wmi and asus_wmi but eeepc_wmi failed to load due to eeepc_laptop being loaded already. I blacklisted these 3 modules, but the acpi_listen output stayed the same.

I discovered that my bios was really out of date (706) and updated this to (1202) but this didn't change the acpi_listen output.

BUT the bios update did make the display brightness buttons function correctly with the eeepc_wmi module loaded instead of eeepc_laptop. Because of this and the fact that I believe eeepc_wmi is supposed to replace eeepc_laptop in the future and also all the keys are being reported by x.org so they can be bound to keysyms I'm just going to use the eeepc_wmi module and use your scripts as reference for binding functions to the x.org keysyms.

[1] https://github.com/torvalds/linux/blob/master/drivers/platform/x86/eeepc-laptop.c#L1258
[2] https://github.com/torvalds/linux/blob/master/drivers/input/sparse-keymap.c#L311

[nponeccop]

I found a solution. It's possible to load eeepc-laptop module instead of eeepc-wmi and asus-wmi, and all keys work like before. It works with 3.17 and 3.14 (linux-lts) kernels. Note that 3.17 kernel has a bug that causes eee and many other machines freeze after going out of suspend, so first step is to install linux-lts in addition to linux and add a boot manager entry to try LTS.

Then you need a weird combination of kernel command line options. I'm still investigating which of them are essential. Note that the problem is not only keys, but also caps lock, wifi and hdd leds not working with default kernel command line.

Here is my current solution. It would be nice if you could try and report if it worked for you.

acpi_osi=Linux video.use_native_backlight=0 video.brightness_switch_enabled=0 acpi_backlight=vendor. Append these to your kernel command line.

[tumpio]

Is it possible to work acpi-eeepc-generic to function with eeepc-wmi module?

That is loaded on 1215B, and trying to load eeepc-laptop gives no such device error:

modprobe: ERROR: could not insert 'eeepc_laptop': No such device

[ghthor]

The eeepc_laptop module has been deprecated in favor of the asus-wmi module. Last I checked my eeepce had everything working as expected using the asus-wmi module and NOT using this set of ACPI based listeners.

You should load the wmi's set of modules can check that x.org is outputing the correct keysyms for each of the func keys. If it isn't, then I don't know what could be wrong -

[tumpio]

ok, thanks for your reply ghthor.

[nbigaouette]

As ghthor mentioned, I believe acpi-eeepc-generic is not required anymore. The kernel should emit the proper symbols that window managers interpret directly, without needing acpid.