Date: Thu, 13 Dec 2007 12:18:45 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-questions@freebsd.org Cc: gnome@FreeBSD.org, kde@freebsd.org, Nikos Vassiliadis <nvass@teledomenet.gr> Subject: Re: mounted cd and tray locking Message-ID: <47610705.90100@icyb.net.ua> In-Reply-To: <476025E1.7020200@icyb.net.ua> References: <475FC26C.3030508@icyb.net.ua> <200712121555.24953.nvass@teledomenet.gr> <47601344.8020106@icyb.net.ua> <476025E1.7020200@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 12/12/2007 20:18 Andriy Gapon said the following: [trimmed] > Investigated more and it seems that hald is a main culprit here. Without > it everything works reasonably well as long as I don't mix acd and cd > accesses. > That is, if I mount through acd, then trough cd, then unmount the cd > mount, then tray gets unlocked. In a perfect world I would like to fix > even this, but in real world this is OK. > But if mount only through one device then tray is locked. > > So, hald is doing something "wrong" here. I am not sure if it is by > design (to make the behavior mswindows-like) or if it is a bug or a > side-effect of something. Okey, I think I got it finally. There is a capability for ATAPI devices that I didn't know about before: there is a possibility to poll a device and check if physical eject button was pressed while tray was locked with "prevent" command. Hald does just this and then posts "EjectPressed" event. When KDE mediamanager gets this notification it tries to do various stuff which should ultimately lead to unmounting media in the device and ejecting the tray. This seems to work reasonably well if KDE knows something the mount, but this works miserably otherwise. Examples: 1. atapicam is enabled and media is manually mounted via acd device 2. media is mounted via user-land fuse-based filesystem driver In these cases "KDE" simply issues eject command and the drive is only happy to oblige. I wish that there was a way in KDE to configure handling of such events where I could select one of the following: 1. ignore eject button press 2. give me a notification about it but do not do anything 3. give me a dialog asking how to proceed 4. try to unmount media and eject tray but don't eject if proper unmount could not be done (unknown fs, etc) And, of course, if device was not locked (via prevent) for reasons of mounting media or otherwise opening device file or explicit command, then a drive itself should handle the button. It should not be "artificially" prevented from doing so. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47610705.90100>