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

[Richard Purdie]

On Thu, 2007-02-22 at 14:34 -0200, Henrique de Moraes Holschuh wrote:
> 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?

Yes, it can have an Acked-by: Richard Purdie <rpurdie@xxxxxxxxx>.

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

Which it can't in the corgi_bl case (excluding poking things
like /dev/mem). Its safe to assume it has exclusive access.

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

Right, I'd be against such a driver. On the embedded hardware we can
safely assume there is nothing else playing with the brightness settings
though and such a driver is perfectly valid.

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

If the backlight controls would then power off the backlight properly
that would be desirable as we've have a more standard interface.

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/