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

[Henrique de Moraes Holschuh]

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.

> > 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.

> 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.

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.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh