(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
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel