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

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

 



On Sun, Feb 16, 2014 at 12:04 AM, Anssi Hannula <anssi.hannula@xxxxxx> wrote:
> 15.02.2014 22:32, Elias Vanderstuyft kirjoitti:
>> On Sat, Feb 15, 2014 at 3:04 PM, Anssi Hannula <anssi.hannula@xxxxxx> wrote:
>>>
>>> However, from what I can see, you can achieve the exact same effect with
>>> these parameters (DInput deadband definition):
>>> sat_left = 0xFFFF
>>> sat_right = 0x0000
>>> coeff_left = 0x4000
>>> coeff_right = 0x0000
>>> center = 0x0000 (50% point)
>>> deadband (DInput/ours) = 0x8000 (50% total area, or 50% of
>>> center-to-end, so it reaches 25%..75%)
>>>
>>> On the left side, the effect is exactly the same as before with same
>>> parameters (sat 0xffff, coeff 0x4000, starts at 25% point).
>>>
>>> On the right side the parameters differ, but the end-result is the same,
>>> there is no effect at all:
>>> - In the first example, the right side is fully in deadband area,
>>>   causing the effect to have zero effect.
>>> - In my variant with our definition, the right side has zero saturation,
>>>   causing the effect to have zero effect.
>>>
>>>
>>> So the present definitions (and DInput definitions) can achieve the same
>>> effects as your proposed definitions, unless I'm missing something,
>>> making the change unneeded.

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))

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