As you know Mika I did some testing with the SC1 on Linux, since we already talked about that some time ago. I recently did some more tests and some also include things you mentioned here, so let me give you a few more hints:
-
One problem – as you mentioned – can be that there are two interfaces for joysticks in the kernel, the jsdev and the evdev one. Actually it can be problematic in games if both are present, since joysticks may be detected twice (depending on how the software is programmed, I guess). Everything I tested so far (couple of sims) does work without the jsdev interface, so I’d just suggest to block it completely, which is done via an entry in a file like
/etc/modprobe.d/blacklist-joydev.conf(actually the name does not matter here, just has to end with .conf):
blacklist joydev -
There is test software for evdev, e.g. evtest-qt:
https://gitlab.com/evtest-qt/evtest-qt
It’s also a very good idea to install linuxconsole, since that contains some other tools useful for the evdev interface (i.e. evdev-joystick, which is required in the next step) -
For some reason Linux – by default – applies some really idiotic deadzone, which is most likely what you mean with “was not able to calibrate the joystick properly”. This can be checked with evdev-joystick. First, you need to get the path for the device, e.g. by:
evdev-joystick --l
which lists all evdev joystick devices. There you’ll notice that deadzone and fuzz are both non-0, which is the cause of the problem here. Hence set these to zero:
evdev-joystick --evdev /some/path/output/by/the/previous/command --axis 0 --deadzone 0
Now this won’t be permanent, meaning that it’ll reset when rebooting. To get this as a permanent setting, most people would suggest to set up a shell script run by udev, most likely because they just don’t know any better.
Actually the better idea is to enter this in the hwdb provided by udev (or rather systemd which contains udev these days). btw. as a manufacturer you could possibly submit a patch for systemd to include appropriate data for your device to get rid of this necessity for all GD-based wheels, if you feel it is a correct setting. Anyway, the entry here would go into a file in /etc/udev/hwdb.d, e.g.
/etc/udev/hwdb.d/61-evdev-local.hwdb:
evdev:name:*Simucube*:*
EVDEV_ABS_00=:::0:0
*Simucube* matches the name for the device as reported by evdev during driver loading (see dmesg output). I think it might also be possible to match the device IDs, but I haven’t been able to get that working so far and unfortunately I couldn’t find really helpful docs on hwdb telling me how to do it correctly.
The entry after the = means MIN:MAX:STEP:FUZZ:DEADZONE where you can leave out the settings that you do not want to adjust (meaning I set FUZZ and DEADZONE here).
ABS_00 is the absolute axis 0, axis 1 would be ABS_01 etc. Since I don’t use the additional connectors, for me it’s sufficient to only set axis 0, but for others (e.g. if connecting pedals) setting fuzz and deadzone for additional axis (1 or above) may be necessary as well.
Using this it is also possible to set min and max, in case you want to calibrate pedals for a specific range (like I do for my Heusinkveld pedals where the physical range does not match the full range of the controller).
While it will most likely update on its own at some point, it’s a good idea to update the hwdb manually to ensure the entry is included:
systemd-hwdb update
After that at least my Simucube behaves like it should. Well, apart from the next one.
- FFB does not work (yet). The patch for that isn’t really massive, there is only one field you need to patch out and that is 0xa7 (PID_START_DELAY):
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index fddac7c72f64..8684808c5967 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -57,9 +57,8 @@ the only field in that report */
#define PID_TRIGGER_BUTTON 3
#define PID_TRIGGER_REPEAT_INT 4
#define PID_DIRECTION_ENABLE 5
-#define PID_START_DELAY 6
static const u8 pidff_set_effect[] = {
- 0x22, 0x50, 0x52, 0x53, 0x54, 0x56, 0xa7
+ 0x22, 0x50, 0x52, 0x53, 0x54, 0x56
};
#define PID_ATTACK_LEVEL 1
@@ -311,7 +310,6 @@ static void pidff_set_effect_report(struct pidff_device *pidff,
pidff->effect_direction->value[0] =
pidff_rescale(effect->direction, 0xffff,
pidff->effect_direction);
- pidff->set_effect[PID_START_DELAY].value[0] = effect->replay.delay;
hid_hw_request(pidff->hid, pidff->reports[PID_SET_EFFECT],
HID_REQ_SET_REPORT);
@@ -326,8 +324,7 @@ static int pidff_needs_set_effect(struct ff_effect *effect,
return effect->replay.length != old->replay.length ||
effect->trigger.interval != old->trigger.interval ||
effect->trigger.button != old->trigger.button ||
- effect->direction != old->direction ||
- effect->replay.delay != old->replay.delay;
+ effect->direction != old->direction;
}
/*
@@ -736,7 +733,6 @@ static void pidff_autocenter(struct pidff_device *pidff, u16 magnitude)
pidff->set_effect[PID_TRIGGER_REPEAT_INT].value[0] = 0;
pidff_set(&pidff->set_effect[PID_GAIN], magnitude);
pidff->set_effect[PID_DIRECTION_ENABLE].value[0] = 1;
- pidff->set_effect[PID_START_DELAY].value[0] = 0;
hid_hw_request(pidff->hid, pidff->reports[PID_SET_EFFECT],
HID_REQ_SET_REPORT);
After that the FFB will work. Didn’t test it with a lot of games so far, since I use Linux mainly for flying rather than driving. But wanted to test out ATS and ETS2 in the near future, since for those there exists an FFB plugin for Linux, which is supposed to have much improved FFB compared to the shitty built-in one.
Also my motivation thus far was low because Assetto Corsa via Steam/proton was a big pain, but this seems to get better slowly, so maybe I’ll have a look at that as well. (AC still is the one racing sim I use the most.)
, so I pushed some patches to upstream Wine to help them in the implementation, and to iron out some bugs. Tested everything on the SC2, as they didn’t have any other PID FFB devices, so we may say that the PID implementation in Wine is developed with SC2 in mind 
.
)