udisks replacement for the HAL EjectPressed signal?

Kay Sievers kay.sievers at vrfy.org
Thu Jan 14 21:31:26 PST 2010

On Fri, Jan 15, 2010 at 02:48, Benjamin K. Stuhl
<benjamin.stuhl at colorado.edu> wrote:
>   I'm (slowly) working on writing a udisks/upower/udev/... backend for
> KDE's hardware abstraction layer ("Solid"), and I've run into a
> substantial functionality loss with udisks: there doesn't seem to be a
> replacement for HAL's EjectPressed signal for CD/DVD drives. (HAL emits
> EjectPressed when the user presses the _physical_ eject button on the
> drive itself, but there's no way to get that information other than by
> polling the drive. Well, supposedly there's an asynchronous status
> request as well, but at least as of a few years ago word was that no
> drives actually implemented it...) Since I would rather not have to put
> polling code into KDE at the desktop level (it _should_ be at the udisks
> level where it will obey the same "inhibit polling" requests as the rest
> of the stack), would it be possible to get an equivalent to EjectPressed
> added to udisks?

No, there is no smart polling in udisks anymore, it's just a simple
open(), the rest is in the kernel. It is expected, that ll the polling
will move to the kernel itslef, which also will not care about the
button handling.

The EjectPressed did not work for many devices anyway. We probably
just unlock the CD tray, and need to recover from the media going away
underneath. Or the software eject in the UI just needs to be used.

So, it's unlikely, that there will be any eject button handling signal
for devices in the future.


More information about the devkit-devel mailing list