[Kde-hardware-devel] Notes from Solid BoF at Tokamak4

[Kevin Ottens]

(CCing Martin Sandsmark as his name popped up regarding the audio support)

Hello metalworkers![*]

Since the mail of sebas about the notes taken during the Solid BoF at Tokamak4 
didn't go through after two attempts (and is not even stuck into the moderator 
queue... go figure), I decided to send it here directly myself.

Of course, if you're interested in hardware support in KDE for 2010 you 
probably want to read it all.

As a bonus (as apparently it wasn't in sebas' ghost mail), I'm providing you 
URLs to the two pictures we took of the whiteboard. They kind of summarize the 
two great directions we're taking for the project.

http://ervin.ipsquad.net/share/solidcontrol_magically_disappearing.jpg
Extra info on this picture:
We all noticed that unlike what was planned, there's really only one consumer 
of each of the areas (power, network, bluetooth, lirc) of libsolidcontrol. As 
such its structure to ensure independence is an unnecessary burden to the 
people working on libsolidcontrol and the people using it in the stack as the 
abstraction is low level.
Also, we noticed that there's an organizational pattern happening already in 
the powermanagement and networkmanagement area with a kded module at its 
center, providing a control interface for a KCM and a Plasma data engine which 
feeds a Plasma widget display. In some case libsolid might query said daemon 
for very high level and simple features aimed at general purpose applications.
So, the idea is to rollback the relevant libsolidcontrol parts in the KDED 
module, killing the backend separation in the process. The abstraction over 
the system facilities used would then be done within the KDE module in a more 
ad hoc way, or using several versions of the module.

http://ervin.ipsquad.net/share/solid_multibackend.jpg
Extra info on this picture:
Right now, libsolid has a frontend/backend architecture. But there can be only 
one backend loaded at a time which then has to provide *everything* by itself. 
That was quite a limitation, and for instance in the end that's the reason why 
we weren't listing any of the bluetooth devices directly from libsolid for 
instance (as that would require a BlueZ backend).
In order to fix the situation, and also to distribute better the 
responsibilities among us (so far the HAL backend is mostly a one man show, 
and there's only 24 hours per day), the idea is to finally allow libsolid to 
use several backends at the same time depending on the requests it gets from 
the application. We listed several benefits to that:
 - Bringing more contributors to libsolid via its backends;
 - Tackling some of the expected features that we couldn't really provide 
(better audio support or bluetooth for instance);
 - Easier to also provide virtual devices that we were completely ignoring so 
far (alsa come to mind here);
 - Opening up libsolid on the network (yes! network devices from your home! as 
we aim at having a UPNP backend);
 - Make ervin happy as he'll feel less alone, doing mostly integration work. 
;-)

So we still have bugreports against libsolid, but I kicked myself and actually 
fixed the most important issue it still had to my knowledge: the leak which 
was reported on kde-core-devel in december. So now I can actually start 
touching the architecture to go to the multi-backend architecture as soon as I 
find some time for it. I don't expect it to take too long in fact...

The movement toward disbanding libsolidcontrol is still in its infancy and 
will probably take some time. Dario and Will are probably well placed to 
comment on their own areas (which are AFAIK the biggest ones).

That's all for now folks. Interesting times ahead for us.

Comments and questions are welcome, in particular since that's mostly raw 
material that we have taken during the meeting (tried to reinsert some context 
though).

Regards.

[*] Since KDE people are called "gearheads", I just decided to call the people 
dealing with hardware in KDE the "metalworkers" (and yes for those who wonder 
it's kind of a reference to Judas Priest which was playing earlier at 
Tokamak4).
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
Solid BoF Tokamak 4 Notes

Present: Dario, Kevin, Fredrik, sebas, Friedrich, Alex, Will, Sandro

  - power management should become more session-friendly
  - Suspension moves into KSM, where also halt, reboot, logout are (Dario)
  - consolekit is used to do policy on that level,
  - it is concerning that consolekit is hardly maintained while it is a central component and many things stop working if it breaks
  - Dario considers making powerdevil modular by using plugins, for hardware-related functionality, making it more adaptable for mobile devices and device-specific implementations
  - We should look into Pardus's power management stuff, and consider using that instead of moving from HAL to upower (sebas), maybe upstreaming parts of comar
  - we might want to fire up consolekit in startkde ourselves, so we can prevent authorization problems (dario)


  - networkmanagement plasmoid finished this week
  - better support for multiple batteries, weighted display for batteries with (sebas)
  - support for UPS (we want to know when the UPS runs out of power), there's a battery type for that already
  - likewise mouse batteries (just a different battery type reported)
  - testing this can be done with libsolid's fake backend, basically an XML description for 
  - We need a resumed() signal, for updating UIs after sleep (clock!), we've been waiting for HAL (upower, devicekit) for too long, as the DBus call to suspend is sync, we should be able to fire such a signal relatively reliably (dario has a patch, sebas will test it), we need to note that the signal might not be a 100% reliable, but better than nothing and will likely work in many cases
  - The screenlocker in powerdevil should lock right before suspend, not after, to prevent a small window from opening where the screen isn't locked (dario)
  - solidcontrol should get a list of shared wireless networks instead of accesspoints (a network can have multiple accesspoints, what matters to the user is the network, not the accesspoint) (Will)
  - as most of the stuff in libsolidcontrol (in kdebase,not kdelibs' solid) has only one user, we might fold it back into those applications, making development of those slightly easier (probably not a big problem anyway)
    - some simple patches will be needed (powermanagement dataengine for example), but shouldn't be a lot of work
    
  - Kevin considers adding virtual devices to the scope of solid as well (think of ALSA's fake devices, or pulseaudio's), 4.6 material
  - previously, only one backend was allowed to be loaded at a time
  - in the future, we might to go to multiple backends at a time i.e.:
    - udev,
    - udisk (kevin),
    - upower (dario),
    - bluez (afiestas?),
    - alsa (sandsmark?),
    - pulse (guthrie),
    - upnp (friedrich)
    not all backends matter a lot; 
  - contact Pardus guys to put their backends upstream to fit into this
  - this would simplify providing a complete devicetree from libsolid
  - there would not be any interaction between the different backends
  - this makes libsolid able to deal with different frameworks at a time
  - talking directl to udev would not enable virtual devices, as udev is not allowed to do that
  - contact Alex Fiestas about bluez stuff
  - upnp fits nicely into solid based on its structure, for example on top of StorageAccessDevice
  - Bart is working on a KIO slave for upnp
  - A solid sprint would be great, maybe in June
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100223/fad9556e/attachment.sig