[Libcdio-devel] [PATCH] Linux drive detection without medium

[R. Bernstein]

First and foremost, thanks for the patch or more precisely the work
gone to think about what is lacking and packaging how to fix it. It is
rare libcdio gets patches.

address@hidden writes:
 > Hi all,
 > 
 > I just updated gmerlin (http://gmerlin.sf.net/) for use of libcdio.
 > It's was really easy and everything works great so far (tested
 > analog audio playback and ripping via cdparanoia) 

I'm glad to hear that too. In the interest though of full disclosure,
there seem to be recent problems noted when one uses libcdio's
paranoia with a CD-ROM that has SCSI emulation. 

 > except for one:
 > The linux driver detects CD Drives only, when a disk is in the
 > drive. 

Okay, I'll come clean with the sad truth. This project wasn't started
from the standpoint of someone who knew a lot about CD-ROM's and the
various kinds for formats on CD's, and what a library for such a best
should look like. It came from the a simple and trivial observation
that there was way too much cut and paste in the media players, not
all that much abstraction either and a desire to try to add a little
bit of abstraction and hopefully come up with the best of all of the
cuts and pastes. (The rest has been a bit of a nightmare)

So part of the reason at present GNU/Linux driver, and libcdio in
general, detects only drives with CD's in them is two fold: first
that's what was mostly useful in media players or say in the VCD
programs (vcdxrip, vcd-info). Second, many Multimedia commands in the
MMC set seem to make this assumption too - I don't know why. Or
perhaps I just been able to fathom the available MMC drafts to figure
out how say to get drive capabilities when a CD isn't loaded in a
CD-ROM.

But having witten all of this, I have realized that this was a
deficiency and one that would have to eventually get addressed. 

The most recent in-my-face example of the deficiency was in the recent
addition of audio controls and porting Gerd Knorr's cdda-player
program. Here one should have the ability to close a CD-ROM
tray. Rather than deal with the issue and libcdio design deficiency in
the last release I decided it postpone it so as not to delay the other
additions. But in the back of my mind there has been this reworking
that probably needs to go on.

You've been warned :-)

And my current thought here, but as always I invite the opinions of
others (and have burried this already far enough down that most people
won't have read this far) is not to elimate the "detect CD-ROM with CD
in it" function but also *add* the "detect CD-ROM with *or* *without*
a CD in it.

 > I managed to track the problem down to 2 issues:
 > 
 > 1. In the function is_cdrom_linux(...) in the file lib/driver/gnu_linux.c,
 >    the CDROMREADTOCHDR ioctl gets called, which fails when the drive is
 >    empty. The CDROM_GET_CAPABILITY ioctl always succeeds for CDrom drives
 >    and fails for hard disks etc.

Okay that's nice to know. Thanks for the info and tracking this down.

 > 
 > 2. For some reasons, at least my (2.6.10) Kernel fails to open empty drives,
 >    when only O_RDONLY is used. Changing the open flag to
 >    O_RDONLY|O_NONBLOCK, the call succeeds also for emtpy drives.
 >    By the way, the cdrom header file in the kernel says explicitely,
 >    that O_RDONLY|O_NONBLOCK should used whenever a cdrom is touched.

And this may touch on another can of worms and/or deficiency. There
seems to be one camp that thinks that applications whould get CD-ROMs
exclusive access and another that thinks one should be non-exclusive
access. Right now libcdio seems to be in the non-exclusive access
camp. But I have a feeling that as with the CD-ROM detection problem,
libcdio may have to accomodate the other camp as well. And for the
exclusive access CD-ROM situation where in GNU/Linux there is a flag
for exclusive access and I suspect this might be used with O_BLOCK to
block and wait for access.

BEGIN YET ANOTHER DIGRESSION
The exclusive access camp:
-   On Darwin, it seems one has to get exclusive access to issue arbitrary
    MMC 

-   perhaps as a result of the above one of the OSX ports of cdparanoia
    gets exclusive access. Another and libcdio don't require exclusive
    access but I think they'll be able to do less.

-   I believe xine-lib uses exclusive access on say GNU/Linux 

-   I think Peter Jones a Redhat cdparanoia indicated that RedHat suggests
    CD apps get exclusive access
END OF YET ANOTHER DIGRESSION

 > 
 > The attached patch against 0.73 (1) fixes the ioctl and (2) introduces
 > an additional flag argument for the function cdio_generic_init. The
 > linux driver will use O_RDONLY|O_NONBLOCK, the other drivers which use
 > this function (osx and solaris) use O_RDONLY to resemble the old behaviour
 > (I don't have access to these systems).

Okay, will probably commit this after doing a bit of testing. It will
probably cascade some changes on other OS's, I don't know.

 > 
 > Please cc me, I'm not subscribed

Done.