Cannot write to tuning-menu

[gnac]

I've installed the hid-fanatecff driver per the instructions. everything went without a hitch.
I plugged in my fanatec DD CSL, and see that it gets registered (see modinfo and dmesg output at bottom).

However, if I try to write to "range" I get an invalid argument error:

/sys/module/hid_fanatec/drivers/hid:fanatec/0003:0EB7:0020.0011 $ echo 4 > range
bash: echo: write error: Invalid argument

dmesg shows

[ 1998.742528] usbhid 2-1:1.0: Cannot write to tuning-menu, not yet read data from device.

Which is printed out in hid-ftecff-tuning.c, line 135.
I can however write to 'display' and see the characters on the wheel.

I also tried building the next branch, with similar results.
modinfo on the next modules shows:

filename:       /lib/modules/5.14.21-150500.55.52-default/kernel/drivers/hid/hid-fanatec.ko
description:    A driver for the Fanatec CSL Elite
author:         gotzl
license:        GPL
suserelease:    SLE15-SP5
srcversion:     18C66856D563171D5C9E556
alias:          hid:b0003g*v00000EB7p00000011
alias:          hid:b0003g*v00000EB7p00000020
alias:          hid:b0003g*v00000EB7p00000007
alias:          hid:b0003g*v00000EB7p00000006
alias:          hid:b0003g*v00000EB7p00006204
alias:          hid:b0003g*v00000EB7p00000005
alias:          hid:b0003g*v00000EB7p00000E03
alias:          hid:b0003g*v00000EB7p0000183B
alias:          hid:b0003g*v00000EB7p00000004
alias:          hid:b0003g*v00000EB7p00000001
depends:        
retpoline:      Y
name:           hid_fanatec
vermagic:       5.14.21-150500.55.52-default SMP preempt mod_unload modversions 
parm:           init_range:int
parm:           profile:Enable profile debug messages. (int)
parm:           init_load:int

Here's the dmesg output when I first plug in the unit:

[ 2349.184816] usb 2-1: USB disconnect, device number 15
[ 2352.890516] usb 2-1: new full-speed USB device number 16 using xhci_hcd
[ 2353.040261] usb 2-1: New USB device found, idVendor=0eb7, idProduct=0020, bcdDevice= 0.17
[ 2353.040270] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
[ 2353.040274] usb 2-1: Product: FANATEC Wheel
[ 2353.040276] usb 2-1: Manufacturer: Fanatec
[ 2353.042414] hid_map_usage: 78 callbacks suppressed
[ 2353.042418] Fanatec FANATEC Wheel: Invalid code 768 type 1
[ 2353.042422] Fanatec FANATEC Wheel: Invalid code 769 type 1
[ 2353.042424] Fanatec FANATEC Wheel: Invalid code 770 type 1
[ 2353.042425] Fanatec FANATEC Wheel: Invalid code 771 type 1
[ 2353.042427] Fanatec FANATEC Wheel: Invalid code 772 type 1
[ 2353.042429] Fanatec FANATEC Wheel: Invalid code 773 type 1
[ 2353.042430] Fanatec FANATEC Wheel: Invalid code 774 type 1
[ 2353.042432] Fanatec FANATEC Wheel: Invalid code 775 type 1
[ 2353.042434] Fanatec FANATEC Wheel: Invalid code 776 type 1
[ 2353.042436] Fanatec FANATEC Wheel: Invalid code 777 type 1
[ 2353.042552] input: Fanatec FANATEC Wheel as /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/0003:0EB7:0020.0012/input/input44
[ 2353.042789] fanatec 0003:0EB7:0020.0012: input,hiddev96,hidraw0: USB HID v1.11 Joystick [Fanatec FANATEC Wheel] on usb-0000:00:14.0-1/input0
[ 2353.105822] fanatec 0003:0EB7:0020.0012: Hires timer: period = 2 ms

Thank you.

[gotzl]

Hi,

the range sysfs file is mapped to the tuning-menu SEN value. For writing to this file, first, the current values of the tuning-menu have to be transmitted at least once from the wheel to the PC. This happens for example when you open the tuning-menu on the wheel (I guess), or when you change a value on the wheel directly.

I still have to figure out how I can get the current tuning-menu values from the wheel on initialization ... I'll add this to the 'known issues'.

Does this sound OK for you?

[arepavich]

Loaded up an old Windows 10 machine today and took a shot at capturing the relevant traffic. Worth noting that I also updated my wheel's firmware along the way, so I'm hoping that doesn't introduce any new variables into the fray here.

Since I don't hope to load up this system frequently, I exported two sets of packets for each action - one filtered on usb.data_len == 64 and one without that filter. I did my best to get some targeted interactions, but there's definitely some extra traffic on the value update from software as I started the capture just before loading up the Fanatec control panel; it looked like there were a few periodic handshakes/polls occurring while the software was running.
csl_dd_windows_traffic.zip

[gotzl]

Ty, I'll have a closer look tomorrow. But one idea would be to just put

		drv_data->tuning.ftec_tuning_data[3] = drv_data->tuning.ftec_tuning_data[3]&0xf;

just after the memcpy at https://github.com/gotzl/hid-fanatecff/blob/124372964d81ab71b4dc54858c746f1fe3621dbe/hid-ftecff.c#L1176C6-L1176C7

[gotzl]

So, it seems the additional bit I had trouble with indicates if the tuning menu is in standard or in advanced mode. In your case it was in standard mode (0x82) while I always had it in advanced mode (0x02). When writing to the device, this bit has to be masked out, similar to what I proposed in the last comment.

I've just pushed a change to the master that does this, and it also allows to read/switch between standard/advanced mode via the advanced_mode sysfs file. Could you try this out?

[arepavich]

That seems to have done it! Loaded up Oversteer, and the correct values were populated right out of the gate; changes to the settings are now being recognized on the wheel, and (of course) I'm no longer getting errors in the dmesg output.

Also, I had no idea that the advanced mode existed - I should really RTFM 😆

Thanks for the quick turnaround!

[gotzl]

Great, glad to hear :) Thanks for your help in fixing this!