Update on DeviceKit

Daniel Stone daniel.stone at nokia.com
Fri May 9 05:50:26 PDT 2008


On Fri, May 09, 2008 at 12:14:15PM +0100, ext Bastien Nocera wrote:
> 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:
> > > 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?

I don't know, I'd just got used to the idea of HAL/DeviceKit as
something that, y'know, enumerated devices.  It was nice having all the
information we needed in one spot instead of 73, but if the decision is
just that things like this (e.g. machine-specific quirks, such as 'this
ACPI resource is the backlight for this display') don't go in DeviceKit,
then that means we don't use DeviceKit.

Maybe it means that we rewind to 1997 and we dump all this inside of X;
maybe someone just forks HAL and continues development on that.  Maybe
someone actually finds an API that makes the 'oh my god what if I press
a brightness hotkey while I'm in between X sessions because I just
activated FUS' people happy.  I don't know: I'm still trying to digest
the design after the whole, 'don't worry plebs, someone has handed me
the new design from high on stone tablets' Moses thing.

> > > - 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?

Yeah.  We can cope with the brightness changing underneath us: any time
someone queries the property, we can double-check the value with the
hardware.  If we really need notifications, then I guess that'll have to
be hooked up somehow too.

> > > - 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...

Okay, cool.  So I guess the options here are either magical in-kernel
associations, or building our own list of 'the Dell C3000 variant three
as sold in Finland maps this ACPI device to the primary LVDS display,
whereas variant four maps _this_ ACPI device ...' in X.  Yay.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/hal/attachments/20080509/ff9664a3/attachment.pgp 


More information about the hal mailing list