linux-kernel - Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <38b3b7c0703211503s3a8ee177v5b149cfd5975de8c@mail.gmail.com>
Date:	Wed, 21 Mar 2007 23:03:12 +0100
From:	"johann deneux" <johann.deneux@...il.com>
To:	"Jiri Slaby" <jirislaby@...il.com>
Cc:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
	"\"STenyaK (Bruno González)\"" <stenyak@...il.com>,
	"Anssi Hannula" <anssi.hannula@...il.com>,
	"Linux kernel mailing list" <linux-kernel@...r.kernel.org>,
	linux-input@...ey.karlin.mff.cuni.cz
Subject: Re: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]

On 3/21/07, Jiri Slaby <jirislaby@...il.com> wrote:
> Dmitry Torokhov napsal(a):
> > On 3/21/07, johann deneux <johann.deneux@...il.com> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/