On Tue, Jun 18, 2002 at 02:19:16AM +0200, Pozsar Balazs wrote: > > On Mon, 17 Jun 2002, Zephaniah E. Hull wrote: > > > Ok, I should have commented a while back but I have been very busy with > > life. > > > > First off, doing the init via the shut off via reset, set everything, > > and reactivate does fix a /lot/ of problems. > > > > However it also breaks a lot of mice which, while they seem to plug into > > the PS/2 port, don't have a damn clue how to speak most of the protocol. > > > > Failure modes vary, but in general they just Don't Work. > > Could you tell me, how they 'dont work'? > The worst I can imagine is that they misinterpret somehow the reset byte. The failure modes vary, some die at the reset, some die other places. For instance, the Logitech OEM mice once in imps/2 mode, when they receive a command they don't like (just about anything except the rate and the ID command, even the re-enable command can trigger it), have a nice seizure. They start speaking the PS/2 protocol again, however the ID command still states that they are speaking IMPS/2. Other mice will stop reporting, or will not give a valid reply, or other interesting bits. However the single most common case is the Logitech OEM mice, which get relabeled as gateway, hp, and others. > Also, do you know which mice are that bad? Reports from unhappy users, this code has been sitting in Debian for a while now, it works with everything but the broken mice. > > I had a feeling that this might not work for all mice, but now I can be > sure. Though I would be really happy if we could have a "autops2" which > rules them all :) We can cover everything /except/ the broken mice, there is no way to handle them automaticly. > > > Below I will attach bits of the current Debian gpm init stuff, which > > handles PS/2, IMPS/2, and EXPS/2 all in the same init function, and also > > has a autops2 protocol which will automaticly detect which protocol of > > the three the mouse can speak which supports the most options. > > > > In addition to these modes I have fups2 and fuimps2, for mice which > > can't handle any sort of complex init sequence, I have yet to see > > reports of exps2 mice not being able to support the full set of > > commands, however it is only a matter of time before there become > > Logitech OEM mice which have more buttens. (OTOH, we could get lucky and > > they could be entirely USB.) > > What does 'fu' stand for? Maybe 'force user'? :) Er, you will not find this in /any/ documentation, but 'fucked up'. (=:] (The users need not know what it means, however it aptly describes the mice in question.) > > > I'll also include the parser for the protocols. > > > > (This code has NOT been updated to 1.20 yet, it is high on my todo list, > > but lower then getting the bathroom back together and usable.) > > > > This is just grabbing the relevant sections from the mice.c FWIW. > > Well thanks, I've have already gone trough the patches/ dir in the gpm > sources, but I'm yet to see the debian version. > > I would really like to have that 'autops2' detection, so please tell me > what you know. I might also be able to get my hands on some of those bad > rats. I have one, as long as you /only/ feed it the rate commands it works, otherwise hold on tight because the mouse just started spewing the wrong protocol, with no sane way to detect it. (There may be really really evil kludges, but they still have problems.) The other warning with all of this is that those calls to alarm CAN NOT be excluded, otherwise for some systems which don't have a PS/2 mouse connected at that time you loose the keyboard, entirely. (I've looked at the kernel side, the alarms are the cleanest way.) Zephaniah E. Hull. > > -- > pozsy > > > > -- 1024D/E65A7801 Zephaniah E. Hull <warp@xxxxxxxxxxxxxxxx> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Stubborness will get you where self-esteem won't let you go. -- Queen Of Swords in the SDM.
Attachment:
pgp00044.pgp
Description: PGP signature