Backlight turned off on Radeon Mobility X600

[leavengood]

This may be a known problem on some ATI chipsets since I saw euan mention it on another bug, but nonetheless:

When I boot up my IBM ThinkPad Z60m I get a very dark screen. Graphics are there but barely visible so the problem seems to be the backlight. The output from listdev for my display controller is:

device Display controller (VGA compatible controller, VGA controller) [3|0|0]
  vendor 1002: ATI Technologies Inc
  device 3150: M24 1P [Radeon Mobility X600]

Attached is my syslog from two boots, with the first boot using the radeon driver and the second using forced VESA mode, which works.

If there is any simple fix or way for me to correct this myself, let me know. I am a developer but certainly not any driver expert, but I'm willing to try.

[euan]

Now that AMD released the docs, there were some changes to this area. I'll see if I can dig them out. I will see if I can supply you with a diff. Might not be too quick though due to current work loads sorry. :(

[scottmc]

Any progress on this one?

[euan]

doubtful. problem is finding people who still use this chipset.

[leavengood]

I still have this machine and would actually like to use it more with Haiku. If there is any simple way to fix it let me know. Like if you can point me to some Xorg sources and say "hey, here on line xxx they set this register which causes the backlight to come on" and then I could put that in our Radeon driver, I'd be willing to try.

Or if you can try something and send me the driver or diff then I can test it.

[leavengood]

Actually I just read some of the ​comments on BeBits for your ATI driver which mention backlight issues on this and other chipsets, and you said that maybe ACPI is controlling the backlight. Maybe with recent fixes and improvements to ACPI it is possible to control the backlight on these chipsets?

Before you spend too much time looking at this I could investigate that first. Maybe we need some sort of ACPI backlight utility first though.

[euan]

after the radeon hd docs where release a lot of info about the past cards could be deduced. One place in particular to look is the BIOS_x_SCRATCH (x = 0 to 8).

Have a look at RADEONInitBIOSRegisters() in xf86-video-ati here:

​http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_driver.c

I'm sure I made patches, or versions that used the latest info on the scratch regs, but not sure if I got feedback or not.

I still don't rule out ACPI integration in the laptop though either. Though I never gained the knowledge to be able to rule it out or not.

[leavengood]

So I upgraded the Haiku on my ThinkPad and it still has the backlight issue. I'm not entirely what the correct approach is for resolving this issue since lack of a backlight makes it difficult to test :)

I do know that using the function key and brightness buttons doesn't help. I was hoping that Haiku might at least handle those buttons and maybe could turn on the backlight with ACPI, but I guess not. I may look a bit at the backlight code in ACPI, but maybe looking over the Xorg sources is the way to go. If anyone reading on the bugs list (mmlr?) has an idea, please chime in.

Turning on VESA results in a non-native resolution which is why I am so eager to get this fixed. It pretty much makes this laptop unusable for Haiku, when most other ThinkPads seem to work quite well.

[mmlr]

Replying to leavengood:

I do know that using the function key and brightness buttons doesn't help. I was hoping that Haiku might at least handle those buttons and maybe could turn on the backlight with ACPI, but I guess not. I may look a bit at the backlight code in ACPI, but maybe looking over the Xorg sources is the way to go. If anyone reading on the bugs list (mmlr?) has an idea, please chime in.

If the backlight works in VESA but doesn't when the ATI driver is in use then it's most probably not ACPI who's doing the backlight configuration. Of course it's possible, but it'd seem strange to me that it'd behave differently depending on the driver since as far as I've read the relevant ACPI spec parts I'd have guessed that the ACPI backlight stuff is pretty much device/driver independent.

So looking at the suggested scratch registers in RADEONInitBIOSRegisters() would seem more promising to me.

[tqh]

It is probably ACPI and not graphics driver that controls backlight. Backlight is more part of a display than gfx driver. Try booting with ACPI disabled. Btw, writing ACPI drivers is easy and fun ;)

ACPI Spec 4.0a Chapter B.6 list these functions and more:

• _BCL (Query List of Brightness Control Levels Supported)
• _BCM (Set the Brightness Level)
• _BQC (Brightness Query Current level)

[leavengood]

Michael makes a good point that if VESA causes the backlight to work but the ATI driver doesn't, it must be a graphics driver issue. Where in the Haiku driver architecture would the scratch register code be?

I do think it still would be good to have a backlight ACPI driver (maybe even with keyboard hotkey support) so I may work on that too eventually. Though I can do that on any laptop I suppose, not just this one.

[anevilyak]

Replying to leavengood:

Michael makes a good point that if VESA causes the backlight to work but the ATI driver doesn't, it must be a graphics driver issue. Where in the Haiku driver architecture would the scratch register code be?

That code is in ​http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/graphics/radeon/CP_setup.c , it's not really something that's generic to the driver architecture, rather a feature of the Radeon GPU.

Edit: see also ​http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/accelerants/radeon/ , they're touched in flat_panel.c and EngineManagment.c

[leavengood]

As an update, disabling ACPI didn't help (the backlight was still off.)

Based on Rene's tips I tried changing the accelerant to disable the driver handling the backlight (which seems to be what the Xorg driver does, at least at first) but that didn't help. It also didn't help to explicitly enable the driver handling the backlight.

When I get a chance I can attach a patch showing what I did, which maybe more experienced graphics driver developers can look at to see if I just did it totally wrong.

[euan]

Replying to anevilyak:

That code is in ​http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/drivers/graphics/radeon/CP_setup.c , it's not really something that's generic to the driver architecture, rather a feature of the Radeon GPU.

Edit: see also ​http://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/accelerants/radeon/ , they're touched in flat_panel.c and EngineManagment.c

You want to be messing with the RADEON_BIOS_6_SCRATCH register and friends, not any of the other SCRATCH regs, those are for the command processor DMA stream sync etc. So specifically only RADEON_BIOS_*_SCRATCH. AFAIK they are only used in flat_panel.c

Euan

[euan]

Closing these tickets due to the passing of time. Please consider opening new tickets with current syslogs if still using these graphics accelerators and seeing these issues.