Some keyboard keys not working

[oddsocks]

Until recently, my PBP was working absolutely fine. However when I turned it on the day, after some confusion I realized that some of the keys simply don't work. Quite a lot in fact. I'm using an external USB keyboard at the moment which does work. So far I've has no luck in diagnosing the problem or whether it's simply a hardware failure. The last thing I did before powering off was to do a full update on Manjaro but I find that hard to believe that would cause this, who knows.

Couple of points

1. I have the ANSI keyboard
2. I've tried booting archlinux from an SD card to check that it wasn't something in Manjaro. It exhibits the same behaviour
3. Tried re-flashing the keyboard firmware (only once) to see if something had gone awry there. No change
4. Popped the bottom of visually inspect the cables. As far as I can tell, everything looks connected properly

Is there anything I can do to confirm if it's a hardware, firmware or software issue? I'm I out of luck and the keyboard is toast?

Thanls.

[dsimic]

Based on the debugging steps you've already performed, I'd say that the keyboard is faulty.  Though, I might be wrong.

[KC9UDX]

Is there something in Linux that can report raw keycodes?

It's possible that a modifier might be stuck on. As in, if CTRL is stuck on, but there are other modifiers, sometimes ones that don't even have a key.

I'm pretty sure I've run something that can do this in Unix, but don't recall what it was. Possibly something that comes with X, so it may be present in Linux as well.

---

Also, an interrupt should be generated each time you press a key. If you can watch the interrupt counts in real time, that would tell you if you have keys that are dead in hardware. But again, I know how to do that in NetBSD, but specifically not in Linux.

[dsimic]

Good idea!  Under X, xev can be used to display keyboard events.

Edit: Actually, USB keyboards, such as the one in PineBook Pro, cannot generate interrupts.  Reading of the key press/release events is done entirely by polling.

[oddsocks]

Is there something in Linux that can report raw keycodes?

It's possible that a modifier might be stuck on.  As in, if CTRL is stuck on, but there are other modifiers, sometimes ones that don't even have a key.

I'm pretty sure I've run something that can do this in Unix, but don't recall what it was.  Possibly something that comes with X, so it may be present in Linux as well.

---

Also, an interrupt should be generated each time you press a key.  If you can watch the interrupt counts in real time, that would tell you if you have keys that are dead in hardware.  But again, I know how to do that in NetBSD, but specifically not in Linux.

That's a great idea! I think you're probably thinking of Xev, definately something worth looking at...

[oddsocks]

Based on the debugging steps you've already performed, I'd say that the keyboard is faulty.  Though, I might be wrong.

Yeah I suspected as much. I'm wondering if it's possible to actually disassemble the keyboard itself to access the membrane. It seems to me that the keyboard might be riveted together with plastic rivets so it might not be possible without damaging it anyway...

[oddsocks]

Good idea!  Under X, xev can be used to display keyboard events.

Edit: Actually, USB keyboards, such as the one in PineBook Pro, cannot generate interrupts.  Reading of the key press/release events is done entirely by polling.

Right, so you're saying a stuck key wouldn't affect any others if that's the case?

[dsimic]

Yeah I suspected as much. I'm wondering if it's possible to actually disassemble the keyboard itself to access the membrane. It seems to me that the keyboard might be riveted together with plastic rivets so it might not be possible without damaging it anyway...

I haven't disassembled or replaced the keyboard inside the PineBook Pro, but you're right, laptop keyboards are pretty much always made in a way that doesn't allow them to be opened and serviced.  There are two pictures of the back side of keyboard in the Pine64 store (ISO variant and ANSI variant), which seem to confirm your assumption.

Right, so you're saying a stuck key wouldn't affect any others if that's the case?

Regardless of the keyboard type (USB or PS/2), it should keep sending a "key press" event (i.e. a scancode) for a stuck key that is printable, which excludes "modifier" keys such as Ctrl and Alt.  Also, no "key release" scancode would be sent in that case, because a stuck key is never released.  In other words, xev should not report a stuck "modifier" key, and there should be no visible effects (except the inability to actually use the stuck "modifier" key), because the once-generated key press scancode would be consumed by U-Boot.  That's how the things should work, at least in theory, but it would need to be tested.

Could you, please, shut your PineBook Pro down, press and hold the Ctrl or Shift key, and then power on and boot the laptop?  Then, please let us now what happens while using the keyboard, and also please check what is reported by xev.

[KC9UDX]

xev does report all keys. You can find a stuck key by elimination. It'll be the one key that doesn't report properly.

The exception is the Fn key and combinations with it. Those are handled directly by the keyboard processor and don't necessarily report the way you'd expect at the operating system level.

[ab1jx]

I suspect we'd get better results if we standardize on which OS keyboard layout to use, since AFAIK there are only 2 internal keyboard types. Debian calls them one thing, Manjaro probably something different. But we're re-inventing the wheel with everybody trying different ones. I was using Manjaro's generic 105 key until I counted and found there are only 78 keys on my ANSI. Now a double quote key gets me @.

Network crapout but look at man pages for showkey, setxkbmap, XkbChangeMap, xkbcomp, localectl. We're walking on marbles. Everything can change.