[Libburn] Drive data/properties gathering

[Derek Foreman]

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

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

Sounds good to me.

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

yes.

Both those subcode formats work for DAO burning as well.

> i read MMC4 draft but this should exists from MMC3

Yup, this stuff's in the mmc3 docs too.

> do you see any needed write mode missing ?

Don't forget the data type bitfield to fill in the block types, it's under
the 0021h feature definition in my copy of the mmc3 docs.

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

That's what I mean.  If feature lists fail, fall back to 2A.  That would
be good.  Unless we come across drives that freak out when sent
GET_CONFIGURATION, or pretend to report good data. :/

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

Ahh yes.  The way we currently check speeds is "obsolete" according to
mmc3 because of this.

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

My LTR-52327S supports it as well, but I'm pretty confident there are
drives in service that don't support this.

As an aside, have you come across any way to get these Lite-On drives to
pass us back c1 error pointers?  I suspect it's a vendor extension. <sigh>

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

That would be great :)