Description

This is a hardware-specific "hack" for SDL. If you use a Marson USB keyboard/mouse adaptor (aka USBLink) and the Enter key doesn't work properly in SDL applications running under X, this will fix the problem.

The patched code works by special-casing X11 key release events for the Enter key, and delaying them by a bit. If you use the console to run SDL 1 applications, or Wayland for SDL2, this won't help you.

Hardware

The specific hardware that has the Enter key problem for me is USB vendor ID 04b4, product ID 0101, "Marson Keyboard and Mouse Link Ver:ps2120L". It has a label on the front that says "USBLink", and on the back, the model number is "MT606-1". It looks like:

I'm not sure if any other USB keyboard adaptors are affected. The issue is caused by the adaptor reporting the Enter key-release event only 8 milliseconds after the keypress event, no matter how long your finger actually stays on the key. This causes SDL to see the key release before the application has seen the keypress. The result is that the Enter key only works about 1 out of every 3 times you press it, which is very annoying.

Patches

For SDL-1.2.15: sdl1-marson-hack.diff

For SDL2-2.0.20: sdl2-marson-hack.diff

These should apply with the regular patch command. If you're cd'ed into the top-level directory of the SDL-1.2.15 source, use patch -p1 (same holds true for the SDL2-2.0.20 source)

History

I bought this adaptor in 2003, so I could use an IBM Model M with a Mac. I noticed the Enter key problem, but assumed it was just Mac OSX weirdness. Later installed Linux on that Mac, and had the same problem. It didn't seem to matter what PS/2 keyboard was plugged into the adaptor... and it had the same problem on multiple computers, including the Mac and several PCs, including ones running FreeBSD and Windows.

I noticed that the applications that were dropping Enter keystrokes were all using SDL, but instead of spending time/effort trying to fix it in code, I "solved" the problem by buying another adaptor (which worked fine). The Marson adaptor went into a junk drawer, and got used occasionally when I had to spend time typing on a laptop at home. I always hoped some new Linux kernel would fix the issue, but it never happened.

Earlier this year (2025) I decided to set up a laptop on the enclosed back porch of my house, for reading e-books and maybe playing emulated Atari games. Found this old Marson USBLink adaptor and decided to try it again... same problem. Worked fine in terminals, browsers, text editors, but the Enter key only worked occasionally in MAME or the Atari800 emulator. But I got stubborn and decided to actually try to fix it this time, instead of caving and buying yet another adaptor.

On investigation, I found the problem. The Enter key (and only the Enter key) has some kind of special-case logic in the adaptor's firmware. Using "xset r" to set the repeat rate for the keyboard, or disable repeats altogether, doesn't affect the Enter key at all. With "xset -r" to disable key repeat, holding down Enter still produces repeats (though, the other keys don't repeat). Changing the repeat delay and speed doesn't affect the Enter key either.

Even worse: using "xev -event keyboard", I discovered that the timestamps between the Enter key press and release events were consistently 8 milliseconds apart. All the other keys, it's more like 80 to 100ms (depending on exactly how long I keep my finger on the key).

How It Works

The proper way to fix this would probably be in the kernel. I'm not really a kernel hacker, but I'm OK with C so I decided to patch the SDL libraries. The result seems to work well enough.

The reason SDL apps fail to respond to the Enter key with this adaptor is that they tend to all have an event loop that runs periodically, iterating over all the events (keyboard and otherwise) received from the X server. When the time between a key press and release event is so short, it's possible that both the press and release events come in during the same polling period. The SDL library delivers the events to the app just fine, but if the app sees the press and release during the same polling period, it won't do anything with the press after the poll is complete, because it's already seen the release. If that makes sense.

Im my patches, I delay the release events by 30ms. This number was chosen because the Atari800 emulator only checks the keyboard every 16.667ms (in NTSC mode; 20ms in PAL), because it's tied to the TV framerate of the emulated Atari. I wanted to make sure an entire emulated frame happens between the press and release.

I don't know the mame codebase that well, but it has the same issue, and using a 30ms delay fixes it, too.

If you look at the patches, you'll see they only change how X11 events are handled. If you use some other display (like the Linux console or Wayland), these patches won't do you any good. At some point I may at least fix it in the console, but I don't know anything about Wayland. If you do, the patches should at least give you a starting point for patching SDL2's Wayland driver.