[ltp] thinkpad-acpi release 0.18-20071203 uploaded to ibm-acpi.sf.net

[Yves-Alexis Perez]

On mar, 2007-12-04 at 16:07 -0200, Henrique de Moraes Holschuh wrote: 
> On Tue, 04 Dec 2007, Yves-Alexis Perez wrote:
> > > You should not need to do *anything* of the sort.  video.c should change the
> > > brightness *by itself*.  If things try to handle backlight changes twice, it
> > > causes borkages like the one you describe.
> > 
> > Well, if I don't manage brightness change myself, nobody cares to do it. And
> > the delay is only after a first sleep/resume.
> 
> You have to test that in console mode, without loading X.  As I said, Xorg
> is likely telling the BIOS to keeps its hands off, which could well confuse
> video.c, the thinkpad firmware, Xorg, or whatever.  This thing is not well
> debugged yet.
> 
> If no video.c -> no backlight changes; video.c -> backlight changes in
> console mode, then everything is working as it should when X.org is out of
> the picture.

Without xorg running, there is no backlight change, with or without
video.c. 
> 
> > > Now, if video.c is NOT changing brightness, it is because either it is
> > > buggy, or because x.org messed with the BIOS scratch registers, and the BIOS
> > > is honouring that and not changing the brightness.  Unless X.org and video.c
> > > are communicating and video.c knows it is not to try to change brightness,
> > > weird things might happen.  Ask the X.org people about it, I don't know
> > > enough about this :-(
> > 
> > Mhmh ok. I'll try to report a bug against xserver-xorg-video-intel. If
> > KEY_BRIGHTNESSUP/DOWN are correctly reported, do you confirm that the correct
> > behavior _is_ for intel driver to manage the backlight itself?
> 
> You should *NOT* have KEY_BRIGHTNESSUP/DOWN reports on a Lenovo *61
> thinkpad, ever.  It reports ACPI standard backlight brightness change
> events.

> 
> If something is producing KEY_BRIGHTNESSUP/DOWN events, you better track it
> down to check if it is sane.  One of the fixes in thinkpad-acpi
> 0.18-20071203 was exactly to STOP producing these events over the input
> layer by default.

corsac@hidalgo: sudo input-events 4
/dev/input/event4
   bustype : BUS_HOST
   vendor  : 0x0
   product : 0x6
   version : 0
   name    : "Video Bus"
   phys    : "LNXVIDEO/video/input0"
   bits ev : EV_SYN EV_KEY

waiting for events
22:03:19.325677: EV_KEY KEY_BRIGHTNESSUP pressed
22:03:19.325682: EV_SYN code=0 value=0
22:03:19.325688: EV_KEY KEY_BRIGHTNESSUP released
22:03:19.325690: EV_SYN code=0 value=0
22:03:19.515716: EV_KEY KEY_BRIGHTNESSDOWN pressed
22:03:19.515723: EV_SYN code=0 value=0
22:03:19.515728: EV_KEY KEY_BRIGHTNESSDOWN released
22:03:19.515731: EV_SYN code=0 value=0

This is with video.c loaded. If I unload it, no more /dev/input/event4.

> 
> > But there, I'm confused. Who should adjust brightness? gnome-power-manager (or
> > other client) trough hal, or intel driver?
> 
> Here is the proper way for these things to work.  Braindamaged, shortsighted
> "let's hack on it"-style lack of design on all levels (kernel, HAL, X.org,
> desktop-environments) may make it impossible to archieve right now... or
> not.  I am not fully uptodate on how things are implemented on every level
> right now, but maybe we have fixed most of the crap already.
> 
> When X.org is NOT active:
>  1. video.c kernel driver must agree with whatever is the kernel framebuffer
>  throught the framebuffer driver and backlight drivers on who should handle
>  backlight changes, and should communicate to do it.
> 
>  2. Only one driver in the kernel should be told to change the backlight
>  level, and the others should stay quiet.
>  
>  3. HAL and acpid should stay well out of the way if any kernel drivers are
>  handling backlight changes.  Otherwise, it should tell all kernel drivers
>  to not do it automatically (how?), and do it through whatever helper (e.g.
>  through thinkpad-acpi).
> 
>  On thinkpads in a very new kernel, the above should just work, as long as
>  the framebuffer drivers do nothing to the backlight. thinkpad-acpi behaves
>  well, so it won't break anything.  Depends only on HAL and acpid not doing
>  something utterly stupid (like telling thinkpad-acpi to change the
>  brightness!) and breaking everything.  You can test that by killing hald
>  and acpid if needed.

Even without hal, acpi and xorg running, it doesn't work (but I think
it worked at one time, can't remember when.
> 
> When X.org is active:
>   1. video.c kernel driver must be informed to not attempt to change
>   brightness for any devices X.org knows how to change brightness.
> 
>   2. Nothing in userspace should be trying to change the backlight level
>   behind video.c and X.org's backs, through e.g. thinkpad-acpi.
> 
>   3. ACPI standard brightness interface must be used to inform the firmware
>   of the same as in (1)
> 
>   4. Either HAL or X.org (but NOT both!) should track down standard ACPI
>   brightness change events and call xbacklight to do it *on the proper
>   backlight device* (there could be more than one), and this is *NOT*
>   trivial to do right now AFAIK.  If it can't be done properly, do it
>   through something akin to (5) below.
> 
>   5. HAL or desktop environment should map KEY_BRIGHTNESSUP/DOWN to none,
>   one, or more than one *user-configurable* target: each of the backlight
>   devices, xbacklight for the current server display, xbacklight for a
>   specific display.

Hmhmh, ok, but in the end, I don't know where is the problem. acpid
reports events from brightness keys:

Dec  4 22:11:02 hidalgo acpid: received event "video LCD0 00000086 00000000" 
Dec  4 22:11:02 hidalgo acpid: notifying client 3583[101:104] 
Dec  4 22:11:02 hidalgo acpid: notifying client 3697[0:0] 

I don't know if I should catch them or not (I guess not, but nothing
else work). I could get rid of acpid, but I currently need it to put
the thinkpad to sleep when it receives a LID event.

Sorry for this long thread (again)

Cheers, and thanks for your time,
-- 
Yves-Alexis Perez