Input: add sensable phantom driver

add sensable phantom driver

drivers/input/misc/phantom.c new file +5 -0

+
+#define phantom_remap(io, vma, addr)   ({                              \
+       vma->vm_pgoff = (addr) >> PAGE_SHIFT;                           \
+       io ## remap_pfn_range(vma, (vma)->vm_start, (vma)->vm_pgoff,    \
+               (vma)->vm_end - (vma)->vm_start, (vma)->vm_page_prot);  \

drivers/input/misc/phantom.c new file +21 -0

+               break;
+       case 1:
+               retval = phantom_remap(io_, vma, dev->ibase);
+               break;
+       default:
+               retval = phantom_remap(io_, vma, dev->obase);
+       }
+
+       return retval ? -EINVAL : 0;
+}
+
+
+static int __devinit phantom_probe(struct pci_dev *pdev,
+       const struct pci_device_id *pci_id)
+{
+       struct phantom_device *pht;
+       unsigned int minor;
+       int retval;
+
+       retval = pci_enable_device(pdev);
+       if (retval)

drivers/input/misc/phantom.c new file +36 -0

+
+       retval = pci_request_regions(pdev, "phantom");
+       if (retval)
+               goto err_null;
+
+       retval = -ENOMEM;
+       pht = kzalloc(sizeof(*pht), GFP_KERNEL);
+       if (pht == NULL) {
+               dev_err(&pdev->dev, "unable to allocate device\n");
+               goto err_reg;
+       }
+
+       pht->stat = (void *)__get_free_page(GFP_KERNEL | __GFP_WAIT);
+       if (pht->stat == NULL)
+               goto err_fr;
+
+       pht->caddr = pci_iomap(pdev, 0, 0);
+       if (pht->caddr == NULL) {
+               dev_err(&pdev->dev, "can't remap conf space\n");
+               goto err_frp;
+       }
+       pht->ibase = pci_resource_start(pdev, 2);
+       pht->obase = pci_resource_start(pdev, 3);
+
+       mutex_init(&pht->open_lock);
+       init_waitqueue_head(&pht->wait);
+
+       phantom_write_cfgl(pht, 0, PHN_IRQCTL);
+       retval = request_irq(pdev->irq, phantom_isr,
+                       IRQF_SHARED | IRQF_DISABLED, "phantom", pht);
+       if (retval) {
+               dev_err(&pdev->dev, "can't establish ISR\n");
+               goto err_unm;
+       }
+
+       cdev_init(&pht->cdev, &phantom_file_ops);

Hi Jiri,

Quoted 1 line

add sensable phantom driver

...

General question - can this driver use force-feedback mecahnisms already present in kernel instead of exporting raw datastream to userspace. What are shortcomings of kernels force-feedback implemenattion that make it insufficient for phantom?

Quoted 8 lines

drivers/input/misc/phantom.c new file +8 -0

+#define phantom_remap(io, vma, addr)   ({                              \
+       vma->vm_pgoff = (addr) >> PAGE_SHIFT;                           \
+       io ## remap_pfn_range(vma, (vma)->vm_start, (vma)->vm_pgoff,    \
+               (vma)->vm_end - (vma)->vm_start, (vma)->vm_page_prot);  \
+})
+
+static int phantom_mmap(struct file *file, struct vm_area_struct *vma)
+{

drivers/input/misc/phantom.c line 185

Quoted 6 lines

drivers/input/misc/phantom.c new file +6 -0

+       struct phantom_device *dev = file->private_data;
+       int retval;
+
+       switch (vma->vm_pgoff) {
+       case 0:
+               retval = phantom_remap(, vma, virt_to_phys(dev->stat));

This really hurts my eyes. Is there any reason for using the macro here?

Quoted 25 lines

drivers/input/misc/phantom.c new file +25 -0

+               break;
+       case 1:
+               retval = phantom_remap(io_, vma, dev->ibase);
+               break;
+       default:
+               retval = phantom_remap(io_, vma, dev->obase);
+       }
+
+       return retval ? -EINVAL : 0;
+}
+
+
+static int __devinit phantom_probe(struct pci_dev *pdev,
+       const struct pci_device_id *pci_id)
+{
+       struct phantom_device *pht;
+       unsigned int minor;
+       int retval;
+
+       retval = pci_enable_device(pdev);
+       if (retval)
+               goto err;
+
+       minor = phantom_get_free();
+       if (minor == PHANTOM_MAX_MINORS) {

drivers/input/misc/phantom.c line 257

Quoted 6 lines

drivers/input/misc/phantom.c new file +6 -0

+               dev_err(&pdev->dev, "too many devices found!\n");
+               retval = -EIO;
+               goto err;
+       }
+
+       phantom_devices[minor] = 1;

Locking? In face of multithreaded PCI probes it might be needed.

isicom, fix probe race

Fix two race conditions in the probe function with mutex.

...

static int __devinit isicom_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ static DEFINE_MUTEX(probe_lock);

Quoted 41 lines

drivers/input/misc/phantom.c new file +41 -0

+
+       retval = pci_request_regions(pdev, "phantom");
+       if (retval)
+               goto err_null;
+
+       retval = -ENOMEM;
+       pht = kzalloc(sizeof(*pht), GFP_KERNEL);
+       if (pht == NULL) {
+               dev_err(&pdev->dev, "unable to allocate device\n");
+               goto err_reg;
+       }
+
+       pht->stat = (void *)__get_free_page(GFP_KERNEL | __GFP_WAIT);
+       if (pht->stat == NULL)
+               goto err_fr;
+
+       pht->caddr = pci_iomap(pdev, 0, 0);
+       if (pht->caddr == NULL) {
+               dev_err(&pdev->dev, "can't remap conf space\n");
+               goto err_frp;
+       }
+       pht->ibase = pci_resource_start(pdev, 2);
+       pht->obase = pci_resource_start(pdev, 3);
+
+       mutex_init(&pht->open_lock);
+       init_waitqueue_head(&pht->wait);
+
+       phantom_write_cfgl(pht, 0, PHN_IRQCTL);
+       retval = request_irq(pdev->irq, phantom_isr,
+                       IRQF_SHARED | IRQF_DISABLED, "phantom", pht);
+       if (retval) {
+               dev_err(&pdev->dev, "can't establish ISR\n");
+               goto err_unm;
+       }
+
+       cdev_init(&pht->cdev, &phantom_file_ops);
+       pht->cdev.owner = THIS_MODULE;
+       retval = cdev_add(&pht->cdev, MKDEV(phantom_major, minor), 1);
+       if (retval) {
+               dev_err(&pdev->dev, "chardev registration failed\n");
+               goto err_irq;

drivers/input/misc/phantom.c line 303

Quoted 6 lines

drivers/input/misc/phantom.c new file +3 -0

+       }
+
+       device_create(phantom_class, &pdev->dev, MKDEV(phantom_major, 

minor),

drivers/input/misc/phantom.c new file +2 -0

+                       "phantom%u", minor);
+

Error handling is needed.

Dmitry Torokhov napsal(a):

Quoted 13 lines

Quoted 13 lines

drivers/input/misc/phantom.c new file +13 -0

+static int __devinit phantom_probe(struct pci_dev *pdev,
+       const struct pci_device_id *pci_id)
+{
+       struct phantom_device *pht;
+       unsigned int minor;
+       int retval;
+
+       retval = pci_enable_device(pdev);
+       if (retval)
+               goto err;
+
+       minor = phantom_get_free();
+       if (minor == PHANTOM_MAX_MINORS) {

Quoted 8 lines

drivers/input/misc/phantom.c line 257

Quoted 6 lines

drivers/input/misc/phantom.c new file +6 -0

+               dev_err(&pdev->dev, "too many devices found!\n");
+               retval = -EIO;
+               goto err;
+       }
+
+       phantom_devices[minor] = 1;

Locking? In face of multithreaded PCI probes it might be needed.

I think, this is the same issue?

<cite from="akpm" date="12/19/06">

Quoted 10 lines · On Sat, 16 Dec 2006 02:09:48 +0100 (CET) Jiri Slaby <[email protected]> wrote:

isicom, fix probe race

Fix two race conditions in the probe function with mutex.

...

static int __devinit isicom_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ static DEFINE_MUTEX(probe_lock);

hm. How can isicom_probe() race with itself? Even with the dreaded multithreaded-pci-probing? It's only called once, by a single thread.

Confused.
</cite>

What do you think? Greg?

Dmitry Torokhov napsal(a):

Quoted 1 line

Hi Jiri,

Hi.

Quoted 4 lines · Jiri Slaby

Quoted 1 line

add sensable phantom driver

...

Quoted 4 lines

General question - can this driver use force-feedback mecahnisms already present in kernel instead of exporting raw datastream to userspace. What are shortcomings of kernels force-feedback implemenattion that make it insufficient for phantom?

I didn't even think about it, sorry. Does any problem with rate about 2kHz come on your mind before I'll try to rewrite it?

Quoted 14 lines · Jiri Slaby

Dmitry Torokhov napsal(a):

Quoted 1 line

Hi Jiri,

Hi.

Quoted 8 lines · Jiri Slaby

Quoted 1 line

add sensable phantom driver

...

General question - can this driver use force-feedback mecahnisms already present in kernel instead of exporting raw datastream to userspace. What are shortcomings of kernels force-feedback implemenattion that make it insufficient for phantom?

Quoted 2 lines

I didn't even think about it, sorry. Does any problem with rate about 2kHz come on your mind before I'll try to rewrite it?

No, not really.

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

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.

Why did you remove all Cced people? Anyway I filtered some of them out

johann deneux napsal(a):

Quoted 2 lines

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.

Quoted 9 lines

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

Quoted 18 lines

Why did you remove all Cced people? Anyway I filtered some of them out

johann deneux napsal(a):

Quoted 2 lines

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.

Quoted 9 lines

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.

Quoted 4 lines

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?

Also yet another one such as FF_VECTOR or FF_3D could be considered as one posibility, but it's still the same -- to have no more than 3 entries to pass forces...

Dmitry Torokhov napsal(a):

Quoted 7 lines · Jiri Slaby

Quoted 6 lines

Why did you remove all Cced people? Anyway I filtered some of them out

johann deneux napsal(a):

Quoted 2 lines

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.

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

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.

Quoted 6 lines

Quoted 4 lines

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

I definitely agree.

Quoted 1 line

rather add new set of 3D effects.

I was thinking about having "raw" (e.g. FF_RAW) effect, which would be only X "axes"/entries of u32, where X is about 10 for future use and simply posting these values further to HW (maybe after clamping or driver specific processing) from this array. This seems to be augmentation of FF_CONSTANT but the fact, it doesn't compute forces from direction.

Also yet another one such as FF_VECTOR or FF_3D could be considered as one posibility, but it's still the same -- to have no more than 3 entries to pass forces...

Quoted 1 line

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.

Quoted 4 lines · Jiri Slaby

Dmitry Torokhov napsal(a):

Quoted 3 lines · Jiri Slaby

Quoted 2 lines

Why did you remove all Cced people? Anyway I filtered some of them out

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

johann deneux napsal(a):

Quoted 2 lines

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.

Interesting. What kind of device is that? i.e. what is the third direction value?

Quoted 4 lines

Quoted 2 lines

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

Quoted 1 line

developped multiplatform virtual reality system.

Wine and BZflag come to mind, though I think the support is quite limited in both.

Quoted 4 lines

Quoted 1 line

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.

Quoted 3 lines · Anssi Hannula

Quoted 3 lines

Quoted 1 line

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

Quoted 5 lines

Quoted 1 line

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

By the way, is this the correct list for asking trivial questions (such as questions about how the ff api works), or is it only for development of kernel?

Quoted 5 lines

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.

Quoted 6 lines · Dmitry Torokhov

Quoted 5 lines

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

Quoted 4 lines

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

Quoted 8 lines · STenyaK (Bruno González)

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?

Quoted 4 lines

Quoted 1 line

I have a question: if the force is to be 3D, why only 3 possible

values?

Quoted 2 lines

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

Quoted 8 lines

for 6 dof

Quoted 2 lines

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

- something else? (did I forget something)

STenyaK (Bruno González) napsal(a):

Quoted 14 lines · Dmitry Torokhov

Quoted 4 lines

Quoted 1 line

I have a question: if the force is to be 3D, why only 3 possible

values?

Quoted 2 lines

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

Quoted 8 lines

for 6 dof

Quoted 2 lines

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.

Quoted 8 lines

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)

Quoted 37 lines · Jiri Slaby

STenyaK (Bruno González) napsal(a):

Quoted 14 lines · Dmitry Torokhov

Quoted 4 lines

Quoted 1 line

I have a question: if the force is to be 3D, why only 3 possible

values?

Quoted 2 lines

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

Quoted 8 lines

for 6 dof

Quoted 2 lines

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.

Quoted 8 lines

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

Quoted 2 lines

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

Quoted 6 lines

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 would not worry aboput extra memory needed on I-force like devices because they just would not support additional "planes". What about phantom? Would it have enough memory?

On the other hand if you guys (Anssi, Johann, Jiri...) decide that a simple new 3d effect is the most efficient solution for now and will be enough for a few years (till we get FF v2 API) I will merge it.

Dmitry Torokhov napsal(a):

Quoted 8 lines · johann deneux

Quoted 6 lines

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.

Quoted 6 lines

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?

Quoted 36 lines · Jiri Slaby

Dmitry Torokhov napsal(a):

Quoted 8 lines · johann deneux

Quoted 6 lines

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.

Quoted 6 lines

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;
        };
    };
};

Quoted 2 lines

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_ruct 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.

Quoted 35 lines · Jiri Slaby

Quoted 34 lines

Dmitry Torokhov napsal(a):

Quoted 7 lines · johann deneux

Quoted 6 lines

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.

Quoted 6 lines

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;
        };
    };
};

Quoted 3 lines

Quoted 2 lines

and need to pass the three 16bits torques into s16 ioaddr[0..2]. How?

Stupid question,

Quoted 2 lines

I have forgotten the details of ioctl: Wouldn't the following work?

Quoted 18 lines

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_ruct ff_plane plane;
};

Quoted 2 lines

Alternatively, one could leave ff_effect effect untouched and find another way to specify the plane, e.g. another ioctl.

I was thinking about a new ioctl to specify a plane for a specific effect, but probably extending the structure and having 2 distinct ioctls (with and without plane) is cleaner.

Dmitry Torokhov napsal(a):

Quoted 36 lines · johann deneux

Quoted 35 lines · Jiri Slaby

Quoted 34 lines

Dmitry Torokhov napsal(a):

Quoted 7 lines · johann deneux

Quoted 6 lines

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.

Quoted 6 lines

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;
        };
    };
};

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

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:

Quoted 3 lines

Quoted 3 lines

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?".

Quoted 5 lines

Dmitry Torokhov napsal(a):

Quoted 3 lines · johann deneux

Quoted 2 lines

I have forgotten the details of ioctl: Wouldn't the following work?

Quoted 4 lines

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 deneux napsal(a):

Quoted 6 lines · Jiri Slaby

Quoted 5 lines

Dmitry Torokhov napsal(a):

Quoted 3 lines · johann deneux

Quoted 2 lines

I have forgotten the details of ioctl: Wouldn't the following work?

Quoted 6 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 6 lines

johann deneux napsal(a):

Quoted 4 lines

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?

Quoted 12 lines

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.

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;

Quoted 8 lines

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;

Quoted 5 lines

by

__u8 motor;
__u8 type;

Splitting type field seems to be a good idea.

Quoted 8 lines

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;

Quoted 5 lines

by

__u8 motor;
__u8 type;

Splitting type field seems to be a good idea.

Dmitry Torokhov napsal(a):

Quoted 11 lines · johann deneux

Quoted 10 lines

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

Quoted 4 lines

Quoted 3 lines

__u8 motor;
__u8 type;

Splitting type field seems to be a good idea.

Maybe stupid question, but what about endianness + backward compatibility? If we split it into motor,type sequence, it would break LE (untouched BE), if we do type,motor, it is OK for LE (broken BE).

Jiri Slaby napsal(a):

Quoted 12 lines

Dmitry Torokhov napsal(a):

Quoted 11 lines · johann deneux

Quoted 10 lines

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

Quoted 8 lines

Quoted 4 lines

Quoted 3 lines

__u8 motor;
__u8 type;

Splitting type field seems to be a good idea.

Maybe stupid question, but what about endianness + backward compatibility? If we split it into motor,type sequence, it would break LE (untouched BE), if we do type,motor, it is OK for LE (broken BE).

Aha, and the question is: do

#ifdef __BIG_ENDIAN
#else
#endif

?

Quoted 10 lines · Jiri Slaby

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.

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.

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.

Quoted 13 lines · STenyaK (Bruno González)

Quoted 3 lines · Anssi Hannula

Quoted 3 lines

Quoted 1 line

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

Quoted 5 lines

Quoted 1 line

developped multiplatform virtual reality system.

Wine and BZflag come to mind, though I think the support is quite limited in both.

Quoted 8 lines

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.

Quoted 23 lines

Why did you remove all Cced people? Anyway I filtered some of them out

johann deneux napsal(a):

Quoted 1 line

You are right, the direction in ff_effect is meant to

be an angle.

Quoted 1 line

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.

Quoted 1 line

maybe we should change the API. I don't think there

are many

Quoted 1 line

applications using force feedback yet, so maybe that

should be ok?

Quoted 2 lines

If we change the API, we should remove the assumption

that a device has

Quoted 1 line

at most two axes to render effects. We could for

instance have a

Quoted 1 line

magnitude argument for each axis which is capable of

rendering effects.

Quoted 1 line

That might be necessary even for more common gaming

Quoted 9 lines

devices like racing

Quoted 1 line

wheels: One can think pedals could also be capable of

force feedback

Quoted 1 line

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?

Hi!

Quoted 39 lines

Quoted 23 lines

Why did you remove all Cced people? Anyway I filtered some of them out

johann deneux napsal(a):

Quoted 1 line

You are right, the direction in ff_effect is meant to

be an angle.

Quoted 1 line

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.

Quoted 1 line

maybe we should change the API. I don't think there

are many

Quoted 1 line

applications using force feedback yet, so maybe that

should be ok?

Quoted 2 lines

If we change the API, we should remove the assumption

that a device has

Quoted 1 line

at most two axes to render effects. We could for

instance have a

Quoted 1 line

magnitude argument for each axis which is capable of

rendering effects.

Quoted 1 line

That might be necessary even for more common gaming

Quoted 9 lines

devices like racing

Quoted 1 line

wheels: One can think pedals could also be capable of

force feedback

Quoted 1 line

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.

Quoted 1 line

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