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