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

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



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


Reply to: