See attached build log. (Please do not complain about the need for looking at the build log until you can provide an easy way to open bugs with the correct data picked out of a tinderbox log. Thanks.)
Created attachment 249499 [details] Build log
If I remember correctly, this package isn't needed for a long time with recent kernels
I use app-laptop/acpi4asus and at least a year ago it was the only way I discovered where I could gain control of the backlighting on my Asus laptop keyboard. Please provide instructions on what is required in the kernel and I'll be happy to test that indeed I can live without the package. I currently run vanilla-source-3.2.7 on this laptop. Thanks!
I am now far from my old asus laptop but, if I don't misremember, the option was: CONFIG_ASUS_LAPTOP (remember that you can find the route from menuconfig simply pressing "/" and writing the option) I am 100% sure it replaces acpi4asus for new kernels and is properly maintained while the former is stalled for ages
(In reply to comment #2) > If I remember correctly, this package isn't needed for a long time with > recent kernels There's also a user-space component that can be used to handle special key events (that runs in unprivileged-user context, so it's not simply replaced by acpid). It's not really specific to the Asus driver though, it just takes events from acpid and handles them according to the user's own configuration, so maybe there's some other alternative - if anyone knows one, it would be nice to mention it in the masking message.
In my asus laptop I am sure special Fn keys were still working to, for example, rise up and down brightness
I have removed acpi4asus as an emerge package and still have backlighting, which is the only thing I actually require in daily use. However at this time none of the function keys do anything. I cannot dim the display or the keyboard lighting using Fn+Function_Key. I will continue to investigate what's required to get this working as it did work a long time ago. I have no idea if it was working recently so I cannot blame the lack of this functionality on the removal of acpi4asus
(In reply to comment #6) > In my asus laptop I am sure special Fn keys were still working to, for > example, rise up and down brightness I just tested and on mine, those are the only two that /don't/ have a built-in effect of some kind - all the others at least generate key events (perhaps due to X improvements since I last checked / since the daemon was written?) But they also don't seem to be picked up by acpid, so the acpi4asus daemon wouldn't see them either. Anyway, objection withdrawn as far as I'm concerned.
At this point I'm also removing any opposition I previously had to getting rid of asus4acpi. I'm not seeing any difference using the internal driver for any kernel I've actually tested both soutions on. However there is the potential for aa problem coming along one of these days. I run vanilla-sources as it allows me some real-time scheduling capabilities. (I used to use rt-sources) Anyway, with the internal Asus driver up through 3.2.7 I get the following key mappings for the functions keys on my laptop and as best I can tell all keys except Fn-F5 create an ACPI event: vanilla-sources-3.2.7 slinky ~ # acpi_listen button/sleep SLPB 00000080 00000001 hotkey ATKD 0000005d 00000000 hotkey ATKD 0000007e 00000000 hotkey ATKD 000000c5 00000000 hotkey ATKD 000000c4 00000000 hotkey ATKD 0000002e 00000000 hotkey ATKD 0000001a 00000000 hotkey ATKD 00000034 00000000 hotkey ATKD 00000033 00000000 hotkey ATKD 00000034 00000001 hotkey ATKD 00000033 00000001 hotkey ATKD 00000061 00000000 hotkey ATKD 0000006b 00000000 hotkey ATKD 00000032 00000000 hotkey ATKD 00000032 00000001 hotkey ATKD 00000032 00000002 hotkey ATKD 00000031 00000000 hotkey ATKD 00000031 00000001 hotkey ATKD 00000031 00000002 hotkey ATKD 00000030 00000000 hotkey ATKD 00000030 00000001 hotkey ATKD 00000030 00000002 hotkey ATKD 00000030 00000003 However for 3.2.9 the only key that produces an ACPI event (as measured using acpi_listen) at Fn-F1. I don't know if this is a kernel regression, an ACPI regression, or just some new way of doing things that requires configuration. WRT Asus laptop users, it would be good to discover & document how to map all the keys and actually get them to work. On 3.2.7 only F1, F11 & F12 do anything. One 3.2.9 it's down to just F1.
That sounds me like a kernel regression you should report on a separate bug report ;)
Through Gentoo or on the LKML?
(In reply to comment #11) > Through Gentoo or on the LKML? Send it to bugs.gentoo.org for now, kernel team will point you to proper place if needed
dropped
