[Debian-eeepc-devel] brightness keys and keycodes [was: Beta 1 of eeepc-acpi-scripts 1.1.0 available for testing]

[Damyan Ivanov]

-=| Darren Salt, Sat, Apr 04, 2009 at 10:44:38PM +0100 |=-
> I demand that Sven Arvidsson may or may not have written...
> 
> > On Sat, 2009-04-04 at 00:25 +0100, Darren Salt wrote:
> >> http://bugs.debian.org/522472
> 
> > Great!
> 
> > I did notice one thing after playing around with it some more. If
> > brightness is set to maximum and I try to increase it again, I don't get an
> > OSD. (The same goes for minimum of course)
> 
> This is "by design": there isn't a KEY_BRIGHTNESSUNCHANGED. I could have it
> send KEY_BRIGHTNESSDOWN if already at minimum or KEY_BRIGHTNESSUP if already
> at maximum, I suppose, but I don't really see much point.
> 
> (The BIOS reports 0x20+brightness, as can be seen if you run acpi_listen and
> alter the brightness. This is easier in that the brightness doesn't then have
> to be read for reporting purposes...)
> 
> > This is different from the volume buttons where the OSD always is shown,
> > even if I'm already at max.
> 
> It should be reasonably easy to tweak this to avoid this reporting of no
> change (compare amixer before and after)...
> 
> > Not sure if this is problem with g-p-m or the buttons, anyway it's a
> > minor problem.
> 
> Fine; I'll leave both alone for now, but I'm listening should somebody try to
> convince me one way or the other...

I'll try convincing you :)

In short, I think pressing a brightness/volume key shall report the 
"key pressed" event regardless of the actual brightness/volume state 
in the hardware.

Compare brightness with volume level. On an ordinary "multimedia" 
keyboard, there are keys that are used to control the volume level. 
These are ordinary keys, emitting keycodes as any other key on the 
keyboard. The task for changing the volume is in the software and is 
completely detached from the hardware.

In the same line of thought, brightness control keys shall emit 
keycodes regardless of the current brightness state. The fact that the 
hardware possibly adjust the brightness is reported in parallel by the 
acpi subsystem anyway.

In my understanding, g-p-m does not try to adjust the brightness in 
response to these codes, just to report it, so it won't hurt if 
KEY_BRIGHTNESSUP event happens if the brightness is already at maximum 
-- the only effect would be showing the brightness level meter.

The fact that the brightness is at minimum/maximum is important by 
itself and silencing the keys if nothing is to be done may confuse 
users thinking that something does not work ("no meter shown, there 
used to be one before, what's wrong?").


-- 
dam            JabberID: dam at jabber.minus273.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20090409/172fc05a/attachment.pgp>