The problem today is with the XBox again. It turns out the weird XBox
drives shipped by MS are rpc1 DVD-ROM's while everything you can buy
now is rpc2. so current open-market drives are not region-free, while
the original XBox is. rpc1 is important for Linux because, yes Linux
will still play DVD's from all regions forever even if your drive is
rpc2, but libdvdcss works in a degraded mode with rpc2
(DVDCSS_METHOD=title) which can't decode all disks. In
my experience it is about 1/4 to 1/2 of disks have some problem with
one or two of the .VOB's or titles or whatever it's decoding, and it's
much slower as well. This Linux problem is documented on
this
page in the 'libdvdcss' section.
I believe my problems are that the drive is currently Region 'unset'
because I just took them out of the box. I think if I were willing to
set a region with regionset,
DVDCSS_METHOD=key and =disc would work. But
I want to deliver a region-free player. I think it's easier to be
sure I succeeded if I don't set a region.
All my RPC2 drives are fresh from the box and have no region set. The
TSST SH-S182D drive will still read with DVDCSS_METHOD=key DVD's of
the [All] region (as shown by rpcmgr -i), but the other
two drives won't. Please realize the region number on the DVD case
isn't always right---sometimes DVD's are more permissive. My Baron
Munchausen disk is regions 1, 3, 4. Use rpcmgr -i to
test.
I started working on rpcmgr11.c, a Linux tool that works with the native firmware of certain older Hitachi/LG drives. I ported it from Linux's crufty ``SCSI Generic'' interface to Solaris's more rational uscsi interface. To do the port, I used a combination of this outdated chatty document and the Solaris uscsi man page. The port worked on the first try, but the tool doesn't work with my Lite-ON drive. I liked the Linux documentation because in spite of its short length I could still learn from it key SCSI background like what is a CDB, what's a command group, what's the relationship between command group and CDB length, and what is a data phase. I didn't have to go look at t10.org just for this small project. so sg sucks, but the Linux culture agreed with my impatient mood this time.
My alternative is to reverse-engineer the win32-gamer tool like the original rpcmgr author did. This tool can supposedly set currently-shipping Lite-ON drives to rpc1. I've spent hours trying to get wine ASPI to work, which is longer than the Linux->Solaris port took. And it possibly won't work at all if the protocol is complex, like rewriting the SEEPROM by hand. I'm not sure I'll continue this.
I've been working on this since before the One Night of Work. What I accomplished tonight was to refactor my XBox eject button fixes so ide-cd.ko can be compiled as a module and loaded and unloaded. Here are the latest patches.
With this, I can unload ide-cd.ko, load ide-scsi.ko, and hopefully run
WINEDEBUG=+aspi wine LtnRPC.exe to see what SCSI commands
the win32 gamer tool is using.
update 2007-02-26: With this Wine patch
and WINEDEBUG=+cdrom I'm able to capture the SCSI commands LtnRPC.exe is sending. It
doesn't use ASPI at all. It uses Windows DeviceIoControl's. And Wine
isn't using the /dev/sg[0-9] interface at all. It's using the Linux
SG_IO ioctl, which is the SCSI-generic v3 interface, which is a lot
more like Solaris uscsi. And this interface works with ide-cd.ko or
ide-scsi.ko, so my earlier work to refactor the eject button fix was
unnecessary. It's necessary to put a disc in the drive. It's also
necessary to mount the disc and assign it a Wine drive letter in
~/.wine/dosdevices/ for LtnRPC.exe to list the drive as a
choice in its GUI.
So far I've only tried pressing the [Query] button, so I don't even know yet if this tool actually can rpc1-ify my modern optical drive. I want to make sure the SCSI command traceing is really working first, because some of the other buttons might use up my RPC2 user/vendor resets. Next steps are:
DVDCSS_METHOD=key.
still need a lot more luck before this is done.
update 2007-02-27: the [Query] stuff looks reasonable, although I can't explain every command. One thing that looks wrong is, it seems to send 12-byte CDB's for all commands, even 6- and 10-byte commands. I made another patch to truncate CDB's to their natural lengths, but I've never run Wine with this patch. It's not needed and can be harmful.
The [Disable] button doesn't work. I wish I had a Lite-ON drive that's known to work with this tool for comparison.
...ha! Using WINEDEBUG=+relay,+cdrom traced back the NT
error to EACCES. I ran wine as non-root, and Linux allows certain
commands with read access to the device (enough for mplayer/libdvdcss
I guess), but not these weird commands. For that you need write
access to the device. so,
f3 0e 03 00 00 00 00 00 00 00 00 00
f3 0e 03 00 01 00 00 00 00 00 00 00
f3 02 00 00 00 00 00 00 00 00 00 00
I'm not sure if they're really 12-byte commands, since the Windows program is sending everything---TEST UNIT READY, INQUIRY, MODE SENSE 10---as 12-byte, even though some of those are 6- and 10-byte commands. f3 and df would normally be 10-byte commands.
I tested with a DVD, and rpc2 vs. rpc1 does make the difference of whether DVDCSS_METHOD=key works or not. so we've finished up to step 3.
Here's step 4: Linux/Solaris source for rpcmgr 1.4
Now I will do step 5. cha-ching. oh, snap! I got the last one in stock on NewEgg. suckah.
update 2007-03-11: My NewEgg order arrived, including their last SHM-165H6S in stock, but also a different Lite-ON drive, the LH-20A1H. I updated rpcmgr above to version 1.4, and it will now work with this drive. It will probably work with most past and future Lite-ON drives.