Update on DeviceKit

[Lennart Poettering]

On Wed, 07.05.08 16:24, Matthew Garrett (mjg59 at srcf.ucam.org) wrote:

> 
> On Wed, May 07, 2008 at 05:03:30PM +0200, Lennart Poettering wrote:
> 
> > I think it would be best if backlight control is left to X. For some
> > graphics cards its already properly exported in XRANDR. XRANDR knows
> > about multiple screens, hotplug and stuff, is network transparent and
> > so on. It's also much easier for normal desktop apps like cheese to
> > use the backlight as a flash if its exported via XRANDR.
> 
> I'm not entirely sold on this - it does mean that we're then tied to a 
> fairly X-centric model. 

What's wrong with the X-centric model? People who are crazy enough to
go without X are probably crazy enough to go without D-Bus as well, hence
nothing is won if we'd keep this in some D-Bus service. And frankly I
don't care about these people, aynway. They can recode this without X
if they wish, but why should this hold anyone back?

Also, if you'd really want to keep this in some D-Bus service you had
to extend the backlight stuff for: multiple screens, hotplug, to allow
more controls like contrast/brightness, some code to identify those
screens, link them to X screens and so on. That'd be a huge pile of
code copying what X does anyway these days -- just because some crazy
people like to go without X.

> What's the issue with cheese (and similar) applications using a dbus
> call for this purpose?

Not much. I claim however that it is easier to push this all through X
then distributing it over all kinds of different protocols.

But, you know, I am not an X hacker. Maybe ajax or someone is the
better person to discuss this with.

> > For those devices where backlight control cannot be done via the
> > graphics hardware the kernel interfaces should be hooked up to X. And
> > there are already many cases were brightness can be controlled via the
> > gfx hw (i.e. X) but not via the kernel interfaces.
> 
> Unfortunately, in many cases X is going to have to fall back to driving 
> the kernel interface - a great deal of hardware assumes that the 
> firmware is the only thing driving the brightness controls. As we move 
> to more intelligent kernel support for graphics hardware, it's likely 
> that everything will be exposed via the kernel interface in any
> case.

I don't have much insight into kernel mode setting and stuff. But it
would strike me very strange if the code for issuing a few i2c
commands is really something that would be moved to the kernel.
 
> > (Oh, and I'd love to see someone taking
> > http://ddccontrol.sourceforge.net/ and making a module for X of it, so
> > that we could control the backlight of external LCD screens via XRANDR
> > too ;-))
> 
> Adam Jackson has done some work on this, but I don't know how far he 
> got.

Apparently the i2c code in X is fully synchronous right now, and he
wasn't happy with blocking the X server for 100ms when a ddc/ci
command is issued. Should be fixable by making the i2c code a bit more
asynchronous. 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4