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 invalid driver." Alain, you should send him a download URL for 1.6b, so he can compare :-) Of course this still does not give him wheel support, but maybe the touchpad has no scroll buttons / scroll area or other wheel equivalent anyway? Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
