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. […]

  • Psythik@lemmy.worldEnglish
    1·
    3 小时前

    What I usually do is increase deadzone until joystick no longer registers inputs while centered. And then move them around a bit and check to make sure that they return to 0,0 when let go of every time.

  • mrbigmouth502@piefed.zipEnglish
    1·
    9 小时前

    Since you haven’t mentioned it, are there any specific games you’re running into issues with? If so, are these Steam/Proton games, Wine games, native titles, or emulated games?

  • tal@lemmy.todayEnglish
    2·
    13 小时前

    How do you calibrate controller deadzones?

    Personally, I went with the hardware fix route for dealing with stick drift rather than the software approach of aiming to filter it out, and got a controller with Hall effect thumbsticks.

    • tal@lemmy.todayEnglish
      2·
      13 小时前

      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 小时前

        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 小时前

          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 小时前

            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 小时前

              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.

  • Silverchase@sh.itjust.worksEnglish
    4·
    23 小时前

    For Steam games (and non-Steam games launched through Steam), you can use Steam’s controller settings to expand the dead zones. Not the most universal solution, though.

    • Kalcifer@sh.itjust.worksOPEnglish
      3·
      15 小时前

      […] you can use Steam’s controller settings to expand the dead zones. […]

      I tried this, but I can’t get it to work: to use steam’s deadzone control, I need to enable Steam Input [2], but when I do that, my controller no longer works in games [1].

      References
      1. Type: Anecdote.
      2. Type: Post. Title: “PSA: Valve added deadzones to every Steam Input controller with a Client update and it’s messing up racing/fps games. Here’s how to fix.”. Author: “ManlySyrup”. Published: 2024-05-18T20:15:35.382Z. Accessed: 2026-03-25T00:31Z. URI: https://www.reddit.com/r/Steam/comments/1cv67af/psa_valve_added_deadzones_to_every_steam_input/. Publisher: [“r/Steam”<“Reddit”].
      • tal@lemmy.todayEnglish
        1·
        13 小时前

        There are few Steam games I’ve seen that do use gamepads but don’t support Steam Input. Not saying that they don’t exist, but I’d be kind of inclined to suggest playing around with the global Steam Input settings if your gamepad isn’t working with any titles via Steam Input.