Re: input.h changes

[Bj|rn A. <d3a...@dt...>]

Quoting Johann Deneux <jo...@Do...>:
> Hi,
> 
> I am changing the ff_effect struct. I went for the 1-parameter-1-effect
> scheme (actually it's really (1,2)-parameter(s)-1-effect).

Good. 

>         __u16 right_saturation[2]; /* Max level when joystick is on the
> right */
>         __u16 left_saturation[2];  /* Max level when joystick in on the
> left */
> 
>  [...]
> Note the arrays. There is one value for each axis. The axis mumber has
> become useless and has therefore been droped.

I wondered about this part when reading the spec. Why two axes? Why not
3? Or "n"?  This seems a bit joystick-centered, I can easily imagine a
spaceball-like device with FF in all 3 axis. (And rotation This seems a
bit joystick-centered, I can easily imagine a spaceball-like device 
with FF in all 3 axis. (And rotational around all as well)

Oh well.

>         struct ff_shape shape;

How would you feel about renaming shape to envelope? It fits the PID
spec, and it has some precedent from audio waveforms.
 
> The _u32 for the number of samples is a bit oversized, maybe.
 
Well, 16 bits could be to small in some future, so I think we should go
with 32.
 
Antother thing we might want to add to the API is supporting the "Start
Solo" action on an effect, in addition to the "start" and "stop" that we
already have. I'm at work now and the spec is at home, but it's in there
somewhere.

/August.
-- 
Wrong on most accounts.  const Foo *foo; and Foo const *foo; mean the same: foo
being a pointer to const Foo.  const Foo const *foo; would mean the same but is
illegal (double const).  You are confusing this with Foo * const foo; and const
Foo * const foo; respectively. -David Kastrup, comp.os.linux.development.system