Keyboard issues under Linux

[jibsaramnim]

The MiniBook X seems to have an issue with its keyboard, which seems to only (or mostly?) happen when running Linux.

This mostly seems to happen because the system seem to not catch that a button has been de-pressed, though my attempts to figure out where exactly this issue occurs have not yielded anything fruitful.

The issue, described

The two ways that I have seen this end up behaving is:

1.The system never receives the un-pressed event. When this happens, pressing the same key again will "unlock" it and actually send the un-pressed event. No actual "down" event is registered by the system when this happens, so if the letter "e" was stuck for example, the secondary press will not actually write "e". After this, the button will work as usual again.
2. The same as above, but this time the system thinks the button remains in the "down" position, so the system starts spitting out the key's action as quickly and often as it can. If this is the "e" key, for example, it would keep writing "eeeeee" as long as it can.

If you have your system configured to disable the trackpad while typing, you'll notice that the trackpad in both of these conditions becomes "unresponsive," but simply disabling that option in your system will avoid the problem. For this reason I don't think there's actually any technical issue with the trackpad, and it's just the keyboard.

Can you "un-stick" them?

In the first described scenario, simply pressing the same key again basically "un-sticks" it. In the second scenario, though, the only ways I have found to make it stop doing this is to either:

• Temporarily put the computer to (S2) sleep by closing the lid, or;
• unbinding and re-binding teh i8042 driver

The latter is obviously difficult to do without access to a working keyboard, but I was able to test this by SSH'ing into the MiniBook X and running the commands from there. Another way would be to ensure your user has password-less (sudo) write access to this section of the system, so you could consider adding a desktop/toolbar shortcut perhaps. If it helps, here's the commands that should do the trick, so long as you have write access of course:

echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind && echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind

Neither are (sustainable) solutions though, especially because the second scenario described above can be quite destructive depending on what you're doing. Not to mention it yanks you out of whatever you're doing, this is not something a productivity device should ever do, of course.

Is it a hardware issue?

I think we both first thought the issue might be an actual hardware design flaw. In my tests, by adding several layers of Kapton and Teflon (heat resistant) tape on and around the area where the Keyboard ribbon cable lays under the battery does seem to reduce the frequency with which this problem occurs, but it does not fully solve it. This might indicate that the issue is at least in part caused by electrical interference, which can be made worse when the battery (and rest of the device) heat up.

I actually never used Windows on this device (I wiped and installed Fedora on it the day it arrived), but have since gone back and re-installed Windows in a dual boot setup, just so I can try to spend some time in Windows to see if I can reproduce the problem. I have not yet had a lot of time with it since I have done that, but at least one afternoon of work on the MiniBook X running Windows I did not run into this issue at all.

This makes me wonder if whatever configuration is being used for the keyboard to communicate with the system under Windows is configured different enough for the issue to be (mostly?) avoided.

Some theories I have based on not much more than just me thinking out loud here:

• Could it be that the configured polling rate is different, possibly higher under Windows?
• Could it be that Windows has a different default assumption, where when it does not actively receive the "un-pressed" event but does not continuously receive "pressed" events either, it just assumes nothing is happening with that key?
• Or something else?

What have I tried?

• Modifying the hardware by adding Kapton and Teflon tape
• Tried most i8042 kernel parameters to see if these have any effect (e.g. i8042.noaux, i8042.noloop, i8042.notimeout, i8042.reset=1, i8042.direct, i8042.nopnp)

Neither have resolved the issue. Though as mentioned before, the former seems to have reduced how often the issue pops up.

---

To me this is the single biggest issue with the MiniBook X, making an otherwise incredible portable yet highly productive Linux device basically unusable. And that's really a shame, as this hardware (keyboard issue aside) positively shines when it runs Linux. Especially with the GNOME environment it looks gorgeous, and the in-screen camera almost perfectly blends in, too.

[kenya888]

@jibsaramnim Thank you for describing our issue:) I'd like to share my attempts.

About i8042 kernel parameter I use i8042.nomux=1 i8042.noloop=1 i8042.unlock=1 i8042.reset=1 Which of them (or combination of them) avoid the keyboard keeping pressed state. It is a little better state.

And I think that both pressed and de-pressed events cannot be caught by OS sometimes. Only de-pressed event brings issue. The pressed event issue can be easily recovered by pressing the another key.

[jibsaramnim]

About i8042 kernel parameter I use i8042.nomux=1 i8042.noloop=1 i8042.unlock=1 i8042.reset=1 Which of them (or combination of them) avoid the keyboard keeping pressed state. It is a little better state.

I noticed that you used those yes. I've tried them too, but am still getting the issue in the same way I get without these in place -- or if there is a difference, it's not something I can actively notice.

And I think that both pressed and de-pressed events cannot be caught by OS sometimes.

Ah yes, think you're right. That makes sense, also why the issue can expose itself in two different ways. Perhaps the first scenario I described is actually when the OS failed to notice a pressed event.

Either way, though, I wonder what exactly works differently in the Linux Kernel that might make this issue appear. I can't help but feel like it might be something like the keyboard's poll rate being too fast, or the OS's poll rate being too slow -- or both? I have been trying to look through i8042 related parts of the Kernel, and while I do spot some delays here and there, I can't be certain if that's even remotely connected to what might be causing/affecting this.

Even if those might be related, I know that adjusting those numbers wouldn't be the solution, but if we could only figure out where exactly this issue is coming from, we could try to communicate this back to Chuwi and see if they can supply a patched BIOS.

Edit: I tried adjusting those timeouts linked above (down to just 10ms, from 50ms), and I still ended up getting a stuck key after letting a game run for a bit to let the device warm up (It seems easier to get the issue to appear when the device is warmer, as you probably have also noticed already). Still no step closer.