All ARM Keyboards do not work on Ubuntu 18.04 #5631
Comments
|
hid_listen only opens the raw device to read input. i can also 'make the keyboard' work by cat'ting the raw device, in my case 'cat /dev/hidraw0' to start reading the raw device and then the keyboard starts working. at least for me the keyboard continues to work until disconnect, but others have reported it will stop working after a few minutes. update: so far this happens everytime with the instant60, but is inconsistent with the planck, sometimes the planck will start working after about 30 seconds. unclear why it works sometimes. |
|
Looks like Xorg is crashing and taking down the system with it https://gist.github.com/yanfali/a16bd5a7da633830962d127e81999caa I haven't done a headless test to see if this affects terminal. |
|
This was with a 5.0.7 kernel on Arch Linux, so it's pretty new. Xorg was 1.20.4 so fairly new. |
|
OK, I just tested this with just a tty and it works perfectly. This seems to be an xorg issue. They are crashing when they detect our keyboard firmware. |
|
https://bugs.freedesktop.org/show_bug.cgi?id=110453 issue filed with Xorg. Not sure what'll happen. |
|
thanks for the quick turnaround. if you need to me generate a dump from my ubuntu system i can do that, just let me know how to generate the coredump. |
|
It should be in the journald. I found it by using root and typing |
|
I have the same issue as mxgian on Gentoo Linux. My system: Hopefully that is enough information. |
|
@TellNoLies feel free to chime in on the bug I filed. |
|
@yanfali Should I paste the same info on the Bugzilla? |
|
@TellnlNoLies I think that would be helpful to have more than one user chime in, especially on different distros |
|
@yanfali how was that comment that I just left on the bug report? Will that info be helpful? |
|
Very nice |
|
Okay, thanks. |
|
I just booted up my laptop to test this. |
|
@drashna did it do the same for you on Ubuntu? |
I'm assuming you mean 18.04, specifically. I don't know. I've been using 18.10 for a while, since the ARM GCC binaries are broken on 18.04. However, I will swap drives out and test this in the next day or so. |
|
Installed 18.04. Can't reproduce. had system on for an hour, testing periodically. |
|
To date I've reproduced it on 18.04, 18.10, and 19.04, as well as on 3 different machines by 3 different manufacturers. However, X does not dump core for me, it just doesn't recognize the device: I think it may have to do with the order udev enumerates... it sees it as a mouse first and as a keyboard second.. |
|
Well, if you have mousekeys enabled, it does add a USB HID Mouse device, as well. |
|
I wonder if that's the problem. I'll disable mousekeys (it's part of the cannonkeys ortho60 default image, if it is in fact on) and see what happens. If it does, it's still a problem- just a different one. |
|
For me the keyboard is only recognized if I boot with it plugged in from the start. I'm on Ubuntu 18.04. |
|
@sfines, having the exact same issue on Arch Linux/Centos 6.5 with the Ortho60. Did disabling mouse keys fix the issue for you? With limited knowledge it looks like the following for me:
In my case the keyboard is trying to be initialized before the "mouse". The board used by the Ortho60 is the STM32F103C8. |
|
We're not going any response for xorg, you might want to go nag them as it's an xinput issue and it's not clear how to resolve it. |
|
Well you could try and do a debug build for xinput and then capture a coredump and see if you can find out where it's crashing. |
|
On Mon Jun 24, 2019 at 3:04 PM Yan-Fa Li wrote:
Well you could try and do a debug build for xinput and then capture a coredump and see if you can find out where it's crashing.
As mentioned by multiple comments. There are no issues with X for some
of the boards, that seems to only be happening for you. As far as it
looks most people have the issue where the board is simply not
responsive. At least until they run hid_listen or pull from the
correct fs /dev/hidraw<n>.
|
|
I think it's all related. There are no issues if you just run it from a tty. Only from X. I'm running on Arch which has a modern kernel and xinput. Ubuntu is ancient in comparison. |
|
I've had this issue as well, but the keyboard behaves exactly the same in a tty as it does in x. In both cases, no keypresses are registered until I run hid_listen as root, at which point it starts working and continues even after I kill hid_listen. This makes me think that it isn't an issue with X, but an issue with the USB drivers. I'm using a BluePill-based Ortho48 from Cannonkeys on Arch Linux (technically AntergOS, which is now dead, but it's Arch for all intents and purposes). My My boot log, grepped for usb (`journalctl -b | grep usb) is located here: https://gist.github.com/evamvid/88f54b35faa04ca2aa53206e6299ed59 I think this might give some more insight into what the issue is. The keyboard is located on usb 1-1.2. For some reason it repeatedly "rejects the address" assigned by the computer, causing read errors. Hopefully this is somewhat helpful! Also, is it worth opening a separate issue for the STM boards? I don't have the original issue with crashing xorg. It seems like the STM boards might have a separate issue, because they don't seem to work in tty either. |
|
So I've been trying to figure out what's going on. I have 1 linux box that crashes, it has Sandy Bridge hardware and it's a laptop. I have one desktop running a server based chipset and it does not crash and it's running exactly the same version of xorg 1.20.5. Still haven't figured out what is the difference. Can people chime in on what hardware they running linux on? Specifically intel chipset would be interesting to know. I thought it might be a XHCI (USB3) vs EHCI (USB2) but I was unable to make it crash with that change. I've also disabled NKRO, SHARED_EP and MOUSE and it still crashes the problematic laptop. |
|
OK folks, I just confirmed that after linux kernel 5.2.9 the problem is gone. I don't know what they fixed but it was still broken around 5.2.5, so in between those two releases something got fixed in the kernel. It's working for me now. I think it's just a kernel issue. |
|
#6801 (review) please test this patch if you having Linux issues |
|
Tested the patch, and it does not fix the linux issue. The patch actually would have made no difference with my config settings (mouse buttons disabled, raw hid disabled, audio disabled, console enabled.) With only console enabled, the outcome of HID ordering is the same before and after the patch is applied. I'm actually fairly confident that the problem has to do with the I've also found that, at least on my system, if I have the console enabled, the keyboard will work on linux if I treat it like a PS/2 keyboard: keep the keyboard plugged in on boot. Once replugged or restarted, the keyboard will become unresponsive until next boot. Sometimes the keyboard will get into a funky "frozen" state during bootup, which would require me to restart the keyboard and then restart my system, but the instances that that had happened were pretty rare (meaning, I couldn't replicate the freezing behavior.) iirc, my home desktop is running Pop OS 19.04 with kernel 5.0.0 |
|
@krnhotwings do you have any QMK keyboards that are AVR based with console turned on? Would like an a/b comparison. It looks like something chibios is doing is causing linux to puke for console output. |
|
Yup, I have a Tada68 (atmega32u4). Console enabled, keyboard works fine. Keyboard still works when replugged. I added debug print statements to |
|
thanks for that @krnhotwings - disabling console also fixed a similar issue with my alice pcb |
|
Just want to add my experience to this issue. I had been using a Proton C on Ubuntu 18.04 (kernel 4.15.0) for some time now with no issues. CONSOLE_ENABLE had been set to yes in rules.mk at least as far back as Oct 31 of this year. Soon after I added the uprintf statement to process_record_user from testing and debugging docs a few days ago, I noticed the keyboard became intermittently spammy or unresponsive unless hid_listen was running as root. As soon as I commented out the uprintf, but with CONSOLE_ENABLE still set to yes, the issue went away. quick edit: actually it does appear to become unresponsive after a time, so I've set CONSOLE_ENABLE to no to see if that helps. |
|
I just ran into this issue myself. The culprit is The root cause is that the QMK ChibiOS USB driver does not drain the debug message queue until the hidraw device is opened, e.g. by running You can clearly see this when attaching the Now, what’s the most elegant way to fix this? I don’t know yet :) Looking at this now. |
Before this commit, attaching an ARM-based (i.e. ChibiOS-based) keyboard that uses CONSOLE_ENABLE = yes and produces debug messages would deadlock the keyboard unless one was running hid_listen. With this commit, dead-locking writes to the queue are detected and prevented. fixes qmk#5631
Before this commit, attaching an ARM-based (i.e. ChibiOS-based) keyboard that uses CONSOLE_ENABLE = yes and produces debug messages would deadlock the keyboard unless one was running hid_listen. With this commit, dead-locking writes to the queue are detected and prevented. fixes #5631
|
Hello everyone, please review my improved fix for this issue here: |
On Ubuntu 18.04, ARM powered keyboards are not recognized by default.
The OS sees the device, but no input shows up until you run hid_listen, eventually hid_listen picks up the device and then you can start typing.
The keyboard will intermittently stop working, and you will have to run hid_listen again to get it to work.
@mxgian reproduced this issue with a Planck rev 6, Instant60, and Ortho60 board. So it's not just limited to f303, but is also present on f103 and f072.
The text was updated successfully, but these errors were encountered: