Re: Questions about the documentation/specification of Linux ForceFeedback input.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 19, 2014 at 7:54 PM, Elias Vanderstuyft <elias.vds@xxxxxxxxx> wrote:
> Today, I noticed something strange: an explicit saturation of zero in
> DInput (or at least using the most recent driver for my Logitech MOMO
> wheel), appears to be transformed to max saturation! (This is why I
> chose to quote your "sat_right = 0x0000" part, however that's not the
> point I want to make in this mail)
>
> E.g:
>     pos_sat = 10000    ->    Max saturation send to device
>     pos_sat =  5000    ->    Half saturation send to device
>     ...
>     pos_sat =     1    ->    Zero saturation send to device (because
> it appears to be rounded to zero)
>     pos_sat =     0    ->    Max saturation send to device (?!)
>
> Also interesting is that the FEdit tool (from MS DirectX SDK) sets all
> 'saturation' values to zero by default. This is not the case for the
> 'coefficient' values: they are set to maximum. The resulting default
> conditional force generates a maxed out conditional effect on my MOMO
> wheel.
> The weird thing is, that MSDN does not explicitly say anything about
> this: http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.dicondition%28v=vs.85%29.aspx
> "dwPositiveSaturation:
>     Maximum force output on the positive side of the offset, in the
> range from 0 through 10,000.
>     If the device does not support force saturation, the value of this
> member is ignored.
> "
>
> So, my question is:
>     - Should Wine's translation layer convert a 0 dinput saturation to
> max linux saturation?
>     - or Should the Linux FF drivers send a max saturation command
> when the linux saturation equals zero?
>     - or Should we forget about this? (but that will result Wine's
> behaviour to be different from Windows', at least for my MOMO wheel (I
> don't have another capable (non-Logitech?) wheel to test it with))
>

On Thu, Feb 20, 2014 at 9:52 AM, Elias Vanderstuyft <elias.vds@xxxxxxxxx> wrote:
> Another question:
> There is written on /include/uapi/linux/input.h:1058 :
>     "@phase: 'horizontal' shift"
> where 'horizontal' most likely means time dimension, not phase of the
> waveform, right?
>

Hi Anssi,

Any thoughts about my previous 2 mails' questions?
(I just need be sure of these things to finish my Wine FF patchset,
however, if you don't have time, no problem, it can wait for some time)

Best regards,
Elias
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux