On Sun, Mar 09, 2014 at 11:38:06AM +0100, Elias Vanderstuyft wrote:
On Wed, Mar 5, 2014 at 4:03 PM, Andrew Eikum aeikum@codeweavers.com wrote:
On Tue, Mar 04, 2014 at 08:20:09PM +0100, Elias Vanderstuyft wrote:
So change in dinput/effect_linuxinput.c:488 : This->effect.u.periodic.period = tsp->dwPeriod / 1000; to : if (0 < tsp->dwPeriod && tsp->dwPeriod <= 1000) This->effect.u.periodic.period = 1; else This->effect.u.periodic.period = tsp->dwPeriod / 1000;Seems good. While we're here, any reason not to use round(3) instead of always rounding down in the >1000 case?
That's a good question, the reason is that I want to avoid floating point arithmetic (round(3)).
Okay. If using floating point is costly, then I agree the tiny (<1ms) increase in accuracy isn't worth it.
Is this how Windows behaves for massive dwPeriod? I would expect E_INVALIDARG, since it's out of the range [0,36000).
I think you're mixing up dwPeriod with dwPhase. The range of dwPeriod is not defined in MSDN.
Yes, you're right. Your updated patch seems fine.
Maybe we should also change all occurrences of 10000 in a force context to DI_FFNOMINALMAX, in the whole FF dinput implementation?
I would support a patch like that, yes.
(I've been busy lately, but I'll get to the rest of your mail sequence soon!)
Andrew