Fixing the kernels backlight API

Fixing the kernels backlight API

[Hans de Goede]

Hi All,

Quick self intro: I've been a FOSS developer for 15+ years now and I've been
working for Red Hat for 5 years. Recently I've moved to the graphics team.

One of my first tasks in the graphics team is to make the xserver run without
root rights. I'm making good progress with this, having solved almost all issues
already.

The biggest remaining stumbling block is the backlight API, because opening the
sysfs files requires root rights. I'll very likely write a little helper for this
for now, but in the long run it would be good to have a better solution.

While discussion this in the graphics devroom at Fosdem, the general consensus
seemed to be that the current backlight API is in need of an overhaul anyways.

There are several issues with the current API:
-there is no reliable way to determine the relation between a backlight
 control in sysfs and the display it controls the backlight off
-on many laptops we end up with multiple providers of backlight control
 all battling over control of the same backlight controller through various
 firmware interfaces
-and there is no way to do acl management on it because of sysfs usage

At Fosdem it was suggested to "simply" make the backlight a property of
the connector in drm/kms and let users control it that way. From an acl pov
this makes a ton of sense, if a user controls the other display-panel settings,
then he should be able to control the backlight too.

This also nicely solves the issue of userspace having to figure out which backlight
control to use for a certain output.

Last this makes it the kernels responsibility to figure out which firmware interface
(if any) to use and tie that to the connector, rather then just exporting all of
them, including conflicting ones, and just hoping that userspace will figure things out.

Note that wrt the last point, the kernel is the one which should have all the hardware
knowledge to do this properly, after all hardware abstraction is one of the tasks of
the kernel.

I realize moving this more into the kernel, and tying things into drm is in no means
easy, but it is about time we clean up this mess.

Note that although I'm kicking of this discussion, my focus within the graphics team is
mostly on input devices, so I'm hoping that someone else will pick things up once we've
a better idea of how we would like to solve this.

Regards,

Hans

Fixing the kernels backlight API

[Hans de Goede]

Hi All,

Quick self intro: I've been a FOSS developer for 15+ years now and I've been
working for Red Hat for 5 years. Recently I've moved to the graphics team.

One of my first tasks in the graphics team is to make the xserver run without
root rights. I'm making good progress with this, having solved almost all issues
already.

The biggest remaining stumbling block is the backlight API, because opening the
sysfs files requires root rights. I'll very likely write a little helper for this
for now, but in the long run it would be good to have a better solution.

While discussion this in the graphics devroom at Fosdem, the general consensus
seemed to be that the current backlight API is in need of an overhaul anyways.

There are several issues with the current API:
-there is no reliable way to determine the relation between a backlight
 control in sysfs and the display it controls the backlight off
-on many laptops we end up with multiple providers of backlight control
 all battling over control of the same backlight controller through various
 firmware interfaces
-and there is no way to do acl management on it because of sysfs usage

At Fosdem it was suggested to "simply" make the backlight a property of
the connector in drm/kms and let users control it that way. From an acl pov
this makes a ton of sense, if a user controls the other display-panel settings,
then he should be able to control the backlight too.

This also nicely solves the issue of userspace having to figure out which backlight
control to use for a certain output.

Last this makes it the kernels responsibility to figure out which firmware interface
(if any) to use and tie that to the connector, rather then just exporting all of
them, including conflicting ones, and just hoping that userspace will figure things out.

Note that wrt the last point, the kernel is the one which should have all the hardware
knowledge to do this properly, after all hardware abstraction is one of the tasks of
the kernel.

I realize moving this more into the kernel, and tying things into drm is in no means
easy, but it is about time we clean up this mess.

Note that although I'm kicking of this discussion, my focus within the graphics team is
mostly on input devices, so I'm hoping that someone else will pick things up once we've
a better idea of how we would like to solve this.

Regards,

Hans

_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Dave Airlie]

>
> The biggest remaining stumbling block is the backlight API, because opening the
> sysfs files requires root rights. I'll very likely write a little helper for this
> for now, but in the long run it would be good to have a better solution.
>
> While discussion this in the graphics devroom at Fosdem, the general consensus
> seemed to be that the current backlight API is in need of an overhaul anyways.
>
> There are several issues with the current API:
> -there is no reliable way to determine the relation between a backlight
>  control in sysfs and the display it controls the backlight off
> -on many laptops we end up with multiple providers of backlight control
>  all battling over control of the same backlight controller through various
>  firmware interfaces
> -and there is no way to do acl management on it because of sysfs usage
>
> At Fosdem it was suggested to "simply" make the backlight a property of
> the connector in drm/kms and let users control it that way. From an acl pov
> this makes a ton of sense, if a user controls the other display-panel settings,
> then he should be able to control the backlight too.
>
> This also nicely solves the issue of userspace having to figure out which backlight
> control to use for a certain output.
>
> Last this makes it the kernels responsibility to figure out which firmware interface
> (if any) to use and tie that to the connector, rather then just exporting all of
> them, including conflicting ones, and just hoping that userspace will figure things out.
>
> Note that wrt the last point, the kernel is the one which should have all the hardware
> knowledge to do this properly, after all hardware abstraction is one of the tasks of
> the kernel.
>
> I realize moving this more into the kernel, and tying things into drm is in no means
> easy, but it is about time we clean up this mess.
>
> Note that although I'm kicking of this discussion, my focus within the graphics team is
> mostly on input devices, so I'm hoping that someone else will pick things up once we've
> a better idea of how we would like to solve this.
>

I hate to respond with yeah no, but yeah no,

http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05

read down that until you see me and tagr talking, read it a few times,
and the follow on chat with dvdhrm.

The biggest problem with leaving the kernel to pick the correct one,
is the kernel simply never knows which is the
correct one, and you also have to deal with a load of problems like
runtime module deps between very misc modules
or using some kind of notifier mechanism that will turn into a locking
nightmare.

I don't mean to dissuade you from trying to "fix" this, but actually
getting a solution upstream is going to require a lot of messing
around.

Talk to Matthew Garrett, if you haven't talked to him, then you
haven't talked to anyone who understands backlights.

Dave.

Re: Fixing the kernels backlight API

[Dave Airlie]

>
> The biggest remaining stumbling block is the backlight API, because opening the
> sysfs files requires root rights. I'll very likely write a little helper for this
> for now, but in the long run it would be good to have a better solution.
>
> While discussion this in the graphics devroom at Fosdem, the general consensus
> seemed to be that the current backlight API is in need of an overhaul anyways.
>
> There are several issues with the current API:
> -there is no reliable way to determine the relation between a backlight
>  control in sysfs and the display it controls the backlight off
> -on many laptops we end up with multiple providers of backlight control
>  all battling over control of the same backlight controller through various
>  firmware interfaces
> -and there is no way to do acl management on it because of sysfs usage
>
> At Fosdem it was suggested to "simply" make the backlight a property of
> the connector in drm/kms and let users control it that way. From an acl pov
> this makes a ton of sense, if a user controls the other display-panel settings,
> then he should be able to control the backlight too.
>
> This also nicely solves the issue of userspace having to figure out which backlight
> control to use for a certain output.
>
> Last this makes it the kernels responsibility to figure out which firmware interface
> (if any) to use and tie that to the connector, rather then just exporting all of
> them, including conflicting ones, and just hoping that userspace will figure things out.
>
> Note that wrt the last point, the kernel is the one which should have all the hardware
> knowledge to do this properly, after all hardware abstraction is one of the tasks of
> the kernel.
>
> I realize moving this more into the kernel, and tying things into drm is in no means
> easy, but it is about time we clean up this mess.
>
> Note that although I'm kicking of this discussion, my focus within the graphics team is
> mostly on input devices, so I'm hoping that someone else will pick things up once we've
> a better idea of how we would like to solve this.
>

I hate to respond with yeah no, but yeah no,

http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-04
http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05

read down that until you see me and tagr talking, read it a few times,
and the follow on chat with dvdhrm.

The biggest problem with leaving the kernel to pick the correct one,
is the kernel simply never knows which is the
correct one, and you also have to deal with a load of problems like
runtime module deps between very misc modules
or using some kind of notifier mechanism that will turn into a locking
nightmare.

I don't mean to dissuade you from trying to "fix" this, but actually
getting a solution upstream is going to require a lot of messing
around.

Talk to Matthew Garrett, if you haven't talked to him, then you
haven't talked to anyone who understands backlights.

Dave.
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Ville Syrjälä]

On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
> >
> > The biggest remaining stumbling block is the backlight API, because opening the
> > sysfs files requires root rights. I'll very likely write a little helper for this
> > for now, but in the long run it would be good to have a better solution.
> >
> > While discussion this in the graphics devroom at Fosdem, the general consensus
> > seemed to be that the current backlight API is in need of an overhaul anyways.
> >
> > There are several issues with the current API:
> > -there is no reliable way to determine the relation between a backlight
> >  control in sysfs and the display it controls the backlight off
> > -on many laptops we end up with multiple providers of backlight control
> >  all battling over control of the same backlight controller through various
> >  firmware interfaces
> > -and there is no way to do acl management on it because of sysfs usage
> >
> > At Fosdem it was suggested to "simply" make the backlight a property of
> > the connector in drm/kms and let users control it that way. From an acl pov
> > this makes a ton of sense, if a user controls the other display-panel settings,
> > then he should be able to control the backlight too.
> >
> > This also nicely solves the issue of userspace having to figure out which backlight
> > control to use for a certain output.
> >
> > Last this makes it the kernels responsibility to figure out which firmware interface
> > (if any) to use and tie that to the connector, rather then just exporting all of
> > them, including conflicting ones, and just hoping that userspace will figure things out.
> >
> > Note that wrt the last point, the kernel is the one which should have all the hardware
> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
> > the kernel.
> >
> > I realize moving this more into the kernel, and tying things into drm is in no means
> > easy, but it is about time we clean up this mess.
> >
> > Note that although I'm kicking of this discussion, my focus within the graphics team is
> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
> > a better idea of how we would like to solve this.
> >
> 
> I hate to respond with yeah no, but yeah no,
> 
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
> 
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.
> 
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one,

That could be solved by still allowing userspace to change the
connection between the property and the actual backlight device.

With the prop approach + atomic modeset you could also do some
slightly fancier things like changing the backlight at the same
time as doing a modeset or just adjusting some other display
related properties.

> and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.

This would still be an issue though.

I like the idea of the property, but I'm not volunteering to do any
of the work.

> 
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
> 
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.
> 
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

Re: Fixing the kernels backlight API

[Ville Syrjälä]

On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
> >
> > The biggest remaining stumbling block is the backlight API, because opening the
> > sysfs files requires root rights. I'll very likely write a little helper for this
> > for now, but in the long run it would be good to have a better solution.
> >
> > While discussion this in the graphics devroom at Fosdem, the general consensus
> > seemed to be that the current backlight API is in need of an overhaul anyways.
> >
> > There are several issues with the current API:
> > -there is no reliable way to determine the relation between a backlight
> >  control in sysfs and the display it controls the backlight off
> > -on many laptops we end up with multiple providers of backlight control
> >  all battling over control of the same backlight controller through various
> >  firmware interfaces
> > -and there is no way to do acl management on it because of sysfs usage
> >
> > At Fosdem it was suggested to "simply" make the backlight a property of
> > the connector in drm/kms and let users control it that way. From an acl pov
> > this makes a ton of sense, if a user controls the other display-panel settings,
> > then he should be able to control the backlight too.
> >
> > This also nicely solves the issue of userspace having to figure out which backlight
> > control to use for a certain output.
> >
> > Last this makes it the kernels responsibility to figure out which firmware interface
> > (if any) to use and tie that to the connector, rather then just exporting all of
> > them, including conflicting ones, and just hoping that userspace will figure things out.
> >
> > Note that wrt the last point, the kernel is the one which should have all the hardware
> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
> > the kernel.
> >
> > I realize moving this more into the kernel, and tying things into drm is in no means
> > easy, but it is about time we clean up this mess.
> >
> > Note that although I'm kicking of this discussion, my focus within the graphics team is
> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
> > a better idea of how we would like to solve this.
> >
> 
> I hate to respond with yeah no, but yeah no,
> 
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05
> 
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.
> 
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one,

That could be solved by still allowing userspace to change the
connection between the property and the actual backlight device.

With the prop approach + atomic modeset you could also do some
slightly fancier things like changing the backlight at the same
time as doing a modeset or just adjusting some other display
related properties.

> and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.

This would still be an issue though.

I like the idea of the property, but I'm not volunteering to do any
of the work.

> 
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
> 
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.
> 
> Dave.
> _______________________________________________
> dri-devel mailing list
> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[David Herrmann]

Hi

On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>> >
>> > The biggest remaining stumbling block is the backlight API, because opening the
>> > sysfs files requires root rights. I'll very likely write a little helper for this
>> > for now, but in the long run it would be good to have a better solution.
>> >
>> > While discussion this in the graphics devroom at Fosdem, the general consensus
>> > seemed to be that the current backlight API is in need of an overhaul anyways.
>> >
>> > There are several issues with the current API:
>> > -there is no reliable way to determine the relation between a backlight
>> >  control in sysfs and the display it controls the backlight off
>> > -on many laptops we end up with multiple providers of backlight control
>> >  all battling over control of the same backlight controller through various
>> >  firmware interfaces
>> > -and there is no way to do acl management on it because of sysfs usage
>> >
>> > At Fosdem it was suggested to "simply" make the backlight a property of
>> > the connector in drm/kms and let users control it that way. From an acl pov
>> > this makes a ton of sense, if a user controls the other display-panel settings,
>> > then he should be able to control the backlight too.
>> >
>> > This also nicely solves the issue of userspace having to figure out which backlight
>> > control to use for a certain output.
>> >
>> > Last this makes it the kernels responsibility to figure out which firmware interface
>> > (if any) to use and tie that to the connector, rather then just exporting all of
>> > them, including conflicting ones, and just hoping that userspace will figure things out.
>> >
>> > Note that wrt the last point, the kernel is the one which should have all the hardware
>> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> > the kernel.
>> >
>> > I realize moving this more into the kernel, and tying things into drm is in no means
>> > easy, but it is about time we clean up this mess.
>> >
>> > Note that although I'm kicking of this discussion, my focus within the graphics team is
>> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> > a better idea of how we would like to solve this.
>> >
>>
>> I hate to respond with yeah no, but yeah no,
>>
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>
>> read down that until you see me and tagr talking, read it a few times,
>> and the follow on chat with dvdhrm.
>>
>> The biggest problem with leaving the kernel to pick the correct one,
>> is the kernel simply never knows which is the
>> correct one,
>
> That could be solved by still allowing userspace to change the
> connection between the property and the actual backlight device.
>
> With the prop approach + atomic modeset you could also do some
> slightly fancier things like changing the backlight at the same
> time as doing a modeset or just adjusting some other display
> related properties.

The "attach" stuff actually sounds doable, but who decides which one
to attach? You still need some user-space script during device-plug
for that.
But to be honest, the simplest way would be a "backlightd"
bus-activatable daemon. SetBacklight() then takes a DRM-connector and
brightness-value, which the daemon looks up in /sys and sets.. This
has the advantage that we can do any fancy matching in user-space. We
can provide quirks (maybe even via udev-hwdb) and other helpers for
weird setups.

Cheers
David

Re: Fixing the kernels backlight API

[David Herrmann]

Hi

On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>> >
>> > The biggest remaining stumbling block is the backlight API, because opening the
>> > sysfs files requires root rights. I'll very likely write a little helper for this
>> > for now, but in the long run it would be good to have a better solution.
>> >
>> > While discussion this in the graphics devroom at Fosdem, the general consensus
>> > seemed to be that the current backlight API is in need of an overhaul anyways.
>> >
>> > There are several issues with the current API:
>> > -there is no reliable way to determine the relation between a backlight
>> >  control in sysfs and the display it controls the backlight off
>> > -on many laptops we end up with multiple providers of backlight control
>> >  all battling over control of the same backlight controller through various
>> >  firmware interfaces
>> > -and there is no way to do acl management on it because of sysfs usage
>> >
>> > At Fosdem it was suggested to "simply" make the backlight a property of
>> > the connector in drm/kms and let users control it that way. From an acl pov
>> > this makes a ton of sense, if a user controls the other display-panel settings,
>> > then he should be able to control the backlight too.
>> >
>> > This also nicely solves the issue of userspace having to figure out which backlight
>> > control to use for a certain output.
>> >
>> > Last this makes it the kernels responsibility to figure out which firmware interface
>> > (if any) to use and tie that to the connector, rather then just exporting all of
>> > them, including conflicting ones, and just hoping that userspace will figure things out.
>> >
>> > Note that wrt the last point, the kernel is the one which should have all the hardware
>> > knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> > the kernel.
>> >
>> > I realize moving this more into the kernel, and tying things into drm is in no means
>> > easy, but it is about time we clean up this mess.
>> >
>> > Note that although I'm kicking of this discussion, my focus within the graphics team is
>> > mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> > a better idea of how we would like to solve this.
>> >
>>
>> I hate to respond with yeah no, but yeah no,
>>
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-04
>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05
>>
>> read down that until you see me and tagr talking, read it a few times,
>> and the follow on chat with dvdhrm.
>>
>> The biggest problem with leaving the kernel to pick the correct one,
>> is the kernel simply never knows which is the
>> correct one,
>
> That could be solved by still allowing userspace to change the
> connection between the property and the actual backlight device.
>
> With the prop approach + atomic modeset you could also do some
> slightly fancier things like changing the backlight at the same
> time as doing a modeset or just adjusting some other display
> related properties.

The "attach" stuff actually sounds doable, but who decides which one
to attach? You still need some user-space script during device-plug
for that.
But to be honest, the simplest way would be a "backlightd"
bus-activatable daemon. SetBacklight() then takes a DRM-connector and
brightness-value, which the daemon looks up in /sys and sets.. This
has the advantage that we can do any fancy matching in user-space. We
can provide quirks (maybe even via udev-hwdb) and other helpers for
weird setups.

Cheers
David

Re: Fixing the kernels backlight API

[Alexander E. Patrakov]

13.02.2014 04:26, David Herrmann wrote:
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.

What would be done with Samsung monitors (like an old SyncMaster 770P) 
that have a DVI connection, no physical buttons and have to be 
controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but 
only from root. I would like this use case to be covered in such a way 
that it could work both in Xorg and in Wayland, and, if possible, 
without races related to i2c usage from the kernel and from userspace.

-- 
Alexander E. Patrakov

Re: Fixing the kernels backlight API

[Alexander E. Patrakov]

13.02.2014 04:26, David Herrmann wrote:
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.

What would be done with Samsung monitors (like an old SyncMaster 770P) 
that have a DVI connection, no physical buttons and have to be 
controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but 
only from root. I would like this use case to be covered in such a way 
that it could work both in Xorg and in Wayland, and, if possible, 
without races related to i2c usage from the kernel and from userspace.

-- 
Alexander E. Patrakov
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/12/2014 09:14 PM, Dave Airlie wrote:
>>
>> The biggest remaining stumbling block is the backlight API, because opening the
>> sysfs files requires root rights. I'll very likely write a little helper for this
>> for now, but in the long run it would be good to have a better solution.
>>
>> While discussion this in the graphics devroom at Fosdem, the general consensus
>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>
>> There are several issues with the current API:
>> -there is no reliable way to determine the relation between a backlight
>>  control in sysfs and the display it controls the backlight off
>> -on many laptops we end up with multiple providers of backlight control
>>  all battling over control of the same backlight controller through various
>>  firmware interfaces
>> -and there is no way to do acl management on it because of sysfs usage
>>
>> At Fosdem it was suggested to "simply" make the backlight a property of
>> the connector in drm/kms and let users control it that way. From an acl pov
>> this makes a ton of sense, if a user controls the other display-panel settings,
>> then he should be able to control the backlight too.
>>
>> This also nicely solves the issue of userspace having to figure out which backlight
>> control to use for a certain output.
>>
>> Last this makes it the kernels responsibility to figure out which firmware interface
>> (if any) to use and tie that to the connector, rather then just exporting all of
>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>
>> Note that wrt the last point, the kernel is the one which should have all the hardware
>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> the kernel.
>>
>> I realize moving this more into the kernel, and tying things into drm is in no means
>> easy, but it is about time we clean up this mess.
>>
>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> a better idea of how we would like to solve this.
>>
> 
> I hate to respond with yeah no, but yeah no,
> 
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
> 
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.

I think I'm going to save myself some time and just believe you, esp.
since you ...

> 
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one, and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.
> 
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
> 
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.

Also bring up Matthew Garrett, who seems to have a knack for working on things which
involve inflicting a certain amount of pain onto the developer working on them.

I still believe we need to do better, but maybe that better needs to be done
in userspace rather then in the kernel.

More about that further down in this thread.

Regards,

Hans

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/12/2014 09:14 PM, Dave Airlie wrote:
>>
>> The biggest remaining stumbling block is the backlight API, because opening the
>> sysfs files requires root rights. I'll very likely write a little helper for this
>> for now, but in the long run it would be good to have a better solution.
>>
>> While discussion this in the graphics devroom at Fosdem, the general consensus
>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>
>> There are several issues with the current API:
>> -there is no reliable way to determine the relation between a backlight
>>  control in sysfs and the display it controls the backlight off
>> -on many laptops we end up with multiple providers of backlight control
>>  all battling over control of the same backlight controller through various
>>  firmware interfaces
>> -and there is no way to do acl management on it because of sysfs usage
>>
>> At Fosdem it was suggested to "simply" make the backlight a property of
>> the connector in drm/kms and let users control it that way. From an acl pov
>> this makes a ton of sense, if a user controls the other display-panel settings,
>> then he should be able to control the backlight too.
>>
>> This also nicely solves the issue of userspace having to figure out which backlight
>> control to use for a certain output.
>>
>> Last this makes it the kernels responsibility to figure out which firmware interface
>> (if any) to use and tie that to the connector, rather then just exporting all of
>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>
>> Note that wrt the last point, the kernel is the one which should have all the hardware
>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>> the kernel.
>>
>> I realize moving this more into the kernel, and tying things into drm is in no means
>> easy, but it is about time we clean up this mess.
>>
>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>> a better idea of how we would like to solve this.
>>
> 
> I hate to respond with yeah no, but yeah no,
> 
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-04
> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05
> 
> read down that until you see me and tagr talking, read it a few times,
> and the follow on chat with dvdhrm.

I think I'm going to save myself some time and just believe you, esp.
since you ...

> 
> The biggest problem with leaving the kernel to pick the correct one,
> is the kernel simply never knows which is the
> correct one, and you also have to deal with a load of problems like
> runtime module deps between very misc modules
> or using some kind of notifier mechanism that will turn into a locking
> nightmare.
> 
> I don't mean to dissuade you from trying to "fix" this, but actually
> getting a solution upstream is going to require a lot of messing
> around.
> 
> Talk to Matthew Garrett, if you haven't talked to him, then you
> haven't talked to anyone who understands backlights.

Also bring up Matthew Garrett, who seems to have a knack for working on things which
involve inflicting a certain amount of pain onto the developer working on them.

I still believe we need to do better, but maybe that better needs to be done
in userspace rather then in the kernel.

More about that further down in this thread.

Regards,

Hans
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/12/2014 11:26 PM, David Herrmann wrote:
> Hi
> 
> On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>>>>
>>>> The biggest remaining stumbling block is the backlight API, because opening the
>>>> sysfs files requires root rights. I'll very likely write a little helper for this
>>>> for now, but in the long run it would be good to have a better solution.
>>>>
>>>> While discussion this in the graphics devroom at Fosdem, the general consensus
>>>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>>>
>>>> There are several issues with the current API:
>>>> -there is no reliable way to determine the relation between a backlight
>>>>  control in sysfs and the display it controls the backlight off
>>>> -on many laptops we end up with multiple providers of backlight control
>>>>  all battling over control of the same backlight controller through various
>>>>  firmware interfaces
>>>> -and there is no way to do acl management on it because of sysfs usage
>>>>
>>>> At Fosdem it was suggested to "simply" make the backlight a property of
>>>> the connector in drm/kms and let users control it that way. From an acl pov
>>>> this makes a ton of sense, if a user controls the other display-panel settings,
>>>> then he should be able to control the backlight too.
>>>>
>>>> This also nicely solves the issue of userspace having to figure out which backlight
>>>> control to use for a certain output.
>>>>
>>>> Last this makes it the kernels responsibility to figure out which firmware interface
>>>> (if any) to use and tie that to the connector, rather then just exporting all of
>>>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>>>
>>>> Note that wrt the last point, the kernel is the one which should have all the hardware
>>>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>>>> the kernel.
>>>>
>>>> I realize moving this more into the kernel, and tying things into drm is in no means
>>>> easy, but it is about time we clean up this mess.
>>>>
>>>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>>>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>>>> a better idea of how we would like to solve this.
>>>>
>>>
>>> I hate to respond with yeah no, but yeah no,
>>>
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-04
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date 14-02-05
>>>
>>> read down that until you see me and tagr talking, read it a few times,
>>> and the follow on chat with dvdhrm.
>>>
>>> The biggest problem with leaving the kernel to pick the correct one,
>>> is the kernel simply never knows which is the
>>> correct one,
>>
>> That could be solved by still allowing userspace to change the
>> connection between the property and the actual backlight device.
>>
>> With the prop approach + atomic modeset you could also do some
>> slightly fancier things like changing the backlight at the same
>> time as doing a modeset or just adjusting some other display
>> related properties.
> 
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.

This sounds like a good idea, note that at-least gnome already has
something similar in the form of the (one-shot, not daemon)
gsd-backlight-helper which also has some code to try and figure out
what is the right backlight class device to use.

Interestingly enough the xf86-video-intel driver does this on its own
using somewhat more complex logic to find the right backlight class
device to use, and then exporting this as a property on the connector
in Xrandr.

So a first rough idea of how this would work / a plan would be:

1) We have a bus-activated backlightd running as root

2) This can be asked for backlight properties on a certain drm/kms
connector

3) If there actually is a backlight for the connector, it can also be
used to change the backlight brightness

4) The xserver will get some helper functions which drivers can call
to create a backlight property on xrandr connectors

5) In the long run gsd-backlight-helper and the xf86-video-intel
backlight code can be removed

Note there also is a step:

0) Get xf86-video-intel backlight code to work without root in some
way for now


Regards,

Hans

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/12/2014 11:26 PM, David Herrmann wrote:
> Hi
> 
> On Wed, Feb 12, 2014 at 9:43 PM, Ville Syrjälä
> <ville.syrjala-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
>> On Thu, Feb 13, 2014 at 06:14:04AM +1000, Dave Airlie wrote:
>>>>
>>>> The biggest remaining stumbling block is the backlight API, because opening the
>>>> sysfs files requires root rights. I'll very likely write a little helper for this
>>>> for now, but in the long run it would be good to have a better solution.
>>>>
>>>> While discussion this in the graphics devroom at Fosdem, the general consensus
>>>> seemed to be that the current backlight API is in need of an overhaul anyways.
>>>>
>>>> There are several issues with the current API:
>>>> -there is no reliable way to determine the relation between a backlight
>>>>  control in sysfs and the display it controls the backlight off
>>>> -on many laptops we end up with multiple providers of backlight control
>>>>  all battling over control of the same backlight controller through various
>>>>  firmware interfaces
>>>> -and there is no way to do acl management on it because of sysfs usage
>>>>
>>>> At Fosdem it was suggested to "simply" make the backlight a property of
>>>> the connector in drm/kms and let users control it that way. From an acl pov
>>>> this makes a ton of sense, if a user controls the other display-panel settings,
>>>> then he should be able to control the backlight too.
>>>>
>>>> This also nicely solves the issue of userspace having to figure out which backlight
>>>> control to use for a certain output.
>>>>
>>>> Last this makes it the kernels responsibility to figure out which firmware interface
>>>> (if any) to use and tie that to the connector, rather then just exporting all of
>>>> them, including conflicting ones, and just hoping that userspace will figure things out.
>>>>
>>>> Note that wrt the last point, the kernel is the one which should have all the hardware
>>>> knowledge to do this properly, after all hardware abstraction is one of the tasks of
>>>> the kernel.
>>>>
>>>> I realize moving this more into the kernel, and tying things into drm is in no means
>>>> easy, but it is about time we clean up this mess.
>>>>
>>>> Note that although I'm kicking of this discussion, my focus within the graphics team is
>>>> mostly on input devices, so I'm hoping that someone else will pick things up once we've
>>>> a better idea of how we would like to solve this.
>>>>
>>>
>>> I hate to respond with yeah no, but yeah no,
>>>
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-04
>>> http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&show_html=true&highlight_names=&date=2014-02-05
>>>
>>> read down that until you see me and tagr talking, read it a few times,
>>> and the follow on chat with dvdhrm.
>>>
>>> The biggest problem with leaving the kernel to pick the correct one,
>>> is the kernel simply never knows which is the
>>> correct one,
>>
>> That could be solved by still allowing userspace to change the
>> connection between the property and the actual backlight device.
>>
>> With the prop approach + atomic modeset you could also do some
>> slightly fancier things like changing the backlight at the same
>> time as doing a modeset or just adjusting some other display
>> related properties.
> 
> The "attach" stuff actually sounds doable, but who decides which one
> to attach? You still need some user-space script during device-plug
> for that.
> But to be honest, the simplest way would be a "backlightd"
> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
> brightness-value, which the daemon looks up in /sys and sets.. This
> has the advantage that we can do any fancy matching in user-space. We
> can provide quirks (maybe even via udev-hwdb) and other helpers for
> weird setups.

This sounds like a good idea, note that at-least gnome already has
something similar in the form of the (one-shot, not daemon)
gsd-backlight-helper which also has some code to try and figure out
what is the right backlight class device to use.

Interestingly enough the xf86-video-intel driver does this on its own
using somewhat more complex logic to find the right backlight class
device to use, and then exporting this as a property on the connector
in Xrandr.

So a first rough idea of how this would work / a plan would be:

1) We have a bus-activated backlightd running as root

2) This can be asked for backlight properties on a certain drm/kms
connector

3) If there actually is a backlight for the connector, it can also be
used to change the backlight brightness

4) The xserver will get some helper functions which drivers can call
to create a backlight property on xrandr connectors

5) In the long run gsd-backlight-helper and the xf86-video-intel
backlight code can be removed

Note there also is a step:

0) Get xf86-video-intel backlight code to work without root in some
way for now


Regards,

Hans
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 07:37 AM, Alexander E. Patrakov wrote:
> 13.02.2014 04:26, David Herrmann wrote:
>> The "attach" stuff actually sounds doable, but who decides which one
>> to attach? You still need some user-space script during device-plug
>> for that.
>> But to be honest, the simplest way would be a "backlightd"
>> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
>> brightness-value, which the daemon looks up in /sys and sets.. This
>> has the advantage that we can do any fancy matching in user-space. We
>> can provide quirks (maybe even via udev-hwdb) and other helpers for
>> weird setups.
> 
> What would be done with Samsung monitors (like an old SyncMaster 770P) that have a DVI connection, no physical buttons and have to be controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but only from root. I would like this use case to be covered in such a way that it could work both in Xorg and in Wayland, and, if possible, without races related to i2c usage from the kernel and from userspace.

The nice thing about having a userspace daemon for this is that we can
actually add some support for DCC-CI too.

WRT races between user and kernelspace, those can be avoided by using
the I2C_RDWR ioctl, in this case you can specify multipel i2c writes /
reads which will all get executed as one transaction, note this
assumes that the protocol supports repeated START conditions,
if it needs a STOP condition and still needs everything to be in
one transaction, then things become trickier. This also assumes
that the i2c controller driver used supports I2C_FUNC_I2C

Regards,

Hans

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 07:37 AM, Alexander E. Patrakov wrote:
> 13.02.2014 04:26, David Herrmann wrote:
>> The "attach" stuff actually sounds doable, but who decides which one
>> to attach? You still need some user-space script during device-plug
>> for that.
>> But to be honest, the simplest way would be a "backlightd"
>> bus-activatable daemon. SetBacklight() then takes a DRM-connector and
>> brightness-value, which the daemon looks up in /sys and sets.. This
>> has the advantage that we can do any fancy matching in user-space. We
>> can provide quirks (maybe even via udev-hwdb) and other helpers for
>> weird setups.
> 
> What would be done with Samsung monitors (like an old SyncMaster 770P) that have a DVI connection, no physical buttons and have to be controlled via DDC-CI? Currently, ddccontrol works (via /dev/i2c-*), but only from root. I would like this use case to be covered in such a way that it could work both in Xorg and in Wayland, and, if possible, without races related to i2c usage from the kernel and from userspace.

The nice thing about having a userspace daemon for this is that we can
actually add some support for DCC-CI too.

WRT races between user and kernelspace, those can be avoided by using
the I2C_RDWR ioctl, in this case you can specify multipel i2c writes /
reads which will all get executed as one transaction, note this
assumes that the protocol supports repeated START conditions,
if it needs a STOP condition and still needs everything to be in
one transaction, then things become trickier. This also assumes
that the i2c controller driver used supports I2C_FUNC_I2C

Regards,

Hans
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Matthew Garrett]

On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:

> I still believe we need to do better, but maybe that better needs to be done
> in userspace rather then in the kernel.

One option is to put it on the connector but provide some mechanism for 
userspace to define the relationship between platform/firmware 
interfaces and connectors. We ought to be able to tie connectors into 
the ACPI namespace and do a better job than we currently do with the 
association between backlight and connector. The bigger problem is 
figuring out how platform interfaces tie into things, and that's where 
heuristics are probably going to be involved.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 06:19 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
> 
>> I still believe we need to do better, but maybe that better needs to be done
>> in userspace rather then in the kernel.
> 
> One option is to put it on the connector but provide some mechanism for 
> userspace to define the relationship between platform/firmware 
> interfaces and connectors. We ought to be able to tie connectors into 
> the ACPI namespace and do a better job than we currently do with the 
> association between backlight and connector. The bigger problem is 
> figuring out how platform interfaces tie into things, and that's where 
> heuristics are probably going to be involved.

Right, but as Dave Airlie pointed out that means putting links between
two completely unrelated subsystems, causing locking and module load
ordering problems.

I can understand where Dave is coming from, from a kernel pov, so this
might really be easier to just solve in userspace. I don't know if you've
seen my very rough sketch of how this could work in userspace in my other
mail. The idea would be to still make this show up on a specific connector,
but only at the xrandr level, not at the drm level, and have the xserver
talk to some kind of backlightd for this.  The backlightd API should of cource
be generic enough that it can be used in wayland too.

This sounds like a reasonable and workable plan to me, but I must admit
I'm very naive when it comes to backlight stuff.

Regards,

Hans

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 06:19 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 02:41:53PM +0100, Hans de Goede wrote:
> 
>> I still believe we need to do better, but maybe that better needs to be done
>> in userspace rather then in the kernel.
> 
> One option is to put it on the connector but provide some mechanism for 
> userspace to define the relationship between platform/firmware 
> interfaces and connectors. We ought to be able to tie connectors into 
> the ACPI namespace and do a better job than we currently do with the 
> association between backlight and connector. The bigger problem is 
> figuring out how platform interfaces tie into things, and that's where 
> heuristics are probably going to be involved.

Right, but as Dave Airlie pointed out that means putting links between
two completely unrelated subsystems, causing locking and module load
ordering problems.

I can understand where Dave is coming from, from a kernel pov, so this
might really be easier to just solve in userspace. I don't know if you've
seen my very rough sketch of how this could work in userspace in my other
mail. The idea would be to still make this show up on a specific connector,
but only at the xrandr level, not at the drm level, and have the xserver
talk to some kind of backlightd for this.  The backlightd API should of cource
be generic enough that it can be used in wayland too.

This sounds like a reasonable and workable plan to me, but I must admit
I'm very naive when it comes to backlight stuff.

Regards,

Hans
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Matthew Garrett]

On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:

> I can understand where Dave is coming from, from a kernel pov, so this
> might really be easier to just solve in userspace. I don't know if you've
> seen my very rough sketch of how this could work in userspace in my other
> mail. The idea would be to still make this show up on a specific connector,
> but only at the xrandr level, not at the drm level, and have the xserver
> talk to some kind of backlightd for this.  The backlightd API should of cource
> be generic enough that it can be used in wayland too.

Sure. You should probably take a look at libbacklight, which already has 
some amount of support for appropriate heuristics.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Fixing the kernels backlight API

[Matthew Garrett]

On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:

> I can understand where Dave is coming from, from a kernel pov, so this
> might really be easier to just solve in userspace. I don't know if you've
> seen my very rough sketch of how this could work in userspace in my other
> mail. The idea would be to still make this show up on a specific connector,
> but only at the xrandr level, not at the drm level, and have the xserver
> talk to some kind of backlightd for this.  The backlightd API should of cource
> be generic enough that it can be used in wayland too.

Sure. You should probably take a look at libbacklight, which already has 
some amount of support for appropriate heuristics.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 09:12 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:
> 
>> I can understand where Dave is coming from, from a kernel pov, so this
>> might really be easier to just solve in userspace. I don't know if you've
>> seen my very rough sketch of how this could work in userspace in my other
>> mail. The idea would be to still make this show up on a specific connector,
>> but only at the xrandr level, not at the drm level, and have the xserver
>> talk to some kind of backlightd for this.  The backlightd API should of cource
>> be generic enough that it can be used in wayland too.
> 
> Sure. You should probably take a look at libbacklight, which already has 
> some amount of support for appropriate heuristics.

Ah, I did not know about libbacklight, thanks for the pointer.

Note that although I believe we do need to sort out this mess, and having
something like backlightd would be a good idea, I likely won't have time to
work on this in the near future. For $dayjob I will be focussing on finishing
rootless xorg and working on libinput. And $hobbytime is all going to getting
upstream support for Allwinner ARM SoCs into place.

Still I'll put a line about this in my todo file, just don't expect anything
soon, and no promises about this at all!

Regards,

Hans

Re: Fixing the kernels backlight API

[Hans de Goede]

Hi,

On 02/13/2014 09:12 PM, Matthew Garrett wrote:
> On Thu, Feb 13, 2014 at 08:43:10PM +0100, Hans de Goede wrote:
> 
>> I can understand where Dave is coming from, from a kernel pov, so this
>> might really be easier to just solve in userspace. I don't know if you've
>> seen my very rough sketch of how this could work in userspace in my other
>> mail. The idea would be to still make this show up on a specific connector,
>> but only at the xrandr level, not at the drm level, and have the xserver
>> talk to some kind of backlightd for this.  The backlightd API should of cource
>> be generic enough that it can be used in wayland too.
> 
> Sure. You should probably take a look at libbacklight, which already has 
> some amount of support for appropriate heuristics.

Ah, I did not know about libbacklight, thanks for the pointer.

Note that although I believe we do need to sort out this mess, and having
something like backlightd would be a good idea, I likely won't have time to
work on this in the near future. For $dayjob I will be focussing on finishing
rootless xorg and working on libinput. And $hobbytime is all going to getting
upstream support for Allwinner ARM SoCs into place.

Still I'll put a line about this in my todo file, just don't expect anything
soon, and no promises about this at all!

Regards,

Hans
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel