Menu
▾
▴
linuxconsole-dev
|
From: Johann D. <jo...@Do...> - 2002-01-30 23:06:51
|
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).
New effect types:
* FF_DAMPER
This effect really is the former FF_FRICTION.
* FF_INERTIA
* FF_RAMP
Note that this effect is not periodic. Reasons:
1. PID does not define it as a periodic effect
2. A periodic ramp is just a sawtooth up or down
I wonder if we still need the FF_CONSTANT, as it's just a special case of
FF_RAMP.
* FF_CUSTOM
It's not new actually. I just did not remember it was there.
New or changed structures:
* Ramp effects
struct ff_ramp_effect {
_s16 start_level;
_s16 end_level;
struct ff_shape shape;
}
* Friction
No new structure. We can use the ff_interactive, according to PID. What is
its meaning is still not clear. I would guess the following:
force = f(position, direction)
force.direction = -direction
force.magnitude = p(position), p being the function described at page 12.
The ff_interactive_effect structure has changed:
struct ff_interactive_effect {
__u16 right_saturation[2]; /* Max level when joystick is on the
right */
__u16 left_saturation[2]; /* Max level when joystick in on the
left */
__s16 right_coeff[2]; /* Indicates how fast the force grows when
the
joystick moves to the right */
__s16 left_coeff[2]; /* Same for left side */
__u16 deadband[2]; /* Size of area where no force is produced
*/
__s16 center[2]; /* Position of dead zone */
};
Note the arrays. There is one value for each axis. The axis mumber has
become useless and has therefore been droped.
* ff_periodic_effect:
struct ff_periodic_effect {
__u16 waveform; /* Kind of wave (sine, square...) */
__u16 period; /* in ms */
__s16 magnitude; /* Peak value */
__s16 offset; /* Mean value of wave (roughly) */
__u16 phase; /* 'Horizontal' shift */
struct ff_shape shape;
/* Only used if waveform == FF_CUSTOM */
__u32 custom_len; /* Number of samples */
__s16 *custom_data; /* Buffer of samples */
/* Note: the data pointed by custom_data is copied by the driver. You can
* therefore dispose of the memory after the upload/update */
};
The _u32 for the number of samples is a bit oversized, maybe.
I think that's all for now. Comments and critics welcome.
--
Johann Deneux
|
|
From: Bj|rn A. <d3a...@dt...> - 2002-01-31 11:18:16
|
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 |
|
From: Johann D. <jo...@Do...> - 2002-01-31 17:06:36
|
On Thu, 31 Jan 2002, Bj|rn Augustsson wrote: > 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 Indeed. Then we would need a list of (parameter/axis id) pairs. That sounds doable. > 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. Ok. I can also change the ff_interactive_effect to ff_condition_effect, if you prefer. > > > 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 What do you mean ? One can only start one effect at a time ? Or do you mean to play an effect to play once ? That's already supported. -- Johann Deneux |
|
From: Bj|rn A. <d3a...@dt...> - 2002-01-31 17:24:52
|
Quoting Johann Deneux <jo...@Do...>: > On Thu, 31 Jan 2002, Bj|rn Augustsson wrote: > > Quoting Johann Deneux <jo...@Do...>: > > > 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 > > Indeed. Then we would need a list of (parameter/axis id) pairs. > That sounds doable. Yes. On the other hand, it's difficult to tell if it's ever going to be needed... Hmm. I'd like to cheat again, and have a look at what MS DirectInput does. > > How would you feel about renaming shape to envelope? It fits the PID > > spec, and it has some precedent from audio waveforms. > > Ok. I can also change the ff_interactive_effect to ff_condition_effect, > if you prefer. OK, that'd be good too. > > 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 > > What do you mean ? One can only start one effect at a time ? Or do you > mean to play an effect to play once ? That's already supported. According to the PID spec (5.9), it means "Start the effect specified by the Effect Handle and stop all other effects." As opposed to "Start" which means "Start the effect specified by the Effect Handle". /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 |
|
From: Johann D. <jo...@Do...> - 2002-01-31 21:40:34
|
On Thu, 31 Jan 2002, Bj|rn Augustsson wrote: > > According to the PID spec (5.9), it means "Start the effect specified by > the Effect Handle and stop all other effects." As opposed to "Start" which > means "Start the effect specified by the Effect Handle". The iforce driver allows several processes to access the device concurrently. However, one process cannot control effects it does not own. -- Johann Deneux |
|
From: Bj|rn A. <d3a...@dt...> - 2002-02-04 22:36:33
|
Quoting Johann Deneux <jo...@Do...>: > On Thu, 31 Jan 2002, Bj|rn Augustsson wrote: > > > > According to the PID spec (5.9), it means "Start the effect specified by > > the Effect Handle and stop all other effects." As opposed to "Start" which > > means "Start the effect specified by the Effect Handle". > > The iforce driver allows several processes to access the device > concurrently. However, one process cannot control effects it does not > own. Uh, several processes concurrently playing effects on one FF device? Maybe I'm just being unimaginative, but can you give an example of when that would be useful? /August, puzzled. -- 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 |
|
From: Johann D. <jo...@do...> - 2002-02-05 09:02:46
|
On Mon, 4 Feb 2002, Bj|rn Augustsson wrote: > Quoting Johann Deneux <jo...@Do...>: > > On Thu, 31 Jan 2002, Bj|rn Augustsson wrote: > > > > > > According to the PID spec (5.9), it means "Start the effect specified by > > > the Effect Handle and stop all other effects." As opposed to "Start" which > > > means "Start the effect specified by the Effect Handle". > > > > The iforce driver allows several processes to access the device > > concurrently. However, one process cannot control effects it does not > > own. > > Uh, several processes concurrently playing effects on one FF device? > Maybe I'm just being unimaginative, but can you give an example of > when that would be useful? It was actually Vojtech's idea. His point was that you may want to use (for example) vibrating effects coupled with alarm clocks. This does make sense when used with mice, for example. In that case, you would have X accessing the mouse in read mode, and ff-enabled applications would also access it (in "write" mode). You may object that we could as well allow only X to access the device, and add a force feedback extension to X. That would also be a solution, but not as good as the first one, IMO. -- Johann Deneux |
|
From: Vojtech P. <vo...@su...> - 2002-01-31 17:17:16
|
On Thu, Jan 31, 2002 at 12:06:40AM +0100, Johann Deneux wrote:
> 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).
>
> New effect types:
> * FF_DAMPER
> This effect really is the former FF_FRICTION.
> * FF_INERTIA
> * FF_RAMP
> Note that this effect is not periodic. Reasons:
> 1. PID does not define it as a periodic effect
> 2. A periodic ramp is just a sawtooth up or down
> I wonder if we still need the FF_CONSTANT, as it's just a special case of
> FF_RAMP.
There might be a device which doesn't support RAMP, but does support CONSTANT.
> * FF_CUSTOM
> It's not new actually. I just did not remember it was there.
>
> New or changed structures:
> * Ramp effects
> struct ff_ramp_effect {
> _s16 start_level;
> _s16 end_level;
> struct ff_shape shape;
> }
> * Friction
> No new structure. We can use the ff_interactive, according to PID. What is
> its meaning is still not clear. I would guess the following:
> force = f(position, direction)
> force.direction = -direction
> force.magnitude = p(position), p being the function described at page 12.
> The ff_interactive_effect structure has changed:
> struct ff_interactive_effect {
> __u16 right_saturation[2]; /* Max level when joystick is on the
> right */
> __u16 left_saturation[2]; /* Max level when joystick in on the
> left */
>
> __s16 right_coeff[2]; /* Indicates how fast the force grows when
> the
> joystick moves to the right */
> __s16 left_coeff[2]; /* Same for left side */
>
> __u16 deadband[2]; /* Size of area where no force is produced
> */
> __s16 center[2]; /* Position of dead zone */
>
> };
>
> Note the arrays. There is one value for each axis. The axis mumber has
> become useless and has therefore been droped.
>
> * ff_periodic_effect:
> struct ff_periodic_effect {
> __u16 waveform; /* Kind of wave (sine, square...) */
> __u16 period; /* in ms */
> __s16 magnitude; /* Peak value */
> __s16 offset; /* Mean value of wave (roughly) */
> __u16 phase; /* 'Horizontal' shift */
>
> struct ff_shape shape;
>
> /* Only used if waveform == FF_CUSTOM */
> __u32 custom_len; /* Number of samples */
> __s16 *custom_data; /* Buffer of samples */
> /* Note: the data pointed by custom_data is copied by the driver. You can
> * therefore dispose of the memory after the upload/update */
> };
>
> The _u32 for the number of samples is a bit oversized, maybe.
>
>
> I think that's all for now. Comments and critics welcome.
Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well?
--
Vojtech Pavlik
SuSE Labs
|
|
From: Johann D. <jo...@Do...> - 2002-01-31 21:44:40
|
On Thu, 31 Jan 2002, Vojtech Pavlik wrote: > > Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well? > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger effects when a button is pushed. -- Johann Deneux |
|
From: Vojtech P. <vo...@su...> - 2002-02-01 07:19:23
|
On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote: > On Thu, 31 Jan 2002, Vojtech Pavlik wrote: > > > > > Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well? > > > > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger > effects when a button is pushed. Is there ever any difference between EV_KEY defined buttons and those in FF_BTN? Just checking ... -- Vojtech Pavlik SuSE Labs |
|
From: Johann D. <jo...@Do...> - 2002-02-01 08:58:21
|
On Fri, 1 Feb 2002, Vojtech Pavlik wrote: > On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote: > > On Thu, 31 Jan 2002, Vojtech Pavlik wrote: > > > > > > > > Looks OK. Maybe we should get rid of FF_ABS then? Maybe FF_BTN as well? > > > > > > > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger > > effects when a button is pushed. > > Is there ever any difference between EV_KEY defined buttons and those in > FF_BTN? Just checking ... > No, you are right, a button is a button, no need to have both regular buttons and force-feedback buttons. -- Johann Deneux |
|
From: Bj|rn A. <d3a...@dt...> - 2002-02-01 15:33:52
|
Quoting Johann Deneux <jo...@Do...>: > On Fri, 1 Feb 2002, Vojtech Pavlik wrote: > > On Thu, Jan 31, 2002 at 10:44:28PM +0100, Johann Deneux wrote: > > > On Thu, 31 Jan 2002, Vojtech Pavlik wrote: > > > > > > For FF_ABS, maybe, but FF_BTN is still needed. It is used to trigger > > > effects when a button is pushed. > > > > Is there ever any difference between EV_KEY defined buttons and those in > > FF_BTN? Just checking ... > > > No, you are right, a button is a button, no need to have both regular > buttons and force-feedback buttons. Well, again I'm at work and haven't got the spec here, but I think it says that not all buttons are neccessarily available as FF-trigger buttons. On my joystick they all are, and while that's not exactly a statistically significant sample, I can't really see any reason not to have all of them FF-capable. Ah, The deadman grip, if reported as a button, shouldn't be FF-capable. (It kills all effects if you drop the stick.) BTW, if anyone has a MS FF racing wheel, I'd be a happy man if they would send me the report descriptor for it. /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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X