Re: [RFC 1/2] Input: ff, add FF_RAW effect
On 4/18/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: johann deneux napsal(a): > Jiri, > > Which solution did you chose to implement? From what I remember, we > last discussed Dmitry's idea of specifying an axis for an effect, then > combine several effects to achieve complex effects. I think you mean motor instead of axis, because I don't push real axes to the devices, but motor's torques... Yes, sorry, I meant motor. -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] Input: ff, add FF_RAW effect
Jiri, Which solution did you chose to implement? From what I remember, we last discussed Dmitry's idea of specifying an axis for an effect, then combine several effects to achieve complex effects. The implementation would specify the axis using the upper bits of the effect type. The patches you have sent seem to implement an easier, but in my opinion inferior solution. If this FF_RAW effect does not have semantics which are meaningful for other kinds of devices, I think using the FF API is not a good idea. On 4/17/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: So fellows, what about these ones? -- ff, add FF_RAW effect Add new FF_RAW effect for devices such Phantom. The new model has up to 6DOF torque force feedback independent on any 3d-or-so value. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] Input: ff, add FF_RAW effect
Jiri, Which solution did you chose to implement? From what I remember, we last discussed Dmitry's idea of specifying an axis for an effect, then combine several effects to achieve complex effects. The implementation would specify the axis using the upper bits of the effect type. The patches you have sent seem to implement an easier, but in my opinion inferior solution. If this FF_RAW effect does not have semantics which are meaningful for other kinds of devices, I think using the FF API is not a good idea. On 4/17/07, Jiri Slaby [EMAIL PROTECTED] wrote: So fellows, what about these ones? -- ff, add FF_RAW effect Add new FF_RAW effect for devices such Phantom. The new model has up to 6DOF torque force feedback independent on any 3d-or-so value. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/2] Input: ff, add FF_RAW effect
On 4/18/07, Jiri Slaby [EMAIL PROTECTED] wrote: johann deneux napsal(a): Jiri, Which solution did you chose to implement? From what I remember, we last discussed Dmitry's idea of specifying an axis for an effect, then combine several effects to achieve complex effects. I think you mean motor instead of axis, because I don't push real axes to the devices, but motor's torques... Yes, sorry, I meant motor. -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Ok, so how to deal with these devices? Does anybody have some idea? That's
what I was talking about somewhere in the beginning of this thread, the raw
values, because it seems too specific for letting kernel to cope with each
of these devices separately, but there might be a better idea in somebody's
head? But raw is ugly...
What about adding a member to ff_effect which would be the number of the motor?
We can't change the layout of ff_effect too much though, so we have to
find unused bits and put them to work.
For instance, we could replace
__u16 type;
by
__u8 motor;
__u8 type;
since 16 bits seems way more than needed for the effect type.
Another possibility is to get rid of "trigger" and replace it by __u8
motor and some padding, since that's I-Force specific (are there other
drivers that implement that?). The goal of "trigger" is to start an
effect when a button is pressed, which can be done from userland
instead. It's not like we need micro-second latency when starting
effects.
As a reminder, here is the current definition of ff_effect:
struct ff_effect {
__u16 type;
__s16 id;
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_ramp_effect ramp;
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
} u;
};
--
Johann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: johann deneux napsal(a): > On 3/27/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: >> Dmitry Torokhov napsal(a): >> > On Wednesday 21 March 2007 18:03, johann deneux wrote: >> >> I have forgotten the details of ioctl: Wouldn't the >> >> following work? >> >> No, at least, as far as I understand this. I have computed _torques_, not >> forces vector (this was misleading info in my first post), the >> question is >> "how can I pass torques through plane and direction entries into KS?". > > Torques and forces are both represented as 3d vectors. Yes, may be. > Are we > misunderstanding eachother maybe? By "vector" I mean a triplet of > numbers, when you say "torques" and "forces vector", do you mean that > each effect is composed of a bunch of torques? Ok, let's make things a little bit clear. I need to put somehow 3 short values (torques -- to tell 3 motors how much to spin around) into the kernel space via ff layer. I computed them using FP in US from forces (3d vector) and the problem is, that I don't know how to transform torques to plane(s) and dir and then back to torques -- this is what I can't figure out, since I have no longer vector -- 3 values for each axis, which says how big is the force in each axis -- but I have values (no axis) specific to each motor. I think I'm starting to understand. Looking back at the url you gave, it appears your device is some kind of articulated arm, possibly with one or more motor(s) at each joint. You are not really dealing with a single torque applied at one point in space, but several torques applied at several points in space. For this particular device you have three values, but for other devices it could just as well be any other number, right? A realistic example would be a robot arm with claws, there would be a torque for each joint, and some more for the claws. -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov napsal(a):
> On Wednesday 21 March 2007 18:03, johann deneux wrote:
>> On 3/21/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
>>> Dmitry Torokhov napsal(a):
>>>> On 3/21/07, johann deneux <[EMAIL PROTECTED]> wrote:
>>>>> I would suggest adding a new effect type (3d effect) and extending the
>>>>> union in struct ff_effect.
>>>>> Let me know if I'm too vague, I already suggested that solution but
>>>>> got no answer. I wonder if my mail got lost, nobody understood what I
>>>>> said, or if it's just a plain bad idea.
>>>>>
>>>> My concern with a new 3D effect is that it will be a very "simple"
>>>> effect with only constant force apllied. That might be enough for
>>>> phantom but may not be sufficient for future devices. If we add
>>>> ability to specify a "plane" for an effect we will be able to add
>>>> envelopes on top of more complex effects and get desired combined
>>>> effcet.
>>> I didn't get this too much, because I don't understand the FF layer well so
>>> far. How is this going to work? Let's say, we have 3 torque values computed
>>> in US, and this structure:
>>>
>>> struct ff_effect {
>>> __u16 direction;
>>> struct ff_trigger trigger;
>>> struct ff_replay replay;
>>>
>>> struct ff_constant_effect {
>>> __s16 level;
>>> struct ff_envelope {
>>> __u16 attack_length;
>>> __u16 attack_level;
>>> __u16 fade_length;
>>> __u16 fade_level;
>>> };
>>> };
>>> };
>>>
>>> and need to pass the three 16bits torques into s16 ioaddr[0..2]. How?
>>>
>> Stupid question,
Sorry to be out for so long, maybe I'm stupid idiot, that understands
nothing, but:
No, it's not you, there are still things that are unclear. For
instance I think Dmitry intended to combine several planes, which I
don't understand.
What we want is to specify a 3d vector, which can be done using two
angles and a magnitude.
One angle and the magnitude we already have in ff_effect, so all we
need is an additional angle, which can be specified using a new ioctl.
I originally thought it could be done without a new ioctl, just by
extending ff_struct, but that won't work.
>> I have forgotten the details of ioctl: Wouldn't the
>> following work?
No, at least, as far as I understand this. I have computed _torques_, not
forces vector (this was misleading info in my first post), the question is
"how can I pass torques through plane and direction entries into KS?".
Torques and forces are both represented as 3d vectors. Are we
misunderstanding eachother maybe? By "vector" I mean a triplet of
numbers, when you say "torques" and "forces vector", do you mean that
each effect is composed of a bunch of torques?
--
Johann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Dmitry Torokhov napsal(a):
On Wednesday 21 March 2007 18:03, johann deneux wrote:
On 3/21/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Dmitry Torokhov napsal(a):
On 3/21/07, johann deneux [EMAIL PROTECTED] wrote:
I would suggest adding a new effect type (3d effect) and extending the
union in struct ff_effect.
Let me know if I'm too vague, I already suggested that solution but
got no answer. I wonder if my mail got lost, nobody understood what I
said, or if it's just a plain bad idea.
My concern with a new 3D effect is that it will be a very simple
effect with only constant force apllied. That might be enough for
phantom but may not be sufficient for future devices. If we add
ability to specify a plane for an effect we will be able to add
envelopes on top of more complex effects and get desired combined
effcet.
I didn't get this too much, because I don't understand the FF layer well so
far. How is this going to work? Let's say, we have 3 torque values computed
in US, and this structure:
struct ff_effect {
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
struct ff_constant_effect {
__s16 level;
struct ff_envelope {
__u16 attack_length;
__u16 attack_level;
__u16 fade_length;
__u16 fade_level;
};
};
};
and need to pass the three 16bits torques into s16 ioaddr[0..2]. How?
Stupid question,
Sorry to be out for so long, maybe I'm stupid idiot, that understands
nothing, but:
No, it's not you, there are still things that are unclear. For
instance I think Dmitry intended to combine several planes, which I
don't understand.
What we want is to specify a 3d vector, which can be done using two
angles and a magnitude.
One angle and the magnitude we already have in ff_effect, so all we
need is an additional angle, which can be specified using a new ioctl.
I originally thought it could be done without a new ioctl, just by
extending ff_struct, but that won't work.
I have forgotten the details of ioctl: Wouldn't the
following work?
No, at least, as far as I understand this. I have computed _torques_, not
forces vector (this was misleading info in my first post), the question is
how can I pass torques through plane and direction entries into KS?.
Torques and forces are both represented as 3d vectors. Are we
misunderstanding eachother maybe? By vector I mean a triplet of
numbers, when you say torques and forces vector, do you mean that
each effect is composed of a bunch of torques?
--
Johann
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby [EMAIL PROTECTED] wrote: johann deneux napsal(a): On 3/27/07, Jiri Slaby [EMAIL PROTECTED] wrote: Dmitry Torokhov napsal(a): On Wednesday 21 March 2007 18:03, johann deneux wrote: I have forgotten the details of ioctl: Wouldn't the following work? No, at least, as far as I understand this. I have computed _torques_, not forces vector (this was misleading info in my first post), the question is how can I pass torques through plane and direction entries into KS?. Torques and forces are both represented as 3d vectors. Yes, may be. Are we misunderstanding eachother maybe? By vector I mean a triplet of numbers, when you say torques and forces vector, do you mean that each effect is composed of a bunch of torques? Ok, let's make things a little bit clear. I need to put somehow 3 short values (torques -- to tell 3 motors how much to spin around) into the kernel space via ff layer. I computed them using FP in US from forces (3d vector) and the problem is, that I don't know how to transform torques to plane(s) and dir and then back to torques -- this is what I can't figure out, since I have no longer vector -- 3 values for each axis, which says how big is the force in each axis -- but I have values (no axis) specific to each motor. I think I'm starting to understand. Looking back at the url you gave, it appears your device is some kind of articulated arm, possibly with one or more motor(s) at each joint. You are not really dealing with a single torque applied at one point in space, but several torques applied at several points in space. For this particular device you have three values, but for other devices it could just as well be any other number, right? A realistic example would be a robot arm with claws, there would be a torque for each joint, and some more for the claws. -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/27/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Ok, so how to deal with these devices? Does anybody have some idea? That's
what I was talking about somewhere in the beginning of this thread, the raw
values, because it seems too specific for letting kernel to cope with each
of these devices separately, but there might be a better idea in somebody's
head? But raw is ugly...
What about adding a member to ff_effect which would be the number of the motor?
We can't change the layout of ff_effect too much though, so we have to
find unused bits and put them to work.
For instance, we could replace
__u16 type;
by
__u8 motor;
__u8 type;
since 16 bits seems way more than needed for the effect type.
Another possibility is to get rid of trigger and replace it by __u8
motor and some padding, since that's I-Force specific (are there other
drivers that implement that?). The goal of trigger is to start an
effect when a button is pressed, which can be done from userland
instead. It's not like we need micro-second latency when starting
effects.
As a reminder, here is the current definition of ff_effect:
struct ff_effect {
__u16 type;
__s16 id;
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_ramp_effect ramp;
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
} u;
};
--
Johann
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/21/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov napsal(a):
> On 3/21/07, johann deneux <[EMAIL PROTECTED]> wrote:
>> I would suggest adding a new effect type (3d effect) and extending the
>> union in struct ff_effect.
>> Let me know if I'm too vague, I already suggested that solution but
>> got no answer. I wonder if my mail got lost, nobody understood what I
>> said, or if it's just a plain bad idea.
>>
>
> My concern with a new 3D effect is that it will be a very "simple"
> effect with only constant force apllied. That might be enough for
> phantom but may not be sufficient for future devices. If we add
> ability to specify a "plane" for an effect we will be able to add
> envelopes on top of more complex effects and get desired combined
> effcet.
I didn't get this too much, because I don't understand the FF layer well so
far. How is this going to work? Let's say, we have 3 torque values computed
in US, and this structure:
struct ff_effect {
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
struct ff_constant_effect {
__s16 level;
struct ff_envelope {
__u16 attack_length;
__u16 attack_level;
__u16 fade_length;
__u16 fade_level;
};
};
};
and need to pass the three 16bits torques into s16 ioaddr[0..2]. How?
Stupid question, I have forgotten the details of ioctl: Wouldn't the
following work?
struct ff_effect {
__u16 type;
__s16 id;
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_ramp_effect ramp;
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
} u;
/* New member: Specify a plane in the 3d space. */
struct ff_plane plane;
};
Would that pose compatibility issues? If the input layer knows the
size of the struct the user-space application is sending, it knows if
it's safe to look into the "plane" member. If it is, and the device
driver is capable of handling 3d effects, then fine. If it is but the
device driver can't handle it, return an error code. If it isn't, just
do whatever it's currently doing.
Alternatively, one could leave ff_effect effect untouched and find
another way to specify the plane, e.g. another ioctl.
--
Johann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/21/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: STenyaK (Bruno González) napsal(a): > On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: >> > I have a question: if the force is to be 3D, why only 3 possible >> values? >> > What would they be, 3 torques or 3 forces? In the case of car sims (ff >> > steering wheels), only one axis of torque is usually used (except >> for 6 dof >> > platforms, as mentioned). >> > >> >> I wonder if we could somehow extend or augment FF envelope se we could >> specify a plane for the effect.. Then a vector could be represented by >> a sum 3 constant effects in 3 separate planes and we could also use >> spring and other effects as well. > > Ideally, afaik we should use: > -3 values for translation force (linear force): x,y,z components of > the force vector. > -4 values for rotation force (torque): x,y,z,w components of the > quaternion. You can also use euler angles (and i think there are > another one or two notations), which is just 3 values, but i'm not > sure it will be a correct decision (due to the gimbal lock problem, > which may or may not be present in ff devices, dunno). So, the resolution is? Since I want no longer have out-of-kernel driver, I need to know how to implement the phantom driver -- merge it `as is', i.e. control through mmio or rewrite ff layer somehow, and in that case how? There seem to be only few possibilities: - new 3D effect, which will be problematic in any other future use, that may need more than 3 axis. no matter if torques or vector is passed -- depending on device and programmer (as I need to compute torques from forces in FP). Maybe struct with 2x 3 axis is OK - "raw" effect, which may contain more axis, but this is ugly in Anssi's eyes - something else? (did I forget something) I would suggest adding a new effect type (3d effect) and extending the union in struct ff_effect. Let me know if I'm too vague, I already suggested that solution but got no answer. I wonder if my mail got lost, nobody understood what I said, or if it's just a plain bad idea. For future devices with more than 3 FF-enabled axes, we can just do the same, or develop a whole new API. There shouldn't be any worry. -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/21/07, Jiri Slaby [EMAIL PROTECTED] wrote: STenyaK (Bruno González) napsal(a): On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: I have a question: if the force is to be 3D, why only 3 possible values? What would they be, 3 torques or 3 forces? In the case of car sims (ff steering wheels), only one axis of torque is usually used (except for 6 dof platforms, as mentioned). I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. Ideally, afaik we should use: -3 values for translation force (linear force): x,y,z components of the force vector. -4 values for rotation force (torque): x,y,z,w components of the quaternion. You can also use euler angles (and i think there are another one or two notations), which is just 3 values, but i'm not sure it will be a correct decision (due to the gimbal lock problem, which may or may not be present in ff devices, dunno). So, the resolution is? Since I want no longer have out-of-kernel driver, I need to know how to implement the phantom driver -- merge it `as is', i.e. control through mmio or rewrite ff layer somehow, and in that case how? There seem to be only few possibilities: - new 3D effect, which will be problematic in any other future use, that may need more than 3 axis. no matter if torques or vector is passed -- depending on device and programmer (as I need to compute torques from forces in FP). Maybe struct with 2x 3 axis is OK - raw effect, which may contain more axis, but this is ugly in Anssi's eyes - something else? (did I forget something) I would suggest adding a new effect type (3d effect) and extending the union in struct ff_effect. Let me know if I'm too vague, I already suggested that solution but got no answer. I wonder if my mail got lost, nobody understood what I said, or if it's just a plain bad idea. For future devices with more than 3 FF-enabled axes, we can just do the same, or develop a whole new API. There shouldn't be any worry. -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/21/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Dmitry Torokhov napsal(a):
On 3/21/07, johann deneux [EMAIL PROTECTED] wrote:
I would suggest adding a new effect type (3d effect) and extending the
union in struct ff_effect.
Let me know if I'm too vague, I already suggested that solution but
got no answer. I wonder if my mail got lost, nobody understood what I
said, or if it's just a plain bad idea.
My concern with a new 3D effect is that it will be a very simple
effect with only constant force apllied. That might be enough for
phantom but may not be sufficient for future devices. If we add
ability to specify a plane for an effect we will be able to add
envelopes on top of more complex effects and get desired combined
effcet.
I didn't get this too much, because I don't understand the FF layer well so
far. How is this going to work? Let's say, we have 3 torque values computed
in US, and this structure:
struct ff_effect {
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
struct ff_constant_effect {
__s16 level;
struct ff_envelope {
__u16 attack_length;
__u16 attack_level;
__u16 fade_length;
__u16 fade_level;
};
};
};
and need to pass the three 16bits torques into s16 ioaddr[0..2]. How?
Stupid question, I have forgotten the details of ioctl: Wouldn't the
following work?
struct ff_effect {
__u16 type;
__s16 id;
__u16 direction;
struct ff_trigger trigger;
struct ff_replay replay;
union {
struct ff_constant_effect constant;
struct ff_ramp_effect ramp;
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
} u;
/* New member: Specify a plane in the 3d space. */
struct ff_plane plane;
};
Would that pose compatibility issues? If the input layer knows the
size of the struct the user-space application is sending, it knows if
it's safe to look into the plane member. If it is, and the device
driver is capable of handling 3d effects, then fine. If it is but the
device driver can't handle it, return an error code. If it isn't, just
do whatever it's currently doing.
Alternatively, one could leave ff_effect effect untouched and find
another way to specify the plane, e.g. another ioctl.
--
Johann
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/16/07, Pavel Machek <[EMAIL PROTECTED]> wrote: Hi! > >Why did you remove all Cced people? Anyway I filtered > >some of them out > > > >johann deneux napsal(a): > >> You are right, the direction in ff_effect is meant to > >be an angle. > >> A dirty solution would be to use the 16 bits as two > >8-bits angles. Or > > > >That would be a problem as I need 3x 16bits. > > > >> maybe we should change the API. I don't think there > >are many > >> applications using force feedback yet, so maybe that > >should be ok? > >> > >> If we change the API, we should remove the assumption > >that a device has > >> at most two axes to render effects. We could for > >instance have a > >> magnitude argument for each axis which is capable of > >rendering effects. > >> That might be necessary even for more common gaming > >devices like racing > >> wheels: One can think pedals could also be capable of > >force feedback > >> some day, not just the steering wheel. > > > >I can do that, but in that case, I need to know how > >people (especially those > >input one) want me to do... > > > > Since we have no idea how many programs (if any) are > using force > feedback interface I would be wary of changing existing > effcets and > rather add new set of 3D effects. > > Do we have any idea if there any users of FF out there? Number of linux games is quite low, so... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Games are not the only application type using FF. I got a few enquiries from universities working on robotics project. I think keeping backward compatibility is not a problem here. The problem is to make an extension that does not duplicate the capabilities of the existing API. We don't want to have two ways of specifying the same effects. -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/16/07, Pavel Machek [EMAIL PROTECTED] wrote: Hi! Why did you remove all Cced people? Anyway I filtered some of them out johann deneux napsal(a): You are right, the direction in ff_effect is meant to be an angle. A dirty solution would be to use the 16 bits as two 8-bits angles. Or That would be a problem as I need 3x 16bits. maybe we should change the API. I don't think there are many applications using force feedback yet, so maybe that should be ok? If we change the API, we should remove the assumption that a device has at most two axes to render effects. We could for instance have a magnitude argument for each axis which is capable of rendering effects. That might be necessary even for more common gaming devices like racing wheels: One can think pedals could also be capable of force feedback some day, not just the steering wheel. I can do that, but in that case, I need to know how people (especially those input one) want me to do... Since we have no idea how many programs (if any) are using force feedback interface I would be wary of changing existing effcets and rather add new set of 3D effects. Do we have any idea if there any users of FF out there? Number of linux games is quite low, so... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Games are not the only application type using FF. I got a few enquiries from universities working on robotics project. I think keeping backward compatibility is not a problem here. The problem is to make an extension that does not duplicate the capabilities of the existing API. We don't want to have two ways of specifying the same effects. -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/14/07, STenyaK (Bruno González) <[EMAIL PROTECTED]> wrote: On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > I have a question: if the force is to be 3D, why only 3 possible values? > > What would they be, 3 torques or 3 forces? In the case of car sims (ff > > steering wheels), only one axis of torque is usually used (except for 6 dof > > platforms, as mentioned). > > > > I wonder if we could somehow extend or augment FF envelope se we could > specify a plane for the effect.. Then a vector could be represented by > a sum 3 constant effects in 3 separate planes and we could also use > spring and other effects as well. I would think one plane and one axis is all that's needed for a 3d vector, or? Do we understand eachother? Ideally, afaik we should use: -3 values for translation force (linear force): x,y,z components of the force vector. -4 values for rotation force (torque): x,y,z,w components of the quaternion. You can also use euler angles (and i think there are another one or two notations), which is just 3 values, but i'm not sure it will be a correct decision (due to the gimbal lock problem, which may or may not be present in ff devices, dunno). Same remark here. A torque is a 3-dimensional thing, just like a force. What for do you need 4 components? -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: On 3/14/07, STenyaK (Bruno González) <[EMAIL PROTECTED]> wrote: > > > On 3/14/07, Anssi Hannula <[EMAIL PROTECTED]> wrote: > > >> Do we have any idea if there any users of FF out there? > > > > > > At least me :). I'm using it for wheel and joystick in modules for > locally > > > developped multiplatform virtual reality system. > > > > Wine and BZflag come to mind, though I think the support is quite > > limited in both. > > > > There's also vDrift (racing sim), they added support very recently. > I plan to add it in my car sim too, but there's still nothing coded. > > I have a question: if the force is to be 3D, why only 3 possible values? > What would they be, 3 torques or 3 forces? In the case of car sims (ff > steering wheels), only one axis of torque is usually used (except for 6 dof > platforms, as mentioned). > I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. I don't think struct ff_envelope is a good candidate: Spring effects don't have any envelope. We have plenty of space for new effect types. Why not add a bunch of new types, and add more structs in the ff_effect union? The other option where you somehow manage to specify planes and combine several effects is a good solution for devices where the driver is responsible for storing effects, but it's wasteful for I-Force-like devices where the effects are stored on the device. You would be using two (or more) effects in the device's memory where only one would be used if you used all the potential of the device. That is, unless the driver is smart enough to merge effects, but that seems hard. -- Johann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 3/14/07, STenyaK (Bruno González) [EMAIL PROTECTED] wrote: On 3/14/07, Anssi Hannula [EMAIL PROTECTED] wrote: Do we have any idea if there any users of FF out there? At least me :). I'm using it for wheel and joystick in modules for locally developped multiplatform virtual reality system. Wine and BZflag come to mind, though I think the support is quite limited in both. There's also vDrift (racing sim), they added support very recently. I plan to add it in my car sim too, but there's still nothing coded. I have a question: if the force is to be 3D, why only 3 possible values? What would they be, 3 torques or 3 forces? In the case of car sims (ff steering wheels), only one axis of torque is usually used (except for 6 dof platforms, as mentioned). I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. I don't think struct ff_envelope is a good candidate: Spring effects don't have any envelope. We have plenty of space for new effect types. Why not add a bunch of new types, and add more structs in the ff_effect union? The other option where you somehow manage to specify planes and combine several effects is a good solution for devices where the driver is responsible for storing effects, but it's wasteful for I-Force-like devices where the effects are stored on the device. You would be using two (or more) effects in the device's memory where only one would be used if you used all the potential of the device. That is, unless the driver is smart enough to merge effects, but that seems hard. -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/14/07, STenyaK (Bruno González) [EMAIL PROTECTED] wrote: On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: I have a question: if the force is to be 3D, why only 3 possible values? What would they be, 3 torques or 3 forces? In the case of car sims (ff steering wheels), only one axis of torque is usually used (except for 6 dof platforms, as mentioned). I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. I would think one plane and one axis is all that's needed for a 3d vector, or? Do we understand eachother? Ideally, afaik we should use: -3 values for translation force (linear force): x,y,z components of the force vector. -4 values for rotation force (torque): x,y,z,w components of the quaternion. You can also use euler angles (and i think there are another one or two notations), which is just 3 values, but i'm not sure it will be a correct decision (due to the gimbal lock problem, which may or may not be present in ff devices, dunno). Same remark here. A torque is a 3-dimensional thing, just like a force. What for do you need 4 components? -- Johann - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
