Re: [Freedos-devel] New Mouse Driver Development...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
> 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...
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] FreeDOS reads DVD discs
Hi HCL, > I found it in the Australian PC magazine (APC) DVD and > modified it in my desktop that works well. Ah nice! I wonder whether we could get a copy of whatever they write about us so we can put it on our press coverage corner on our homepage? > I don't know if this feature has been documented but I hope the FreeDOS .iso > image file can be burned into a DVD disc and boots in DVD drives as well. Well I do know and use that, because I always use DVD-RW for everything :-). The good thing about DVD-RW is that you can use them several times and that you can put more data on them than on CD. Booting from DVD works exactly like booting from CD in the first place, but when DOS then uses a CDX driver to access the rest of the disk, you will notice that only classic ISO9660 filesystem is supported. UDF-formatted DVD or CD disks cannot be used with SHSUCDX. As far as I remember, NWCDEX and MSCDEX doe not support UDF filesystems either. 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...
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...
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...
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...
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...
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...
> 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
