Length 0 instead of 0xFFFF for infinite effect duration.

[groybe]

Name of the game: Fedit
Steam ID: No Steam
Game version: 1.0
Game Type (native/proton/wine): Wine
Proton/Wine version: wine-7.2 (Staging)
Wheel Model: OpenFFBoard (https://github.com/Ultrawipf/OpenFFBoard)
Compatibility Mode: None
Distribution: Fedora 34
Kernel version: 5.16.12-100

Force Feedback present: No
Symptoms or Special Notes: Fedit (also I tried Richard Burns Rally) My wheel recieves length as 0 instead of 0xFFFF for infinite effect duration.

I used rohitab api monitor to confirm that dinput out of fedit sends 0xFFFF so I guess this might not be a wine issue.
At this point I'm lost. Can anyone point me where to look next?

Native program Tux racer appears to work although only in one direction but I think that's a whole other issue.

The creator of OpenFFboard has confirmed it arrives at the OpenFFBoard itself as 0xFFFF on a windows machine. They seem to think it is a linux issue.
My G25 wheel gets sent 0 as length but seems to just accept this and play the effect anyways.
Should the openFFBoard handle this the same way? I'm not sure this would be to standards?

The log on wine staging is empty for some reason. But the wrapper is working. I've added a length overwrite here and it works.

Log from wine lutris-5.7-11-x86_64
000034473776 > UPLOAD id:2 dir:15681 length:0 delay:0 type:CONSTANT level:-8192 attack_length:0 attack_level:32000 fade_length:0 fade_level:32000

Thanks for anyone who takes the time to look at this.

[berarma]

The Linux FF API is different to Windows. The Linux source code has this comment:

All duration values are expressed in ms. Values above 32767 ms (0x7fff) should not be used and have unspecified results.

So using 0xFFFF can give unexpected results, it could even work but it's not following the API specs.

Infinite effect duration is requested with replay.length = 0.

Proton 7.0 has switched to a new input API implementation and has issues with wheels and FF. Wine might have similar issues in case they've switched to this new implementation.

[groybe]

Thanks for the quick response.
Ah that might ruin the author of OpenFFBoard's plans for compatibility of universal drivers across windows and linux.

Anyways I have a dirty fix using your wrapper here. https://github.com/groybe/ffbtools/tree/OpenFFBoard_fix

Thanks again!

[Ultrawipf]

I changed the behaviour in the OpenFFBoard firmware back to treating 0xffff and 0 as infinite. The PID standard is not fully clear about if the maximum or 0 is treated as infinite. Check the definitions page of the PID document. That indicates to me that it is likely the max value.
Never seen anything on windows send 0. Windows always uses the maximum but also no game would send 0 it seems so its probably best to treat both as infinite for compatibility reasons.

But there are currently other issues. I can't get FFB at all to work on my linux machine at the moment to test it.

Maybe someone here has an idea.
dmesg always reports implement() called with too large value 4 (n: 1)! which hints at core-hid.c and sometimes when an effect should be loaded it reports upload request failed.

device reports 0 simultaneous effects
pid_block_load failed 60 times
upload request failed

But the device never receives an effect request at all for some reason so it could be a descriptor interpretation problem on linux.
Linux seems very strict about what fields must be present in the descriptor in what order with which values while on windows the descriptor defines what capabilities the device has and the OS sends reports accordingly.

[berarma]

Hi @Ultrawipf. I was following your work some time ago. I'm glad you're still working on it. It's very interesting and I hope I can get to try it sometime and perhaps help.

I didn't know about the PID document, it isn't in the usb.org index of documents. Logitech wheels don't use it and I don't know any wheels using it. In any case, that's for the USB interface, we're comparing the Windows and Linux interfaces, at a higher level of abstraction.

The PID document is fundamentally done by Microsoft so it may have similarities with DInput on Windows.

I haven't found any Linux documentation that says 0 is infinite duration but it's implied by drivers and Wine. Search "infinite" in this discussion in the Wine mailing list.

About the other issues, I don't know how you are interfacing with the OpenFFBoard firmware. I guess you would need a driver or use hidraw. Maybe I don't know enough about USB and its implementation on Linux, though.

[Ultrawipf]

Currently debugging the linux handling of the device memory management reports.
It seems like windows does not really care about those reports while on linux it is quite important.
There was indeed a bug in the pool and block load report replies causing a 1 byte offset causing it not to detect the device managed memory flag (if it is not 1 hid-pidff.c seems to fail immediately).
The device is now detected again and effects can be sent but there are still some things to fix.

Also the "autocentering detection" is a bit weird causing some workarounds for other games to break again. Not sure if it was ever common to have a preset spring effect for autocentering. Never seen that before.

If you have some sources to look into about the lower level device management (pool report, block load report, effect creation sequences on linux) it would be nice to look into. The effect setup sequencing does not follow the windows order so thats something i need to look into for now.

[Ultrawipf]

The Linux FF API is different to Windows. The Linux source code has this comment:

All duration values are expressed in ms. Values above 32767 ms (0x7fff) should not be used and have unspecified results.

So using 0xFFFF can give unexpected results, it could even work but it's not following the API specs.

I checked again and indeed in our firmware the maximum valid range is until 0x7fff but windows will send 0xffff as infinite.
According to the PID document the "maximum of a range" is infinite so for a 16b value that might actually be 0xffff here and not the maximum of the defined valid range of a value which is 0x7fff then.

[berarma]

The differences between OS level APIs and firmware APIs should be handled by drivers I guess. That's what the Logitech drivers do, I don't know what the PID driver does.

[Spacefreak18]

I changed the behaviour in the OpenFFBoard firmware back to treating 0xffff and 0 as infinite. The PID standard is not fully clear about if the maximum or 0 is treated as infinite. Check the definitions page of the PID document. That indicates to me that it is likely the max value. Never seen anything on windows send 0. Windows always uses the maximum but also no game would send 0 it seems so its probably best to treat both as infinite for compatibility reasons.

But there are currently other issues. I can't get FFB at all to work on my linux machine at the moment to test it.

Maybe someone here has an idea. dmesg always reports implement() called with too large value 4 (n: 1)! which hints at core-hid.c and sometimes when an effect should be loaded it reports upload request failed.

device reports 0 simultaneous effects
pid_block_load failed 60 times
upload request failed

But the device never receives an effect request at all for some reason so it could be a descriptor interpretation problem on linux. Linux seems very strict about what fields must be present in the descriptor in what order with which values while on windows the descriptor defines what capabilities the device has and the OS sends reports accordingly.

you have no idea how long i've been searching the internet to find someone who came across that implement error. i've been neck deep in Linux Force Feedback weeds all month, and I came across this repo fairly early, but I didn't take the time to read the issues.

I have a SimXperience Accuforce V2 wheel, which also uses the generic kernel pidff driver. And while tools like ffbtest will work just fine, it wasn't working through wine.

I too have noticed that implement error. but i sort of moved on from it because i think it was a bit of a red herring, or atleast not my biggest issue. i think it only applies to certain effects, i think Rumble, but don't quote me on that. Which would make sense if more common wheels that only have limited common effects, don't see that error.

the biggest issue was the -1 coming from wine dinput into SDL. i put a few lines to set replay.length to SHRT_MAX and i could get ForceTest.exe to play effects.

atleast better. i still think there are other issues i'm working through.

i started a wine thread but now i'm unsure whether or not wine should be sending SHRT_MAX or if SDL should understand and handle the -1.

[groybe]

I too have noticed that implement error. but i sort of moved on from it because i think it was a bit of a red herring, or atleast not my biggest issue. i think it only applies to certain effects, i think Rumble, but don't quote me on that. Which would make sense if more common wheels that only have limited common effects, don't see that error.

I guess it would affect any effect the uses infinite duration. In my case it was Constant Force but I've only tried Richard Burns Rally.

Also looking at the work around I was using here I had a problem with the wheel not listening to a negative direction but direction based on degrees was ok. I forget why this was. I think it was the wheel's handling of it too.

[groybe]

I just read your post over at Wine forum. Yeah now I remember wine 7 doesn't work for me. So you're not the only one. https://bugs.winehq.org/show_bug.cgi?id=52714

[Spacefreak18]

i actually just looked again, and i do see that implement error regardless of the effect. but it's just a warning, and the effect still plays. i'll need to investigate further to see if that's causing the problems i'm seeing, which i may create another thread for.

i also looked at your "override length" addition to the ffbwrapper. It'll just set the length to 0xFFFF when it is enabled, so even if the effect had some other reasonable value, it'll just be ignored. i guess most applications will not use values that are non-zero and not max?

[groybe]

I think on other effects like sine and rumble the duration would matter yeah. So it really would only work with a game that constantly updates the effect. I guess that would be how most games would use constant force where the duration is really irrelevant as long as it has at least some.

Most of this is over my head though.

[berarma]

I have a SimXperience Accuforce V2 wheel, which also uses the generic kernel pidff driver. And while tools like ffbtest will work just fine, it wasn't working through wine.

Does it work with Wine/Proton 6? There were some breaking changes in Wine/Proton 7.

It would be interesting to know more about other PID compatible wheels. More testing would probably help fix bugs unconvered until now. I see there might be discrepancies as to what the different Linux FF drivers understand as infinite. Wine/Proton/SDL might have get caught by these discrepancies.

[Spacefreak18]

berama, i've read that too but I just can't replicate that. I can get wine 7 to work with the version in debian and with the latest from git. As long as i patch SDL with the -1 issue here.

Now, of course, whe I use proton i have to force it to use the system version of SDL by specifiying SDL_DYNAMIC_API=/usr/local/lib/libSDL2.

This is a very confusing landscape, with a lot of moving parts, wine potentially changing backends does not help the matter. I was constantly playing with a registry key in wine (DisableHidraw) thinking that had something to do with it.