The situation is very simple. If I press a key and release, then the key is stuck forever, no matter what I do, including the reboot. If the last key I pressed is “a”, then everywhere I click, it is filled with “a” in a no time if that area is permitted to be written. The only way to un-stick this key is to press other key. And before you ask, no, this is not a hardware issue.
I use KDE Manjaro, with 5.10.151-1 LTS kernel and up-to-date version of packages.
I am currently writing this with “System Settings - Input Devices - Keyboard - when a key is held: Do nothing” option turned on, but this does not prevent my ctrl key to be held down indefinitely, making the scrolling impossible because it will zoom instead.
I don’t even know how this happened, but I only assume that this started to happen right after I gave the matplotlib buggy command (to make it process r"$\rmerg$") by accident, so that is all that I could assume.
How do I fix this? This is my workstation and I cannot do anything at this state. I hope there is a solution, but any possible workarounds are welcome given the extremely dire situation.
How could this be a hardware issue if I attach the same keyboard to other PC it works fine?
I am not an expert in linux, but I strongly believe what happened is some of the drivers gone corrupt because of my buggy command in the python session.
I’m not saying it’s the keyboard itself. It could be a motherboard issue, or an issue with the USB (or PS/2) port.
What you’re saying here is technically impossible. The input driver framework runs in the kernel, which has its own memory address space and runs completely isolated from the rest of the system, in the processor’s highest-privilege mode.
Userspace software such as python runs in individual and separate address spaces and in the processor’s low-privilege mode. That code and data never even see one another, let alone influence each other.
OK, now I understand what you mean. I’ll try to perhaps reboot with other OS to see if this persists.
I am not sure. What you say should be correct in theory, but in a world where a simple C code with some scanf function can be used as a security vulnerability…Anyways, I assumed that because this started immediately after I issued a buggy command to python, but it might be just a coincidence.
