Re: no backlight on radeon after recent kernel "upgrade"s

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Thu, 22 Feb 2007, Richard Purdie wrote:
> If you really care, add a a call to backlight_update_status() after you
> set the brightness attribute like some of the other drivers have. The

I will.  Do you ACK the patch, then?

> Have a look at what corgi_bl does. It can know what state it set the
> hardware too as it keeps track itself, it just can't read that state

You are assuming nothing else is changing the hardware behind the driver's
back.  I am against such assumptions when they can be avoided, but that's a
particular PoV and not much more than that.  IMHO, if you cannot query the
hardware, you shouldn't provide a way to query the current brightness that
will be right only if nobody else messed with the device.

Maybe for corgi, that doesn't hold much strength, but for stuff tied to
ACPI, it does.  And in a ThinkPad's case, where even writes to /dev/nvram
can change the brightness, well, if there weren't a way to ask the EC the
current real brightness, there is NO way I'd be implementing it based on a
memory cache.

> from the hardware. Note how there is extra code in it to handle a power
> limit on the backlight under certain conditions and how this is fed back
> through the class through the get_brightness method.

I will read the corgi driver code, it looks interesting.

> Adding one line of code (admittedly slight more due to error handling),
> is hardly that much code duplication.

No, it really isn't much trouble.  Which is why I wrote a patch right away.

> > Howerver, I *do* strongly wish for a way to combine various drivers into a
> > single backlight device, where radeon/intelfb takes care of some stuff,
> > ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc.  Also, a
> > standard naming for the builtin screen(s) would help, calling it "ibm",
> > "asus", "sony" is not good IMHO.
> 
> I wasn't aware of this problem. If some devices need bits from both
> raedon/whatever and acpi, the current implementations are just plain
> wrong. Its not really a backlight class problem and more of an
> implementation and interaction problem between acpi and the framebuffer
> drivers. They should be presenting and registering *one* backlight class

I.e. we should add hooks to the framebuffer drivers?  It would work, that's
for sure.

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