>thinkpad_acpi: standard ACPI backlight interface available,
>not loading native one...
>/sys/class/backlight/thinkpad_screen/brightness is no longer present
This means that T61p backlight control supports the ACPI video extension.

>So I go hunting around and find
>       /sys/class/backlight/acpi_video0/
>       /sys/class/backlight/acpi_video1/
These are the ACPI video backlight control I/F.

>When I set that to 10, the screen's brightness is not reduced.
Please apply the patch in http://bugzilla.kernel.org/show_bug.cgi?id=9277#c5
and try again.

This isn't considered as a regression by the maintainer of the code in question (ref. http://marc.info/?l=linux-acpi&m=119876135809970&w=2).

Yes, I noticed this thread,
so Henrique, we will not fix it, will we?

No, since "fix it" means actually breaking it further *as things stand right now*.  If we deploy an improved backlight interface that actually informs userspace of all the details it needs to know to handle an n-to-m mapping of sysfs backlight instances to physical backlight devices, even with n>1 and m>1, then I will revert the default.

But I do intend to change something in this area. I am going to place the thinkpad in ACPI mode, which means it will be *much* easier to use e.g. xbacklight, even if one does not load the ACPI video.c driver.

New Lenovo Thinkpads change behaviour after you load video.c once, until the next boot, even if you unload it...   so you can guess we have a major mess in the backlight area which is really difficult to debug, so I have to always ask the users to cold boot into single-user mode, with x.org disabled (so that it doesn't even attempt to load), and with video.ko renamed to something else so that nothing loads it... :-(

>I am going to place the thinkpad in ACPI mode,
>which means it will be *much* easier to use e.g. xbacklight,
>even if one does not load the ACPI video.c driver
I'm not quite clear about this.
what does ACPI mode mean?
And what's the relationship between xbacklight and ACPI video.c driver, usespace get acpi event and use xbacklight to change the brightness level?
>New Lenovo Thinkpads change behaviour after you load video.c once
could you send me an acpidump of such kind of laptops please?
And what's the different before and afater loading the video.c driver?

ThinkPad ACPI backlight mode means the firmware doesn't poke the hardware at all when the user presses brightness up/down hot keys.

Instead, it just sends the 0x86 and 0x87 notifications to the relevant ACPI display device.  You enable it in a thinkpad when you *execute* any _BCL method it provides.

ACPI video.c should work fine in a thinkpad... *if* it is working at all, and as long as:

1. video.c is "fixed" to do rounding to the nearest _BCL-provided level instead of setting whatever the user echoed to sysfs (some ThinkPads deal well with it, others apparently don't).

2. We add the capability to tell video.c to NOT export a backlight interface, since it does more (such as video output selection), and *userspace* can be very stupid and do extremely braindamaged things that are not easy at all to debug for, but become apparent if you take away the backlight interfaces it is using to break brightness control :-)

3. We fix the issue video.c has with inactive ACPI nodes that it is exporting interfaces for.

As for Xorg and xbacklight, it is sort of a bit of a mess.  The very newest versions, I am told, can be configured to:

1. talk to the kernel backlight interface (which one(s) is not properly configurable yet).
2. talk directly to the hardware
3. talk to ACPI(?) or maybe to both. I am not clear on what the third option is.

For Lenovo thinkpads, either (1) or (2) is fine if ACPI video is working.  Doing both breaks things badly quite fast.  Which is why I don't enable thinkpad-acpi's backlight interface on Lenovo thinkpads by default anymore...

Hi, Henrique,

>1. video.c is "fixed" to do rounding to the nearest _BCL-provided level 
patch is in a 2.6.23-rc8.
>2.tell video.c to NOT export a backlight interface
... I think we should export the backlight control I/F to user space, export the brightness change notifications to user space via input layer. then we can stop the acpi video driver action upon hotkey press. that's what X want so that X can handle the backlight stuff all by itself.

>since it does more (such as video output selection), 
video output selection?
I don't think users can do this via the backlight sysfs I/F.
But I think the ACPI video I/F for video output switch (/sys/class/video_output/...) should be removed as these ACPI control methods for display switching seldom works.

>3. We fix the issue video.c has with inactive ACPI nodes that it is exporting
interfaces for.
I think this is with the high priority.
Thomas and Mattehw already got the proposal for this.

>1. talk to the kernel
>2. talk directly to the hardware
>3. talk to ACPI(?) or maybe to both.
I asked a Graphics guy and he said that xbacklight can be be configured to:
1. NATIVE mode, poking the registers
2. LEGACY mode, write the PCI config space.
3. COMBO mode, try both 1 and 2.
4. KERNAL mode, poking the /sys/class/backlight/..., even may looking for /sys/class/backlight/thinkpad_acpi/...

backlight control should go via ACPI video driver on this laptop.

On Intel-GPU-based *61, NATIVE and LEGACY modes are even-better, I am told. Something about 256 levels of backlight control instead of 16.

I agree that the recent changes to video.c are a good way to address the issue.

Hi, I'm junior user jidanni.

You see I was just about to submit this Debian bug

  Package: xserver-xorg-core
  Version: 2:1.4.1~git20080131-3

  I note when one leaves X windows for tty1 via ALT CTRL F1, and then returns
  to X windows via ALT F1 (or ALT CTL F1), the screen is now at full
  brightness. One has to manually set it back to the way it was.

  My computer is an IBM Thinkpad R50e. Brightness is diminshed by hitting "Fn End".

  Other times I find myself having to turn the brightness back down
  again: power up, starting xdm, etc.. Seems the current brightness
  settings are not being saved, if indeed there is such a place in
  hardware to do that -- and not being saved even for a brief trip to
  tty1 and back. Here is what gets appended:

  ...(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)...

When I thought maybe I should install acpid, even though I never
suspend, etc. OK, after installing acpid my brightness is remembered,
at least for visiting tty1 so far, but now I see these messages:

(EE) intel(0): write to /sys/class/backlight/thinkpad_screen/brightness for backlight control failed: Invalid argument

Just wanted to let you know.

The R50e is a *very* different beast than the *61... If you want, we can easily determine whether it does brightness control through the GPU (and, therefore, something the X.org server could be interacting with), or through the EC.

To save the brightness setting on a R50e, you must make sure all brightness setting is done by the BIOS or through ACPI.  When using thinkpad-acpi, it must be using brightness_mode=3 (which IS the default on a R50e, as far as I know).

Anyway, I doubt your R50e problems have the same root cause as the *61 problems.  In order to avoid mixing what is probably two different issues, you might want to open a new bug report IF you have reasons to believe it is a kernel issue.

But I would really appreciate if you post your problem to the linux-thinkpad mailinglist first, and talk to other R50e users (I am also on that list and will monitor the thread).  If it ends up as being a kernel issue, we open a new bug here.

Zhang,

Could you mark this bug as closed, please?  I don't have the access rights to do it.