[Libburn] Drive data/properties gathering

[Stéphane LOEUILLET]

hi,

> > 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. :)

ideas for now, code later if we're lucky :)

perhaps i've found one but i don't know enougth yet about CD burning to
say at 100% it could replace this :

instead of use SPC MODE_SELECT_10, perhaps we could use
MMC_GET_CONFIGURATION (exists but is unused for now).

let me explain that :

GET_CONFIGURATION returns a feature least (what replaces parts of the
ugly page mode 2Ah for example)

in those features, we have :
002Dh : CD TAO (BUF, R-W RAW, R-W pack, Test write, CD-RW, R-W)
002Eh : CD SAO (BUF, SAO, RawMultSess, Raw, Test write, CD-RW, R-W)
FeatureID : global mode (options as booleans)

i suppose RAW96R is TAO with "R-W RAW" set, 96P beeing when "R-W pack"
is set, ...

i read MMC4 draft but this should exists from MMC3

do you see any needed write mode missing ?

> 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. :)

no problem with that, as long as we can add callbacks later (for error
and progress reporting)

> > 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.

are you ok if we keep both in // (first calling the most recent, then
the older as a fallback)

> (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)

standards are good. but they are much better when implementors follow
them. (and do not follow early drafts that could change dramatically)

as you know, we live in a perfect world

<SNIP>

> > 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...

in fact, this feature uses page mode 2Ah. i already added tests based on
page length, which is different for pre-MMC1, MMC1, MMC2 and MMC3 (MMC3
page length beeing variable because of this non-fixed size list of wr
speeds)

so, should be safe for older drives/ones not supporting this MMC3
feature

my Lite-On DVDRW 411S and my LTR 32123S both support it. (first beeing
from october 2003 but second beeing from june 2001 if i remember well)

> 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 could try to do it

bye

-- 
Stéphane LOEUILLET <stephane.loeuillet at tiscali.fr>