On 2/5/20 19:54, Bernd Steinhauser wrote:
On 17/06/2019 13:46, Bernd Steinhauser wrote:
Resending this message to linux input as suggested.
Hi,
I own a Granite Devices Simucube force feedback wheel which I'd like to get
working under Linux.
The current status is that if I use a tool to check/test the FFB, it tells me
that the device does not support FFB.
I'm also using the device under Windows 7 and there it works without any
special driver, so it should work with USB HID FFB.
In principle, it supports the following effects (see link below):
- constant force
- friction
- damping
- spring
- sine wave
- square wave
- sawtooth
- triangle
The device advertises as MCS, Granite Devices SimuCUBE with id 16d0:0d5a,
I'll attach lsusb output.
Upon connection, the device is recognized and the output is:
[ 3271.812807] usb 1-2.4.2: new full-speed USB device number 10 using xhci_hcd
[ 3271.921182] usb 1-2.4.2: New USB device found, idVendor=16d0,
idProduct=0d5a, bcdDevice= 2.00
[ 3271.921184] usb 1-2.4.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 3271.921185] usb 1-2.4.2: Product: SimuCUBE
[ 3271.921186] usb 1-2.4.2: Manufacturer: Granite Devices
[ 3271.921187] usb 1-2.4.2: SerialNumber: 0123456789
[ 3281.943990] input: Granite Devices SimuCUBE as
/devices/pci0000:00/0000:00:09.0/0000:04:00.0/usb1/1-2/1-2.4/1-2.4.2/1-2.4.2:1.0/0003:16D0:0D5A.0016/input/input48
[ 3281.944223] hid-generic 0003:16D0:0D5A.0016: unknown set_effect report layout
[ 3281.944228] hid-generic 0003:16D0:0D5A.0016: input,hiddev2,hidraw15: USB
HID v1.11 Joystick [Granite Devices SimuCUBE] on usb-0000:04:00.0-2.4.2/input0
I spent some time looking at the code and also other ffb code in usbhid, but
since I'm not really familiar with C I have a hard time figuring out why it
doesn't work out of the box and how to fix this, but I'd be happy to help
implementing/debugging it.
For a start, it would be really nice to find out what is reported, what the
report should look like and why it doesn't match.
Kind Regards,
Bernd
Links that might or might not be useful for general information:
https://granitedevices.com/wiki/SimuCUBE_technical_specifications
https://granitedevices.com/wiki/SimuCUBE_Firmware_User_Guide#DirectInput_Effect_Settings_and_Descriptions
Hi,
I would to catch up on this, as I found time to investigate this a bit more.
I also had a chat with one of the devs at GD and he told me that apparently
the PID field A7h (Start Delay) is the problematic thing here.
The hid-pidff.c driver requests this field:
#define PID_EFFECT_BLOCK_INDEX»·0
#define PID_DURATION»···»···1
#define PID_GAIN»···»···2
#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
};
but the device does not send it (I attached the descriptor from the device),
hence the driver complains about the unknown set_effect layout.
Now the thing is they tried adding the field, but in that case the Windows HID
driver will not recognize the device properly anymore as for some reason it
expects that field not to be set.
With that knowledge I tried again with the field 0xa7 removed (and some other
references to start delay) and in that case the device was recognized properly
and I could run some FFB tests successfully.
There was a warning about an unknown condition effect layout (as there are 2
missing fields in that one as well), but that should be a minor thing for the
moment.
I suspect that just removing the 0xa7 field (as I did) is not a proper
solution here, but is there an easy way to get this working with a bit of
special handling?
Best Regards,
Bernd
Hi,
I would catch up on this. Removing the field 0xA7 as well as some references
fixes the issue. I wrote a patch to test that (see attachment) and with that
applied the FFB works fine on the device.
Now I guess just shipping this patch with the default Linux kernel isn't the way
to go, but due to my limited knowledge of writing C code, I don't think I can
write a special driver myself.
Any suggestions on how to properly handle such a case?
GD could in principle provide me with a firmware for the device that adds the
field 0xA7 and therefore would work with the default pidff driver code, but then
it would not work on Windows anymore with the default HID driver on Windows.
(They tried that.)
However, switching firmwares to be able to use it on different operating systems
shouldn't be necessary, right?
Kind Regards,
Bernd
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);
