[Libburn] Drive data/properties gathering

[Derek Foreman]

On Sat, 8 May 2004, [ISO-8859-1] St=E9phane LOEUILLET wrote:

> hello libburn ML readers,

Hello

> i decided to give libburn a try to see what needed work
>
> so, i gathered latest CVS, plenty of SCSI docs (MMC-1 std to 4 draft,
> SPC, ...), and a few burners.
>
> i "heard" that Todd from Optimystic was working on improving libisofs by
> addind Rock Ridge, libburn maintainers working on TAO support but i saw
> noone working actively on communication with the drive.
>
> what seems to need work :
>
> Error handling when using MODE_SELECT_10 to test TAO/SAO/...
> availability (is there a better way to do it ? like a page mode that
> describe this kind of capability)

I've not seen a mode page with that information.  The current code is
ugly, but I don't know a better way.  Some drives claim to support modes
they don't, some even claim to support totally useless modes (raw disc at
once with no subchannels, for example.  It's impossible to burn a valid
disc in this mode - the toc requires subchannels).

If you find a better way, I'll merge it asap. :)

BTW, error handling in general sucks right now.  libburn will happily try
to burn a whole cd image while the drive tells it the data is invalid.
(This actually speeds up testing certain pieces of code, which is why
fixing it is a low priority for me right now. :)

> Enhanced MODE_SENSE_10 probing : actually, only few informations are
> extracted from page mode 2Ah. (basic MMC-1 i would say but nothing like
> MMC2 or MMC3 info like available write speed list)
>
> Handling of future MMC-4 drives : for now, MMC-4 is still a draft but i
> suppose there are already some drives around that support early MMC-4.
>
> The problem with MMC-4 is that page mode 2Ah is deprecated, in favour of
> a feature/capability list. (which is far clearer that this infinite ugly
> bit-field that 2Ah is)

That mode page sucks.  But I'm not sure how many drives support feature
lists, so we'd still have to support 2A for the forseeable future.

(I'm trying to remember what cool feature Tiago gave up on implementing
because 4 out of 4 drives we tested it on didn't support it - and it was
required by mmc3)

> i'd like your feedback on a few points :
>   - how should capabilities be presented ?

I think a lot of the capabilities junk should be handled via
freedesktop.org's HAL.  Though, I'm not sure I like the idea of making
libburn dependent on HAL.  <sigh>

> extending the drive_info structure infinitly would make it as ugly as
> page mode 2Ah is.
>
> or should we provide a feature list like what MMC-4 (and perhaps even
> earlier versions) provide, as a linked list ? (recreating it from 2Ah in
> the case that the drive is too old and does not provide it)
>
> or even several lists :
> one for accepted media types
> (DVD-R/DVD+R/DVD-RW/DVD+RW/DVD+R9/CD-R/CD-RW/DD-CD/CD-MO/DVD+R DL/....)
>
> one for writing modes :
> (Packet writting, SAO 96R, DAO 16, TAO, ...)
>
> and what does not fit in a list going to a structure like we have
> actually

This is starting to sound like a bit of a pain to use... I'm not going to
pass a linked list to an app.  If we decide on something more complicated
than a struct, it'll have to provide all the helper functions required to
keep it simple.

Is the struct all that ugly?  The same amount of information still needs
to be presented, I think names in a struct is simpler than a bunch of
function calls to get one bit's worth of information.  It's not like we're
asking the user to do the same bitshifts and masking that 2A makes us do.

I suppose breaking binary compatibility every time we need to add a field
to the struct is a pain in the ass.

I don't mind bitfields and enums/defines for modes and media types.

>   - what info are really needed ?

That's a good question.

I've already considered dropping a few of the really obscure write types.
Writing code to generate sectors for all available modes is pointless when
there are modes that the spec calls "optional" that are less useful than
ones the spec mandates.

> few would need to know their drive supports bar-code reading, CD+G, CD
> Extra, CD-I/Photo CD, VCD/SVCD, ...

Well, those don't all get their own bits per se.  If you can read mode2
form <mumble> then you can read VCD, if you can read subcodes, you can
read CD+G, etc.  That's all pretty important information.  Bar codes are
still a piece of information we could "backup" off a disc, so maybe we
still need that too.

CD Extra is either multi session, data in pregap, or mixed mode, depending
on generation.  It doesn't have a 1:1 mapping with bits in a mode page.

I don't think we care too much about page 2A's "number of volume levels"
or "Digital port" for burning purposes.  Maybe libburn should be able to
report anything the drive can tell us about itself, no matter how useless
that information is to libburn's operation...  (or HAL should?)

That doesn't mean we have to support burning in every possible mode
though.

> i already implemented "available write speed list" (for MMC-3 drives
> only) even if actually i don't know where to store those speeds.

Cool.  If you can make it gracefully fallback to 2A when the drive fails
the command, you can just dump the values into an array of speeds in
struct drive somewhere, and make the existing get/set speed functions use
that if it's available...

Functions to export that array somehow would also be nice - not sure what
we want to do in that case for drives that don't support lists.  Maybe
fabricate something, at least a single entry with the drive's maximum
speed.

> i did it at the end of the MODE_SENSE_10/2Ah call. i don't yet know why
> but it seems this list is sensitive to the type of media which has last
> been inserted :
>
> on my combo CD/DVD burner, the reported available speeds aren't the same
> depending on the media type. i need to find a way to query those either
> on demand, specifying a fake media type as parameter to query each speed
> list or only just before burn time.

Yes, the drive reconfigures itself when you load new media.  CDRWs
generally can't be written to as fast as CDRs.

Since we lock the drive door when the front end "grabs" the drive, we can
depend on those values staying the same until the front end releases the
drive, so this quirk shouldn't cause anyone any trouble.  (I think we
query speed after the grab, if we don't, we should.  :)