Hi Arkady, thanks for the feedback :-) > EA> Current CuteMouse 2.1 development is done by me :-) . > > And how progress so far? (I was missing half of year, so I miss > latest news).
Unfortunately, you did not miss much. But at least CuteMouse is still maintained, and people still get support when they have questions about problems with it... Yet I wonder why ctmouse 2.1b3 /O /P works worse than 1.9 for that problematic PC (2.1 with wheel does not see mouse, 2.0 hangs, 2.1 /O is supposed to work like 1.9 but does not see mouse either). If you have an idea how to test this...? > Let me object this assertion. :) CuteMouse source code is full of > different tricks, but in other there was done a lot of work to make > it more readable (including introducing high level constructions like > if_/else_/end_). Which leads to a "new language" which is harder to read ;-). It might also have side-effects in some ways, but I usually do trust that if else end macro, it can be nice yes :-). > EA> www.coli.uni-saarland.de/~eric/ctmouse21b3.zip > EA> What I was planning to do next was to make the COM handling > EA> automatic: Maybe remove Mouse Systems (Genius) protocol or > EA> at least make it no supported by default. > > I suggest, today this change (not enabled by default) shouldn't harm - > I doubt there remained any of MSM mouse alive. :) But who knows? On the > other side, I not see ANY urgent need in making MSM protocol disabled by > default - if user need to omit this protocol, (s)he always may add /y > option. 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". > EA> The current version > EA> has an option /Y ignore Mouse Systems, and most people > EA> should use it, > > NOT "should". You should use this option ONLY IF you not want to > remain CuteMouse in memory, when there is no mice attached. The /Y option is only intended to avoid pretending that an empty com port is a Genius mouse, so I think /Y is good. And if you have no mouse /Y is a good idea, because the driver will not load if it finds no mouse :-). > EA> So my plan is to make that "ignore Mouse Systems" the default. > > This is cosmetic change, which may be useful, but it may also have side > effects (for those users, who have MSM mice). Especially if driver > runned by 3rd party software (like Partition Magic) and you not have > possibility to add options manually. In that case, you probably want "disable wheel" to be the default, too, as disabling the wheel improves compatibility quite a bit. > if 4th byte = zero then ; both protocols > middle button released > else if bit 5 (mask 00100000b) is set then ; LT protocol > middle button pressed > else ; MS+wheel protocol > parse low 5 bits (bit 4 - middle button, bits 0-3 - wheel rotation) Lemme see... Mouse Sys: 10000LMR, X1, Y1, X2, Y2 (sum 1 and 2 to get X and Y) only Mouse Systems / Genius uses 8 data bits, the following use 7: Microsoft: 01LRyyxx, 00xxxxxx, 00yyyyyy (high bits are in 1st byte) Logitech: 01LRyyxx, 00xxxxxx, 00yyyyyy, 00M00000 (4th only if M change) MS Wheel: 01LRyyxx, 00xxxxxx, 00yyyyyy, 000Mwwww (w is wheel) 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? PS2 mouse: ??yx1MRL, X, Y (bits in 1st byte are "X/Y overflow") PS2 Wheel: ??yx1MRL, X, Y, wheel (usually wheel is -8 .. +7) PS2 3+wh.: ??yx1MRL, X, Y, 00BFwwww (B F are extra buttons) In PS2, you tell the BIOS to select a protocol size and reset communication to know "where you are". This is why you can get out of sync when trying to hotplug a PS2 mouse (which can also stress the hardware). USB mice can often talk PS2 with a dumb (non-electronic, only mechanical) adapter. If you connect USB mice via USB, the BIOS often is able to create virtual PS2 and feed it with the data from USB. In COM (serial port) mice, you have the 01nnnnnn mark for the first byte and 00nnnnnn for all other bytes, so you can always get back in sync if you hotplug a serial mouse. Of course other parameters can mess up then. > "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...). 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...? > 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? ;-) > There is another problem with PS/2 - to enable wheel support in mouse, > you should "send" some additional initialization, but this support > disabled in mouse again (without knowledge about this in driver!) Exactly. So for hotplugging, you better use /O to disable the wheel. 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 ;-). > if some 3rd party > code also resets mouse. I not see reliable methods to control > wheel support (make it always enabled) with PS/2 mice... Eric ------------------------------------------------------------------------- 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
