testing a Model M

[N8N]

question: does xev in Ubuntu Linux properly recognize the "pause" key?  everything else tests out OK.  Was testing a keyboard that I had in my stash that some kids had been playing with and savaged the cord.  This was on my ex's computer until she gave it back to me (shortly prior to telling me that she was now my ex, but that's a different story) but I don't know if the "print screen/scroll lock/pause" keys were even working - in fact the key caps were on wrong, but I don't know if that was from me messing up when cleaning it or from the kids taking them off while playing with it.

Helpful hint: when a kid says "Uncle Nate, can I play with your spare keyboard?" that doesn't necessarily mean pretending to type on it.  It can also mean swinging it around by the cord and apparently gnawing on the PS/2 plug.  Sometimes you have to be *specific.*

But anyway, the cord on this one was always ugly (I actually bought it for the keycaps so I could fix up a different board, and they both ended up working great, or so I thought up until a few minutes ago) so the new cord makes it look downright spiffy now.  Just wish I still had my old 1391401 so I didn't actually need *tools* to replace the cord (and I liked the feel of that one better as well...) I wish I knew what happened to it.  It went *in* the truck... but never came back out.

[mich]

Normally xev should recognize pause, but n00buntu isn't anything I'd call a normal distro so YMMV
Probably the most reliable method to test this key is to press it during BIOS bootup and check if it pauses BIOS execution until you hit return.

Alternatively, if you have a PS/2-USB adapter:

Code: [Select]

root@saruman:/home/m # lsusb
... lots of stuff here ...
Bus 002 Device 002: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter
... and here ....
root@saruman:/home/m # tcpdump -ni usbmon002   <-- the 002 here is USB _bus_ numberThis will print all USB packets flowing on this bus, including those from the keyboard. If pressing pause doesn't generate any output in tcpdump, you might be reasonably sure the key is dead.

[N8N]

I think it's OK...  must be an artifact of the PS/2 to USB adapter I am using.  Tried every keyboard that I have and only the SIIG (which is a USB board) actually worked correctly.  All of the PS/2 boards worked the same way - when I tried it again, hitting the "pause" key on any of the PS/2 boards would cause scrolling output on xev of repeated presses of the pause key, only hitting another key would stop it.

It did nothing on booting, and your method of looking at the USB bus didn't work for me - not sure what I was doing wrong, but I just got an error when I tried tcpdump.  But since I got the same behavior on three different keyboards I am guessing that it's not the board that is at fault.

Now, I don't particularly have any problem with the pause key not being functional, since it's damn near useless anyway, but what's the current recommend for a "best" PS/2 to USB adapter?  I'm using a Ziotek adapter that I either got from clickykeyboards or Amazon (got my first one from CKB, then bought a couple more as an add-on to an Amazon order, as none of my current machines have a native PS/2 port - and even my new work computer's docking station now omits the PS/2 port.  Whiskey Tango Foxtrot?  I know USB is more "modern" but it's actually more limited as an interface to keyboards... (yes, I know that my Model M doesn't have NKRO, but what if I were using something that did?)

[theferenc]

While xev might or might not, the kernel definitely should.

Try this in a terminal:

Code: [Select]

tail -f /var/log/syslog
And push some keys. You should get something about atkbd.c, and then stuff.

Edit: I like the Belkin for my Model Ms, and people here tend to promote the blue cube adapter. The belkin is a much better form factor, though. You can find the belkin on Amazon.

[jpc]

@OP: Yes, ubuntu xev recognizes pause. I'm running Natty.

[N8N]

OK, then it's def. the ZioTek USB adapter.  Unless I got three bad keyboards somehow?  I don't have a box w/ a built in PS/2 port, sadly.

[sordna]

Normally xev should recognize pause, but n00buntu isn't anything I'd call a normal distro so YMMV
Probably the most reliable method to test this key is to press it during BIOS bootup and check if it pauses BIOS execution until you hit return.

Alternatively, if you have a PS/2-USB adapter:

Code: [Select]


root@saruman:/home/m # lsusb
... lots of stuff here ...
Bus 002 Device 002: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter
... and here ....
root@saruman:/home/m # tcpdump -ni usbmon002   <-- the 002 here is USB _bus_ number
This will print all USB packets flowing on this bus, including those from the keyboard. If pressing pause doesn't generate any output in tcpdump, you might be reasonably sure the key is dead.

 
Didn't know tcpdump could monitor USB, very nice, I just tried it.

I also tried the Pause button on my linux box, the Kinesis Advantage keyboard (usb) as well as the Kinesis Classic (ps/2 + bluecube) both register the Pause button in xev.
Only strange thing is that even if you hold Pause down, you still get a KeyRelease event. Pushing the button, immediately generates KeyPress and KeyRelease. Releasing the button didn't generate anything else.

Code: [Select]


KeyPress event, serial 35, synthetic NO, window 0x5e00001,
    root 0x15a, subw 0x0, time 172800049, (149,98), root:(1883,1088),
    state 0x0, keycode 127 (keysym 0xff13, Pause), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x5e00001,
    root 0x15a, subw 0x0, time 172800057, (149,98), root:(1883,1088),
    state 0x0, keycode 127 (keysym 0xff13, Pause), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False


[mich]

It's a quirk of the AT (and hence also PS/2) keyboard protocol. In AT keyboards, pause and break are "one-shot" keys - they only send a single make code and never repeat nor send a break code. Hosts treat this as a single, infinitely short keypress and don't wait for break codes for these keys.

Since there is no break code, your USB adapter can only accept this as a fact of life and emulate this legacy behavior.