Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

6-Янв-2008 11:50 [EMAIL PROTECTED] (Jim Hall) wrote to
freedos-devel@lists.sourceforge.net:

JH> I must admit that I'm confused about who is the maintainer of
JH> Cutemouse these days, and what is the latest official version. Can
JH> someone clear this up for me?

 Maintainer (was) Daniel Nagy, I was (main) contributor. I was long ago
not develop/update CuteMouse (and it was frozen in slightly unfinished
state, because there is two branches, which should be joined), and I see
Eric tries to offer own efforts to continue CuteMouse development. (I not
know which event was nudge he in this direction).

 If Eric's changes will not (too) differ in style from current code and
he will discuss changes before implementation, I not see objections against
his contributions.

JH> Is Cutemouse 2.1 the latest official version?

 Latest official versions (was) 1.9.1 (alpha 1) and 2.0 (alpha 4).
History of changes by Eric I not know yet.

JH> Or is 2.1 Eric's own
JH> fork of the project? The Cutemouse web site
JH>  only mentions a 2.0 branch and
JH> nothing about 2.1. But that page hasn't been updated in a very long
JH> time (2003) so maybe the Cutemouse site is dead?

 Well, site was not updated because there was no update CuteMouse
itself. :) I not know, if Daniel is currently responsible and (will)
continue to maintain CuteMouse.

JH> I don't see Eric listed as a developer or admin on
JH> http://sourceforge.net/projects/cutemouse so I assume Eric's 2.1 is a
JH> fork. This seems correct, as the LSM for Cutemouse
JH> 
JH> says Eric's 2.1 version is beta, and is not listed as official.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Jim Hall]

I must admit that I'm confused about who is the maintainer of
Cutemouse these days, and what is the latest official version. Can
someone clear this up for me?

Is Cutemouse 2.1 the latest official version? Or is 2.1 Eric's own
fork of the project? The Cutemouse web site
 only mentions a 2.0 branch and
nothing about 2.1. But that page hasn't been updated in a very long
time (2003) so maybe the Cutemouse site is dead?

I don't see Eric listed as a developer or admin on
http://sourceforge.net/projects/cutemouse so I assume Eric's 2.1 is a
fork. This seems correct, as the LSM for Cutemouse

says Eric's 2.1 version is beta, and is not listed as official.

-jh


On 12/31/07, Eric Auer <[EMAIL PROTECTED]> wrote:
>
> Hi there :-)
>
> > Hello everybody! CuteMouse project is dead; I can develop new mouse
> > driver for the FreeDOS project. This driver, named "FreeMouse", I
> > started today. Please reply to me, I want that you help me writing
>
> Well maybe you did not wait long enough for a reply from Nagy Daniel:
> Current CuteMouse 2.1 development is done by me :-). So CuteMouse is
> not dead, but you are welcome to help :-).
>
> > correct autodetection of used mouse type, and handle the
> > PS/2/COM/MSMouse's. I do not understand the architecture of the
> > CuteMouse, which is written in assembler, but I write FreeMouse
> > in the  TurboPascal v3.0. Previously big thanks for all of this case!
>
> I must admit that the CuteMouse source code is ugly but on the
> other hand it is small because it is written in Assembler :-).
>
> Current version 2.1b3 is here:
>
> www.coli.uni-saarland.de/~eric/ctmouse21b3.zip
>
> What I was planning to do next was to make the COM handling
> automatic: Maybe remove Mouse Systems (Genius) protocol or
> at least make it no supported by default. The current version
> has an option /Y ignore Mouse Systems, and most people should
> use it, because you cannot detect whether you talk to one of
> those mice or just to an empty serial port in a nice way ;-).
> So my plan is to make that "ignore Mouse Systems" the default.
>
> Then, only two main COM protocols are left: Logitech mouse and
> Microsoft Mouse protocol. My plan would be to change the code
> of "MSLTproc" to automatically decide for each packet which of
> the two protocols the packet is. Then you have hotplugging for
> COM mice :-). You also have a chance for hotplugging of PS2
> mice already with 2.1, if you use the /O option to disable the
> wheel part (which is hard to re-bootstrap on the fly). Note that
> PS2 is not officially meant to support hotplugging, you might
> even damage old hardware by doing it?
>
> As this COM protocol autodecision is a bit tricky, you may want
> to write a Pascal version of it first, so I can port it to ASM
> for CuteMouse :-).
>
> Eric
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

Arkady V.Belousov escreveu:
>>>  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/ (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.
> AM> I DISAGREE.
> 
>  With what?
> 
> AM> No discuttionon that matter because *have it working* so
> AM> everything else is vain philosophy.
> 
>  If you not have problems with your set of apps doesn't mean that there
> not exist apps, which will have problems with changed on the fly mouse type.

I give up :(

Alain


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

5-Янв-2008 04:32 Arkady V.Belousov wrote to
freedos-devel@lists.sourceforge.net:

AVB>  Ops. Reviewing MSLTproc I see, that "3 buttons support through MS
AVB> protocol" isn't removed, it remained there (see MSLTCODE2 label) and
AVB> should work...

 ...if you use /3 option. Effect should be noticeable for mouse with 3
buttons in Microsoft mode.

AVB> (My bad memory: I not remove this code, I just not use it
AVB> for
AVB> myself). So, if/when you will add autoswitch, don't forget about this part:
AVB> MS3 protocol sends 3 bytes, but middle button toggle indicated by "empty
AVB> event" (not L+R, but packet, which identical to previously sent packet -
AVB> ie., this packet changes nothing, it just indicates event). This makes MS3

 Today I update PROTOCOL.TXT (joke: "Microsoft mode" was mistyped as
"Mouse mode" :) ) and add:

"
===
Serial Microsoft 3-button mode: 1200 bps, 7 data bits, 1 stop bit, no parity

All bytes are equal to Microsoft mode packet.
Middle button state toggle indicated by packet, where state of left and
  right buttons identical to previous packet and movement bits are zero.
"

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

5-Янв-2008 01:43 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

>> >>   /3   - force 3-button mode (for Microsoft and PS/2 mice only)
>> >>  force wheel support (for PS/2 mice)
>> >> BTW, /3 option was used to force middle button support through L+R
>> It has effect - without it, PS2 handler will not return info about 3rd
EA> Well but then /3 only affects reporting now, not protocol.

 Protocol too. See "buttonsmask" variable at start of mouseupdate
procedure.

EA> Bit for middle button is the same in PS2 whether or not a
EA> middle button exists. Enabling wheel support, on the other
EA> hand, is a serious thing which involves switching to 4 byte
EA> protocol and doing a handshake, both of which can hang the
EA> PC if you have a bad BIOS or bad USB PS2 emulation. So the
EA> option to enable the wheel should stay a SEPARATE option
EA> from the "change reported button count but keep same proto".

 Well... What about /pw (where "w" is argument of /p option, like "2"
in /s2)?

>> EA> The "enable PS2 wheel" option should have another name then.
>> Why not /3? It already there and already does half of work (wheel
>> support is linked with 3rd button support).
EA> Not for PS2 mice. In PS2, wheel support is linked with 4th / 5th
EA> button support, but I believe CuteMouse does not read the 4th and
EA> 5th buttons yet anyway :-). And for COM port mice, as you say, a
EA> /3 option is no longer relevant for the protocol because L+R=M is
EA> not supported any more anyway.

 For serial mice, /3 is ignored for WM/LT protocols (they already offer
3 buttons), it have effect only for MS protocol...

 Ops. Reviewing MSLTproc I see, that "3 buttons support through MS
protocol" isn't removed, it remained there (see MSLTCODE2 label) and
should work... (My bad memory: I not remove this code, I just not use it for
myself). So, if/when you will add autoswitch, don't forget about this part:
MS3 protocol sends 3 bytes, but middle button toggle indicated by "empty
event" (not L+R, but packet, which identical to previously sent packet -
ie., this packet changes nothing, it just indicates event). This makes MS3
protocol incompatible with MS2/WM/LT, where middle button should be released
in case of truncated (3 bytes only) packets.

 The more so, see ctmouse.txt:

"
WARNING: when the middle button of a plain Microsoft mouse is enabled,
pressing left or right button along with the middle button can cause
"middle button state triggering" - i.e. when the middle button is pressed
the driver thinks it is released and vice-versa. This is a peculiarity of
the Microsoft protocol and can't be changed. If button triggering occurs
simply press the left or right button along with the middle button once
again to clear the problem.
"

 Alain, MS3 protocol is another reason, which hinder autoswitch
introduction.

EA> So as said - today, /3 does something
EA> simple (report 3rd button if PS2 even if PnP said there are 2) but
EA> an "enable PS2 wheel" option does something complicated (allow the
EA> driver to do wheel init setup at startup) and should be used with
EA> more care than the /3 option.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi!

> >>   /3   - force 3-button mode (for Microsoft and PS/2 mice only)
> >>  force wheel support (for PS/2 mice)
> >> BTW, /3 option was used to force middle button support through L+R
> It has effect - without it, PS2 handler will not return info about 3rd

Well but then /3 only affects reporting now, not protocol.
Bit for middle button is the same in PS2 whether or not a
middle button exists. Enabling wheel support, on the other
hand, is a serious thing which involves switching to 4 byte
protocol and doing a handshake, both of which can hang the
PC if you have a bad BIOS or bad USB PS2 emulation. So the
option to enable the wheel should stay a SEPARATE option
from the "change reported button count but keep same proto".

> EA> The "enable PS2 wheel" option should have another name then.
>
> Why not /3? It already there and already does half of work (wheel
> support is linked with 3rd button support).

Not for PS2 mice. In PS2, wheel support is linked with 4th / 5th
button support, but I believe CuteMouse does not read the 4th and
5th buttons yet anyway :-). And for COM port mice, as you say, a
/3 option is no longer relevant for the protocol because L+R=M is
not supported any more anyway. So as said - today, /3 does something
simple (report 3rd button if PS2 even if PnP said there are 2) but
an "enable PS2 wheel" option does something complicated (allow the
driver to do wheel init setup at startup) and should be used with
more care than the /3 option.

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

5-Янв-2008 00:53 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

>>   /3   - force 3-button mode (for Microsoft and PS/2 mice only)
>>  force wheel support (for PS/2 mice)
>> BTW, /3 option was used to force middle button support through L+R
>> extension. Now there remains only option.
EA> If /3 has no effect now, it should be removed from /? text.

 It has effect - without it, PS2 handler will not return info about 3rd
button. In previous statement I mean only "there remains only option, which
was introduced partially for support L+R extension".

EA> The "enable PS2 wheel" option should have another name then.

 Why not /3? It already there and already does half of work (wheel
support is linked with 3rd button support).

>> I doubt. Why, if there is MS+wheel protocol?
EA> Probably pre-Logitech MS-3button mice used L+R=Mtoggle protocol
EA> but were useable as 2button with classic MS protocol anyway.

 You ask "are there [produced] mice which use such a protocol?".
Pre-logitech mice are "pre-", they not todays.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Arkady,

>   /3   - force 3-button mode (for Microsoft and PS/2 mice only)
>  force wheel support (for PS/2 mice)

> BTW, /3 option was used to force middle button support through L+R
> extension. Now there remains only option.

If /3 has no effect now, it should be removed from /? text.

The "enable PS2 wheel" option should have another name then.

The /o option can be removed, it is so new that nobody will
miss it yet (it means "disable all wheels"). Note that it
is not "FORCE PS2 wheel" but ENABLE - the detection already
tries to get hold of the wheel, but you cannot force it if
it does not react ;-). As discussed, there is no need to
disable the wheel on COM port mice. Of course one could
change the whole /o option from "disable all wheels" into
"enable PS2 wheels" but "o" is an odd letter for that ;-).

> I doubt. Why, if there is MS+wheel protocol?

Probably pre-Logitech MS-3button mice used L+R=Mtoggle protocol
but were useable as 2button with classic MS protocol anyway.

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi!

> "Want"? Capturing first port is usually safe and not hurt, there only
> one drawback - extra stub in memory.

COM port mice are the exception now, so allowing MSys mode means
that a mouse driver is loaded at a place where no mouse exists
(and no mouse will be connected to the COM port later either)
which is much worse than reporting a wheel or a 3rd button in a
situation where hotplugging has allowed the user to change the
mouse to a mouse which has only 2 buttons and no wheel...


> EA> With /y as the default, only people with very old
> EA> Genius mice will have to read the docs to find the name
> EA> of the new non-/y switch ;-).

> ...which they anyway can't use, if driver called from programs
> like Partition Magic.

I will send each user of a mouse which cannot do better than
MSys protocol a copy of an old ctmouse version myself :-p.
Even Alain thinks that he is the only remaining owner of
such a mouse at all.


> EA> Any suggestions for a letter to name it?
> May be /m?

Sounds good as a name for "enable old mouse systems protocol" :-)

> EA> If no 4th byte, reset middle button.
> EA> Otherwise: Middle button
> EA> state = bit 5 or bit 4, wheel change = low 4 bits. This should
> EA> work for all 3 affected protocols :-).
> This is same as above, but offers slight optimization. :) Yes, good
> optimization.

Thanks :-)

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

4-Янв-2008 15:10 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

EA> you are right, disabling the wheel only helps compatibility
EA> in the PS2 case. But as said, I assumed that wheel usage in
EA> DOS is rare, so /O (OPT_noWheel) affects both PS2 and COM
EA> at the moment even though COM wheels seem to be no real risk
EA> for compatibility... Would be easy to change :-). Maybe you
EA> can think of a good line for the /? screen to describe your
EA> suggested /O option style.

  /3   - force 3-button mode (for Microsoft and PS/2 mice only)
 force wheel support (for PS/2 mice)

BTW, /3 option was used to force middle button support through L+R
extension. Now there remains only option.

>> AM> 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
EA> Alain has already clarified in another mail: His code only
EA> supports on the fly detection of the 7bit serial mouse types,
EA> it does never switch to MSys or other. Luckily ;-).

 He clarify, that MSys supported too. :)

>> >> 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...?
>> was idea for it support, but it was excluded after some testing.
EA> Actually, are there mice which use such a protocol? Or are

 I doubt. Why, if there is MS+wheel protocol?

EA> they "dinosaurs" like ancient Genius mice before they learned
EA> to use the MS protocol for 2 or all 3 buttons...? ;-)

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

4-Янв-2008 14:21 [EMAIL PROTECTED] (Alain M.) wrote to
freedos-devel@lists.sourceforge.net:

>> 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.
AM> What I said and some people agreed is to *change the default* to
AM> whatever is more compatible.

 "programs have instructions to activate it".

 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/ (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.
AM> I DISAGREE.

 With what?

AM> No discuttionon that matter because *have it working* so
AM> everything else is vain philosophy.

 If you not have problems with your set of apps doesn't mean that there
not exist apps, which will have problems with changed on the fly mouse type.

AM> 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.
AM> Please don't get too philosophical about button numbers, wheel and byte
AM> numbers. I just used some very dirty tricks, it usualy is resynched
AM> after very few packets and *never* an extra click is generated.

 Alain, above talking about support middle button through MS protocol
extension (when mouse returns middle button press event as L+R press state).
This not relates to auto-switch.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

4-Янв-2008 17:58 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

L>> If you by default disable the wheel (and I think it is not good
L>> idea)

 Unfortunately, for PS2 this IS good idea.  :(

L>> you definitely must write some mouse tool which can detect
L>> mouse.

 CuteMouse does detection.

L>> It is necessary for FreeDOS installers. Installer calls
L>> this tool and found whether mouse has or hasn't the wheel and
L>> than can adjust the AUTOEXEC

 Why? Only user may decide if he need wheel support and if this worth of
risk to enable wheel with PS2 mouse.

EA> I think it is too risky to detect the wheel and adjust the autoexec
EA> only because 4dos, mpxplay and arachne work better with wheel. This
EA> is because the price is too high. FreeDOS 1.0 for example tries to

 In given case - I agreed.

EA> COM port mouse protocols excluding MSys. As Arkady has pointed
EA> out, autoswitching between those 3 types is very safe and easy

 Safe in theory. Practice may differ.

EA> and compatible :-). But Arkady is also right that autoswitching
EA> means that you never really know whether a wheel or 3rd button
EA> is present. A relevant problem! BUT: I think it is good enough
EA> to report the number of buttons and wheels at the time when you
EA> loaded ctmouse, maybe allowing the number to grow when data of
EA> middle button presses or wheel movements is coming in. But I

 Good suggestion. At least, this makes auto-driver behavior identical to
current behavior in case, if mouse (type) will not changed (by hotpluging).

EA> MSys, and we might want an option to disable autoswitch
EA> completely because of side effects mentioned by Arkady,
EA> but I think we can live without the latter option :-).

 I think same. Correcting returned information about 3rd button (when
4th byte is received) and wheel presence (when wheel rotated) should be
enough in Real Life. (Of course, initialization part should set initial
returned values according to detected mouse).

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

4-Янв-2008 15:24 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:

>> 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 still think /y is a good default. It only hurts people with VERY
EA> old Genius mice (such with no "switch to Microsoft mode" switch,
EA> or with switch but 3rd button only supported in MSys mode) but it
EA> helps many people who would otherwise get "trapped" in the caveat
EA> that an empty com port can be confused with a MSys mouse and who
EA> fail to read the docs carefully enough to realize that they want
EA> the /y option.

 "Want"? Capturing first port is usually safe and not hurt, there only
one drawback - extra stub in memory.

EA> With /y as the default, only people with very old
EA> Genius mice will have to read the docs to find the name of the
EA> new non-/y switch ;-).

 ...which they anyway can't use, if driver called from programs like
Partition Magic.

EA> Any suggestions for a letter to name it?

 May be /m?

>> But WHEN driver should re-initialize mouse?! I not see events, which
>> allows make reinitialization not too late or too often.
EA> As autodetection of "sync lost" is hard because the PS2 protocol
EA> is not designed to indicate sync, I suggest manual re-initialize.
EA> This will be by running ctmouse at the prompt. As far as I do

 There is one problem: desynced packets flow may cause "button pressed"
state imitation. Your current shell, if it works with mouse (like
Norton/Volcov Commander) may prevent you from doing anything while "button
pressed".

EA> understand, this will re-use the TSR part of ctmouse after doing
EA> the mouse detection and init stuff :-).

>> 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> Just checked... It says "if no 4th byte, always force middle button
EA> to not pressed state". So mice have to keep sending a 4th byte the
EA> whole time while middle button is pressed.

 Yes. And they do so.

EA> How about modifying...
>>> if 4th byte = zero then ; both protocols
>>>   middle button released
>>> else if bit 5 (mask 0010b) 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> ...as follows then:
EA> If no 4th byte, reset middle button.

 This is assumed (as in current implementation). Above I show only part,
related to processing received 4th byte, and should be injected into
MSLTproc to make it generic across MS/LT protocols.

EA> Otherwise: Middle button
EA> state = bit 5 or bit 4, wheel change = low 4 bits. This should
EA> work for all 3 affected protocols :-).

 This is same as above, but offers slight optimization. :) Yes, good
optimization.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Alain (including a reply for Ladislav),

L> If you by default disable the wheel (and I think it is not good
L> idea) you definitely must write some mouse tool which can detect
L> mouse. It is necessary for FreeDOS installers. Installer calls
L> this tool and found whether mouse has or hasn't the wheel and
L> than can adjust the AUTOEXEC

I think it is too risky to detect the wheel and adjust the autoexec
only because 4dos, mpxplay and arachne work better with wheel. This
is because the price is too high. FreeDOS 1.0 for example tries to
detect networking and USB storage during install, which means that
MANY people only see that FreeDOS HANGS during install and throw
the CD in the recycle bin... Or ask the standard question on our
list. Remember that the "install without network related packages"
workaround has been mentioned FIFTEEN times on the list already!

So I would REALLY prefer the default to be NOT to try to mount USB
disks during install and NOT to download extra packages during
install and NOT to use the mouse wheel during install. You can of
course ALWAYS give the user checkboxes where he can select that
he DOES want to try using / detecting things, but it has to stay
the decision of the user. FreeDOS 1.1 must have defaults which let
you walk away after the usual questions and drive preparations and
come back 5 minutes later (not 60 minutes of USB or DHCP timeouts
later - most people reboot before that) and have a working DOS.
Even if that DOS does not have all features enabled automatically!

About the tool suggestion: Well if you ask me, just put a REMark
in the autoexec which tells to remove the /o if you dare to use
the PS2 wheel. And change ctmouse so /o only suppresses PS2 wheel
but not COM wheel usage :-).




> What I said and some people agreed is to *change the default* to
> whatever is more compatible.

Exactly.

> > autoswicth we not know (can't know) how much buttons currently
> > attached mouse have or if current mouse have wheel or not...
...
> 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).

This involves a high risk of confusing mice and UARTs while at
the same time MSys mice are VERY rare today and the UART mods
make the driver complicated. While I think that you programmed
something really fancy, please do accept that I want a simple
and stable driver with autoswitching only for the three 7bit
COM port mouse protocols excluding MSys. As Arkady has pointed
out, autoswitching between those 3 types is very safe and easy
and compatible :-). But Arkady is also right that autoswitching
means that you never really know whether a wheel or 3rd button
is present. A relevant problem! BUT: I think it is good enough
to report the number of buttons and wheels at the time when you
loaded ctmouse, maybe allowing the number to grow when data of
middle button presses or wheel movements is coming in. But I
would not try to detect the "removal" of buttons or wheels. If
you ask me, if the user removes a wheel mouse and replaces it
with a 2 button mouse on the fly, it is his problem that the
driver still remembers that there was a wheel and a 3rd button.


> >>> there are other protocols where for example "LR encodes a M
> >>> toggle" is used to get along with only 3 bytes...?
> > ... 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.

Needless to say that I do not want very dirty tricks...!
You may be able to avoid ghost clicks, but your method
will have the side effect of chopping "keep middle button
pressed" events into "middle button is pressed, uhm, now
I am not sure, oh, yes it is indeed pressed (again?)" ;-).
In particular for old mice which use the old "L+M means
toggle middle" protocol which Arkady deliberately did not
support because it generated too many spurious events.


In summary: /o should only disable the wheel in the PS2
case, autoswitch should be COM only and should exclude
MSys, and we might want an option to disable autoswitch
completely because of side effects mentioned by Arkady,
but I think we can live without the latter option :-).



Of course it is okay if Alain is happy with 1.6b but my
focus for 2.1 is mass compatibility, not support for all
ancient mice at any price, sorry. It is a bit odd that
we now have FOUR generations of ctmouse to recommend,
but then it seems that universal automatic compatibility
for everything including MSys and PS2 and USB wheel is
very hard to reach. For example we still have no solution
for the CCed guy who can only use 1.9, because both 2.0
and 2.1 even with "disable wheel" option fail to work
with his Dell Inspiron 1501 PS2 touchpad, see the thread
"CuteMouse v2.1 is i

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

Eric Auer escreveu:
>>  Alain, talking about disabling/enabling through command line
>> completely, API doesn't have (yet?) functions to enable wheel support.

ONLY for PS2

> Indeed. If you had a function to enable wheel support, it would
> have to re-detect the mouse to see if there is actually a mouse
> with wheel attached and to activate the wheel.
> 
>> ... 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...
> 
> Very good point. Yet I cannot remember any app which forces
> me to use the wheel as soon as it knows that a wheel exists.
> How about apps which force me to use the 3rd button as soon
> as they know I have one?

Not for Serial mice. Wheel is no trouble at all, and IIRC it can be 
detected on the fly. No discussion on where it is possible or not, I 
have it working so it is possible.

>> AM> 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
> Alain has already clarified in another mail: His code only
> supports on the fly detection of the 7bit serial mouse types,
> it does never switch to MSys or other. Luckily ;-).

No. Correcting: It works with ANY serial mice, 7 or 8 bits MS, LT or 
MSys. ANY combination in ANY order. All it takes is moving the mouse a 
few milimiters and it is working again.

Please, just belive me, I have over 30 years of experience tweeking 
serial bits ;-)

Alain

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

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/ (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/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Ladislav Lacina]

If you by default disable the wheel (and I think it is not good idea) you
definitely must write some mouse tool which can detect mouse. It is
necessary for FreeDOS installers. Installer calls this tool and found
whether mouse has or hasn't the wheel and than can adjust the AUTOEXEC.BAT
file.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Ladislav Lacina]

> Yes, but 3 apps that are important: 4DOS, Arachne (but it needs its own 
> ctmouse??) and Mpxplay.

Arachne works with normal 2.xx Ctmouse.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi again,

> >> EA> has an option /Y ignore Mouse Systems, and most people
> >> 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.

I still think /y is a good default. It only hurts people with VERY
old Genius mice (such with no "switch to Microsoft mode" switch,
or with switch but 3rd button only supported in MSys mode) but it
helps many people who would otherwise get "trapped" in the caveat
that an empty com port can be confused with a MSys mouse and who
fail to read the docs carefully enough to realize that they want
the /y option. With /y as the default, only people with very old
Genius mice will have to read the docs to find the name of the
new non-/y switch ;-). Any suggestions for a letter to name it?

> I suggest, all (new) options should remain one-letter... Or you may
> use /y+ (enable), /y- (disable) syntax.

Then we better use a new letter :-)

> This should affect only PS2 handler, because for serial mice there
> is no problems with supporting wheel.

You are right. I can change /o to disable only PS2 wheel, not
serial port wheel. See my other mail.

> But WHEN driver should re-initialize mouse?! I not see events, which
> allows make reinitialization not too late or too often.

As autodetection of "sync lost" is hard because the PS2 protocol
is not designed to indicate sync, I suggest manual re-initialize.
This will be by running ctmouse at the prompt. As far as I do
understand, this will re-use the TSR part of ctmouse after doing
the mouse detection and init stuff :-).

> You mean, that driver should also trap INT15 and monitor BIOS calls?

No...

> 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.

Just checked... It says "if no 4th byte, always force middle button
to not pressed state". So mice have to keep sending a 4th byte the
whole time while middle button is pressed. How about modifying...

>> if 4th byte = zero then ; both protocols
>>   middle button released
>> else if bit 5 (mask 0010b) 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)

...as follows then:

If no 4th byte, reset middle button. Otherwise: Middle button
state = bit 5 or bit 4, wheel change = low 4 bits. This should
work for all 3 affected protocols :-).

> 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.

Ah. So it was yet another very old but evil protocol :-)

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Arkady,

you are right, disabling the wheel only helps compatibility
in the PS2 case. But as said, I assumed that wheel usage in
DOS is rare, so /O (OPT_noWheel) affects both PS2 and COM
at the moment even though COM wheels seem to be no real risk
for compatibility... Would be easy to change :-). Maybe you
can think of a good line for the /? screen to describe your
suggested /O option style.

> I think, this is important only for PS2, where wheel support is dumb
> and unreliable. In serial protocols (MS+wheel, LT) disabling wheel
> gives nothing.

>  Alain, talking about disabling/enabling through command line
> completely, API doesn't have (yet?) functions to enable wheel support.

Indeed. If you had a function to enable wheel support, it would
have to re-detect the mouse to see if there is actually a mouse
with wheel attached and to activate the wheel.

> ... 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...

Very good point. Yet I cannot remember any app which forces
me to use the wheel as soon as it knows that a wheel exists.
How about apps which force me to use the 3rd button as soon
as they know I have one?

> AM> 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

Alain has already clarified in another mail: His code only
supports on the fly detection of the 7bit serial mouse types,
it does never switch to MSys or other. Luckily ;-).

> >> 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...?
>
> was idea for it support, but it was excluded after some testing.

Actually, are there mice which use such a protocol? Or are
they "dinosaurs" like ancient Genius mice before they learned
to use the MS protocol for 2 or all 3 buttons...? ;-)

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Flox,

> > In short, the wheel stuff is
> > less foolproof than the protocol without wheel, and as 95% of
> > the DOS apps do not use the wheel anyway,

> Yes, but 3 apps that are important: 4DOS, Arachne (but it needs
> its own  ctmouse??) and Mpxplay.

Then users of those apps will have to live with the risk.
If you enable wheel support, your keyboard can crash or
ctmouse can fail to detect the mouse at all (only affects
ps2 and usb wheel mice, not com port wheel mice). Which
is why I recommend not to enable the wheel on boot disks
with fixed configuration...

I believe you can get in contact with several users of
4dos, arachne and mpxplay. So it would be nice if you
could collect a bit of feedback from them! Questions
are: Does wheel mode of ctmouse 2.0 and 2.1b3 work for
them? Which versions work with Arachne? Why (not)?
In versions where wheel mode does not work, does at
least the non-wheel mode work for 1.9, 2.0 and 2.1b3?

Thanks for testing :-)

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

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/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

3-Янв-2008 13:21 [EMAIL PROTECTED] (Alain M.) wrote to
freedos-devel@lists.sourceforge.net:

>> 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.

 I think, this is important only for PS2, where wheel support is dumb
and unreliable. In serial protocols (MS+wheel, LT) disabling wheel gives
nothing.

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.

>> 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/ (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.

>>> "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).

AM> 100% tested
AM> in the field what 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.

AM> remember that changing mice qas

 "qas"?

AM> very common before the advent of modern
AM> optical ball-less mice.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

3-Янв-2008 12:26 [EMAIL PROTECTED] (lyricalnanoha) wrote to
freedos-devel@lists.sourceforge.net:

>> "is empty or attached mouse in Mouse Systems mode".  :)  And Genius
>> mice are long ago based on Logitech protocol.
l> ...
>> Forget "Genius". All (newer) Genius mice, which I seen, was working
>> in LT protocol.
l> I used to have a Genius serial mouse, and used a Microsoft driver with it,
l> though apparently you could flip a switch for Mouse Systems compatibility.
l> This was ten years ago.

 Yes, old Genius mice was based on MSys and MS protocols, selectable by
switch. (I was testing MSys mode of CuteMouse with such mouse). Middle
button was supported only in MSys mode (of course). But these mice very old.

 MS drivers (was) too support MSys protocol.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Florian Xaver]

> In short, the wheel stuff is
> less foolproof than the protocol without wheel, and as 95% of
> the DOS apps do not use the wheel anyway, 

Yes, but 3 apps that are important: 4DOS, Arachne (but it needs its own 
ctmouse??) and Mpxplay.

Bye
  Flo

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Arkady,

>  I not seen your edition yet, so I not have any ideas. :)

It is on www.coli.uni-saarland.de/~eric/ctmouse21b3.zip

Your points about the macros are okay :-)

> "is empty or attached mouse in Mouse Systems mode". :) And Genius
> mice are long ago based on Logitech protocol.

Which even means that only -old- Genius mice use Mouse Systems.

>  Well, I never seen such bug report...

You are right - users can be so lazy that they just download
another driver instead ;-).

> >> 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.

So you agree to make /y the default :-) I suggest to introduce
a new option (name? maybe /yy?) which means ENABLE Mouse Systems
mode, and ignore the /y option because DISABLE Mouse Systems
would be the default in the future.

> EA> default, too, as disabling the wheel improves compatibility
> EA> quite a bit.
>  How it improves compatibility?

Using the wheel needs a "handshake" (a sequence of clock changes)
and it needs the not-so-common 4 byte protocol. The 2.0 driver
used direct keyboard controller programming, which sometimes (too
often) crashed my keyboard and which might confuse BIOS USB mouse
drivers which emulate PS2 via the BIOS PS2 interface and/or by
feeding the data into the keyboard controller. For example some
user recently reported that 2.0 hangs his PC. The 2.1 driver is
"plain BIOS", but I got a bug report that some emulated PCs do
not support 4 byte protocol in their BIOS, while they do support
the wheel detection handshake... In short, the wheel stuff is
less foolproof than the protocol without wheel, and as 95% of
the DOS apps do not use the wheel anyway, I suggest to use the
disable wheel option for example in the autoexec of a generic
boot floppy or boot cdrom or dvd.

> Microsoft: 01LRyyxx, 00xx, 00yy (high bits are in 1st byte)
> Logitech:  01LRyyxx, 00xx, 00yy, 00M0 (4th only if M change)
> MS Wheel:  01LRyyxx, 00xx, 00yy, 000M (w is 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. :(

You could resync by selecting the protocol again, possibly after
a rate change or similar to make it clear that there is something
to be synced.

> Not need - review again resync check at start of MSLTproc.

Yes yes. You only get one bad packet, but in Logitech and MS
Wheel protocol, this means that the middle button state might
be wrong until you press that button again. If you have some
protocol which does "L+R means toggle middle" (pre-Wheel MS
3 button mice?), it can be quite hard to resync the state of
the middle button. Well I guess you just press both buttons
simultaneously to force a toggle then :-).

> Bad, very bad protocol design. :( How annoys such brain damaged
> working...

Basically PS2 mice are like PS2 keyboards - not designed for
hotplugging. Might even damage something, although unlikely.

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

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/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[lyricalnanoha]

On Thu, 3 Jan 2008, Arkady V.Belousov wrote:

> "is empty or attached mouse in Mouse Systems mode". :) And Genius
> mice are long ago based on Logitech protocol.

...

> Forget "Genius". All (newer) Genius mice, which I seen, was working
> in LT protocol.

I used to have a Genius serial mouse, and used a Microsoft driver with it, 
though apparently you could flip a switch for Mouse Systems compatibility. 
This was ten years ago.

-uso.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

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 0010b) 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: 1LMR, 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, 00xx, 00yy (high bits are in 1st byte)
EA> Logitech:  01LRyyxx, 00xx, 00yy, 00M0 (4th only if M change)
EA> MS Wheel:  01LRyyxx, 00xx, 00yy, 000M (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:

>   testal,0100b; =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
xchgax,c

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Alain,

> IMHO the default should be off, but the code should remain
> there.

For Genius? Agreed. Probably would be harder to remove it ;-)

> 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.



> 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?

> 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!



> > 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.

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

Eric Auer escreveu:
> Rule 1: Users never read the manual. So they just type ctmouse,
> see that it somehow fails to see their ps2 mouse, then grabs their
> empty com port (because you never know if it is empty or Genius)
> and then file a bug report instead of reading the manual ;-). This
> is why I suggest to make the default "do not guess that a com port
> which is nothing else might be a Genius mouse".

Agrred, but: IMHO the dafault shuld be off, but the code should remain 
there.

> In that case, you probably want "disable wheel" to be the
> default, too, as disabling the wheel improves compatibility
> quite a bit.

I 100% agree. The proble is two fold: first it causes compatibility 
problems, sencond there is *very* few programs around that would use it 
anyway and it would be logical that *these* programs have instructions 
to activate it.

> So the above 3 types "talk Microsoft" unless you press or release
> the middle button or move the wheel at that moment, although I am
> unsure whether MS Wheel mice use the 4th byte only on demand or
> for every packet?

YES i have made it for 1.6b, all MS Logitech are intercangeable on the 
fly. I still use that version because all my improvements were 
disregarded :(

>> "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...).

What 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. 100% tested 
in the field what serial mice where commmon.

> I hope it was Genius only. If you change a mouse while busy,
> you can end up throwing any of the 2th to 4th bytes into the
> slots for 2th to "7th" byte before you get a new "sync" marked
> first byte again. I think this is acceptable, though. As long
> as the 4th byte marks the middle button STATE, not the toggle,
> you can always get the middle button "fixed" by pressing and
> 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...?

It can be done, I did it...

>> Also, I should mention: Alain was doing some changes for himself
>> to make "autodecision".
> I think I remember his plans, but does he still have the
> sources? Are they readable, stable, understandable? ;-)

I have the sources, they as as readable as any of CuteMouse source, (in 
a  in later versions some comments were added to a small portion that 
was dis-assembled). And I have the source on which I based my changes, 
so that it can be "kompared".

>> There is another problem with PS/2

PS/2 is not perfect with 1.6b, sometimes it doesn't find and 2.0 works.

> 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 woth while.

remember that changing mice qas very common before the advent of modern 
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/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

Arkady V.Belousov escreveu:
> 
> EA> I must admit that the CuteMouse source code is ugly but on the
> 
>  Let me object this assertion. :) 

Hi Arkady, wellcome back... I look forward to many new discussions :)

Alain
PS: this is a joke ...


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Alain M.]

First thing that come to mind: if you write free software, write it 
using free compiler.

Alain

Андрей Влащенко escreveu:
> Hello everybody! CuteMouse project is dead; I can develop new mouse driver 
> for the FreeDOS project. This driver, named "FreeMouse", I started today. 
> Please reply to me, I want that you help me writing correct autodetection of 
> used mouse type, and handle the PS/2/COM/MSMouse's. I do not understand the 
> architecture of the CuteMouse, which is written in assembler, but I write 
> FreeMouse in the TurboPascal v3.0. Previously big thanks for all of this case!


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi Arkady, thanks for the feedback :-)

> 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).

Unfortunately, you did not miss much. But at least CuteMouse
is still maintained, and people still get support when they
have questions about problems with it... Yet I wonder why
ctmouse 2.1b3 /O /P works worse than 1.9 for that problematic
PC (2.1 with wheel does not see mouse, 2.0 hangs, 2.1 /O is
supposed to work like 1.9 but does not see mouse either). If
you have an idea how to test this...?

> 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_).

Which leads to a "new language" which is harder to read ;-).
It might also have side-effects in some ways, but I usually
do trust that if else end macro, it can be nice yes :-).

> 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.

Rule 1: Users never read the manual. So they just type ctmouse,
see that it somehow fails to see their ps2 mouse, then grabs their
empty com port (because you never know if it is empty or Genius)
and then file a bug report instead of reading the manual ;-). This
is why I suggest to make the default "do not guess that a com port
which is nothing else might be a Genius mouse".

> 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.

The /Y option is only intended to avoid pretending that an
empty com port is a Genius mouse, so I think /Y is good.
And if you have no mouse /Y is a good idea, because the
driver will not load if it finds no mouse :-).

> 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.

In that case, you probably want "disable wheel" to be the
default, too, as disabling the wheel improves compatibility
quite a bit.

> if 4th byte = zero then ; both protocols
>   middle button released
> else if bit 5 (mask 0010b) 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)

Lemme see...



Mouse Sys: 1LMR, X1, Y1, X2, Y2 (sum 1 and 2 to get X and Y)
only Mouse Systems / Genius uses 8 data bits, the following use 7:



Microsoft: 01LRyyxx, 00xx, 00yy (high bits are in 1st byte)
Logitech:  01LRyyxx, 00xx, 00yy, 00M0 (4th only if M change)
MS Wheel:  01LRyyxx, 00xx, 00yy, 000M (w is wheel)



So the above 3 types "talk Microsoft" unless you press or release
the middle button or move the wheel at that moment, although I am
unsure whether MS Wheel mice use the 4th byte only on demand or
for every packet?



PS2 mouse: ??yx1MRL, X, Y (bits in 1st byte are "X/Y overflow")
PS2 Wheel: ??yx1MRL, X, Y, wheel (usually wheel is -8 .. +7)
PS2 3+wh.: ??yx1MRL, X, Y, 00BF (B F are extra buttons)



In PS2, you tell the BIOS to select a protocol size and reset
communication to know "where you are". This is why you can get
out of sync when trying to hotplug a PS2 mouse (which can also
stress the hardware). USB mice can often talk PS2 with a dumb
(non-electronic, only mechanical) adapter. If you connect USB
mice via USB, the BIOS often is able to create virtual PS2 and
feed it with the data from USB. In COM (serial port) mice, you
have the 01nn mark for the first byte and 00nn for all
other bytes, so you can always get back in sync if you hotplug
a serial mouse. Of course other parameters can mess up then.

> "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...).

I hope it was Genius only. If you change a mouse while busy,
you can end up throwing any of the 2th to 4th bytes into the
slots for 2th to "7th" byte before you get a new "sync" marked
first byte again. I 

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

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 0010b) 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/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Ladislav Lacina]

Great! CuteMouse is good driver but is very slow in protected mode. F.e when
playing Doom and you control it with mouse, it is jerky. (with another
drivers is it OK). So test it also from this point of view.
Why did you choose the 3.0 version of TP? Because it compiles into COM?
Why not, but the disadvatage is that you can't use the assembler code. TP
3.0 understands only machine code.



> Hello everybody! CuteMouse project is dead; I can develop new mouse driver
for the FreeDOS project. This driver, named "FreeMouse", I started today.
Please reply to me, I want that you help me writing correct autodetection of
used mouse type, and handle the PS/2/COM/MSMouse's. I do not understand the
architecture of the CuteMouse, which is written in assembler, but I write
FreeMouse in the TurboPascal v3.0. Previously big thanks for all of this
case!



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Eric Auer]

Hi there :-)

> Hello everybody! CuteMouse project is dead; I can develop new mouse
> driver for the FreeDOS project. This driver, named "FreeMouse", I
> started today. Please reply to me, I want that you help me writing

Well maybe you did not wait long enough for a reply from Nagy Daniel:
Current CuteMouse 2.1 development is done by me :-). So CuteMouse is
not dead, but you are welcome to help :-).

> correct autodetection of used mouse type, and handle the
> PS/2/COM/MSMouse's. I do not understand the architecture of the
> CuteMouse, which is written in assembler, but I write FreeMouse
> in the  TurboPascal v3.0. Previously big thanks for all of this case!

I must admit that the CuteMouse source code is ugly but on the
other hand it is small because it is written in Assembler :-).

Current version 2.1b3 is here:

www.coli.uni-saarland.de/~eric/ctmouse21b3.zip

What I was planning to do next was to make the COM handling
automatic: Maybe remove Mouse Systems (Genius) protocol or
at least make it no supported by default. The current version
has an option /Y ignore Mouse Systems, and most people should
use it, because you cannot detect whether you talk to one of
those mice or just to an empty serial port in a nice way ;-).
So my plan is to make that "ignore Mouse Systems" the default.

Then, only two main COM protocols are left: Logitech mouse and
Microsoft Mouse protocol. My plan would be to change the code
of "MSLTproc" to automatically decide for each packet which of
the two protocols the packet is. Then you have hotplugging for
COM mice :-). You also have a chance for hotplugging of PS2
mice already with 2.1, if you use the /O option to disable the
wheel part (which is hard to re-bootstrap on the fly). Note that
PS2 is not officially meant to support hotplugging, you might
even damage old hardware by doing it?

As this COM protocol autodecision is a bit tricky, you may want
to write a Pascal version of it first, so I can port it to ASM
for CuteMouse :-).

Eric



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Arkady V.Belousov]

Hi!

31-Дек-2007 14:44 [EMAIL PROTECTED] (Андрей Влащенко) wrote to
freedos-devel@lists.sourceforge.net:

АВ> Hello everybody! CuteMouse project is dead;

 Well, it long ago wasn't updated, but authors are here.

АВ> I can develop new mouse driver
АВ> for the FreeDOS project.

 New?!! Well, well...

АВ> This driver, named "FreeMouse", I started today.
АВ> Please reply to me, I want that you help me writing correct autodetection of
АВ> used mouse type, and handle the PS/2/COM/MSMouse's.

 Read protocol.txt from CuteMouse package.

АВ> I do not understand the
АВ> architecture of the CuteMouse,

 It not hard. And you may ask me, if you not understand something.

АВ> which is written in assembler, but I write
АВ> FreeMouse in the TurboPascal v3.0.

 One of reasons for CuteMouse was small memory footprint. You not get
small memory footprint in high level languages.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Mouse Driver Development...

[Japheth]

Андрей Влащенко wrote:
> Hello everybody! CuteMouse project is dead; 
 > I can develop new mouse driver for the FreeDOS project.
 > This driver, named "FreeMouse", I started today.
> Please reply to me, I want that you help me writing correct
 > autodetection of used mouse type, and handle the PS/2/COM/MSMouse's.
 > I do not understand the architecture of the CuteMouse, which is
 > written in assembler, but I write FreeMouse in the TurboPascal v3.0.
 > Previously big thanks for all of this case!

CuteMouse possibly is not as dead as you might believe. But even if it is, 
it works at least and therefore you should first tell us what your driver is 
to make better than CuteMouse.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] New Mouse Driver Development...

[Андрей Влащенко]

Hello everybody! CuteMouse project is dead; I can develop new mouse driver for 
the FreeDOS project. This driver, named "FreeMouse", I started today. Please 
reply to me, I want that you help me writing correct autodetection of used 
mouse type, and handle the PS/2/COM/MSMouse's. I do not understand the 
architecture of the CuteMouse, which is written in assembler, but I write 
FreeMouse in the TurboPascal v3.0. Previously big thanks for all of this case!

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel