On Wed, 2 Oct 2002, Alessandro Rubini wrote:
Hi!
>first byte and some other protocol don't. If your protocol does but
>it's not used than this is a bug in the definition of the type.
OK. I've found, and fix that.
>Please fix mice.c, not the main loop, and please send a patch even it
>it's one line. Patches are generated and applied by tools, descriptions
>must be written and applied by hand [this is "type-once use many"]
The problem was more complex then i though.
After each screen change gpm calls the I_* rutine again. If there was some
leftover data, then imps2 initialization failed. It turs out, that this
was failed because reading an ACK and not the answer. ImPS/2 is falling
back then to plain PS/2.
But, if there was a real imps2, then it would send 4 byte packes, since we
requested that, but PS/2 driver cannot handle them.
Things that changed:
I_imps2 now flushes the data input at startup.
Intelli Explorer mouse with 5 button is the same protocol, with small changes.
I_imps2 now detect exps2 also.
If imps/2 was not found, then now a reset is issued, to be clear, that no
imps/2 like wonder sends 4 byte packets again to ps2 driver.
data[0] & c0 == 0 now data[0] & 8 == 8, according to the ps2 protocol.
There is now support for the 4th and 5th button of exps2.
(Defining GPM_B_FIFTH)
----->
I have a bug also, bug i had no time to fix it:
If an I_* returned with null, then the /var/run/gpm.pid is not removed!
Regards,
--
Cserveny Tamas
"Mosokonyha! Vigyazat ne ingereljuk a bestiat!" Vanek B. Eduard
The following attachment was sent,
but NOT saved in the Fcc copy:
A Text/PLAIN segment of about 14,301 bytes.