[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tip: [Solved] Correct password login fail when CAPS LOCK not on [SOLVED]

On Thu 21 Apr 2016 at 11:44:59 (-0400), Cindy-Sue Causey wrote:

[ ... much snipping ... ]

> My accidental discovery of this particular error fix is BECAUSE.... I
> personally next do the same, meaning drag my own Fingertips a split
> extra nano-second too long, when I'm then typing in the next *visually
> viewable* command (in tty1). For my personal #Debian use, that command
> is:
> startx.

There's a good reason *not* to put startx into your muscle memory:
it'll prevent your accidentally starting X as root. Just alias it to
something easy, like xxx. So, for example, I have it defined as a
bash function:

function xxx {
    local TIMESTAMP=$(date +%Y-%m-%d-%H-%M-%S)
    # normally we empty the file first...
    : >| "$HOME/.xsession-errors"
    # ... but write a marker to find each invocation when not emptied
    printf '%s\n' "zzzyyyxxx $HOSTNAME $TIMESTAMP" >> "$HOME/.xsession-errors"
    /usr/bin/X11/startx >> "$HOME/.xsession-errors" 2>&1 &

But that's a side-issue...

> What it's *most likely* about is something to do with the most
> default, universal of settings *potentially* defined at the top of the
> whole login process default order. If it's not consciously defined by
> developers as a default, then it's something innate within our
> systems.

Yes, the kernel AIUI sets the keyboard repeat rate to maximum.

> After we each actually enter our chosen desktop environments, that
> type of user definable custom setting is then found under something
> fairly universal like Applications > Settings > Mouse and Touchpad..
> *BUT*....those settings do NOT take effect until our individual users
> *successfully* sign in [...]
> Occasionally those password fails boil down to minute keyboard click
> drag... and [...] we have a tendency to drop down to the elementary level
> of one finger hunt-and-peck. Our keyboard clicks become a more
> meticulous poke-poke-poke that tends to eliminate the causative
> keyboard drag in the process.

A solution is to put a line:

@reboot /sbin/kbdrate -r 2 -d 1000

into /root/crontab and then type

# crontab /root/crontab

to activate it. When you next boot up, the keyboard repeat rate will
be dead slow. (Tune those numbers to taste.) X will be unaffected.
Note that it can take a second or two after the _first_ login prompt
appears before the new speed kicks in.

# crontab -l

will check that root's crontab file is activated.


Reply to: