Re: [RFC 1/2] Input: ff, add FF_RAW effect
Dmitry Torokhov napsal(a): > On 4/22/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: >> I think we won't be able to make the transition in independent way >> due to unspecified meaning of the torques. >> > > With phantom it still seems doable - if I understand correctly ther is > one point of containct and one resulting vector of forces applied to > user's hand. With the glove there are multiple points of contact and > multiple feedback effects applied to different part of hand > simultaneously and that is for sure requires special application. Hi. Good news are, that I've got openhaptics (OS independent layer for sensable devices) under academic license (I don't know, what the "open" word in that name means -- no sourcecodes; licensed), the bad ones are, that they use ioctl approach for both reporting and FF. Furthermore I tried phantom with input layer in X and realized, that it's needed to compute real axies from that numbers and that's what I'm doing in userspace with doubke precision. Ok, so the question is if the old ioctl approach (something which I posted as a first patch before we ever starrted to talk about FF and input layer without mmaping anything to US) is acceptable alone (this is what is needed for OHaptics) or at least some particular computing to convert the numbers and reporting to input layer should be implemented (which will have no users anyway, who will ever want to have 6$ pointer ;))? thanks a lot, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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/22/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: On 4/19/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > On 4/19/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: > > Dmitry Torokhov napsal(a): > > > If we are interested in using FF API we need to come up with a way > > > to express this effect without exposing implementation details of > > > one particular device. > > > > Still, torques are better named raw/motor values, which goes to the device > > and I'm sceptic about inventing something class-better than this. > > > > Well, I guess we need to make a decision whether moving this kind of > devices into a force feedback layer is possible or whether every > device needs to have an application specifically tailored to that > particular device. > > If we say that it is feasible to plug a device into FF layer then we > must not expose hardware implementation details. That means that > device-sepcific translation between 3d vector of forces into motor > torques must be done by the driver itself. Hmm, it's 3d at minimum (the glove has 14 torque points, phantom up to 6), The vector of forces is always 3d in our world. I think we won't be able to make the transition in independent way due to unspecified meaning of the torques. With phantom it still seems doable - if I understand correctly ther is one point of containct and one resulting vector of forces applied to user's hand. With the glove there are multiple points of contact and multiple feedback effects applied to different part of hand simultaneously and that is for sure requires special application. -- Dmitry - 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
Hi Jiri,
On 4/23/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov napsal(a):
> For devices that require tailored application (for example that glove
> - I am not sure how a generic application could control it) old
> phantom way of controlling via ioctl will suffice. The device may
> still use input layer to report back coordinates.
And how about the individual FF ioctl? Did you mean registering another
chardev, which is totally ugly in my eyes or augment evdev.c to support
driver specific ioctl? i.e. either add another 'E' ioctl with pointer to
struct { code, value } as arg param or changing
if (_IOC_TYPE(cmd) != 'E'))
return -EINVAL;
to sth. like
if (_IOC_TYPE(cmd) != 'E'))
return dev->ioctl ? dev->ioctl(file, cmd, p) : -EINVAL;
in evdev_ioctl_handler, which is acceptable?
I really do not want to have driver-specific ioctls attaching to
evdev. What is wrong with a separate device to control phantom? You
won't even have to use ioctl but regial write on it.
--
Dmitry
-
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
Hi Jiri,
On 4/23/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Dmitry Torokhov napsal(a):
For devices that require tailored application (for example that glove
- I am not sure how a generic application could control it) old
phantom way of controlling via ioctl will suffice. The device may
still use input layer to report back coordinates.
And how about the individual FF ioctl? Did you mean registering another
chardev, which is totally ugly in my eyes or augment evdev.c to support
driver specific ioctl? i.e. either add another 'E' ioctl with pointer to
struct { code, value } as arg param or changing
if (_IOC_TYPE(cmd) != 'E'))
return -EINVAL;
to sth. like
if (_IOC_TYPE(cmd) != 'E'))
return dev-ioctl ? dev-ioctl(file, cmd, p) : -EINVAL;
in evdev_ioctl_handler, which is acceptable?
I really do not want to have driver-specific ioctls attaching to
evdev. What is wrong with a separate device to control phantom? You
won't even have to use ioctl but regial write on it.
--
Dmitry
-
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/22/07, Jiri Slaby [EMAIL PROTECTED] wrote: On 4/19/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 4/19/07, Jiri Slaby [EMAIL PROTECTED] wrote: Dmitry Torokhov napsal(a): If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. Hmm, it's 3d at minimum (the glove has 14 torque points, phantom up to 6), The vector of forces is always 3d in our world. I think we won't be able to make the transition in independent way due to unspecified meaning of the torques. With phantom it still seems doable - if I understand correctly ther is one point of containct and one resulting vector of forces applied to user's hand. With the glove there are multiple points of contact and multiple feedback effects applied to different part of hand simultaneously and that is for sure requires special application. -- Dmitry - 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
Dmitry Torokhov napsal(a): On 4/22/07, Jiri Slaby [EMAIL PROTECTED] wrote: I think we won't be able to make the transition in independent way due to unspecified meaning of the torques. With phantom it still seems doable - if I understand correctly ther is one point of containct and one resulting vector of forces applied to user's hand. With the glove there are multiple points of contact and multiple feedback effects applied to different part of hand simultaneously and that is for sure requires special application. Hi. Good news are, that I've got openhaptics (OS independent layer for sensable devices) under academic license (I don't know, what the open word in that name means -- no sourcecodes; licensed), the bad ones are, that they use ioctl approach for both reporting and FF. Furthermore I tried phantom with input layer in X and realized, that it's needed to compute real axies from that numbers and that's what I'm doing in userspace with doubke precision. Ok, so the question is if the old ioctl approach (something which I posted as a first patch before we ever starrted to talk about FF and input layer without mmaping anything to US) is acceptable alone (this is what is needed for OHaptics) or at least some particular computing to convert the numbers and reporting to input layer should be implemented (which will have no users anyway, who will ever want to have 6$ pointer ;))? thanks a lot, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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
Dmitry Torokhov napsal(a):
> For devices that require tailored application (for example that glove
> - I am not sure how a generic application could control it) old
> phantom way of controlling via ioctl will suffice. The device may
> still use input layer to report back coordinates.
And how about the individual FF ioctl? Did you mean registering another
chardev, which is totally ugly in my eyes or augment evdev.c to support
driver specific ioctl? i.e. either add another 'E' ioctl with pointer to
struct { code, value } as arg param or changing
if (_IOC_TYPE(cmd) != 'E'))
return -EINVAL;
to sth. like
if (_IOC_TYPE(cmd) != 'E'))
return dev->ioctl ? dev->ioctl(file, cmd, p) : -EINVAL;
in evdev_ioctl_handler, which is acceptable?
thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
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
Dmitry Torokhov napsal(a):
For devices that require tailored application (for example that glove
- I am not sure how a generic application could control it) old
phantom way of controlling via ioctl will suffice. The device may
still use input layer to report back coordinates.
And how about the individual FF ioctl? Did you mean registering another
chardev, which is totally ugly in my eyes or augment evdev.c to support
driver specific ioctl? i.e. either add another 'E' ioctl with pointer to
struct { code, value } as arg param or changing
if (_IOC_TYPE(cmd) != 'E'))
return -EINVAL;
to sth. like
if (_IOC_TYPE(cmd) != 'E'))
return dev-ioctl ? dev-ioctl(file, cmd, p) : -EINVAL;
in evdev_ioctl_handler, which is acceptable?
thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
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/19/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: On 4/19/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: > Dmitry Torokhov napsal(a): > > If we are interested in using FF API we need to come up with a way > > to express this effect without exposing implementation details of > > one particular device. > > Still, torques are better named raw/motor values, which goes to the device > and I'm sceptic about inventing something class-better than this. > Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. Hmm, it's 3d at minimum (the glove has 14 torque points, phantom up to 6), I think we won't be able to make the transition in independent way due to unspecified meaning of the torques. For devices that require tailored application (for example that glove - I am not sure how a generic application could control it) old phantom way of controlling via ioctl will suffice. The device may still use input layer to report back coordinates. Ok, nobody seems to have an idea, I'm going to avoid FF layer in the code and hope this is the final change ;). thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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/19/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 4/19/07, Jiri Slaby [EMAIL PROTECTED] wrote: Dmitry Torokhov napsal(a): If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. Hmm, it's 3d at minimum (the glove has 14 torque points, phantom up to 6), I think we won't be able to make the transition in independent way due to unspecified meaning of the torques. For devices that require tailored application (for example that glove - I am not sure how a generic application could control it) old phantom way of controlling via ioctl will suffice. The device may still use input layer to report back coordinates. Ok, nobody seems to have an idea, I'm going to avoid FF layer in the code and hope this is the final change ;). thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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/19/07, Jiri Slaby <[EMAIL PROTECTED]> wrote: Dmitry Torokhov napsal(a): > I have been thinking about this and I don't think that exporting motor > data is a good idea, at least not in case of Phantom driver. The fact > that there are 3 motors is a hardware implementation detail and it > is not interesting for general application. Ok, so what about torques (despite it's still something like FF_RAW or motor descriptor)? It seems not to be so bad called effect name -- not only phantom uses torques on motors as an unit of force, for example I get this by quick googling: http://www.caip.rutgers.edu/~bouzit/lrp/glove.html They use there some motors with 14 torque values too, so the phantom isn't the only device which uses this approach. > My understanding that the end result of controlling these 3 motors Actually there is also a version with 6 motors :). > is a force vector (I don't know if there is such english term, this > is a literal translation from russian) applied to user's hand. Better say torques vector. You must compute a torque for each place from the 3d (or bigger) vector of forces in different way for each device that exists -- this means forces are not independent unit, torques are in the meaning of layer which doesn't care about what is connected above and below it. > If we are interested in using FF API we need to come up with a way > to express this effect without exposing implementation details of > one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. For devices that require tailored application (for example that glove - I am not sure how a generic application could control it) old phantom way of controlling via ioctl will suffice. The device may still use input layer to report back coordinates. -- Dmitry - 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
Dmitry Torokhov napsal(a): > I have been thinking about this and I don't think that exporting motor > data is a good idea, at least not in case of Phantom driver. The fact > that there are 3 motors is a hardware implementation detail and it > is not interesting for general application. Ok, so what about torques (despite it's still something like FF_RAW or motor descriptor)? It seems not to be so bad called effect name -- not only phantom uses torques on motors as an unit of force, for example I get this by quick googling: http://www.caip.rutgers.edu/~bouzit/lrp/glove.html They use there some motors with 14 torque values too, so the phantom isn't the only device which uses this approach. > My understanding that the end result of controlling these 3 motors Actually there is also a version with 6 motors :). > is a force vector (I don't know if there is such english term, this > is a literal translation from russian) applied to user's hand. Better say torques vector. You must compute a torque for each place from the 3d (or bigger) vector of forces in different way for each device that exists -- this means forces are not independent unit, torques are in the meaning of layer which doesn't care about what is connected above and below it. > If we are interested in using FF API we need to come up with a way > to express this effect without exposing implementation details of > one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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
Dmitry Torokhov napsal(a): I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. Ok, so what about torques (despite it's still something like FF_RAW or motor descriptor)? It seems not to be so bad called effect name -- not only phantom uses torques on motors as an unit of force, for example I get this by quick googling: http://www.caip.rutgers.edu/~bouzit/lrp/glove.html They use there some motors with 14 torque values too, so the phantom isn't the only device which uses this approach. My understanding that the end result of controlling these 3 motors Actually there is also a version with 6 motors :). is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. Better say torques vector. You must compute a torque for each place from the 3d (or bigger) vector of forces in different way for each device that exists -- this means forces are not independent unit, torques are in the meaning of layer which doesn't care about what is connected above and below it. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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/19/07, Jiri Slaby [EMAIL PROTECTED] wrote: Dmitry Torokhov napsal(a): I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. Ok, so what about torques (despite it's still something like FF_RAW or motor descriptor)? It seems not to be so bad called effect name -- not only phantom uses torques on motors as an unit of force, for example I get this by quick googling: http://www.caip.rutgers.edu/~bouzit/lrp/glove.html They use there some motors with 14 torque values too, so the phantom isn't the only device which uses this approach. My understanding that the end result of controlling these 3 motors Actually there is also a version with 6 motors :). is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. Better say torques vector. You must compute a torque for each place from the 3d (or bigger) vector of forces in different way for each device that exists -- this means forces are not independent unit, torques are in the meaning of layer which doesn't care about what is connected above and below it. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. For devices that require tailored application (for example that glove - I am not sure how a generic application could control it) old phantom way of controlling via ioctl will suffice. The device may still use input layer to report back coordinates. -- Dmitry - 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
Hi, On Thursday 19 April 2007 00:25, johann deneux wrote: > 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. > I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. My understanding that the end result of controlling these 3 motors is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. -- Dmitry - 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: [RFC 1/2] Input: ff, add FF_RAW effect
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... > The implementation would specify the axis using the upper bits of the > effect type. Ok, if this is preferred, I'll post it with the const of having more context switches for a single effect. This was just a realization of the idea how I though it with the quick'n'dirty FF_RAW. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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
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... The implementation would specify the axis using the upper bits of the effect type. Ok, if this is preferred, I'll post it with the const of having more context switches for a single effect. This was just a realization of the idea how I though it with the quick'n'dirty FF_RAW. thanks, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: [RFC 1/2] Input: ff, add FF_RAW effect
Hi, On Thursday 19 April 2007 00:25, johann deneux wrote: 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. I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. My understanding that the end result of controlling these 3 motors is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. -- Dmitry - 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/
[RFC 1/2] Input: ff, add FF_RAW effect
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.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 759e7f172031959f49e5d3a7282379e7d73621b3
tree 906d51925ff7f95ebae8148ef2f1b2f252ef3f4e
parent bd99756ce7fb8f3e9105b076a71046b0d8ad1f8f
author Jiri Slaby <[EMAIL PROTECTED]> Tue, 17 Apr 2007 21:50:21 +0200
committer Jiri Slaby <[EMAIL PROTECTED]> Tue, 17 Apr 2007 21:50:21 +0200
drivers/input/ff-memless.c |4
include/linux/input.h |4 +++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index d226d93..3bbace9 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -275,6 +275,10 @@ static void ml_combine_effects(struct ff_effect *effect,
min(i + effect->u.rumble.weak_magnitude, 0xU);
break;
+ case FF_RAW:
+ memcpy(effect->u.ff_raw, new->u.ff_raw, sizeof(new->u.ff_raw));
+ break;
+
default:
printk(KERN_ERR "ff-memless: invalid type in
ml_combine_effects()\n");
break;
diff --git a/include/linux/input.h b/include/linux/input.h
index 2a23768..cc4ae1f 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -859,6 +859,7 @@ struct ff_effect {
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
+ __u32 ff_raw[6];
} u;
};
@@ -874,9 +875,10 @@ struct ff_effect {
#define FF_DAMPER 0x55
#define FF_INERTIA 0x56
#define FF_RAMP0x57
+#define FF_RAW 0x58
#define FF_EFFECT_MIN FF_RUMBLE
-#define FF_EFFECT_MAX FF_RAMP
+#define FF_EFFECT_MAX FF_RAW
/*
* Force feedback periodic effect types
-
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/
[RFC 1/2] Input: ff, add FF_RAW effect
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.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 759e7f172031959f49e5d3a7282379e7d73621b3
tree 906d51925ff7f95ebae8148ef2f1b2f252ef3f4e
parent bd99756ce7fb8f3e9105b076a71046b0d8ad1f8f
author Jiri Slaby [EMAIL PROTECTED] Tue, 17 Apr 2007 21:50:21 +0200
committer Jiri Slaby [EMAIL PROTECTED] Tue, 17 Apr 2007 21:50:21 +0200
drivers/input/ff-memless.c |4
include/linux/input.h |4 +++-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/input/ff-memless.c b/drivers/input/ff-memless.c
index d226d93..3bbace9 100644
--- a/drivers/input/ff-memless.c
+++ b/drivers/input/ff-memless.c
@@ -275,6 +275,10 @@ static void ml_combine_effects(struct ff_effect *effect,
min(i + effect-u.rumble.weak_magnitude, 0xU);
break;
+ case FF_RAW:
+ memcpy(effect-u.ff_raw, new-u.ff_raw, sizeof(new-u.ff_raw));
+ break;
+
default:
printk(KERN_ERR ff-memless: invalid type in
ml_combine_effects()\n);
break;
diff --git a/include/linux/input.h b/include/linux/input.h
index 2a23768..cc4ae1f 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -859,6 +859,7 @@ struct ff_effect {
struct ff_periodic_effect periodic;
struct ff_condition_effect condition[2]; /* One for each axis */
struct ff_rumble_effect rumble;
+ __u32 ff_raw[6];
} u;
};
@@ -874,9 +875,10 @@ struct ff_effect {
#define FF_DAMPER 0x55
#define FF_INERTIA 0x56
#define FF_RAMP0x57
+#define FF_RAW 0x58
#define FF_EFFECT_MIN FF_RUMBLE
-#define FF_EFFECT_MAX FF_RAMP
+#define FF_EFFECT_MAX FF_RAW
/*
* Force feedback periodic effect types
-
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/
