strange keyboard behaviour, is it faulty?

[rdmarsh]

Hey All,  Spent ages trying to solve this one and still no closer to getting it solved.

Bought PinebookPro, ansi keyboard at the end of 2019. This problem has been happening for ages. Due to covid etc I haven't gotten to looking at this for ages.

Would appreciate if anyone knows what's going on, or if the keyboard is faulty.


* On boot using an external keyboard everything is fine
* As soon as any key is pressed on the internal keyboard, it goes to uppercase and gets stuck there. Numbers only type the shifted items (!@#$% etc)
* Running showkey (https://linux.die.net/man/1/showkey) and pressing left shift once keeps saying that 'keycode 42 press', which is left shift key. It's not physically stuck though and pressing it shows press and release for it as well.


Pressing any other key stops the constant stream of 'keycode 42 press', but still behaves as if it's stuck.

Only a reboot fixes it and lets me type normally on the external kb again.

I've updated using jackhumbert firmware updater from github, tried this several times and still no joy. In desperation I tried the ISO keyboard version, that doesn't show the shift stuck behaviour. Going back to ansi and it reverts to the shift stuck behaviour.

Would really appreciate any tips on how to solve this, or even if it's possible.

[barray]

* On boot using an external keyboard everything is fine
* As soon as any key is pressed on the internal keyboard, it goes to uppercase and gets stuck there. Numbers only type the shifted items (!@#$% etc)
* Running showkey (https://linux.die.net/man/1/showkey) and pressing left shift once keeps saying that 'keycode 42 press', which is left shift key. It's not physically stuck though and pressing it shows press and release for it as well.


Pressing any other key stops the constant stream of 'keycode 42 press', but still behaves as if it's stuck.

Only a reboot fixes it and lets me type normally on the external kb again.

Sounds like it's not getting a "key up" event. Some reasons for this can be:

* Kernel is busy, key presses get dropped in buffer - this can't be the case as the other keys work.
* USB bus is dropping packets - again this can't be the case as the other keys work.
* Bridge across switch - unlikely given these style of keyboards usually don't have traces exposed.
* Key switch is broken - most likely as just one key is affected.

Regarding the last two points, the way a keyboard will typically work is that it'll poll the traces and check the return. A key press is registered when the poll (a small electrical pulse) gets through the circuit and keyboard chip reads it.

To save on the number of pins required on the kayboard chip, typically these traces will be shared. If it's unlikely more than say 5 keys will be pressed at the same time, you can use diodes to share pins by pulsing in different directions. If this process was broken I would expect more than one key to be broken.

So my suggestion:

* Be sure that ONLY one key is exhibiting this behaviour. If you find it's more than one key, check any pins connections for a short (it could be some water damage, stray copper thread or something). Make sure any exposed metal is properly insulated from anything it could conduct on.
* If you are sure, follow a guide online to lift the key cap and clean it. Laptop keys can quite easily break when being lifted, so bare that in mind when starting.
* If you still have no success, you'll probably be better served by replacing the keyboard.

[rcarroll215]

I am experiencing the exact same issue. The computer behaves as if the shift key is being pressed. The issue persists even if trying another distribution.  I have the ANSI keyboard variant.  I haven't been able to test it with an external keyboard yet. I will do that tomorrow and report back.

[rdmarsh]

I am experiencing the exact same issue. The computer behaves as if the shift key is being pressed. The issue persists even if trying another distribution.  I have the ANSI keyboard variant.  I haven't been able to test it with an external keyboard yet. I will do that tomorrow and report back.

Thanks, would be really interested to hear how it goes.

[barray]

Actually I saw something in IRC about flashing firmware to the trackpad... Just checked the Wiki: https://wiki.pine64.org/index.php/Pinebook_Pro#Trackpad

> Everyone with a Pinebook Pro produced in 2019 should update their keyboard and trackpad firmware.

So you should follow the instructions there. Probably some buggy firmware...

[rcarroll215]

I just finished flashing the keyboard and trackpad firmware, and the same behavior is there.  The built-in keyboard thinks the shift key is being pressed.  When I use an external keyboard everything works fine.  My gut says it is a hardware issue with the actual keyboard.  I went ahead and ordered a replacement keyboard so now I will have to wait until that arrives.  I love the laptop so far but I have to say I am disappointed that the QA issues appear to still be happening.

[rdmarsh]

Thanks for checking the external keyboard, this is the exact behaviour I've seen as well. Flashing the firmware hasn't helped.

I'm not sure where I saw it, but I think that the firmware for the keyboard is on the main board, not the keyboard itself. I'm worried that swapping the keyboard may not resolve the issue.

[barray]

It seems very strange that it would be the shift key for you both. That does sound like either a firmware issue or a hardware defect. Key defects tend to be more random... I suspect this is firmware. Really the greatest hint it's a firmware issue is that a reboot fixes it.

I'm looking at the latest keyboard firmware, make sure you flashed this one: https://github.com/jackhumbert/pinebook-...rd-updater

I was looking for the firmware to see if there was a quick hack I could implement to prevent it from sticking... Honestly, looking at some of the code, I wouldn't be surprised if it's a firmware issue: https://github.com/jackhumbert/pinebook-.../revised.c

I have absolutely no idea why they don't have access to the original source code, or why the community are the ones patching the factory's buggy binaries. The work they are doing is very good - but completely insane. If the factory are unwilling to fix their source code, they should release it.

Edit: Apparently the manufacturer went back on their word to open source the firmware, hence the hacky nature of it.

If they actually had the source code, there are some possibilities:

* There is some code-path where the shift key flag could be cleared but not sent to the main board. I guess this is unlikely as pressing the key again would clear the problem.
* The scanning of the key matrix is too long or too short.
* The key de-bounce is too long or too short.
* The firmware is carrying state incorrectly.

I would literally need to reverse engineer it myself (something I don't have time or resources for) in order to figure out what their patches even do and if it was the manufacturer or a code regression they introduced.

What a mess.

---

A hacky workaround might be to monitor for this scenario and use the reset_device() function to reset the keyboard: https://github.com/jackhumbert/pinebook-...ext.c#L119

Might even be able to bind it to shift+escape or something to reset the keyboard, so if your keyboard starts playing up you can just hit escape and it'll reset if shift is also being held down.

[rcarroll215]

barray, thanks for that info.  As rdmarsh and I have said, we both have tried flashing the keyboard firmware to no avail.  I'm keeping my fingers crossed that it's a hardware issue and the keyboard replacement fixes the problem.  This is very frustrating since the computer is more or less unusable at this point.  I opened a ticket with Pine64 yesterday and haven't heard anything yet.  I ordered the keyboard replacement a few days ago but I have no idea when/if it will ship.  The is very unfortunate.  I want to like this computer and Pine64... and I want to support what they are trying to do, but unless they can sort out these QA issues I don't think I can give them anymore money.

[Arwen]

Actually this issue may be a stuck line. It could be:

• On the main board, (where the keyboard controller chip resides)
  
• In the cable / connectors between the main board and keyboard
  
• In the keyboard
  

If I remember correctly, (can't do the research right now), shift keys tend to be on separate keyboard scan lines. This is so that they can modify other key's behavior.

Having a reboot fix the issue, (temporarily), is expected, as the kernel keyboard driver would keep the current status of the keyboard's shift key(s). So the reboot would clear the key.

In my opinion, it's not a firmware issue. In theory it could be over-come by making that key do nothing. Either by using <code>xmodmap</code> or firmware change, (harder). Of course, neither work around is desirable in the long run.