cvs commit: src/sys/isa psm.c

Justin T. Gibbs gibbs at
Sat Aug 21 20:52:08 PDT 2004

> This won't work for the moused cases I quoted previously:
>     if (pBufP == 0 && (rBuf & cur_proto[0]) != cur_proto[1])
>         return 0;

It is correct for this case.  This test is looking for the start
of a packet.  Setting cur_proto[0] to 0 essentially disables this
test - the psm driver is doing it for moused.

>     /* is there an extra data byte? */
>     if (pBufP >= cur_proto[4] && (rBuf & cur_proto[0]) != cur_proto[1])
>     {

For this case, it is hard to say if it is correct or not.  The 4th
byte is further vetted by the fourth byte sync mask futher down.
The question is whether, in the PS/2 protocol case, the packets
ever vary in size in some unpredictable fashion that can only
be detected by seeing the sync bits in the first byte of the next
packet.  From looking at psm.c, that doesn't seem to be the case.
The format is stable once the mouse is put in a particular mode.

Anyway, the patch that I posted before has the same effect on moused
as using the "disable sync checking" option in psm.c, but without
actually disabling sync checking in psm.  Since I don't have
your mouse, I can't say if your mouse will function correctly through
this code path with a syncmask of zero or not.

> So the psm.c 1.79 changes have essentially broken moused's method of
> determining the first byte.

Not exactly.  1.79 caused moused to always discard the first byte
for your mouse.  The second change insures that this doesn't happen
and should work so long as your mouse has a fixed packet size - seems
to be the case for all PS/2 mice acording to psm.c.

I'm not against further cleanups of moused and friends, but I would
like to know if the second change fixes the problem for you.


More information about the cvs-src mailing list