Update on DeviceKit

[Bastien Nocera]

On Fri, 2008-05-09 at 13:57 +0300, Daniel Stone wrote:
> On Fri, May 09, 2008 at 11:52:08AM +0100, ext Bastien Nocera wrote:
> > On Wed, 2008-05-07 at 20:54 +0300, Daniel Stone wrote:
> > > It's an abstraction layer that already deals with multiple devices and
> > > displays both in a sensible way, so HAL would have to strictly follow
> > > RandR 1.2 (and only people with DRM modesetting would get that useful
> > > mapping) in order to be even remotely useful for configuration.
> > 
> > So, to get back to the original discussion, how does one add support for
> > backlight changes in X when:
> > - the device doing the changes is a platform device, and not connected
> > to the graphics hardware
> 
> It would be nice to have some kind of in-kernel associaton.  Failing
> that, X talks to HAL, so some kind of HAL association would be fine too.

I thought we were just saying that the code should be in X. Is going
kernel and/or userspace daemon <-> DeviceKit add-on <-(custom
interface)-> X <-> g-p-m really the way we want to go?

> > - the hardware does the changes itself, but we want user-space to be
> > made aware of the changes ("laptop_panel.brightness_in_hardware" key in
> > HAL)
> 
> That's fine, we already have support for this.

Do you mean X?

> > - or a combination of both above
> > 
> > And which dependencies are acceptable to add to the X server?
> 
> HAL is just fine, so presumably will be DeviceKit fine too, but GLib and
> GObject are absolutely unacceptable for us.

We're talking about DeviceKit and removing the backlight sub-system in
there. So HAL isn't the answer...