On Fri, 2008-05-02 at 23:18 +0200, Tomaz( S(olc wrote: > Ok, that makes sense. But isn't this just a better way to do the > acpid/acpi_fakekey combination? I understand input layer will only > change the way g-p-m gets notified of the Fn-F4 key press, but won't do > anything to inform g-p-m that the brightness setting is handled in > hardware and that it should react to that keypress in a different manner.
Yes, I think you are right about it just being a better way of handling acpid/acpi_fakekey. I haven't actually looked into how this is handled before. If you use the input layer, or faking it with acpi_fakekey, I don't think it should matter. What is needed is a quirks file for the Eee, describing the hotkeys. This should work even if brightness is set in hardware, it will simply inform g-p-m of the new brightness, and it can adjust itself. The scripts shipped in eeepc-acpi-scripts does not call acpi_fakekey to set KEY_BRIGHTNESSDOWN etc. so it's no wonder it doesn't work. Well, at least that's my understanding on how things might work :) > I was under impression that the code I reintroduced with this patch just > got lost somehow (I couldn't find any note in the changelog why it was > removed). Interesting thing is that there is still an if statement in > the code that basically checks for the same thing. Interesting, it's probably a good idea to bring this up directly with upstream. -- Cheers, Sven Arvidsson http://www.whiz.se PGP Key ID 760BDD22
signature.asc
Description: This is a digitally signed message part
