How to disable Deadzones? about oversteer HOT 21 CLOSED

Oversteer doesn't change the input values, it just renders them visually. There are two possibilities: the values displayed are wrong or the display is right and there's something wrong in your system.

But why jstest-gtk displays the values correctly? jstest-gtk uses joydev (deprecated joystick driver) while Oversteer uses evdev (modern driver).

Oversteer doesn't allow changing some settings like the deadzone and calibration values, basically because default values seem to be right for everyone. You could try to fix it using the evdev-joystick command.

The command to set the deadzone to zero for all axes would be something like:

evdev-joystick --d 0 --e /dev/input/by-id/usb-Logitech_G29_Driving_Force_Racing_Wheel-event-joystick

Check the command help for more info.

Please, try and report back the results.

from oversteer.

Thanks for your help. Setting the Deadzones with this command to zero did help for the steering wheel itself, but unfortunately it didn't do anything for the pedals.

Maybe I'm interpreting that wrong. When I start moving an axis just a little bit, your program is showing a static blue block with a red frame. Should that really tell me that this active axis is still within the Deadzone?

Because now the weird thing is that your program is still showing this that way for the wheel axis, while Dirt Rally is clearly showing me that there is no Deadzone anymore on the steering wheel.
For the pedals it's still as before, that Dirt Rally is showing/reacting to movement on their axes only when in your program the red frame goes away.

from oversteer.

I don't know what those red frames are. Could you attach a screenshot or maybe a video showing what's happening?

from oversteer.

I did find out that these red and green frames around the bars are only there when using a dark theme. The are gone when I'm switching to a light theme. This is 64-Bit Linux Mint 19.3 Cinnamon.
Oversteer.mp4.zip

from oversteer.

Could you include the output of the evdev-joystick --s command. I'd like to reproduce your setup.

Also, which wheel are you using?

from oversteer.

I've been testing and it seems those settings are ignored for my wheel, and I guess any Logitech wheel. There must be something else going on but it doesn't happen to me.

You could try evtest and compare the values displayed with Oversteer. A value of 32768 for the ABS_X corresponds to a centered wheel. A value of 0 for the other axis correponds to a fully pressed pedal, and 255 when not pressed at all. A discrepancy would probably mean some issue in Oversteer, if there's no discrepancy it could be some system or device issue.

from oversteer.

evdev-joystick --s /dev/input/by-id/usb-046d_Driving_Force_GT-event-joystick
Supported Absolute axes:
Absolute axis 0x00 (0) (X Axis) (value: 8436, min: 0, max: 16383, flatness: 0 (=0.00%), fuzz: 0)
Absolute axis 0x01 (1) (Y Axis) (value: 255, min: 0, max: 255, flatness: 0 (=0.00%), fuzz: 0)
Absolute axis 0x02 (2) (Z Axis) (value: 255, min: 0, max: 255, flatness: 0 (=0.00%), fuzz: 0)
Absolute axis 0x10 (16) (Hat zero, x axis) (value: 0, min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)
Absolute axis 0x11 (17) (Hat zero, y axis) (value: 0, min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)

With evtest my DrivingForce GT is working perfectly fine, all axes react exactly as I would expect it.

from oversteer.

Oh, to my surprise all of a sudden also the pedals are working fine for me in Dirt Rally. I guess the only thing I did was installing evtest (or perhaps a system reboot made the difference. Thanks a lot for your help and especially for your great configuration program that actually makes a better impression that the one from Logitech under Windows.

So my only left over question would be: Why do axes display as this solid block at first? I have never seen something like that in other programs displaying states of controller axes and don't see any use for that.

from oversteer.

So just to make it clearer, at first you got deadzones in Oversteer and DR, then the wheel deadzone dissapeared for DR but not Oversteer, and now you haven't any deadzone in DR but still have deadzones in Oversteer?

By deadzone I think we're refering here to that block/offset in the video, but a deadzone is actually a range in the axis around the origin that doesn't produce any input. Do both happen or the display reacts as soon as you move the wheel/pedal?

Thanks.

from oversteer.

@autotoxicus, it seems the problem is in the GTK theme you're using. It looks right with the default theme.

Now I have some doubts if I should be changing the way the user has choosen the UI to look like. Although it looks weird it's a design decission in the theme.

Which theme are you using?

from oversteer.

The controls theme I use is Mint-Y-Dark-Teal. And yes, different themes show different behavior regarding the minimum height of the bars.
Unfortunately all Mint-X and Mint-Y themes of Linux Mint are showing that wrong behavior, only High Contrast of the default themes does work properly in that regard. From the four themes I have downloaded only Adwaita and Adwaita-Dark are displaying the bars properly, while Cinnamox-Rhino and Adapta-Nokto also have this minimum height for the bars.

It would be a bit unfortunate if you would have to remove themes support from your program for that reason, as until that I actually have been very happy to see how perfectly well your program is compatible with the dark theme I use.

from oversteer.

I'm not removing support for themes. I'm trying to understand the issue before changing something that might break the theme for other users.

I've reported this issue to a theme project that did the same and they've already changed it. Is there some Mint issue tracker where we can report this issue and see if it's something intended or an accident?

from oversteer.

From: https://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/where.html#cinnamon-x-apps-and-linux-mint-bugs
I guess:
"If you want to report a general issue about Linux Mint, an issue about an upstream component which is patched by Linux Mint, or an issue about an upstream component which is specific to Linux Mint, you can use https://github.com/linuxmint/linuxmint."

from oversteer.

I have just created an account in the Linux Mint Forums, will ask there about that issue tomorrow.

from oversteer.

Hi, I suspect the Mint themes (and many others) have inherited this issue from Adwaita when they were originally forked - Adwaita also used to set up a minimum width for levelbars until relatively recently. It was changed with this commit GNOME/gtk@96062ff

Given that it's probably not feasible to get this fixed across all third-party themes out there I'd suggest that the application sets some mandatory styling for itself for levelbars.

from oversteer.

@smurphos, a workaround seems like the best option now that we know it wasn't an intended feature. Thanks.

from oversteer.

PR #19.

from oversteer.

@autotoxicus, the fix is in master now. Can you test it?

from oversteer.

Yes, but can I simply install it over the older version or should I uninstall the older version first?

from oversteer.

OK, I have simply uninstalled the old version before installing the new one.
The fix is working perfectly fine.

from oversteer.

You can generally install over the previous version but uninstalling first might be safer sometimes. Thanks @autotoxicus.

from oversteer.