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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1172164119.5837.98.camel@localhost.localdomain>
Date:	Thu, 22 Feb 2007 17:08:39 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Alex Romosan <romosan@...orax.lbl.gov>,
	Yaroslav Halchenko <kernel@...russian.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-fbdev-devel@...ts.sourceforge.net,
	James Simmons <jsimmons@...radead.org>
Subject: Re: no backlight on radeon after recent kernel "upgrade"s

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@...ys.net>.

> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/