> > I had the same problem, and I figured out two things: > > - Sometimes the mouse is confused and imps2 init will fail if I do not > > send a reset to it. > > - moving the mouse before, or during initialization will make it fail. > > This is a problem I think, for all mouse (non trivial) initialization: > What happens is that when you move the mouse it sends motiondata, as > datastreaming is on per default. When you afterwards try to communicate > (init) with the mouse and read the responds you read motiondata instead of > the expected answar and bail out. > > So any mouseinitialization where a respond is expected/needed should first > turn off datastreaming and flush the fd. Then begin to communicating with > the mouse. When ended turn on the datastreaming again. I all figured out this, so that's exactly how the patch works :) > > The attached patch solved all my problems, so can try it, but this is not > > official :) > > The reason for succes with the patch, is that by waiting for mouse_id_code > after reset (00) you effectually flush the fd, and then starts > initialization and read the responds correct. The patch have the faults > that > A) datamotion packets can legally take the value of 0. I was thinking about this too. I do not know why, but the patch worked in every time: I couldn't make the init with moving the mouse around or pressing the buttons or scrolling the wheel (but I do tried.). I thought that we should wait for an 0xAA first, then for a 0x00, and that should be enough, but I didn't have time for testing this. > B) moving the > mouse while initializing can cause the same problem. But it will solve the > problem in most cases. Well, as I said above I tested above I tested it on three mice, and I couldn't make the init fail. Can you? :) ps: I am about to send a more complete patch, with a seperate reset_ps2 function, and calling that from each i_*ps2, this is not the final version yet that should be applied. More testing is needed of course. -- pozsy