Eric Auer escreveu: > Rule 1: Users never read the manual. So they just type ctmouse, > see that it somehow fails to see their ps2 mouse, then grabs their > empty com port (because you never know if it is empty or Genius) > and then file a bug report instead of reading the manual ;-). This > is why I suggest to make the default "do not guess that a com port > which is nothing else might be a Genius mouse".
Agrred, but: IMHO the dafault shuld be off, but the code should remain there. > In that case, you probably want "disable wheel" to be the > default, too, as disabling the wheel improves compatibility > quite a bit. I 100% agree. The proble is two fold: first it causes compatibility problems, sencond there is *very* few programs around that would use it anyway and it would be logical that *these* programs have instructions to activate it. > So the above 3 types "talk Microsoft" unless you press or release > the middle button or move the wheel at that moment, although I am > unsure whether MS Wheel mice use the 4th byte only on demand or > for every packet? YES i have made it for 1.6b, all MS Logitech are intercangeable on the fly. I still use that version because all my improvements were disregarded :( >> "auto decision" may cause "mystic" middle button state changes >> and wheel rotations. I remember, there WAS some troubles with >> middle button in my initial experiments (or this was troubles >> with MSM protocol? don't remember precisely...). What I can tell is that Cutemouse 1.6b can use ANY serial mouse and switch ON THE FLY from ANY serial mouse to ANY other mouse. 100% tested in the field what serial mice where commmon. > I hope it was Genius only. If you change a mouse while busy, > you can end up throwing any of the 2th to 4th bytes into the > slots for 2th to "7th" byte before you get a new "sync" marked > first byte again. I think this is acceptable, though. As long > as the 4th byte marks the middle button STATE, not the toggle, > you can always get the middle button "fixed" by pressing and > releasing it once to get the driver back in sync. But maybe > there are other protocols where for example "LR encodes a M > toggle" is used to get along with only 3 bytes...? It can be done, I did it... >> Also, I should mention: Alain was doing some changes for himself >> to make "autodecision". > I think I remember his plans, but does he still have the > sources? Are they readable, stable, understandable? ;-) I have the sources, they as as readable as any of CuteMouse source, (in a in later versions some comments were added to a small portion that was dis-assembled). And I have the source on which I based my changes, so that it can be "kompared". >> There is another problem with PS/2 PS/2 is not perfect with 1.6b, sometimes it doesn't find and 2.0 works. > It is easy enough without wheel to get out of sync in PS2 anyway, > see above... Of course you could build heuristics based on the idea > that ??001000 is a more typical value for a 1st byte than for one > of the other bytes in the protocol. But IMHO it would add a lot of > complexity for little gain. Just do not hotplug if you cannot take > the risk of having to re-init ctmouse manually at the prompt ;-). No, it adds little complexity, just a few bytes. So it is woth while. remember that changing mice qas very common before the advent of modern optical ball-less mice. Alain ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
