Re: private ioctls in input driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 29, 2009 at 1:05 AM, Trilok Soni <soni.trilok@xxxxxxxxx> wrote:
>
> Hi Dmitry,
>
> On Mon, Sep 28, 2009 at 10:32 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux