Hi!
3-Янв-2008 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
EA> have questions about problems with it... Yet I wonder why
EA> ctmouse 2.1b3 /O /P works worse than 1.9 for that problematic
EA> PC (2.1 with wheel does not see mouse, 2.0 hangs, 2.1 /O is
EA> supposed to work like 1.9 but does not see mouse either). If
EA> you have an idea how to test this...?
I not seen your edition yet, so I not have any ideas. :)
>> 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> Which leads to a "new language" which is harder to read ;-).
Well, ANY way of moving have own pro and own contras. :( :) But in any
case me very annoyed to invent tons of useless labels, which was used only
to implement high level constructs like if/else/end, which are used as basis
of my thinking.
EA> It might also have side-effects in some ways,
It shouldn't. I was think on their architecture very thoroughly, :) and
there was many efforts spend to generate optimized code.
>> 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> Rule 1: Users never read the manual. So they just type ctmouse,
EA> see that it somehow fails to see their ps2 mouse, then grabs their
EA> empty com port (because you never know if it is empty or Genius)
"is empty or attached mouse in Mouse Systems mode". :) And Genius mice
are long ago based on Logitech protocol.
EA> and then file a bug report instead of reading the manual ;-). This
Well, I never seen such bug report...
EA> is why I suggest to make the default "do not guess that a com port
EA> which is nothing else might be a Genius mouse".
...do YOU receive such reports? Or you plan to CHANGE behavior only
because you SUGGEST that current behavior was or will really cause problems?
>> EA> The current version
>> EA> has an option /Y ignore Mouse Systems, and most people
>> EA> should 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> The /Y option is only intended to avoid pretending that an
EA> empty com port is a Genius mouse, so I think /Y is good.
EA> And if you have no mouse /Y is a good idea, because the
EA> driver will not load if it finds no mouse :-).
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 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> In that case, you probably want "disable wheel" to be the
EA> default, too, as disabling the wheel improves compatibility
EA> quite a bit.
How it improves compatibility?
>> 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)
EA> Lemme see...
EA> Mouse Sys: 10000LMR, X1, Y1, X2, Y2 (sum 1 and 2 to get X and Y)
EA> only Mouse Systems / Genius uses 8 data bits, the following use 7:
EA> Microsoft: 01LRyyxx, 00xxxxxx, 00yyyyyy (high bits are in 1st byte)
EA> Logitech: 01LRyyxx, 00xxxxxx, 00yyyyyy, 00M00000 (4th only if M change)
EA> MS Wheel: 01LRyyxx, 00xxxxxx, 00yyyyyy, 000Mwwww (w is wheel)
EA> So the above 3 types "talk Microsoft" unless you press or release
EA> the middle button or move the wheel at that moment, although I am
Of course. This is what I meant.
EA> unsure whether MS Wheel mice use the 4th byte only on demand or
EA> for every packet?
Run PROTOCOL.COM and test. :) But result of testing for one mouse
doesn't proves anything. On the other side, this is unimportant, see start
of MSLTproc:
> test al,01000000b ; =40h ; synchro check
if_ nz ; if first byte
mov [IOdone],1 ; request next 2/3 bytes
mov [MSLT_1],al
MSLTCODE1 label byte ; "ret" if not LT/WM
xchg ax,cx ; OPTIMIZE: instead MOV AL,CL
> sub al,3 ; if first byte after 3 bytes
> jz @@LTWMbutton3 ; then release middle button
ret
end_
Ie., this code doesn't not rely on fixed size of packet.
EA> PS2 mouse: ??yx1MRL, X, Y (bits in 1st byte are "X/Y overflow")
EA> PS2 Wheel: ??yx1MRL, X, Y, wheel (usually wheel is -8 .. +7)
EA> PS2 3+wh.: ??yx1MRL, X, Y, 00BFwwww (B F are extra buttons)
Design, which not better (and even worser), than MSM protocol. :(
EA> In PS2, you tell the BIOS to select a protocol size and reset
EA> communication to know "where you are". This is why you can get
EA> out of sync
...without possibility to resync. :(
>> "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...).
EA> I hope it was Genius only.
Forget "Genius". All (newer) Genius mice, which I seen, was working in
LT protocol.
EA> If you change a mouse while busy,
EA> you can end up throwing any of the 2th to 4th bytes into the
EA> slots for 2th to "7th" byte before you get a new "sync" marked
EA> first byte again. I think this is acceptable, though. As long
EA> as the 4th byte marks the middle button STATE, not the toggle,
EA> you can always get the middle button "fixed" by pressing and
EA> releasing it once to get the driver back in sync. But maybe
Not need - review again resync check at start of MSLTproc.
EA> there are other protocols where for example "LR encodes a M
EA> toggle" is used to get along with only 3 bytes...?
Nice suggestion.
>> Also, I should mention: Alain was doing some changes for himself
>> to make "autodecision".
EA> I think I remember his plans, but does he still have the
EA> sources? Are they readable, stable, understandable? ;-)
They was based on CuteMouse sources. Talk with Alain directly for
details.
>> 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!)
EA> Exactly. So for hotplugging, you better use /O to disable the wheel.
EA> It is easy enough without wheel to get out of sync in PS2 anyway,
EA> see above... Of course you could build heuristics based on the idea
EA> that ??001000 is a more typical value for a 1st byte than for one
EA> of the other bytes in the protocol. But IMHO it would add a lot of
EA> complexity for little gain.
Yes. I remember I was testing (with help of PROTOCOL.COM) MSM mice to
see, if there is possible to build such heuristic to resync (I was analyze
bytes incomed from mouse to find characteristic markers/bits combination),
but no noticeable success. :( With PS2, case isn't better...
EA> Just do not hotplug if you cannot take
EA> the risk of having to re-init ctmouse manually at the prompt ;-).
Bad, very bad protocol design. :( How annoys such brain damaged
working...
-------------------------------------------------------------------------
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
