| Message ID | 1268319668-2798-2-git-send-email-apw@canonical.com |
|---|---|
| State | Accepted |
| Delegated to: | Andy Whitcroft |
| Headers | show |
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c index 614da5b..c804094 100644 --- a/drivers/cdrom/cdrom.c +++ b/drivers/cdrom/cdrom.c @@ -290,7 +290,7 @@ static int keeplocked; /* default compatibility mode */ static int autoclose=1; static int autoeject; -static int lockdoor = 1; +static int lockdoor = 0; /* will we ever get to use this... sigh. */ static int check_media_type; /* automatically restart mrw format */
BugLink: http://bugs.launchpad.net/bugs/397734 It seems that users are have a high expectation that the eject button on their CDROM drive will eject the disk regardless of whether it is in use or not. To this end we are now changing the default LOCK mode for mounted CDROMS to 0 to allow ejects. This however does not handle the direct open cases like music and video players. From the launchpad bug commentary: So, according to the upstream discussion David Zeuthen recommended to just not lock CD-ROM trays by default. Kernel/userspace already handles prematurely removed USB storage devices reasonably, and with read-only devices like CD-ROMs it is even less of an issue. So we should just set /proc/sys/dev/cdrom/lock to 0 by default. Note that we still will have the drive mounted after the eject. There is a media change uevent generated and this will be used to trigger the unmount of the drive in udisks. The burner software will also have to be looked at to ensure they are explicitly locking the drive closed during the burn. This will all be handled under the bug above. Signed-off-by: Andy Whitcroft <apw@canonical.com> --- drivers/cdrom/cdrom.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)