Paolo Bonzini <pbonz...@redhat.com> writes: > Il 05/12/2013 13:42, Alexey Kardashevskiy ha scritto: >> Thanks! >> >> Just out of curiosity. A lot (in fact, all around me) dvd drives do not >> support trayclose as they are in laptops or servers (which use the same >> laptop models). I cannot even verify how this "eject -t" exactly works - no >> hardware around me. And even if I could find it, I could easily take the >> disc off the tray in that short period of time between tray is open and >> tray is closed but we still absolutely want "eject" + "eject -t" to work as >> you described. > > Taking the disc off the tray is equivalent to going to the monitor and > doing "eject -f cd".
Actually, monitor command "eject -f" is like poking the little button hidden in that little hole with an unbent paperclip or something, which makes the drive eject whether the OS likes it or not (and tends to make the OS rather upset), then removing the medium. Monitor command "eject" without -f is like pushing the "normal" button, and if that ejects, and the medium wasn't locked, removing the medium. Yes, that's not exactly elegant semantics. /usr/bin/eject is something else entirely: it sends commands to the device. Such commands can make the drive eject and load, but they cannot cause the medium removal without further user action. Exactly the same on real and virtual systems. > I.e. programmatic actions leave the disc in (at least if you do not > consider laptops and servers; but the guest can detect whether the tray > can be auto-closed, and we tell it that it can). Out-of-band user > actions force the disc out. > >> Why exactly? :) Only because change of behavior is bad? Just asking. Thanks. > > The only practical use of CDs is installation, and it took a looooong > time to get it to work with all sorts of guests. Indeed.
