Hi,
while testing linux-next I wanted to reactivate the backlight type patches laying in my build-dir.
Within 2.6.36-rcX cycle I had successfully tested the backlight type patch [1] with an additional patch for radeon by Michel (posted to dri-devel ML, see [2]).
The main patch needs a little refreshing.
v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next (next-20101027)
Kind Regards, - Sedat -
[1] https://patchwork.kernel.org/patch/163971/ [2] https://patchwork.kernel.org/patch/182352/
On Wed, Oct 27, 2010 at 1:06 PM, Sedat Dilek sedat.dilek@googlemail.com wrote:
Hi,
while testing linux-next I wanted to reactivate the backlight type patches laying in my build-dir.
Within 2.6.36-rcX cycle I had successfully tested the backlight type patch [1] with an additional patch for radeon by Michel (posted to dri-devel ML, see [2]).
The main patch needs a little refreshing.
v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next (next-20101027)
Kind Regards,
- Sedat -
[1] https://patchwork.kernel.org/patch/163971/ [2] https://patchwork.kernel.org/patch/182352/
Hi,
I think rfkill has the same problem, on some platforms, the platform driver will add a rfkill switch, but the network (wlan/wimax/whatever) driver may also add one. AFAIK, the platform one is more likely to be able to power down the device completly.
For the current patch, a common pattern seems to be : video/ -> RAW, platform/ -> PLATFORM. Couldn't we make some guess by checking the parent of the backlight instead of doing this by hand for every drivers ?
Thanks,
The parent of the backlight doesn't let you determine whether it's a platform or a firmware interface without heuristics. I'd prefer to explicitly define that.
dri-devel@lists.freedesktop.org