Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #166918 > unrolled thread

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

Back to article view | Back to linux.debian.user

Contents

  Tip: [Solved] Correct password login fail when CAPS LOCK not on Cindy-Sue Causey <butterflybytes@gmail.com> - 2016-04-21 17:50 +0200
    Re: Tip: [Solved] Correct password login fail when CAPS LOCK not on deloptes <deloptes@gmail.com> - 2016-04-21 20:40 +0200
    Re: Tip: [Solved] Correct password login fail when CAPS LOCK not on  [SOLVED] David Wright <deblis@lionunicorn.co.uk> - 2016-04-25 18:20 +0200
      Re: Tip: [Solved] Correct password login fail when CAPS LOCK not on  [SOLVED] <tomas@tuxteam.de> - 2016-04-25 20:30 +0200

#166918 — Tip: [Solved] Correct password login fail when CAPS LOCK not on

Hi, One of my most favoritest of Lists :)

This is me... trying to make a glass half full day out of having just
lost two large windows full of Internet travels via Chromium. In the
process of attempting to recover those windows, I chose to reboot a
time or two to clear things out. Being frustrated, I wasn't precise so
my Fingertip keyboariding was sloppy. That's when I hit a repeatedly
encountered error for which I've only just recently realized one
cause(y)....

The error I encountered was the one that I've seen lamented a few
times here on the list. It's about constant log on password fail when
we KNOW FOR FACT the caps lock key is NOT on and we KNOW FOR FACT the
password we're typing is EXACTLY WHAT IT SHOULD...

It turns out that the error SOMETIMES is about dragging our Fingertips
for a split extra nano-second when we don't realize we're doing so.
The reason we never discover that particular error is because our
password entries are hidden from sight by security design.

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.

Occasionally THAT command will additionally fail because I've just
typed in "staartx" or "starrtx" instead.... even though I actually did
NOT type that in on purpose.

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.

The setting that would potentially have an effect in this case MIGHT
be something like keyboard behavior affecting the single key
double-click time span. That type of setting affects our ability to
repeat a bunch of the same single characters rapidly and all at
once... or not.

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 to the desktop GUI k/t our chosen
passwords..... that occasionally inexplicably do not work regardless
of all the bazillions of helpful tips found everywhere across the
entire Internet....

Occasionally those password fails boil down to minute keyboard click
drag... and that's why the password then just as mysteriously and
suddenly begins to work again...

That sudden, mysterious success is occasionally because, under those
circumstances, 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.

Just thinking out loud... Wishing everyone out there a likewise glass
half full kind of day..

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs... in circles more often than she used to.. *

[toc] | [next] | [standalone]

#166919

Cindy-Sue Causey wrote:

> Hi, One of my most favoritest of Lists :)
> 
> This is me... trying to make a glass half full day out of having just
> lost two large windows full of Internet travels via Chromium. In the
> process of attempting to recover those windows, I chose to reboot a
> time or two to clear things out. Being frustrated, I wasn't precise so
> my Fingertip keyboariding was sloppy. That's when I hit a repeatedly
> encountered error for which I've only just recently realized one
> cause(y)....
> 
> The error I encountered was the one that I've seen lamented a few
> times here on the list. It's about constant log on password fail when
> we KNOW FOR FACT the caps lock key is NOT on and we KNOW FOR FACT the
> password we're typing is EXACTLY WHAT IT SHOULD...
> 
> It turns out that the error SOMETIMES is about dragging our Fingertips
> for a split extra nano-second when we don't realize we're doing so.
> The reason we never discover that particular error is because our
> password entries are hidden from sight by security design.
> 
> 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.
> 
> Occasionally THAT command will additionally fail because I've just
> typed in "staartx" or "starrtx" instead.... even though I actually did
> NOT type that in on purpose.
> 
> 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.
> 
> The setting that would potentially have an effect in this case MIGHT
> be something like keyboard behavior affecting the single key
> double-click time span. That type of setting affects our ability to
> repeat a bunch of the same single characters rapidly and all at
> once... or not.
> 
> 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 to the desktop GUI k/t our chosen
> passwords..... that occasionally inexplicably do not work regardless
> of all the bazillions of helpful tips found everywhere across the
> entire Internet....
> 
> Occasionally those password fails boil down to minute keyboard click
> drag... and that's why the password then just as mysteriously and
> suddenly begins to work again...
> 
> That sudden, mysterious success is occasionally because, under those
> circumstances, 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.
> 
> Just thinking out loud... Wishing everyone out there a likewise glass
> half full kind of day..
> 
> Cindy :)

Hi Cindy,
Get a fingerprint reader ;-)
You must still keep your finger for a second or two on the reader to
authenticate.

The problem above if not a human error could be also caused by somekind of
keyboard misbehave. I've experienced similar things when using external and
internal keyboard on notebook.

I'm sure you can configure the keyboard behavior also for the login screen,
but I did not understand what kind of desktop you are using and why would
you type startx is also not clear

Never mind - good luck

regards

https://wiki.debian.org/FingerForce
http://www.omgubuntu.co.uk/2013/03/how-to-get-your-fingerprint-reader-working-in-ubuntu

[toc] | [prev] | [next] | [standalone]

#167086 — 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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 25, 2016 at 11:11:38AM -0500, David Wright wrote:

[...]

> A solution is to put a line:
> 
> @reboot /sbin/kbdrate -r 2 -d 1000
> 
> into /root/crontab and then type
> 
> # crontab /root/crontab

A minor detail: I tend not to put system-wide things in a user's crontab,
but in the system-wide crontabs under /etc/cron.d. For example put (a
slightly modified version, see below) this line in a file /etc/cron.d/kbdrate.

The /etc/cron* tables have an additional field, which user they are
to be run under:

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

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlceYT0ACgkQBcgs9XrR2kZ4HwCdEE3zkgTQm+FWihlXJQR6AS6L
EA8An2SoIumD/fqmbFRkfD8OvAhKOjE6
=AGuo
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web