Skip Navigation

Posts
1
Comments
6
Joined
3 wk. ago

  • SDL3/Wayland branch merged to main, bins updated along with AUR packages. Works fine in KDE with some caveats (opacity doesn't work and I can't teleport your mouse cursor - these are Wayland limitations/security).

  • No worries about the downvote. evdev and uinput are kernel interfaces, they work the same on Wayland and X11. The display side has native Wayland support via wlr-layer-shell (Sway, Hyprland, KDE Plasma). Steam does the same thing I'm doing for gamepad input - reads /dev/input/event* directly via SDL, creates virtual devices via uinput for remapping. Same kernel interfaces, same udev rules.

  • Yeah, if it only handles the display side and relies on an accessibility framework like AT-SPI or IBus for input injection. That's how Onboard and GNOME's built-in keyboard work. But those frameworks need a cooperative desktop environment and don't work consistently across compositors.

    This tool needs raw device access because it does more than just display a keyboard:

    • Reads gamepad input directly from evdev (d-pad, sticks, buttons, triggers). Accessibility frameworks don't handle gamepad input, only keyboard/mouse.
    • Injects keyboard and mouse events via uinput. AT-SPI/IBus can inject keystrokes but not mouse movement or arbitrary key combos like Ctrl+Z.
    • Grabs the gamepad exclusively while visible so input doesn't bleed to the game. No framework exposes device grabbing.
    • Emulates a mouse cursor from analog stick input. Continuous analog-to-mouse translation isn't something accessibility buses are built for.

    TL;DRRaw evdev/uinput is what lets it work standalone on any compositor without depending on desktop-specific APIs. The trade-off is device permissions instead of accessibility bus access.

  • Doing so defies the Flatpak security model since the app needs raw evdev and uinput device access. Since Bazzite has a read-only root, you'll need to layer the runtime dependencies:

       
        
    rpm-ostree install SDL3 SDL3_ttf  
      
      

    Then reboot. The udev rule for uinput access goes in /etc which is writable on Bazzite:

       
        
    sudo cp gamepad-osk.udev /etc/udev/rules.d/80-gamepad-osk.rules  
    sudo udevadm control --reload-rules  
      
      

    After that you can build inside a distrobox and run it from ~/.local/bin. I think these will work to build the current branch, I'm not on Bazzite (Fedora):

       
        
    distrobox create --name build --image fedora:41  
    distrobox enter build  
    sudo dnf install golang SDL3-devel SDL3_ttf-devel libX11-devel wayland-devel  
    git clone -b sdl3-migration https://github.com/0x90shell/gamepad-osk.git  
    cd gamepad-osk  
    go build -o gamepad-osk .  
    cp gamepad-osk ~/.local/bin/  
    exit  
      
      

    Promptfont is optional (shows controller button icons on keys), but I recommend it. To install:

       
        
    wget https://github.com/Shinmera/promptfont/raw/main/promptfont.ttf  
    mkdir -p ~/.local/share/fonts  
    cp promptfont.ttf ~/.local/share/fonts/  
    fc-cache  
    
      
  • Nope. Just on my Arch systems (XFCE w/ X11) & Void Linux w/ X11. I am planning to run through some manual tests in KDE Plasma which should be applicable to Steam Deck and CatchyOS, but I need to build a proper test env. Ive done simple tests in Sway and KDE with nested sessions, but those are just spot checks not full testing. I need to boot into real systems for full testing.

  • Linux Gaming @lemmy.world

    Gamepad on-screen keyboard for Linux - looking for Wayland testers

    github.com /0x90shell/gamepad-osk