[Bitpim-devel] Some amusements

[Roger B. <ro...@ro...>]

I have added a firmwarerequest and an offlinerequest
method to com_brew.  You can also reboot the phone from
offline request.  Turns out Stephen already knew about these
from the Sanyo which requires them.  Stephen, you should
also take a look at examples/mystery.txt and see what
you think they are about.

I have also hooked in raw USB device access. The library
is mature on Linux and works really well with the VX6000.
The library is also mature to my knowledge on Mac.

But with the VX4400, you will never guess what happens.
Yes, thats right.  Those damn timeouts.  I have spent
several hours trying to figure out exactly what is going
on.  Unfortunately the usb sniffer tool I have doesn't
work with the (busted) FutureDial driver and only with
the (ok) LGE driver.

However I think I have finally stumbled onto what the
LGE driver does.  It looks like that when you send a
write request, it seperately sends a read request
first.  Then it does the write, gets back confirmation,
and then gets the read results.

ie when I do this at a hight level:  send("command")
it actually does:

  - sends read request
  - sends write request ("command")
  - receives confirmation of write
  - receives read response

I would assume that the phone receiving the read request
before the command means that it sets up some buffers
etc and they are ready to fill when it gets the write
request and wants to fill in its response to a write.

(You can multiple outstanding packets each with seperate
timeouts sort of like SCSI.  It also explains the silly
error I was getting from the LGE drivers that I was
able to work around).

It is going to be really hard to do this same behaviour
(they got to do it inside a device driver).  I have to
do it from user space using a blocking library and
some sort of thread coordination.

Well, if anyone does manage to get someone from FutureDial
who cares I can tell them exactly how to fix their driver.
LG also should take some heat for somewhat substandard
behaviour of the hardware in the phone itself.

Roger