From: Barry Song <21cnbao@gmail.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Trilok Soni <soni.trilok@gmail.com>, linux-input@vger.kernel.org
Subject: Re: private ioctls in input driver
Date: Tue, 29 Sep 2009 10:50:15 +0800 [thread overview]
Message-ID: <3c17e3570909281950q3a391cb6ld33ec69af765549d@mail.gmail.com> (raw)
In-Reply-To: <5d5443650909281005u37503ab0rc6b62effe73f8046@mail.gmail.com>
On Tue, Sep 29, 2009 at 1:05 AM, Trilok Soni <soni.trilok@gmail.com> wrote:
>
> Hi Dmitry,
>
> On Mon, Sep 28, 2009 at 10:32 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Fri, Sep 25, 2009 at 02:21:40PM +0530, Trilok Soni wrote:
> >> Hi Dmitry,
> >>
> >> On Fri, Sep 25, 2009 at 9:32 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > Hi Trilok,
> >> >
> >> > On Thu, Sep 24, 2009 at 05:21:09PM +0530, Trilok Soni wrote:
> >> >> Hi Dmitry,
> >> >>
> >> >> Is there any way of creating private ioctls in the input driver? I see
> >> >> that all the input framework handled
> >> >> by the framework itself and there is no way to call private ioctls if
> >> >> it doesn't match the standard ones.
> >> >>
> >> >
> >> > You are right, event devices only allow standard ioctl. What kind of
> >> > ictl are you considering? Normally device-specific controls are done via
> >> > sysfs attached to the parent device (see atkbd, psmouse, etc).
> >>
> >> sysfs might good for purpose when you can associate one file per
> >> value, so for more data we can't simply create one file per the data.
> >> Say five fingers touch data (I know we have MT_* support but here it
> >> is just for example) , say id, x, y, z etc., per finger, then we can't
> >> create one file for each of them.
> >
> > Maybe use configfs if sysfs is not suitable? I am not sure.
> >
> > I would like to not-have driver-specific ioctls in evdev/input core but
> > rather keep them with device/driver itself. Input core should only have
> > stuff that makes sense for multiple devices.
>
> I mean on the similar line only, we won't add any driver-specific
> ioctls in evdev/input core, but just transfer their control to resp.
> device/driver itself, may be similar in the line of how v4l2 does.
Sometimes, we really have this kind of requirement. Now there are more
and more kinds of input devices. Some devices have special controls
which should not belong to generic input layer. How about add a case
item in evdev_do_ioctl() to handle these commands and call drivers'
ioctl directly?
>
> --
> ---Trilok Soni
> http://triloksoni.wordpress.com
> http://www.linkedin.com/in/triloksoni
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-09-29 2:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-24 11:51 private ioctls in input driver Trilok Soni
2009-09-25 4:02 ` Dmitry Torokhov
2009-09-25 8:51 ` Trilok Soni
2009-09-28 17:02 ` Dmitry Torokhov
2009-09-28 17:05 ` Trilok Soni
2009-09-29 2:50 ` Barry Song [this message]
2009-09-29 3:37 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3c17e3570909281950q3a391cb6ld33ec69af765549d@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=soni.trilok@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).