Hi again, > >> EA> has an option /Y ignore Mouse Systems, and most people > >> I myself always use /y - I not like and not use mouse systems > >> mice, whereas I prefer not remain in my RAM useless code stubs. > EA> So you agree to make /y the default :-)
> No. I just express my own preference, but this not mean, that changing > program behavior will not have negative impact on other users. So, my > vote nearer to against. I still think /y is a good default. It only hurts people with VERY old Genius mice (such with no "switch to Microsoft mode" switch, or with switch but 3rd button only supported in MSys mode) but it helps many people who would otherwise get "trapped" in the caveat that an empty com port can be confused with a MSys mouse and who fail to read the docs carefully enough to realize that they want the /y option. With /y as the default, only people with very old Genius mice will have to read the docs to find the name of the new non-/y switch ;-). Any suggestions for a letter to name it? > I suggest, all (new) options should remain one-letter... Or you may > use /y+ (enable), /y- (disable) syntax. Then we better use a new letter :-) > This should affect only PS2 handler, because for serial mice there > is no problems with supporting wheel. You are right. I can change /o to disable only PS2 wheel, not serial port wheel. See my other mail. > But WHEN driver should re-initialize mouse?! I not see events, which > allows make reinitialization not too late or too often. As autodetection of "sync lost" is hard because the PS2 protocol is not designed to indicate sync, I suggest manual re-initialize. This will be by running ctmouse at the prompt. As far as I do understand, this will re-use the TSR part of ctmouse after doing the mouse detection and init stuff :-). > You mean, that driver should also trap INT15 and monitor BIOS calls? No... > No. When middle button pressed, 4th byte sent always; when button > released, they may sent 4th byte (with bit clear) or may not sent, > but again: review again resync check at start of MSLTproc. If 4th > byte is missed, this code releases middle button state. Just checked... It says "if no 4th byte, always force middle button to not pressed state". So mice have to keep sending a 4th byte the whole time while middle button is pressed. How about modifying... >> 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) ...as follows then: If no 4th byte, reset middle button. Otherwise: Middle button state = bit 5 or bit 4, wheel change = low 4 bits. This should work for all 3 affected protocols :-). > No. I was have 3-button mouse, which was imitate middle button press > through L+R in plain MS protocol, but I found this way very unreliable > (testing with help of MOUSETST and other apps shows, that middle button > state changed unexpectedly too often) and drop it support completely. Ah. So it was yet another very old but evil protocol :-) 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
