Re: dinput: Support INFINITE as number of effect iterations (try 2)
On 01/28/2012 05:56 PM, Marcel Hasler wrote:
According to the DirectX reference, IDirectInputEffect::Start accepts INFINITE (aka -1) for the number of iterations. However, passing -1 to Linux via input_event results in no effect being played at all. This patch sets the number of iterations to the maximum signed value allowed if INFINITE is passed.
This fixes bug 29712.
This patch supersedes patch 83233. It does the same thing but adds a comment and should be easier to understand.
In general looks good. Would be nice to point out that linux/input.h says that any durations should not exceed 0x7fff as a maximum value. Please don't make code "easier to read" by adding needless if / else. Your first patch was fine. Vitaliy.
2012/1/29 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
On 01/28/2012 05:56 PM, Marcel Hasler wrote:
According to the DirectX reference, IDirectInputEffect::Start accepts INFINITE (aka -1) for the number of iterations. However, passing -1 to Linux via input_event results in no effect being played at all. This patch sets the number of iterations to the maximum signed value allowed if INFINITE is passed.
This fixes bug 29712.
This patch supersedes patch 83233. It does the same thing but adds a comment and should be easier to understand.
In general looks good. Would be nice to point out that linux/input.h says that any durations should not exceed 0x7fff as a maximum value.
Please don't make code "easier to read" by adding needless if / else. Your first patch was fine.
Vitaliy.
Thanks for your feedback. I just had another look at linux/input.h and realized I made a mistake. The member 'value' is actually declared __s32, so it really should be 0x7fffffff. Is there any predefined constant that could be used for this, rather than using a literal? This is what the code looks like at the moment: /* Linux doesn't accept INFINITE, use the maximum __s32 value instead */ event.value = (dwIterations == INFINITE) ? 0x7fffffff : dwIterations; The limit 0x7fff mentioned in input.h doesn't concern the number of iterations, just durations. I couldn't find anything on an upper limit for 'value'. I've tested 0x7fffffff and it works just fine. Marcel
On 01/29/2012 04:31 PM, Marcel Hasler wrote:
The limit 0x7fff mentioned in input.h doesn't concern the number of iterations, just durations. I couldn't find anything on an upper limit for 'value'. I've tested 0x7fffffff and it works just fine.
I'm afraid you'll have to dig up some documentation about what is the max value here is then. The fact that it works doesn't mean it's correct. Vitaliy.
2012/1/30 Vitaliy Margolen <wine-devel(a)kievinfo.com>:
I'm afraid you'll have to dig up some documentation about what is the max value here is then. The fact that it works doesn't mean it's correct.
Vitaliy.
The only official documentation I can find is in Documentation/input/ff.txt and it doesn't say anything about the max for 'value'. I had a look at the kernel source instead. input_handle_event() in input.c only checks whether 'value' is >= 0 for EV_FF (which is why the event is ignored for INFINITE), ml_ff_playback() in ff-memless.c sets 'state->count' (which is an 'int') to 'value' and ml_get_combo_effect() finally counts down 'state->count' until it reaches zero. So there really is no limit here (accept what's given by the data type). Marcel
2012/1/30 Marcel Hasler <mahasler(a)gmail.com>:
The only official documentation I can find is in Documentation/input/ff.txt and it doesn't say anything about the max for 'value'. I had a look at the kernel source instead. input_handle_event() in input.c only checks whether 'value' is >= 0 for EV_FF (which is why the event is ignored for INFINITE), ml_ff_playback() in ff-memless.c sets 'state->count' (which is an 'int') to 'value' and ml_get_combo_effect() finally counts down 'state->count' until it reaches zero. So there really is no limit here (accept what's given by the data type).
Marcel
I've submitted a final patch. I don't think there's anything more I can do to improve it. Marcel
On 02/01/2012 11:17 AM, Marcel Hasler wrote:
2012/1/30 Marcel Hasler<mahasler(a)gmail.com>:
I've submitted a final patch. I don't think there's anything more I can do to improve it.
Looks fine. Vitaliy.
participants (2)
-
Marcel Hasler -
Vitaliy Margolen