Arkady V.Belousov escreveu: >>> In that case, you probably want "disable wheel" to be the >>> default, too, as disabling the wheel improves compatibility >>> quite a bit. > AM> I 100% agree. AB> I think, this is important only for PS2, where wheel support is dumb AB> and unreliable. In serial protocols (MS+wheel, LT) disabling wheel gives AB> nothing.
This is a fragment of a statement exclusively about PS2. So yes, only for PS2 > AM> The proble is two fold: first it causes compatibility > AM> problems, sencond there is *very* few programs around that would use it > AM> anyway and it would be logical that *these* programs have instructions > AM> to activate it. > Alain, talking about disabling/enabling through command line > completely, API doesn't have (yet?) functions to enable wheel support. What I said and some people agreed is to *change the default* to whatever is more compatible. >>> So the above 3 types "talk Microsoft" unless you press or release > AM> YES i have made it for 1.6b, all MS Logitech are intercangeable on the > AM> fly. I still use that version because all my improvements were > AM> disregarded :( > Not all. :) But code of handlers was hardly changed in those times, > and there was also target to minimize resident part size as much, as > possible, whereas "autoswitch" may have own side effects. For example, with > autoswicth we not know (can't know) how much buttons currently attached > mouse have or if current mouse have wheel or not, and this makes useless > checking BX after INT 33/0000 (should always contain 3 for serial mice) or > bit 0 of CX after INT33/11 (will/should always be set). And, if some app > wish to change its behavior depending on presence 3rd button/wheel in mouse, > then such app's behavior change will be invalid if there attached > 2-button/non-wheel mouse. I DISAGREE. No discuttionon that matter because *have it working* so everything else is vain philosophy. And a little history on that matter: Arkady and I startet working at the same time from the same version 1.6. Arkady was not willing to add my changes into his version, I was willing to do it when he released the stable version but after many years it never happend. >>>> "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...). > AM> What I can tell is that Cutemouse 1.6b can use ANY serial mouse and > AM> switch ON THE FLY from ANY serial mouse to ANY other mouse. > Including MSys? I remember we discuss reinitializing UART for different > speed (this need, there is no possibility in general to work with some > common speed for MSys and LT/MS protocols). Inclusive MSys, just any serial mice with 2 or 3 buttons with wheel or not (wheeel not working). And yes there is on-the-fly uart reprograming, just not the baud but other things (bits and parity). correcting: > AM> 100% tested > AM> in the field when serial mice where commmon. > >>> 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...? > No. There was idea for it support, but it was excluded after some > testing. Please don't get too philosophical about button numbers, wheel and byte numbers. I just used some very dirty tricks, it usualy is resynched after very few packets and *never* an extra click is generated. Correcting: > AM> remember that changing mice was > AM> very common before the advent of modern > AM> 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
