Some clarifications about the GH22LS30 problem

This commit is contained in:
Thomas Schmitt 2009-12-06 07:32:38 +00:00
parent 2fd0fc3086
commit 07f535c72b
2 changed files with 14 additions and 7 deletions

View File

@ -1 +1 @@
#define Cdrskin_timestamP "2009.12.05.143707"
#define Cdrskin_timestamP "2009.12.06.073404"

View File

@ -4069,11 +4069,18 @@ int mmc_read_disc_structure(struct burn_drive *d,
msg, 0, 0);
ret = 0;
/* LG GH22LS30 revision 1.00 returns for DVD-R an allocation
length of 4 (= 0 payload). A MS-Windows tool can inquire
media code "RITEKF1", though.
This macro causes a try to unconditionally read the desired
payload bytes.
/* ts A91205
LG GH22LS30 revision 1.00 returns for DVD-R format
code 0x0E an allocation length of 4 (= 0 payload).
A MS-Windows tool can inquire media code "RITEKF1",
though.
This macro causes a try to unconditionally read the
desired payload bytes. The drive then returns 35
bytes as requested and the media id is "RITEKF1".
Nevertheless this is not a generally usable gesture
because older Linux USB dislikes requests to fetch
more bytes than the drive will deliver.
# define Libburn_enforce_structure_code_0x0E 1
*/