On Wed, Apr 14, 2010 at 9:29 PM, Zhang Rui <rui.zhang@xxxxxxxxx> wrote: > On Thu, 2010-04-15 at 10:10 +0800, Chris Bagwell wrote: >> On Wed, Apr 14, 2010 at 8:42 PM, Zhang Rui <rui.zhang@xxxxxxxxx> wrote: >> > On Thu, 2010-04-15 at 09:30 +0800, Zhang Rui wrote: >> >> On Thu, 2010-04-15 at 06:18 +0800, Chris Bagwell wrote: >> >> > On Wed, Apr 14, 2010 at 12:26 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: >> >> > > On Wed, Apr 14, 2010 at 12:14:04PM -0500, Chris Bagwell wrote: >> >> > > >> >> > >> Does the acpi-video logic not have logic on its own to send key >> >> > >> events? So I guess laptops that don't have custom modules to handle >> >> > >> this type of stuff don't get visual feedback from gnome-power-manager? >> >> > > >> >> > > It does, but it's dependent upon the firmware sending them. >> >> > >> >> > I think the following tells me firmware is sending them. If I leave >> >> > acpi_osi="Windows 2009" so that eeepc_laptop doesn't get loaded, I see >> >> > events like this on /pro/acpi/event: >> >> > >> >> > video LCDD 00000087 00000000 >> >> > video LCDD 00000087 00000000 >> >> > video LCDD 00000086 00000000 >> >> > video LCDD 00000086 00000000 >> >> > >> >> > Thats a couple decreases followed by a couple increases. >> >> > >> >> I have a EEEpc 1005PE. I'm looking at the backlight problem on this >> >> machine, but it seems to be different from this one. >> >> >> >> The hotkey seems to work perfectly when ACPI video driver is loaded. >> >> i.e. I get a single hotkey event when pressing the hotkey and the value >> >> of /sys/class/backlight/acpi_video0/brightness changes correctly. >> >> >> >> The only problem I get is that the actual brightness does not change >> >> consistently. >> >> say, there are 15 brightness levels in all, >> >> level 0, level 5 and level 12 give me a screen with lowest brightness. >> >> If I want to get maximum backlight, I need to set it to level 4 or level >> >> 11. >> >> I'm curious, do you still see this issue if you first kill >> gnome-power-manager first? >> >> >> >> > Oh, this have already been fixed in the latest BIOS. >> >> Wasn't fixed in my case. I'd be curious to here if it fixes for you. >> > no, the problem still exists. > I misread your comment at > https://bugzilla.kernel.org/show_bug.cgi?id=15182#c33 > >> > >> > Chris, >> > do you mean you get duplicate hotkey events after upgrading the BIOS? >> >> With latest firmware, I get zero hotkey events over /dev/input/event* >> unless I add acpi_backlight=vendor to boot options. > > I just upgrade the BIOS to 1003, and I can still get input event > from /dev/input/event4 (which is ACPI video bus). > and there is no duplicate input events when pressing hotkey. > > thanks, > rui OK, I played around a little more and can now reproduce what your seeing. What I need to do is boot such that eeepc-laptop is not loaded. Thanks for mentioning exact device name /dev/input/event4. Its interesting that mine is registered so late at /dev/input/event7. input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7 ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) If I bootup with no options then eeepc-laptop is not loaded. In this case, I do see events on input7 (I previously stated that I didn't. Sorry about that). In this case, it appears that gnome-power-manager gets involved (I see the percentage bar updates) and the screen does those funky non-linear updates. If I bootup with just acpi_osi="!Windows 2009" then eeepc-laptop does get loaded. In this case, the input7 still gets created but no events are sent on it. Also, an input9 device is created for eeepc-laptop and brightness keys are NOT sent over it as well. In this case, the brightness levels are linear as long as I use Fn-keys only (not the /sys/* interface). And finally, if I boot with both acpi_osi="!Windows 2009" and acpi_backlight=vendor then I see events on eeepc-laptop input9 and gnome-power-manager seems to get involved as well but this time the display is updated linearly. So in summary, I think it tells me this: 1) If ACPI only is involved then brightness controls work fine. By ACPI only, I mean using Fn-keys for brightness and doing something to prevent software like gnome-power-manager from getting involved with /sys/* interface. 2) Anything that writes to /sys/class/backlight/acpi_video0/brightness works non-linearly. 3) If you keep software from writing to /sys/class/backlight/acpi_video0/brightness then brightness changes made with Fn-keys do not get reflected into any of those acpi_video0 files. Writing to those files controls brightness non-linearly and show up when you read back. 4) If I use acpi_backlight=vendor then I can access /sys/class/backlight/eeepc/brightness and it works linearly. Things like gnome-power-manager work good with this interface. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
