Hi!
4-Янв-2008 00:53 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
>> I not seen your edition yet, so I not have any ideas. :)
EA> It is on www.coli.uni-saarland.de/~eric/ctmouse21b3.zip
I look at it later, now I busy with editing book about Narekatsi
(Armenian poet).
>> EA> has an option /Y ignore Mouse Systems, and most people
>> Well, 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.
EA> I suggest to introduce
EA> a new option (name? maybe /yy?) which means ENABLE Mouse Systems
EA> mode, and ignore the /y option because DISABLE Mouse Systems
EA> would be the default in the future.
I suggest, all (new) options should remain one-letter... Or you may use
/y+ (enable), /y- (disable) syntax.
>> EA> default, too, as disabling the wheel improves compatibility
>> EA> quite a bit.
>> How it improves compatibility?
EA> Using the wheel needs a "handshake" (a sequence of clock changes)
EA> and it needs the not-so-common 4 byte protocol. The 2.0 driver
EA> used direct keyboard controller programming, which sometimes (too
EA> often) crashed my keyboard and which might confuse BIOS USB mouse
EA> drivers which emulate PS2 via the BIOS PS2 interface and/or by
EA> feeding the data into the keyboard controller. For example some
Well, I was think that you meant external API (which used by 3rd party
programs to interact with mouse driver).
EA> user recently reported that 2.0 hangs his PC. The 2.1 driver is
EA> "plain BIOS", but I got a bug report that some emulated PCs do
EA> not support 4 byte protocol in their BIOS, while they do support
EA> the wheel detection handshake... In short, the wheel stuff is
EA> less foolproof than the protocol without wheel, and as 95% of
EA> the DOS apps do not use the wheel anyway, I suggest to use the
EA> disable wheel option for example in the autoexec of a generic
EA> boot floppy or boot cdrom or dvd.
This should affect only PS2 handler, because for serial mice there is
no problems with supporting wheel.
>> EA> In PS2, you tell the BIOS to select a protocol size and reset
>> EA> communication to know "where you are"...
>> ...without possibility to resync. :(
EA> You could resync by selecting the protocol again, possibly after
But WHEN driver should re-initialize mouse?! I not see events, which
allows make reinitialization not too late or too often.
EA> a rate change or similar to make it clear that there is something
EA> to be synced.
You mean, that driver should also trap INT15 and monitor BIOS calls?
Unfortunately, this not very reliable method (3rd party application may
bypass BIOS; with INT10, programs too may change video mode directly, but at
least programmers usually take care in this case and disable mouse cursor),
especially with hotpluging (which you can't detect in any way)...
>> Not need - review again resync check at start of MSLTproc.
EA> Yes yes. You only get one bad packet, but in Logitech and MS
EA> Wheel protocol, this means that the middle button state might
EA> be wrong until you press that button again.
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.
EA> If you have some
EA> protocol which does "L+R means toggle middle" (pre-Wheel MS
EA> 3 button mice?),
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.
EA> it can be quite hard to resync the state of
EA> the middle button. Well I guess you just press both buttons
EA> simultaneously to force a toggle then :-).
>> Bad, very bad protocol design. :( How annoys such brain damaged
>> working...
EA> Basically PS2 mice are like PS2 keyboards - not designed for
EA> hotplugging.
Even without hotplugging there a lot of problems...
EA> Might even damage something, although unlikely.
-------------------------------------------------------------------------
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
