Re: dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.

[Vitaliy Margolen]

Loïc Hoguin wrote:
> See the attached patch.
> - /* Get sane state values for the joystick before giving control to the application.
> -
>   Before this call was made in alloc_device, before the application sets the joystick
> -
>   properties, so the values given by fake_current_js_state weren't in the range
> -
>   of values expected by a few applications. */
> - fake_current_js_state(This);
> -

The comment is a bit too verbose. First line is enough.

However my main problem with your patch is you doing it on every acquire
call which invalidates prior state of the joystick which could have been
correct. I'm afraid you'll need to find a way to do it once or pull the real
device state from the device.

Vitaliy

dinput: Initialize js state with sane values when the application acquires the device instead of at allocation.

[Loïc Hoguin]

On 01/01/2010 10:44 PM, Vitaliy Margolen wrote:
> Loïc Hoguin wrote:
> > See the attached patch.
> > - /* Get sane state values for the joystick before giving control to the application.
> > -
> >   Before this call was made in alloc_device, before the application sets the joystick
> > -
> >   properties, so the values given by fake_current_js_state weren't in the range
> > -
> >   of values expected by a few applications. */
> > - fake_current_js_state(This);
> > -
>
> The comment is a bit too verbose. First line is enough.
>
> However my main problem with your patch is you doing it on every acquire
> call which invalidates prior state of the joystick which could have been
> correct. I'm afraid you'll need to find a way to do it once or pull the real
> device state from the device.
>
> Vitaliy

OK for the comment.

I had two possible solutions in mind, doing it in Acquire, which doesn't
seem good, and doing it when the range properties are being changed (and
keeping the original call in alloc_device for a safe initialization).
This would mean the values would be correct at all time from the point
of view of the application.

I'm guessing the second solution is better then; after all, the axis
data in 'js' should be invalidated if the range is changed (and possibly
when the dead zone is changed too).

In fact if I understand it correctly it should be possible to simply
convert the existing data into the new range when this range is changed
by the application. This would fix my issue without invalidating the
data already available.

Doing it for the dead zone doesn't sound as straightforward though, it
would work perfectly if it is being increased but not when decreased, as
data in the dead zone can't be recovered until the joystick sends more
information. And as far as I know no application would benefit from
doing this when the dead zone property is changed.

Tell me what you think about this and I'll start working on a better patch.