Update on DeviceKit
David Zeuthen
david at fubar.dk
Wed May 7 11:01:17 PDT 2008
On Wed, 2008-05-07 at 18:49 +0100, Matthew Garrett wrote:
> On Wed, May 07, 2008 at 12:39:26PM -0400, David Zeuthen wrote:
>
> > So someone just needs to teach X about using libsmbios on Dell machines.
> > Just like it's using /sys/class/backlight on Linux. I don't think the X
> > people are opposed to this; certainly ajax didn't seemed opposed to this
> > last time I checked.
>
> The license of libsmbios means it's not going to go into X, so it's
> going to need to be some external callout /anyway/.
Has someone explained this problem to the libsmbios developers (e.g.
Dell) and asked them to relicense it? Maybe that would be useful.
(Oh, btw, it's C++ too. Fun for the whole family!)
> I'm not convinced
> that this ends up any cleaner :)
The point is not so much about implementation details; the point is more
about having the right bits provide the right interfaces at the right
level in the stack. In this case, I'm convinced the only sane way is to
expose backlight controls is via X. If we were to continue exporting
interfaces like this in a separate D-Bus service then we'd have to
- Know about multiple monitors. (Oh no, what if there's four monitors
with two different sessions? X can deal with this.)
- What about remote displays? If we do this through X this might
actually work properly some day on Sun-Ray-style setups. Epic fail
for a separate D-Bus service.
- What next, should a hypothetical D-Bus service expose DPMS controls
tool? Oh, what about gamma and color correction? Why not resolution
while we're at it?
and the list goes on. It retrospect, I guess, it was a mistake to put
backlight controls in HAL but it sure was practical, useful etc. because
there was no interface in X for it. This situation has now changed.
David
More information about the hal
mailing list