I have a wired Xbox 360 controller [1.1] that has some drift in both analog sticks [1]. I would like to calibrate the deadzones [2] to fix this issue. How do you recommend doing this? I didn’t see any controller calibration option in the KDE Plasma controller settings [1].

References
  1. Type: Anecdote (Screenshot). Accessed: 2026-03-24T23:10Z. Location: “KDE System Settings”>“Game Controller”. Author: Meta

    • All input methods are at rest.
    1. Type: Text.

      Device type: Game Controller

      Xbox 360

  2. Type: Text. Publisher: [Type: Webpage. Title: “Understanding Controller Deadzones”. Publisher: “Elevation IT”. URI: https://www.elevationit.uk/understanding-controller-deadzones/.]. Accessed: 2026-03-24T23:20Z. Location: §“What is a Deadzone?”.>¶1.

    A deadzone is the small range of joystick movement that a controller or game ignores. It prevents unintended movement, such as stick drift, from affecting gameplay. […]

  • tal@lemmy.todayEnglish
    1·
    6 hours ago

    A great many games rely on a library for joystick input.

    Sure, but that doesn’t mean that they’re using the js API at the kernel level.

    SDL, for example, which will use js devices depending on the circumstance.

    Your own link points out that even SDL 1 — very old now — doesn’t use the js interface unless forced to do so.

    I’m running Debian trixie. IIRC in the past, for a while when the evdev interface showed up, a problem was that games that could talk to both interfaces would sometimes get double input, because a number would aggregate all input from all joysticks, and so if one had both the js and evdev interfaces visible, they’d see it as two joysticks both; a fix was to not expose them via the js API, rather than leaving them exposed via both. I don’t know how that’s evolved over time, but it may have been a factor encouraging not exposing them by default. I’ve certainly seen the “double input” behavior myself, maybe ten, fifteen years back.

    • who@feddit.orgEnglish
      1·
      5 hours ago

      SDL, for example, which will use js devices depending on the circumstance.

      Your own link points out that even SDL 1 — very old now — doesn’t use the js interface unless forced to do so.

      In other words, people with stick drift can calibrate it away using the js API, and have it applied to SDL 1 games by setting an environment variable.

      In any case, I don’t know why you’re campaigning so hard against my suggestion to start with the js API. It’s easier than calibrating evdev, it actually affects the generated stick values (unlike evdev), and there’s certainly no harm in starting with it. A more interesting pursuit would be determining whether any popular input libraries apply evdev’s deadzone/flatness value before passing stick readings to a game.

      I’m running Debian trixie.

      Debian Trixie does create js devices.

      IIRC in the past, for a while when the evdev interface showed up, a problem was that games that could talk to both interfaces would sometimes get double input, because a number would aggregate all input from all joysticks, and so if one had both the js and evdev interfaces visible, they’d see it as two joysticks both; a fix was to not expose them via the js API, rather than leaving them exposed via both. I don’t know how that’s evolved over time, but it may have been a factor encouraging not exposing them by default. I’ve certainly seen the “double input” behavior myself, maybe ten, fifteen years back.

      I’m looking at a Trixie system right now, and /dev/input/js0 appears just as expected. Is it possible that you modified your Debian installation way back then, to disable your js devices? Maybe you (or some package you installed) applied a udev rule to block them?

      • tal@lemmy.todayEnglish
        1·
        5 hours ago

        I’m looking at a Trixie system right now, and /dev/input/js0 appears just as expected. Is it possible that you modified your Debian installation way back then, to disable your js devices? Maybe you (or some package you installed) applied a udev rule to block them?

        Nope. Vanilla /etc/udev (well, okay, there are some unrelated changes for snapd and one to keep an JBOD enclosure form spinnign down drives). The joydev module isn’t even loaded.

            • who@feddit.orgEnglish
              1·
              3 hours ago

              That’s strange.

              To make sure I’m not hallucinating, I booted a Debian Trixie installer live image just now and plugged in a game controller. Sure enough, lsmod showed the joydev module loaded, and /dev/input/js0 appeared. Between that and the Trixie system I mentioned earlier, I think I’ve confirmed that js devices are still created by default.

              I wonder why your system doesn’t have them.

              Have you tested on a fresh boot, without starting any games or game-related software? I ask because it’s possible that the device node is being created, but something else on your system is removing it. Do you use the Dolphin emulator by any chance?