[conspire] (forw) Testing New Keyboard
Rick Moen
rick at linuxmafia.com
Fri Jun 26 22:46:57 PDT 2015
----- Forwarded message from "Robert S. Johnstone" <rsjohnst at idiom.com> -----
Date: Fri, 26 Jun 2015 15:47:20 -0700 (PDT)
From: "Robert S. Johnstone" <rsjohnst at idiom.com>
To: danagoyette at gmail.com, rick at linuxmafia.com
Subject: Testing New Keyboard
Hello Rick and Dana,
Thanks for your explanations and suggestions.
The present email summarizes the testing I have done in attempting
to replace the keyboard on my computer running Ubuntu Linux v9.10 .
The new keyboard is Logitech k120, which is supposed to be
plug-and-play with Linux kernel 2.6 or later. The kernel version
on my computer appears to be 2.6.31-14, so the new Logitech
keyboard should work.
Thus far the new keyboard does not appear to be detected during
the boot process or later, which suggests a defective keyboard.
However, in May, the service department at Fry's tested the new
keyboard and said it worked OK. Presumably on a computer running
Microsoft Windows. I did not pursue with them the question of
why it might not work with Linux.
I have only one computer running Linux.
I would like to bring the keyboard to the Installfest on 27 June
and see if it works or fails on another (presumably well-managed)
Linux system.
Bob Johnstone
326-0424
------------------------------------------
0. TEST USB CABLE between port on computer
and port on video monitor.
Plug external Seagate backup disk into USB port on monitor
with computer power OFF.
Turn computer power ON. Lights flash on disk.
Device is detected, identified, and mounted correctly.
Cable is OK.
Shutdown. Power off.
--------------------------------
1. TEST NEW KEYBOARD (Logitech).
This sequence was suggested by Dana Goyette.
Dana's email is included at the end of Rick Moen's
thorough discussion of the boot process, attached below.
( Saved on my computer as: rick_aa.eml )
Boot with old KB (Keytronic), new KB unplugged.
Login, open terminal window.
dmesg > dmesg_oldkb.txt
Plug in new KB (Logitech).
dmesg > dmesg_newkb.txt
sgt_$> ls -lrt dmesg_*
-rw-r--r-- 1 rsj rsj 34313 2015-06-24 11:14 dmesg_oldkb.txt
-rw-r--r-- 1 rsj rsj 34313 2015-06-24 11:19 dmesg_newkb.txt
sgt_$> tail -5 dmesg_oldkb.txt
[ 18.164118] agpgart-intel 0000:00:00.0: putting AGP V2 device
into 4x mode
[ 18.164140] pci 0000:01:00.0: putting AGP V2 device
into 4x mode
[ 18.410476] [drm] Setting GART location based on new memory map
[ 18.410488] [drm] Loading R100 Microcode
[ 18.410543] [drm] writeback test succeeded in 1 usec
sgt_$> tail -5 dmesg_newkb.txt
[ 18.164118] agpgart-intel 0000:00:00.0: putting AGP V2 device
into 4x mode
[ 18.164140] pci 0000:01:00.0: putting AGP V2 device
into 4x mode
[ 18.410476] [drm] Setting GART location based on new memory map
[ 18.410488] [drm] Loading R100 Microcode
[ 18.410543] [drm] writeback test succeeded in 1 usecs
CONCLUSION: No new information has been added
to the dmesg file after boot.
sgt_$> grep Key dmesg_* % No output
sgt_$> grep key dmesg_*
dmesg_newkb.txt:[ 1.046390] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input3
dmesg_oldkb.txt:[ 1.046390] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input3
CONCLUSION: Word 'Keytronic' or 'keytronic' does not appear. (old KB).
CONCLUSION: Keyboards are not referred to by brand bame,
sgt_$> grep logit dmesg_*
dmesg_newkb.txt:[ 7.622435] logips2pp: Detected unknown logitech mouse
model 89
dmesg_oldkb.txt:[ 7.622435] logips2pp: Detected unknown logitech mouse
model 89
sgt_$> grep Logi dmesg_*
dmesg_newkb.txt:[ 8.112176] input: ImExPS/2 Logitech Explorer Mouse as
/devices/platform/i8042/serio1/input/input4
dmesg_oldkb.txt:[ 8.112176] input: ImExPS/2 Logitech Explorer Mouse as
/devices/platform/i8042/serio1/input/input4
CONCLUSION: The new Logitech keyboard has not been detected.
IMPLICATION: ?? Devices hot-plugged after boot do not appear
in dmesg output ?? Should they appear ??
OR
?? New Logitech keyboard produces no output ??
------------------------------------------
2. OTHER TESTS OF NEW KEYBOARD (Logitech).
Variations on Dana Goyette's suggested procedure.
2a. Hot-plug new KB before login, after boot with old KB.
2b. Plug in new KB before power ON.
Both old and new KBs present throughout boot.
Neither of these sequences produced changes
in subsequent output from dmesg after login.
CONCLUSION: ?? New KB produces no output. ??
>-------------------------------------------------
>---------- On May 31 Rick Moen wrote ------------
>-------------------------------------------------
>From rick at linuxmafia.com Sun May 31 09:38:21 2015
Date: Sun, 31 May 2015 09:38:11 -0700
From: Rick Moen <rick at linuxmafia.com>
To: "Robert S. Johnstone" <rsjohnst at idiom.com>
Subject: (forw) Re: [conspire] (forw) How do I install a new keyboard?
Please see Dana's point, below.
I hadn't until this moment had a look through your keyboard problem.
This will seem perhaps a bit like a complaint, Robert, but, when I first
received your mail, I got 2/3 of the way through it before I had any
specific idea what problem you were seeking to solve. Even then, I was
not _sure_ what problem you were trying to solve.
Near as I can tell, you installed Ubuntu 9.10 in 2010, and, at that
time, 'some keys do not always work'. I'm guessing that this is _not_
the problem you're currently asking about. The phrase 'not _always_
work' (emphasis added) implies that they sometimes work, which sounds
more like a hardware problem (defective keyboard) than a software one,
for whatever it's worth. Basically, keypresses on a keyboard generate
scancodes at the hardware level. The OS's keyboard driver uses its
internal list of scancodes (a 'keyboard map') to decide what your
keystroke means, and registers the meaning accordingly.
%{
RSJ RESPONSE_1
Yes, Ubuntu v9.10 was installed in September 2010.
The old (Keytronic) keyboard has been in service since ca June 2002.
Inconsistent behavior of the old KB first became noticable
'recently' == ca December 2014; i.e, about six months ago.
%}
I'm gathering that your problem is that the newly acquired Logitech
keyboard doesn't 'work' in various ways. (As an aside, I really wish
the English phrase 'doesn't work' were taken out and shot, because the
specific meaning is unclear when people use it.)
> With the new keyboard a text screen appears briefly during boot.
> The only line I can read says "keyboard error"
%{
RSJ RESPONSE_2
Cannot log in with new KB. Keystrokes do not register.
Key combinations which sometimes fail with old KB:
ctrl-PgUp, ctrl-PgDn, ctrl-alt-Delete, ctrl-r
Chief suspect is ctrl key.
%}
Well, seems to me like a defective keyboard. This has nothing really to
do with the operating system. Except for some weird edge cases,
changing out one keyboard for another should have no effect at an OS
driver level. The weird edge cases involve switching out, say, a
conventional 103-key keyboard for a 105-key one with several special
keys emitting unaccustomed scancodes, such that you need a different
keyboard map. But even in that edge case, all 103 of the regular keys
should work fine, and the raw symptom might be that the two extra keys
(only) produce no screen output or wrong screen output.
One additional suggestion: Every normal computer has a set of hardware
setup routines in the motherboard's firmware, usually called the BIOS
Setup routines. You can visit those programs by holding down some
'magic' key during machine startup, like F8 or Delete or something like
that. (Naturally, if the keyboard is defective, that 'magic' key may
not register.) If you can get the motherboard to register your pressing
the 'magic' key, you can then enter BIOS Setup, and there find some
fill-in field or other (maybe entering the time, or an administrative
password), and use that to test correct keyboard functionality without
relying on an operating system.
It is also sometimes very handy to have old, lesser-used computers
around the house for testing, and to keep computer parts for the same
purpose. E.g., I have some old computers that I could use to test a
suspect keyboard by plugging the keyboard into the known-good computer's
USB port. If a keyboard fails to work on a known-good spare computer in
addition to the main computer it's intended to be used on, then there is
even more excellent reason to think the problem is the keyboard.
In this case, I am quite confident that the problem is your keyboard,
but cross-testing that keyboard on a second computer could test that
theory and eliminate the small possibility of problems on the rest of
your system being involved.
Your questions:
> In installation step 4 above, does pressing Quit immediately cause the
> selections made in steps 1, 2, and 3 to be ignored? i.e., Are no
> specified data saved until after the disk is reformatted?
I would discourage you from re-running the Ubuntu installation CD's
installation program, as you are almost certain, if you proceed too far
into it, to blow away your system and do a fresh installation, which is
not at all what you want to do. The installation CD is not intended to
be used for adjusting your system.
Yes, your suspicion is correct that choosing Quit during the installer
causes your selections up to that point to be discarded.
> How can I pause the boot process so that I can read the entire
> keyboard error message that appears only briefly on a text screen?
Well, that's indeed the trick, isn't it? ;->
The process of booting divides neatly into two major phases, and then
the second phase can also be broken down into conceptual steps. The
first phase is pre-OS, and is the hardware's self-initialisation. In PC
jargon, this phase is called Power-On Self Test, or POST. Major
hardware subsystems such as your video, keyboard, RAM, network
interfaces, and hard drives are fired up and checked, with hardware
status shown on-screen. At the end of POST, the BIOS startup
routines check each bootable device (such as your hard drive) in a
specific order to find one that has a program that claims to be
bootable, and transfers control of the PC to whatever program is found
there. That might, for example, be the GRUB bootloader, which in turn
finds a binary image of the Linux kernel, an inital RAMdisk (initrd)
image, and a root filesystem. Then, GRUB transfers control of the PC to
the kernel, which mounts the initrd, loads drivers from the initrd,
unmounts the initrd, and mounts the root filesystem, then run the init
process on the root filesystem. The init process now has control and
starts various other services.
Typically, there is no ability to pause the POST phase.
Typically, bootloaders such as GRUB _do_ have the ability to pause
progress, and there is typically a brief display of what keystroke to
use to pause progress. (Of course, if you have keyboard problems, the
keystroke may not register.)
Typically, there is no provision for pausing kernel initialisation,
initrd usage, and mounting of the root filesystem. However, you can, if
there is a good compelling reason such as repair of a damaged filesystem
(rare, unlikely to arise for you) specify in the bootloader (GRUB, etc.)
screens something non-default for the kernel, initrd, root filesystem,
and related instructions, such that you deliberately do an abbreviated
form of a startup, to, say, boot into single-user maintenance mode,
instead of the normal startup of all ordinary services. I'm not going
to cover this in detail. The point is to give you a tourist-level view
of what is possible, as a general answer to the question you posed.
Last, during startup of the ordinary OS services, there is often
onscreen display of a keystroke you can make to intervene and avoid
starting particular services. (Again, a defective keyboard might well
prevent registration of that keystroke.)
> What device-specific files are needed for the new keyboard?
In the general case, none. Changing out one QWERTY keyboard for another
typically has no OS consequences at all. If you were to choose some
very eccentric keyboard with a very different set of scancodes, there
might, I guess, be problems, but I've never seen that.
> Are they actually present in the kernel?
Yes.
> How can I enable the scrolling display of boot and shutdown
> progress? (Was present Ubuntu v6.06, is absent in v9.10).
Their hiding of the progress messages is super-annoying, isn't it? I
think it's outright evil, and shoots users in the foot. Here:
http://askubuntu.com/questions/248/how-can-i-show-or-hide-boot-messages-when-ubuntu-starts
To see shutdown messages, you need to first go to the _real_ (first) console
screen before shutdown. Press Ctrl-Alt-F1 to go to the first console.
At that screen, you just press Ctrl-Alt-Delete to initiate a
software-controlled reboot. (No, Ctrl-Alt-Delete does NOT shoot the OS
in the head and hardware-reboot the machine instantly: Instead, the OS
intercepts the keystroke and does a software-controlled shutdown at the
end of which it does a hardware restart.) If your aim is to power down
your machine rather than a fresh boot, just turn off the power after the
hardware restart and before the kernel loads again.
> I cannot attend the Linux CABAL InstallFest in June
Please note: I have just now changed (updated) the schedule to move the
June CABAL meeting from June 13th (2nd Saturday) to June 27th (4th
Saturday), because my wife and I will be out of the country on June
13th. Perhaps you can attend on the 27th.
Or, better yet, you can maybe solve your problem by returning the
keyboard for one that's not (almost certainly) defective. But, if you
do happen to have a second PC around, do cross-check the Logitech on
that.
----- Forwarded message from Dana Goyette <danagoyette at gmail.com> -----
Date: Fri, 29 May 2015 15:22:24 -0700
From: Dana Goyette <danagoyette at gmail.com>
To: conspire at linuxmafia.com
Subject: Re: [conspire] (forw) How do I install a new keyboard?
On 5/29/2015 2:42 PM, Tony Godshall wrote:
> Wow.
>
> How about plug in a new USB keyboard and see if
> it works? I guess not everyone knows how hot-
> pluggable USB peripherals are?
To be fair, the keyboard might be defective, which would explain the
keyboard error at boot.
Here's something to try:
1. boot with only the working keyboard
2. plug in the new keyboard without unplugging the old one
3. use the old one to run 'dmesg' and look for any errors near the end.
_______________________________________________
conspire mailing list
conspire at linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
----- End forwarded message -----
More information about the conspire
mailing list