slowing_down a super_fast mouse
Polytropon
freebsd at edvax.de
Mon Jul 11 17:24:08 UTC 2016
On Mon, 11 Jul 2016 03:54:12 +0000, spellberg_robert wrote:
> On 06/21/16 05:23, Polytropon wrote:
>
>
>
> dear sir or madam ---
Sir. :-)
> i apologize for the delay of my response and my thanks .
> however , as i am certain that you and other readers will appreciate ,
> since mid_day thursday [ jun_23 ] , here , at the salt_mine ,
> "brexit" has been creating additional work for me .
return BREXIT_SUCCESS; /* see the brexit() manual page for details */
> as i do not know you personally , i find that
> your appellation , "polytropon" , provides insufficient information ,
> for me to make the correct selection ,
> with a high probability of success .
It's a handle I chose from the first few lines of Homer's "Odyssey"
which means (if I understood the translation correctly) "far-traveled"
or more precisely, "[man] of many turns". This is because I have seen
more than my age justifies. ;-)
> my online_search attempts have been fruitless
> [ no doubt , i have not selected , as yet , the right engine ] .
This is the intended purpose of a "pseudonym" handle. :-)
> > On Tue, 21 Jun 2016 01:55:33 +0000, spellberg_robert wrote:
> >> howdy , folks ---
> >>
> >> i hope that everyone is well .
> >>
> >>
> >>
> >> in anticipation of installing 10.3 , i have been buying new hardware
> >> [ probably , intel "skylake" and "z170" , of some kind ] .
> >> this new mechanical keyboard , "daskeyboard" ,
> >> with the cherry "blue" switches , is really nice ,
> >
> > Yes, those are great, but nothing beats "IBM model M". :-)
>
> i believe that i have used one of those ; was it the kbd for the 3270 ?
No, the classical 3270s had different (but also "clicking" keyboards).
The later 3270 editions, as well as the 5250s, had the famous "model M"
keys. They were also present on the IBM PS/2 PC keyboards (which
I'm currently using).
> >> [ before i did any editing , this post looked like
> >> traudl junge's first effort for her new boss ,
> >> in that scene in "downfall" , at the beginning of the film
> >> ] .
> >
> > Then compare to the "typist audition" in "Schindler's List"
> > for improvement. :-)
>
> i do not have that one in my library
> [ i --did-- see it once , though , long ago ] .
I found it: https://www.youtube.com/watch?v=XmsmPWEqkWY
> >> the ps2 keyboards and mice actually have usb interfaces ,
> >> with usb/ps2 adapters , plugged into ps2 ports .
> >> from what i read on wikipedia ,
> >> these should look like ps2 devices to the ps2 ports .
> >> the six_years_old moboes --do-- have usb ports of some kind ,
> >> but this is my first usb equipment ,
> >> therefore , i have no usb experience .
> >
> > Then why don't you use them natively via USB? Basically, it should
> > work out of the box (as the kernel provides ukbd and ums drivers).
>
> now , --this-- is a very good question .
>
> essentially , most_of_the_time , i am a "late adopter"
> [ but , as i said , above , i am considering "skylake" ;
> whoda thunkit ?
> ] .
> when i change things , i like to change them one_at_a_time .
> this comes from my engineering mind_set ;
> change one variable , then , see what happened .
A lesson we all learn at some point. :-)
> this has had the added advantage of suppressing , at shut_down ,
> certain usb_related messages .
> of these usb_messages , on a 24_row screen , their inclusion caused
> other , more_important messages to be scrolled_up ,
> far_enough , so that they fell_off of the top_edge of the world .
They are sill available in the line buffer, which you can scroll
using the "Scroll Lock" key.
> fyi , this next bit referred to psm(4) [ mea culpa ] .
>
> >> so i start reading [ man_pages , handbook , et_cetera ] ;
> >> eventually , i find the man_page about "/boot/device.hints" .
> >> i find words like "flags" , "resolution" and "acceleration" .
> >> i find an example for "psm0" .
> >> this looks promising .
> >> i check my boot messages ;
> >>
> >> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> >> psm0: [GIANT-LOCKED]
> >> psm0: model Intellimouse, device ID 3
> >>
> >> these are the same messages as those for
> >> the old mitsumi mouse on the 10.2 box ;
> >> i get the impression that all ps2 mice are pretty much the same .
> >
> > The easiest way to configure the mouse behaviour for the console
> > is using moused. In this case, accessing the settings via /dev/psm0
> > (through the PS/2->USB adapter) is quite easy:
> >
> > moused_enable="YES"
> > moused_type="auto"
> > moused_flags="-z 4"
> > moused_port="/dev/cuaa0"
> > moused_type="mousesystems"
> > moused_flags="-r 300 -a 2.0"
> >
> > This is an example from one of my older systems where a serial mouse
> > with 3 buttons needed adjustment for resolution and accelleration.
> > See "man moused" for details about the required flags.
> >
> > In your case, you'd probably have to use
> >
> > moused_type="auto"
> > moused_port="/dev/psm0"
> >
> > instead. You can try out various settings by first invoking moused
> > with the -d -f flags (print debugging messages, run in foreground),
> > and when you're happy with the settings, add them to /etc/rc.conf
> > accordingly.
> >
> > Note that using moused with USB devices is not that trivial as it
> > is controlled "dynamically" via devfs/devd, if I remember correctly.
>
> here is the relevant portion , from my "/etc/rc.conf" ;
> all are defaults , except "enable"
> [ i deleted and compressed much , due to "auto_wrap" ] .
>
> #.
> #---+240+-30+a--1---+---+---+---2---+---+---+---3---+---+---+---
> moused_enable="YES" #srl set by srl .
> #---+240+-30+a--1---+---+---+---2---+---+---+---3---+---+---+---
> #.
> #srl moused_nondefault_enable="YES" #bsd T... .
> #srl moused_enable="NO" #bsd R... .
> #srl moused_type="auto" #bsd S... .
> #srl moused_port="/dev/psm0" #bsd S... .
> #srl moused_flags="" #bsd A... .
> #srl mousechar_start="NO" #bsd i... .
> #.
Just a question to make sure I'm not misinterpreting the text:
Do the lines begin with "#srl"? Always keep in mind that /etc/rc.conf
is a shell script, it is sourced (read + executed) by several other
scripts, so it needs to conform to sh syntax. So if you do something
like setting
#comment foo="bar" # another comment
the whole line is commented out: # means "comment until end of line".
> from what i read in moused(8) , along with "-d" and "-f" ,
> "-r" , "-a" and "-A" should do the trick .
> i will "play" with it .
This is a very convenient way to check things, especially if you
need to adjust accelleration or threshold. The final values can then
be put into /etc/rc.conf for permanent use.
> [ note : i create my "/etc/rc.conf" [ and others ] in this manner .
>
> save any existing version that may have been installed .
> copy "/etc/defaults/rc.conf" to "/etc/rc.conf" .
That step is not needed, as /etc/defaults/rc.conf is sourced (see above)
prior to /etc/rc.conf and /etc/rc.conf.local, so you only need to have
the values you want to change in your configuration file.
> invoke vi(1) ; perform extensive editing ,
> for readability [ according to --my-- needs ; ymmv ] .
>
> a] comment --every-- line ,
> with --my-- comment_syntax , "#srl<HT>" ,
> while preserving the bsd_markers as "#bsd<HT>" ; example :
>
> #srl #bsd thingy="mumble" #bsd comment .
>
> b] combine multi_line comments onto one line ; move right_ward .
> c] separate un_related groups of parameters with "#.<LF>" .
> d] high_light changes by
> 0] enclosing them in a pair of horizontal_rule lines ;
> 1] adding the notation "<HT>#srl<HT>set by srl ." .
> e] add a comment_header at the top , for file_scope notes .
> f] add a line at the bottom , "#eof." .
> g] use <HT> to separate , clearly , code from comments .
> h] miscellaneous , as appropriate .
>
> this way , i have --one-- file , only , to manage .
> ]
You always only have one file to manage - /etc/defaults/rc.conf is
incorporated automatically. Also note that this file might change
during a system update, so defaults could change. If you set your
own values anyway - no problem, but if the default _needs_ to be
changed, and your configuration file has a different setting, you'd
have to manually compare both files to find potential changes after
the upgrading process.
Summary: Only put into /etc/rc.conf what you need to set differently
than /etc/defaults/rc.conf.
See "man rc" and "man rc.conf" for details.
> >> i note that there are no "flags" ; so i try that .
> >> i "guess" that flags of "0x01" and "0x04" will
> >> disable "acceleration" and
> >> set "resolution" to either extreme , one way or the other .
> >> if this works ,
> >> then i should observe a 8:1 ratio for cursor distance ;
> >> all that i have to do is to pick a "comfortable" setting .
> >>
> >> well , that was the plan .
> >> it failed .
> >
> > As expected. :-)
>
> if you please , would you elaborate upon this ?
> your use of punctuation suggests that
> you know more than you are letting on .
You can conclude that from punctuation? I always thought it just
illustrates how bad my English is...
> at the time , this method really did look like the correct one .
This method doesn't seem to apply to PS/2 or USB mice, if I
remember correctly. Additionally, as X provides its own input
drivers, I doubt it would care for psm flags.
> >> let me emphasize : the new hardware --works-- .
> >> it is just that the cursor goes flying across the screen ,
> >> for a small mouse_on_pad motion .
> >> positioning --is-- challenging .
> >>
> >> the flags --are-- recognized ; they appear in the boot messages ;
> >> for example ,
> >>
> >> psm0: <PS/2 Mouse> flags 0x1 irq 12 on atkbdc0
> >>
> >> but the behavior does not change on either the console or the xterm .
> >
> > The console has a different mouse driver than X. For X, you need to
> > configure the mouse parameters using the tool your desktop environment
> > provides. If you're not using a DE, consider using /etc/X11/xorg.conf.
> > Again an example:
> >
> > Section "InputDevice"
> > Identifier "Mouse0"
> > Driver "mouse"
> > Option "Device" "/dev/sysmouse"
> > Option "Protocol" "Auto"
> > Option "ZAxisMapping" "4 5"
> > Option "Emulate3Buttons"
> > Option "EmulateWheel"
> > Option "EmulateWheelButton" "2"
> > EndSection
> >
> > You can set "Samplerate" and "Resolution" as well. You can find
> > even more options in the documentation.
>
> i am pleased to report that i no longer use a "desktop environment" .
> twenty_odd years ago , i tried that microsoft_brand "windows" thing ;
> specifically , 3.1 , 95 and 98se .
> in general , they are difficult to use , to configure and to program .
Timeless statement. :-)
> further , i am pleased to report that i have had a "xorg.conf" file ,
> in one location or another , since mr_lehey's second_edition .
This file makes sense for machines where you need to have settings
that are not provided by the desktop environment (such as keyboard
layout or specific mouse flags), and you want to have them in _one_
central location. In the past, there was much trouble with HAL, DBus,
ConsoleKit, PolicyKit, NonsenseKit and whatnot, and configuration
details were scattered across the /usr/local subtree, in XML files.
The xorg.conf file frees you from this trouble.
It also makes sense where autodetection magic doesn't work as inteded,
for example, if the screen manufacturer chose to report bogus data,
or no data at all, and a "native screen resolution" cannot be
determined. For hardware that doesn't change it's very convenient.
A great advantage is the possibility to use a "partial xorg.conf"
where you only need to have the sections you _really_ need - and
have everything else automatically detected.
For _modern_ hardware, xorg.conf shouldn't be needed anymore.
> in fact , my "monitor" section still has "modeline"s ;
> i wonder if a way has been developed to
> probe the lcd_monitor for parameters ;
> that would be nice , but , i digress .
Yes, EDID should do that. But it's not like this is something new.
> again , the relevant portion :
>
> #---+240+-30+a--1---+---+---+---2---+---+---+---3---+---+---+---
> #srl section_begin input device : mouse .
> #.
> Section "InputDevice"
> #.
> Identifier "mouse_3_button"
> #.
> Driver "mouse"
> #.
> Option "Protocol" "Auto" #srl ... .
> #.
> Option "Device" "/dev/sysmouse" #srl ... .
> #.
> #srl from here , all is commentary until "EndSection" .
> #.
>
> [ snip --- prior implementations , kept for historical reference ]
>
> #.
> EndSection
> #.
> #srl section_end input device : mouse .
> #---+240+-30+a--1---+---+---+---2---+---+---+---3---+---+---+---
Looks fairly standard so you should be able to entirely omit it.
> i have never used any_thing else , in this section ,
> because it was never necessary ; perhaps , it has become so .
> you give me some ideas ; i will do some "playing" , here , also .
There are a few parameters to affect mouse behaviour X-wide, as
mentioned above. You need to check what works for you.
> >> maybe there is some "buzzword" , of which i am unaware .
> >> which ignorance prevents further research by me .
> >
> > Yes, there is dynamic leverage synergetic mouse outsourcing for
> > startup unicorn capital growth inflation. :-)
>
> i laughed my_self silly .
> you have a sense_of_humor ; this is good .
It's required to survive "in the industry". ;-)
> >> ps --- does anyone know how to
> >> turn_off this narrow 65_column auto_wrap
> >> in the "thunderbird" editor ?
> >
> > Why is that a problem? You should breat your lines between column
> > 60 and 70. If you prefer to do this manually (as I do), you'll
> > find the relevant setting in the message compose configuration,
> > if I remember correctly.
>
> oh , dear .
>
> the nature of your response was completely un_expected .
> my initial reaction was one of shock ;
> since then , my shock has morphed into disappointment .
> no worries , mate ; i am not angry .
>
> because i am a subscriber to -questions@ ,
> i have observed that you are a frequent responder ,
> when so many posters echo the desperate cry of "tamino" :
> "zu hilfe , zu hilfe , sonst bin ich verloren" .
Silence. :-)
> 0] why is that a problem ?
>
> standing alone , this question is not un_reasonable .
>
> recently , thanks to this new mouse , i have discovered that
> i can "yank" text , from a xterm , and "print" it ,
> into the "thunderbird" editor .
> on the surface , this appears to be A Good Thing .
That's something I'm doing for decades now: Select with left button,
copy with middle button. It's a very handy way to add a "screenshot"
(of text) to a message, or to quote text from a manpage.
> un_fortunately ,
> "thunderbird" insists upon imposing its idea of good manners
> by re_formatting my text .
Does it even do that when the annoying "HTML mail" composition has
been switched off?
> it converts tabs to spaces and [ the affrontery ! ]
> it inserts line_breaks into the middle of blank_delimited words .
Tabs to spaces seems to be normal, my mail composer in Sylpheed does
this too, probably because the terminal window - when captured from -
does not represent tabs as tabs, but as "logical spaces", so at
least this part makes sense.
> for prose , this is not so bad ;
> for "computerese" , this is an un_qualified --disaster-- .
> above , each time , it required several minutes for me to
> re__re_format the result of what should have been a simple task .
This is why I sometimes prefer to re-edit the text and turn the
spaces into tabs manually again (which takes some time, but I prefer
the text to be readable in its initial form, especially when it's
a code snippet that the recipient wants to save to a file - and of
course expects that the indentation is a tab, not 8 spaces).
> 1] you should break your lines between columns 60 and 70 .
>
> this assertion got my attention .
>
> the justly_famous person , lawrence wall , has proclaimed
> his , now , justly_famous motto ,
> "there is more than one way to do it" .
> are you familiar with this ?
Yes, there is more than one way to limit the line length. :-)
Here is a ruler for 70 columns:
....+....1....+....2....+....3....+....4....+....5....+....6....+....7
I have this "ISPF/PDF ruler" forced on top of vim. :-)
The Sylpheed composer window uses a fixed-width font and has a ruler
on top; I set the window width so that column 80 is near where the
window ends. Window end means line end. :-)
> my writing style developed from observations that were made ,
> during team code_review sessions ,
> while sitting around the departmental conference table .
> how does one induce rapid comprehension of new information ?
>
> for prose , over time , i developed and refined this approach :
> a] sentences begin on a new line ;
> b] within a sentence , line breaks are placed --between-- clauses ,
> not --within-- them ;
Which seems to be good for English as the grammar is a more strict
element of language (unlike German where you basically write as you
want, especially after the "spelling reforms").
> normally , i write on a page that has a width of 318 characters .
> this is wide for prose , but , it is just_about right for code .
> of course , different people have different ways .
> for this list , i would use a width of 132 characters .
That looks like the "extended width IBM 3270". :-)
> i propose a compromise :
> i will not demand that you write according to my "manual of style" ,
> if you do not demand that i write according to yours .
The suggestion of the "max. 70 column rule" (others say 72 or 68)
is primarily because of quoting behaviour of mail clients. The
historical reason is the 80 column default terminal width inherited
from Mr. Hollerith. If you check the message archive of this mailing
list, as well as archives of other mailing lists, you'll see that
this rule is often followed.
Some mail clients are unable to automatically wrap text, so you'd
get long lines and have to manually deal with them while reading.
This might apply to mobile devices (which I'm not using for mail,
so I don't have a usable opinion here).
Another suggestion is to not top-post for obvious reasons.
Of course, those all are just suggestions, but they are there for
some reason, and usually make handling the lists (reading them,
replying to them) easier for all participants.
> 2] you'll find the relevant setting in
> the message compose configuration .
>
> hmmm ... , did you configure and compile from "ports" ?
> mine is the "package" from 9.3_amd64 [ 24.4.0 ] .
> there is --nothing-- , --any_where-- , regarding "wrap" .
Because Thunderbird became too slow and unconvenient for me,
I don't use it regularly, that's why I couldn't be more precise,
sorry.
However:
I did check google and... it seems that those settings actually
have been removed! So no wonder you couldn't find them anywhere.
Luckily, there are "hidden settings" that can be used; quote:
Removed Preferences
These depreciated or not frequently used preferences were
removed from the Options, but are still available as "hidden"
preferences through the Config Editor.
Display settings, Fonts dialog:
- "Apply default character encoding..." mailnews.force_charset_override
(defaults to false).
Composition settings:
- "For messages that contain 8-bit..." mail.strictly_mime
(defaults to false).
- "Wrap plain text messages at..." mailnews.wraplength
(defaults to 72).
Advanced settings:
- "Remember the last selected message" mailnews.remember_selected_message
(defaults to true).
- "Connection timeout" mailnews.tcptimeout (new default 100,
affects all protocols: IMAP/POP3/NNTP/SMTP).
Source: http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes#Removed_Preferences
So using the "Config Editor" is the key.
> i re_pose the question :
> does any_one know how to defeat this "feature" ?
There is an "Extension" as well to toggle word wrap:
https://addons.mozilla.org/de/thunderbird/addon/toggle-word-wrap/
Interesting aspect... basic functionality can only be used via external
dependencies... I bet this is what they call "modular" today. ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions
mailing list