I have a Model 01 bought in 2019. I have never changed the firmware.
It has worked perfectly with various distributions of Linux. It has worked perfectly with two different MacBooks. It works perfectly with a Windows 11 desktop and a Windows 10 laptop.
But… if I try to use Linux via Windows - e.g. a Linux VM on a Windows host, or even just an Android shell via ADB from a Windows machine - then it behaves weirdly: if I type quickly, some key presses seem to be missed, and frequently some get stuck. I press a key once and it just keeps repeating, as if I were holding it down.
I don’t see how it could be a hardware issue as the keyboard still works perfectly in other situations: I can open two PowerShell terminals on the same Windows machine, one local and the other connected to an Android device over ADB, and I get normal behaviour in the first and the broken behaviour in the other. Likewise, it works fine on the Windows host, but is broken in a Linux VM running on the same machine.
It also works fine with a machine running Linux natively. The problem only manifests when I use Linux/Android via a Windows machine.
This could be similar to the Remote Desktop problem, where multiple subsequent HID reports would get combined together into a single report, often resulting in things getting sent to the remote host out of order. In this case, I’m guessing reports get dropped entirely if they come in too fast. Have you tested this with a “normal” keyboard to see if you can reproduce the problem?
It would help to know what features you use. For example, home-row modifiers (Qukeys) frequently results in multiple reports being sent very rapidly. OneShot modifiers can also result in back-to-back reports, as can rollover involving keys with modifier flags. Does the problem occur with certain particular keys?
On the one hand, the first thing I would generally recommend is updating the firmware; the current version of Kaleidoscope has some major improvements. On the other hand, none of those changes would fix the problem if my guess is correct about the cause. On the gripping hand, it would be easier to help you out starting from an up-to-date firmware.
I have tested the same setup with an old “normal” Dell keyboard and had no problems. I’ve only seen this issue with my Model 01.
Regarding which features I use… maybe none? I just had to look up Qukeys and OneShot modifiers to find out what they are: I’m not using those. I literally just took the keyboard out of the box three years ago and plugged it in: I’ve never modified anything.
So I guess one thing for me to do is to learn how to upgrade the firmware.
However, I’d also love to learn what’s going wrong here: it’s such a weird problem. How would I go about debugging it? Is there some way I can log keyboard events (HID reports?) on Linux?
It certainly seems like some events are being missed. A missing “key down” event would explain why some key presses don’t seem to do anything, and a missing “key up” event would explain why some get stuck repeating.
But I don’t really understand why this would happen with the Model 01 and not with other keyboards.
My speculation is that it’s the time between events that matters. Does it happen with any particular keys? Curly braces, perhaps?
A normal keyboard only sends events (USB HID reports) when a key toggles on or off (this is not really how it works, but it’s close enough for our purposes), and so the rate at which those events get sent to the computer is limited to the speed that you can type. But with a “smart” keyboard like your Model01 running Kaleidoscope, it’s possible for a single physical key event to result in multiple HID reports, with as little as one millisecond between them. This can happen even with keys that don’t seem “special”, like the curly braces on the default Model01 layout. Those keys are actually sending shift + [ (or ]), so pressing one causes Kaleidoscope to send two reports: first, it adds shift and sends that, then it adds [ and sends a second report, 1 millisecond later. It does this because if it added both and sent just one report, some operating systems would treat the two new keycodes as arriving in the wrong order. That’s just one example of this, however; there are other “combo” keys, and lots of plugins that also cause very rapid “events” to be sent to the host. Rollover to or from a combo key can cause it, too.
What would be most helpful for tracking down exactly what’s causing your problem would be information about which keys are most often involved, either getting “stuck on” or dropped completely.
I just ran an experiment. I opened a PowerShell console and connected to an Android device (i.e. adb shell), then I pressed a single key roughly once per second. I pressed the ‘h’ key one hundred times.
Of the 100 key presses, 8 went missing (i.e. no letter ‘h’ appeared) and 10 got stuck (i.e. the letter ‘h’ just kept repeating until I hit another key). If each key press results in two events, i.e. one ‘key down’ and one ‘key up’, then 9% of them were lost.
I don’t think there were any combo keys, rollovers, or other plugins involved here. It was just the unmodified ‘h’ key, pressed at a slow rate of once per second.
However, I also discovered that I was wrong before. For comparison, I repeated the experiment in Notepad - i.e. just on the Windows host with no Android or Linux involved - and of the 100 key presses, 3 got stuck repeating. So it doesn’t only happen on Linux via Windows, it’s happening on Windows too, but perhaps less frequently.
I guess I didn’t notice before because it works fine on my other Windows machine, and I use this one primarily for Android and Linux work. Sorry for the red herring!
So perhaps it’s something about this machine that’s causing the problem? It’s a Dell XPS 17 laptop.
One thing of possible interest is that the laptop only has USB-C ports, so the Model 01 is connected via a USB-A to USB-C adaptor. I have tried two different adaptors (of two different makes, one Dell and one StarTech) and the problem appears in both cases. I have also tried using the same adaptors to connect the Model 01 to a different laptop via USB-C (a Lenovo Chromebook) and it worked fine then. So there’s nothing obviously wrong with the adaptors… and the Model 01 works via a USB-C adaptor with a different laptop… but I thought I’d better mention it just in case.
I definitely recommend updating the firmware to something newer. The easiest way to do this would be to install the current version of Chrysalis, and use it to flash its bundled version of Kaleidoscope. Then, if you still have the problem, we can do a better job of determining if it’s hardware, software, or the something in the chain of communication between devices.
Re: cables: it’s not likely to be a problem with an adapter, but just in case, the simplest thing to do is to use a USB-C to USB-C cable.
Well, I tried! I downloaded Chrysalis but cannot get it to work. When started, it lists my Model 01, but when I click on “Connect” it shows a “Reading data from device” animation for a few seconds then it returns to the first screen and says “Communication timeout”.
I’ve tried various cables and all the different USB ports on my machine, just in case, but always got the same result.
If so, installing these udev rules should help. Copy that file to /etc/udev/rules.d/, reload udev (sudo udevadm contol -R), reattach the keyboard, and that should do the trick.
Which version of Chrysalis did you try? 0.9.5 had an issue where it couldn’t connect on Windows. 0.9.4 and 0.10.0 should both work (though I’ve heard reports of 0.10 not working either, but have not been able to reproduce that yet).
I was trying 0.10.0 - downloaded today. I just gave 0.9.4 and 0.9.3 a go and had the same issue with both. (I also tried 0.9.5 but that failed even faster, as you suggested it might).
Is there any way I can capture a trace or log or something that would help to diagnose this?
The “Report a problem” screen should still work, and there you can create a debug bundle, with plenty of logs from the session. If that doesn’t work, you can open the developer console with Ctrl+Shift+I, click inside the logs, select all with Ctrl+A, and copy & paste it into a file. If you can DM me either the bundle, or the copy pasted logs, that could help with diagnosing the issue.
I have since wiped my laptop and installed Ubuntu Linux as the host operating system. I still have the same problems. So I am pretty sure that the problem is independent of operating system:
It happens when using Windows 10 directly
It happens when using Ubuntu Linux as a VM guest on a Windows 10 host
It happens when using Ubuntu Linux directly
I have also tried different keyboards with the same laptop and they work fine.
The problem seems to be specific to my Model 01 and the Dell XPS 17. (Though I’ve been wrong before )
I would update the title of this topic but I can’t see how to do that.
I have also created a new thread for my problems connecting to the Model 01 with Chrysalis to upgrade the firmware. I have the same problem with both Windows and macOS, using the latest version of Chrysalis (0.10.4).
)