Hi!
31-Дек-2007 15:13 [EMAIL PROTECTED] (Eric Auer) wrote to Андрей Влащенко
<[EMAIL PROTECTED]>, freedos-devel@lists.sourceforge.net:
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).
>> PS/2/COM/MSMouse's. I do not understand the architecture of the
EA> I must admit that the CuteMouse source code is ugly but on the
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_).
EA> Current version 2.1b3 is here:
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.
EA> The current version
EA> has an option /Y ignore Mouse Systems, and most people should
EA> 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.
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.
EA> Then, only two main COM protocols are left: Logitech mouse and
EA> Microsoft Mouse protocol. My plan would be to change the code
EA> of "MSLTproc" to automatically decide for each packet which of
EA> the two protocols the packet is.
Let me slightly clarify this aspect. In theory, one procedure may
handle all three protocols (MS, LT, MS+wheel) without preliminary knowledge
about initial selections: first 3 bytes in each protocol are identical, 4th
byte (middle button and wheel rotation) is easily distinguished between
protocols:
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)
There only one objection against this: link to mouse may be unreliable. If
link is unreliable and there are bytes losses or garbaged bytes insertion,
"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...).
Also, I should mention: Alain was doing some changes for himself to
make "autodecision".
EA> Then you have hotplugging for
EA> COM mice :-) . You also have a chance for hotplugging of PS2
EA> mice already with 2.1, if you use the /O option to disable the
EA> wheel part (which is hard to re-bootstrap on the fly). Note that
EA> PS2 is not officially meant to support hotplugging, you might
EA> even damage old hardware by doing it?
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!), 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...
EA> As this COM protocol autodecision is a bit tricky, you may want
Nothing tricky - see above. You just should appropriately modify
`setupdriver' procedure.
EA> to write a Pascal version of it first, so I can port it to ASM
EA> for CuteMouse :-).
-------------------------------------------------------------------------
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
