Eric Auer escreveu: >> IMHO the default should be off, but the code should remain >> there. > For Genius? Agreed. Probably would be harder to remove it ;-)
Yes. >> it would be logical that *these* programs have instructions >> to activate [the wheel]. > > You mean have docs to instruct the user how to activate it > when he loads ctmouse? As soon as ctmouse is loaded, it is > your choice whether you actually call wheel related funcs, > but the setup of the wheel communication protocol and the > wheel detection should be done at start up, not later. What I mean is that the program that has dos-wheel support can have an advertisement and the intructions to add wheel support. Of course they have to be in cutemouse docs to... The main motivation for this behaviour is that there are only one or two DOS programs with wheel support. AND this causes an inherent compatibility problem to ALL the other users. >> 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. > Any other -serial- mouse, you mean? Yes. ;-) >> 100% tested in the field what serial mice where commmon. > > Nice. But can you "extract" the relevant parts from your > sources, or maybe make an adjusted version of the core > IRQ handlers? I assume that only those have to be changed > (after reducing the code which now patches the handler / > picks a handler in the current versions) to add your magic > to a current version. > > However... Please make a simplified version which only > supports switching between any 7bit serial mouse. Not > between those and Genius (8bit) or PS2. Thanks! In 1.6b just as in 1.6 there are already 2 executables (compile time option)! So there is no possibility to interchange because only one can hook int 33h. Integration has been done later by Arkady. About Serial mice, there is a very suble adjustment of 7bits versus 8 bits. Some mice are very sensitive to this. (They send 7 bits, no parity, one stop and this incompatible with 8 bit) I remember it was hard to fix... As to sources, I have my source and the one that I started from, they compare very nicely under KOMPARE (Linux/KDE), I just checked ;-) >>> 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 worth while. > > So you also have a tuned PS2 handler with automated resync? > Remember that ctmouse 1.9 and 2.1 use the BIOS to fetch mouse > data for PS2, so you cannot do byte by byte processing in > those more compatible versions. Only the less compatible but > more "forced wheel" version 2.0 could do that... Of course > nothing stops you from giving your PS2 patch to 2.0 and your > COM patch to 2.1 and 2.0, so BOTH 2.0 and 2.1 can be updated. I am not sure about that. I remember that I didn't change much to the PS/2 version. Probably just the "don't load twice" thing. 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
