Some clarifications about the GH22LS30 problem
This commit is contained in:
parent
54bb1ab395
commit
cb8c23ed5a
@ -1 +1 @@
|
|||||||
#define Cdrskin_timestamP "2009.12.05.143707"
|
#define Cdrskin_timestamP "2009.12.06.073404"
|
||||||
|
@ -4069,12 +4069,19 @@ int mmc_read_disc_structure(struct burn_drive *d,
|
|||||||
msg, 0, 0);
|
msg, 0, 0);
|
||||||
ret = 0;
|
ret = 0;
|
||||||
|
|
||||||
/* LG GH22LS30 revision 1.00 returns for DVD-R an allocation
|
/* ts A91205
|
||||||
length of 4 (= 0 payload). A MS-Windows tool can inquire
|
LG GH22LS30 revision 1.00 returns for DVD-R format
|
||||||
media code "RITEKF1", though.
|
code 0x0E an allocation length of 4 (= 0 payload).
|
||||||
This macro causes a try to unconditionally read the desired
|
A MS-Windows tool can inquire media code "RITEKF1",
|
||||||
payload bytes.
|
though.
|
||||||
#define Libburn_enforce_structure_code_0x0E 1
|
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
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#ifdef Libburn_enforce_structure_code_0x0E
|
#ifdef Libburn_enforce_structure_code_0x0E
|
||||||
|
Loading…
Reference in New Issue
Block a user