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
      2·
      13 hours ago

      I would start with section 2.2.3: Joystick API deadzones and calibration, because the joystick API is the lowest common denominator for this stuff.

      Most games don’t use the Joystick API any more (/dev/input/js*), but rather the evdev API (dev/input/event*) which is dealt with further down on that page.

      I don’t even have the js devices on my system these days.

      • who@feddit.orgEnglish
        1·
        5 hours ago

        Most? I think you would need to measure that. A great many games rely on a library for joystick input. SDL, for example, which will use js devices depending on the circumstance. Some bypass both APIs in favour of raw HID protocol. And then there’s Steam Input.

        In practice, I’ve found that calibration at the joystick API level took care of dead zone problems in most of the software where I noticed them. Of course, one’s results will depend on the game, which is why I suggested calibrating jsapi to start with, rather than calibrating only it.

        Also, the evdev API’s calibration tools are not as well developed as those for the js API, making it harder to do. And its deadzone/flatness value did nothing at all to stick axis readings in my recent tests, suggesting that it wouldn’t fix stick drift anyway, unless a game deliberately applied the flatness before using the readings. (The fuzz value did affect the readings, but seems to be for smoothing out numeric noise, not fixing stick drift.)

        What distro do you use that doesn’t create /dev/input/js* devices?

        • tal@lemmy.todayEnglish
          1·
          5 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·
            4 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·
              3 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·
                    1 hour 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?