Up until Fedora 14 I was successfully using cdctl
to enable/disable the CD/DVD eject button on my laptop (Thinkpad T410). Sadly it has stopped working now.
I've consulted the methods discussed in these 2 questions:
- disable cd/dvd button on linux laptop (ubuntu)
- Disable the DVD eject button on a Thinkpad running Linux
None of which have worked for me. So I turn back to cdctl
to see if we can't fix what's broken with it, since it's worked for so long.
Debugging the issue
So starting with cdctl
switches I notice that most things seem to work just fine.
Examples
These things work.
ejects the drive
$ cdctl -e
list capabilities
$ cdctl -k
Tray close : 1
Tray open : 1
Can disable eject : 1
Selectable spin speed : 1
Is a jukebox : 0
Is multisession capable: 1
Can read the MCN (UPC) : 1
Can report media change: 1
Can play audio discs : 1
Can do a hard reset : 1
Can report drive status: 1
According to that list cdctl
even thinks that it can enable/disable the eject button.
Can disable eject : 1
So I continue on with debugging the issue.
Debugging cdctl
So I figure lets do an strace
on cdctl
to see if it can shed some light on what's going on.
$ strace cdctl -o1
...
brk(0) = 0x1371000
open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/cd", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/scd0", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/sr0", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, CDROM_LOCKDOOR, 0x1) = 0
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
Curiously it seems like cdctl
thinks it's disabling the button.
$ strace cdctl -o1
ioctl(3, CDROM_LOCKDOOR, 0x1) = 0
$ strace cdctl -o0
ioctl(3, CDROM_LOCKDOOR, 0) = 0
NOTE: If I understand this right, the return of a 0 means it was successful.
One thing that caught my eye here was the list of devices that cdctl
is attempting to interact with. So I thought "what if I try these devices with eject
"?
eject command
One of the other commands I used to use years ago was the eject
command to interact with the CD/DVD device. I noticed that this command also now has a similar named switch:
$ eject --help
-i, --manualeject <on|off> toggle manual eject protection on/off
Example
$ eject -i 1 /dev/sr0
eject: CD-Drive may NOT be ejected with device button
$ eject -i 0 /dev/sr0
eject: CD-Drive may be ejected with device button
So eject
too thinks that it's disabling the button, yet it isn't either. Using strace
here I see the same system calls:
$ strace eject -i 1 /dev/sr0 |& grep ioctl
ioctl(3, CDROM_LOCKDOOR, 0x1) = 0
$ strace eject -i 0 /dev/sr0 |& grep ioctl
ioctl(3, CDROM_LOCKDOOR, 0) = 0
So now I'm wondering if UDEV or something else is potentially blocking or taking ownership of device?
Thoughts?
Best Answer
Thanks to @Affix's answer which gave me the right direction to head, I've figured out the solution to the problem.
The problem is definitely caused by UDEV as you've guessed. The issue is this line that is in most UDEV files related to the cdrom drive.
Example
On Fedora 19 there is the following file,
/usr/lib/udev/rules.d/60-cdrom_id.rules
. In this file is the following line which is co-opting the eject button for CD/DVD devices.You can work around the issue and disable UDEV's ability to co-opt the eject button by doing the following:
Make a copy of the file
60-cdrom_id.rules
Edit this copied version of the file and comment out the line containing the string,
DISK_EJECT_REQUEST
.Save the file and the change should be noticeable immediately!
The above solution fixes the problem for both
eject
andcdctl
. So now the following commands work as expected:lock the drive
unlock the drive