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.
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.
