Arch Linux

Wowitscow

Member

Registered: 2025-06-28

Posts: 3

Keyboard locking up on FN key usage

I have a bit of an obscure keyboard that uses some odd windows only firmware (its called LDN i cant find much about it anywhere other than a help guide on github written almost exclusively in Chinese. here's the download if anyone's curious https://d-r.works/pages/daringrun-70f-software-guide). I've not had any trouble with it while setting up the keyboard in a windows 10 VM using USB pass through on virtualbox but when i shut down the VM and try to use the keyboard on Linux any time i try and access a function layer the keyboard crashes(freezes?) and has to be unplugged and plugged back in. The only thread I've found on this matter is in the Mint forum and there was no real fix found (https://forums.linuxmint.com/viewtopic.php?t=373521). I followed the advice and tried the FN key with xev open but it registers nothing. the key itself works fine, ive tried mapping multiple keys that all have worked to function and they all behave the same. wondering if anyone knew anything about this? I forgot to mention earlier but i just updated my entire machine so all my packages are up to date as of this post, and i've tried the keyboard on my pop!OS laptop and had the same result.

cryptearth

Member

Registered: 2024-02-03

Posts: 2,092

Re: Keyboard locking up on FN key usage

according to https://mekibo.com/pages/software (btw: your link is broken) the LDN is just a pcb (likely with a microcontroller) to be used with DYI or in OEM products
also this looks related: https://github.com/lswhome/C3_LDN_DRIVERS_Source_Code
guess the simplest options are:
- use windows
- don't use the Fn keys
- buy a cheap office keyboard like the Logitech K120 or similar cheap office keyboards from m$, hp or others ... I mean they cost 20bucks and you get them in pretty much any store that sells anything computer related

Wowitscow

Member

Registered: 2025-06-28

Posts: 3

Re: Keyboard locking up on FN key usage

Thanks for the github link, i hadn't seen that. welp guess im just not using my function layers unless i feel like porting the driver? maybe rebind the function key to something that i can have the computer intercept and fake a function layer that way? who knows. thank you either way.

Last edited by Wowitscow (2025-06-28 12:15:22)

cryptearth

Member

Registered: 2024-02-03

Posts: 2,092

Re: Keyboard locking up on FN key usage

well - don't give up that easy
as the device works it obviously uses at least some parts of the HID standard
the main question is: is the Fn handling done on the microcontroller which due to some bug hangs/crashes and no longer responds to the polls from the computer - or is the Fn just transmitted with a special keycode the driver listens for and the interpretation is done in the driver?
for the latter: why does this cause the issue? it could be the keyboards firmware waits for some acknowledge from the driver that the Fn is pressed, held and released - but doesn't handle the error properly not receiving any because the computer uses standard HID only
although in that case it would happen even on windows when the driver is not installed - unless windows does handle the Fn way different overall than Linux

so, you see - the issue isn't just as simple as "it stops working on use of Fn" but without help of its original designer it's likely hard to fix even with a public driver repo

hope you (or anyone) can get this working - good luck

Wowitscow

Member

Registered: 2025-06-28

Posts: 3

Re: Keyboard locking up on FN key usage

Yeah after some further experimenting the keyboard sends NOTHING when the function layer is triggered (either successfully on windows or unsuccessfully on linux) so i think it is truly hopeless without help from someone involved in making the thing. that is unless there's a lower level to monitor than /dev/input/event*. thanks either way

cryptearth

Member

Registered: 2024-02-03

Posts: 2,092

Re: Keyboard locking up on FN key usage

well - hooking up an oscilloscope or digital analyzer to the data pins of the usb connection aand what it replies
USB works by polling: the computer has to ask the keyboard: do you have anything for me? - and keyboard then usually replies with:
- no change
- key X pressed
- key X held
- key X released
- on more advanced stuff with several other reply codes
now it could be that pressing the Fn key generates not a regular HID key event bit some lower response the special driver listens for and if it gets triggered responding with some more stuff
but I don't know if either the linux kernel or the windows kernel for that matter allows such a deep dive that low-level from the os or if this is something hardware based one really needs physical hooking the cables

RocketSlug

Member

Registered: 2025-12-14

Posts: 2

Re: Keyboard locking up on FN key usage

Hi! I have the same problem with an LDN keyboard (A JRIS65 to be exact) and I thought this issue was going to plague me on Linux. But thanks to your GitHub link and some help with Gemini, I was able to diagnose and solve the problem!

Issue Summary: Keyboards using the LDN Chipset (VID 0x0483, PID 0x2020 for me, 0x8601 in the GitHub repo; use lsusb to find the right PID for your keyboard) freeze or lock up completely when the Fn key is used on Linux (and for me previously in BIOS). The device requires a physical replug to function again.

Technical Root Cause: This is a Firmware Defect related to blocking USB I/O. The keyboard acts as a composite USB device. Besides the standard keyboard and mouse interfaces, it exposes a Vendor-Specific Interface (Usage Page 0xFF, typically Interface 2) used for the Windows configuration software.

1. The Trigger: When the Fn key is pressed or released, the keyboard firmware attempts to send a status report (likely a "Layer Change" event) to the host via this Vendor-Specific Interface.

2. The Failure: On Windows, the proprietary driver (or HID subsystem) keeps this channel open. On Linux (and BIOS), no driver binds to this obscure interface, so the host does not read from it.

3. The Crash: The firmware appears to use a blocking write operation. When it attempts to send the status packet to an unread/full USB endpoint, the microcontroller pauses execution to wait for the host to accept the data. Since Linux ignores the endpoint, the host never accepts the data. The microcontroller enters an infinite wait loop (deadlock), halting all keyboard scanning and input processing.

The Solution: A user-space driver (daemon) is required to claim the specific Vendor Interface and continuously "drain" (read) the data packets. This keeps the USB buffer empty, preventing the firmware from blocking and crashing.

This was the script that I had running in the background in order to get it working. I'm working on turning this into a Systemd user service and/or finding if I can notify the people making the firmware

import hid
import time

#Determine the VID and PID of the LDN Keyboard via lsusb first
VID = 0x0483
PID = 0x2020
TARGET_INTERFACE = 2  # Confirmed by your diagnostic output

def open_interface_by_number(vid, pid, interface_num):
    """
    Finds the specific path for the target interface number.
    """
    devices = hid.enumerate(vid, pid)
    for d in devices:
        if d['interface_number'] == interface_num:
            return d['path']
    return None

try:
    print(f"Hunting for LDN Interface {TARGET_INTERFACE} (Usage Page 255)...")
    path = open_interface_by_number(VID, PID, TARGET_INTERFACE)

    if not path:
        print("Error: Could not find Interface 2. Is the keyboard connected?")
        exit(1)

    print(f"Found target at path: {path}")
    print("Opening device to drain buffer...")

    # Open the specific path to ensure we don't grab the typing interface
    h = hid.Device(path=path)

    # Non-blocking mode is safer for 'drain' scripts
    h.nonblocking = True

    print("Success! Background drain running. You can now use your Fn key.")
    print("(Press Ctrl+C to stop script and re-enable the freeze bug)")

    while True:
        # We read up to 65 bytes.
        # If the buffer is empty, this returns [] immediately (non-blocking).
        d = h.read(65)

        if d:
            # This print confirms the fix is working.
            # You should see this EXACTLY when you release the Fn key.
            print(f"Drained packet: {[hex(x) for x in d[:8]]}...")

        # Sleep to keep CPU usage near 0%
        time.sleep(0.05)

except Exception as e:
    print(f"Error: {e}")

And in case it's necessary, this was another diag script for confirming that the vendor-specific interface was on 2, and most likely usage page 255

import hid

#Use lsusb to determine the VID and PID of your own LDN keyboard
VID = 0x0483
PID = 0x2020

print(f"Enumerating devices with VID={hex(VID)} PID={hex(PID)}")
devices = hid.enumerate(VID, PID)

for i, d in enumerate(devices):
    print(f"--- Device {i} ---")
    print(f"Path: {d['path']}")
    print(f"Interface: {d['interface_number']}")
    print(f"Usage Page: {d.get('usage_page')}")
    print("-" * 20)

RocketSlug

Member

Registered: 2025-12-14

Posts: 2

Re: Keyboard locking up on FN key usage

Uploaded the fix onto GitHub
https://github.com/hanchenlu/ldn-keyboard-fix