another DeviceKit backend for Solid

[Benjamin K. Stuhl]

On Saturday 08 August 2009 16:06:05 Kevin Kofler wrote:
> Benjamin K. Stuhl wrote:
> >   I committed another, alternative, DeviceKit-based Solid backend to
> > KDE's Subversion repository yesterday, in
> > branches/work/alternative-solid- devicekit. It grew out of some
> > experiments I was doing with writing a Qt-ish libudev wrapper (you can
> > see the API in solid/backends/udevqt.h). Since it got large enough to
> > perhaps be useful to other people, and also to convince me that the
> > general approach would work, I imported it into Subversion from my GitHub
> > repository. The major difference from Pino and Lukas's
> > work/solid-devicekit branch is that I also use libudev for enumeration,
> > as well as DeviceKit-*;
>
> Great! I told ltinkl this is necessary, he wasn't very thrilled by the
> idea.

I can appreciate his lack of enthusiasm since it adds some complexity to the 
code, but there's no way to get things like camera information from DeviceKit-
* -- e.g. AFAICT gphoto's plan is that they will just dump a .rules file into 
udev that attaches a GPHOTO_DRIVER property to the detected cameras.

> > I have also made an effort to try to minimize the amount of boilerplate
> > code each Interface needs (c.f.
> > solid/backends/devicekit/dkdevice.cpp:dbusDeviceCall() and
> > solid/backends/devicekit/dkinterface.h). Please take a look and comment
> > or help out, especially if you know DeviceKit or libudev.
>
> In what state is it in? Is it something we could put into Rawhide, keeping
> in mind that the Fedora 12 release is less than 3 months from now? Or is it
> still incomplete and/or buggy?
>
> (We decided that the original work/solid-devicekit branch is not suitable
> because it's missing features the HAL backend has. With libudev, we should
> be able to provide those features.)

I would not say it's ready for Rawhide, especially since it doesn't have all 
the Solid::Ifaces implemented yet. But even once the backend is "finished" (and 
even it the code was bug-free), it's going to have some regressions against 
HAL, simply because upstream projects like gphoto and libgpod haven't yet  
released versions that store their eumeration data in udev. Maybe by Fedora 13 
those versions will be out and KDE can switch to DeviceKit, but in the 
meantime there would be a lot of complaints of "why did KDE suddenly stop 
detecting my camera?".

To be honest, libudev/DeviceKit-* currently lacks substantial features in 
comparison with HAL. Maybe in the future there will be a DeviceKit-* for every 
device imaginable, but in the meantime I feel like I'm having to steal 
substantial amounts of ideas from HAL's addons to get the features we need. 
(E.g. I'm currently writing a class that uses the sg or bsg device associated 
with your cdrom drive to listen for eject button presses -- in HAL, this is 
done by hal-addon-storage, but DeviceKit-disks doesn't provide it.)

Regards,
-- BKS