On Tue, Jun 30, 2009 at 05:48:44PM +0200, Kevin Kofler wrote: > Matthew Garrett wrote: > > I've been working with David Zeuthen to flesh out proper desktop support > > for this, and we're now at the point where there's not a great deal of > > code to write to get this working cleanly. Unfortunately this requires a > > certain level of integration between the kernel and the desktop - > > something has to prompt the user about unmounting the device and then > > trigger the completion of the undock. The kernel still handles the > > actual ACPI execution, but policy now lives in the desktop. > > What changes are needed to the desktop? > > The big problem we've been facing integrating new features of core system > services into KDE so far was lack of documentation. What do we need to > change? An event will be generated and a policy agent then needs to choose what to do in terms of unmounting any media. The precise interface doesn't exist yet, but will be documented. > If this will be all handled within DeviceKit, then this will come by itself > with the Solid DeviceKit backend ltinkl is working on, but if we need to > add some desktop interaction for it, we have to know what it should be. So, what you'll get is a notification that a block device has requested removal along with a notification that a dock device is being undocked. What you do with the block device is up to you, but in general you'll want to unmount it. Whether you're willing to kill applications that have open files on it is a policy decision. After the unmount you'll then trigger the completion of the undock and tell the user that it's now safe to remove their hardware. > > Once this code is ready I'd like to change the kernel defaults to allow > > this. The problem is that this will cause a reduction in functionality > > for desktops that don't have this integration. How should this kind of > > situation be handled? > > You have to tell us what we need to change in KDE and give us the necessary > time to adapt, even if it means you have to wait for Fedora 13 to push this > change. Hm. So, that bit about KDE not holding Gnome back wasn't entirely correct? -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
