('binary' encoding is not supported, stored as-is)
Hi Scott, Jay and all...
I've received an e-mail from Scott asking about SANE support for the
hp4300. I asked him to run USB Snoopy and save a log file. I
received the file one or two days ago, and I compared the log file and
Jay's HP3300 log file. I must say I had no time to explore the whole
file when Jay sent me the log (I asked for the file in October), but
now in Christmas I have some time... so it was nice to inspect the
protocol again.
I knew the hp4300 and hp3400 are more or less the same scanner, or
at least it seems to be the same device driver in windoze. But those
scanners and the hp3300 are more than friends! (maybe cousins or
brothers ;)
There are too many common control commands, and that's what I have
found...
I.- Little (and innacurate) introduction about URB control transfers in USB.
----------------------------------------------------------------------------
The URB is a little packet made of bits, bytes and those stuff, that
USB interfaces use to communicate. A (not so) special packet in made
to send control commands to the device. Those URBs are labeled in the
USB Snoopy log file with URB_FUNCTION_CONTROL_TRANSFER.
Other URB types than control transfers exists, but they are mainly for
data transfers or USB configuration.
The most important information in an control URB is:
* Request: what is asked to the device to be done.
* RequestTypeReserverBits: indicates that the operation is read (0x40) or
write (0xc0) (This is a simplification)
* Value: depends on the meaning of the command.
* Index: also depends on the meaning of the command.
* TransferBuffer contents: also this.
The control procotol --not the data-- is used to be handled in URB control
transfers, and is defined by the values the above fields take during
time.
If you look at the log files, you will find an example like this (line
numbers and time removed):
>>>>>>> URB 4 going down...
-- URB_FUNCTION_VENDOR_DEVICE:
TransferFlags = 00000000 (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = ccaa7970
TransferBufferMDL = 00000000
0000:
a0
UrbLink = 00000000
RequestTypeReservedBits = 40
Request = 0c
Value = 0088
Index = 0970
This packet was sent from the host computer to the scanner. All USB
packets have (normaly) a reply. That is:
<<<<<<< URB 4 coming back...
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = ccd3812c
TransferFlags = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = ccaa7970
TransferBufferMDL = ccaa7980
UrbLink = 00000000
SetupPacket : 40 0c 88 00 70 09 01 00
This one is not very useful, except in case of a read operation. In
such cases the buffer will be filled with info returned from the
scanner, like in this case:
<<<<<<< URB 48 coming back...
-- URB_FUNCTION_CONTROL_TRANSFER:
PipeHandle = ccd3812c
TransferFlags = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
TransferBufferLength = 00000001
TransferBuffer = ccaa7940
TransferBufferMDL = ccaa7980
0000:
00
UrbLink = 00000000
SetupPacket : c0 0c 84 00 21 64 01 00
II.- Hacking the scanner.
-------------------------
All my test were done using the hp4300 driver and its log file, but
I have also contrasted this info with the hp3300 log file.
Firstly, I must say I have no idea about the values that the Index
field gets during the scanning process. That's a mistery for me at
the moment, until somebody give to me a second log file. Then I'll
check if the field will get the same values.
But Value and Buffer contents seems to have some special patters.
When the computer wants to start talking to the scanner, it uses a
special sequence. I have also found the piece of assembler code that
generates that sequence, wich is:
Value Data
===============
0088 a0
0088 a8
0088 50
0088 58
0088 90
0088 98
0088 c0
0088 c8
0088 90
0088 98
0088 e0
0088 e8
You can check those values in all log files, and you will see
that (maybe) this sequence is repeated more than once during the log.
The Value field 0x0088 is used only in the ``startup sequence''.
Here is the assembler code:
:067F4940 83EC08 sub esp, 00000008
:067F4943 A130158006 mov eax, dword ptr [06801530]
:067F4948 C744240000000000 mov [esp], 00000000
:067F4950 83F801 cmp eax, 00000001
:067F4953 C744240400000000 mov [esp+04], 00000000
:067F495B 7579 jne 067F49D6
:067F495D 68A0000000 push 000000A0
:067F4962 E8394D0000 call 067F96A0
:067F4967 68A8000000 push 000000A8
:067F496C E82F4D0000 call 067F96A0
:067F4971 6A50 push 00000050
:067F4973 E8284D0000 call 067F96A0
:067F4978 6A58 push 00000058
:067F497A E8214D0000 call 067F96A0
:067F497F 6890000000 push 00000090
:067F4984 E8174D0000 call 067F96A0
:067F4989 6898000000 push 00000098
:067F498E E80D4D0000 call 067F96A0
:067F4993 68C0000000 push 000000C0
:067F4998 E8034D0000 call 067F96A0
:067F499D 68C8000000 push 000000C8
:067F49A2 E8F94C0000 call 067F96A0
:067F49A7 6890000000 push 00000090
:067F49AC E8EF4C0000 call 067F96A0
:067F49B1 6898000000 push 00000098
:067F49B6 E8E54C0000 call 067F96A0
:067F49BB 68E0000000 push 000000E0
:067F49C0 E8DB4C0000 call 067F96A0
:067F49C5 68E8000000 push 000000E8
:067F49CA E8D14C0000 call 067F96A0
:067F49CF 83C430 add esp, 00000030
:067F49D2 83C408 add esp, 00000008
:067F49D5 C3 ret
[snip]
:067F96A0 8A442404 mov al, byte ptr [esp+04]
:067F96A4 8D4C2404 lea ecx, dword ptr [esp+04]
:067F96A8 51 push ecx
:067F96A9 6A01 push 00000001 # buffer length
:067F96AB 6888000000 push 00000088 # Value field
:067F96B0 88442410 mov byte ptr [esp+10], al
:067F96B4 E807000000 call 067F96C0
:067F96B9 83C40C add esp, 0000000C
:067F96BC C3 ret
q.e.d.
What other values the `Value' field can get? Inspecting the assembler
code I could say... those:
Value length of the buffer direction
===============================================
0083 1 OUT (write)
0084 1 IN (read)
0085 1 OUT
0087 1 OUT
0088 1 OUT
0082 8 OUT
What is the exact meaning of these command values? No idea yet, but
we can try understand them by the way they are used.
There are some patterns that you will find frequently in the log
file. Those are:
Type I
Value buffer contents
===========================
0087 14
0083 (any byte)
Type II
Value buffer contents
===========================
0087 14
0085 (any byte)
Type III
Value buffer contents
===========================
0087 14
0087 34
0084 (reads one byte)
0087 14
Type II sequences are used to appear after Type I sequences.
The behaviour of Type III sequences is to read a (status) byte from
the scanner/USB interface.
The byte values at Type I and II sequences are still an enigma.
The last one is the Type IV `sequence'. That's the more interesting.
Type IV
Value buffer contents
===========================
0082 (an 8-byte vector
with a bulk tranfer
length coded)
[bulk transfer of data]
The 8-byte vectors I have found in the hp4300 log file are:
01 01 00 00 60 00 00 00
^ ^
| +--- hi-byte (length)
+------ lo-byte (length)
00 00 00 00 2a 5d 00 00
This one is from the hp3300 log file:
01 00 00 00 38 dc 00 00a
The length of the following bulk transfer is coded always in the same
byte positions.
Some bulk transfers of Type IV sequences are sent _to_ the scanner
(write) and others the data comes is sent _from_ the scanner (read).
I could find the data that the computer sends to the scanner in the
data segment of the dll, but the meaning of the data is also an
enigma. I thought about gamma or calibration table values, but
it doesn't seem to be the case.
III.- So... what now?
---------------------
It will be nice to:
*) generate more log files, using the same scanning parameters and
different ones to see what has changed and what not,
*) to know if there is a background program running that is checking
the scanner/button status and produces interferences in the log file,
*) know if somebody (developers of SCSI, USB or pport SANE backends)
can recognize the protocol,
*) find somebody who can use a windoze debugger and owns a hp4300,
hp3400 or hp3300 scanner, to know when external events (scanner head
moves, lamp on/off, etc) happens in what part of the log file, and
maybe much more information,
*) excuse me for my english, copyright notices and publishing this in
the SANE mailing list ;)
Cheers,
Adrian Perez Jorge
<adrianpj@easynews.com>
------------------------------------------------------------
Free Web space and web based email @EASYNEWS.COM
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 16:27:26 PST