On Mon, 2010-09-13 at 09:54 +0200, Michel D?nzer wrote:
> On Mit, 2010-09-08 at 12:32 -0400, Matthew Garrett wrote:
> > From: Michel D?nzer
> >
> > Allows e.g. power management daemons to control the backlight level.
> > Inspired
> > by the corresponding code in radeonfb.
> >
> > (Updated to
On Mon, 2010-09-13 at 09:54 +0200, Michel Dänzer wrote:
> On Mit, 2010-09-08 at 12:32 -0400, Matthew Garrett wrote:
> > From: Michel Dänzer
> >
> > Allows e.g. power management daemons to control the backlight level.
> > Inspired
> > by the corresponding code in radeonfb.
> >
> > (Updated to
On Mit, 2010-09-08 at 12:32 -0400, Matthew Garrett wrote:
> From: Michel D?nzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
> (Updated to add backlight type and make the connector the parent device - mjg)
>
> Sign
On Mit, 2010-09-08 at 12:32 -0400, Matthew Garrett wrote:
> From: Michel Dänzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
> (Updated to add backlight type and make the connector the parent device - mjg)
>
> Sign
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi
or platform mechanism w
On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett wrote:
> On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
>
>> The only problem with this is that not all oems use the internal
>> backlight controller; systems that don't need to use the acpi methods.
>
> That's why we expose the backli
On Wed, Sep 8, 2010 at 12:32 PM, Matthew Garrett wrote:
> From: Michel D?nzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
The only problem with this is that not all oems use the internal
backlight controller; system
From: Michel D?nzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel D?nzer
Signed-off-by: Matthew Garrett
Cc: dri-devel at
On Wed, Sep 8, 2010 at 1:03 PM, Matthew Garrett wrote:
> On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
>
>> The only problem with this is that not all oems use the internal
>> backlight controller; systems that don't need to use the acpi methods.
>
> That's why we expose the backli
On Wed, Sep 08, 2010 at 12:58:32PM -0400, Alex Deucher wrote:
> The only problem with this is that not all oems use the internal
> backlight controller; systems that don't need to use the acpi methods.
That's why we expose the backlight type. Userspace should use the acpi
or platform mechanism w
On Wed, Sep 8, 2010 at 12:32 PM, Matthew Garrett wrote:
> From: Michel Dänzer
>
> Allows e.g. power management daemons to control the backlight level. Inspired
> by the corresponding code in radeonfb.
>
The only problem with this is that not all oems use the internal
backlight controller; system
From: Michel Dänzer
Allows e.g. power management daemons to control the backlight level. Inspired
by the corresponding code in radeonfb.
(Updated to add backlight type and make the connector the parent device - mjg)
Signed-off-by: Michel Dänzer
Signed-off-by: Matthew Garrett
Cc: dri-devel@lis
12 matches
Mail list logo
