* private ioctls in input driver @ 2009-09-24 11:51 Trilok Soni 2009-09-25 4:02 ` Dmitry Torokhov 0 siblings, 1 reply; 7+ messages in thread From: Trilok Soni @ 2009-09-24 11:51 UTC (permalink / raw) To: linux-input 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. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 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 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Torokhov @ 2009-09-25 4:02 UTC (permalink / raw) To: Trilok Soni; +Cc: linux-input 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). -- Dmitry ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 2009-09-25 4:02 ` Dmitry Torokhov @ 2009-09-25 8:51 ` Trilok Soni 2009-09-28 17:02 ` Dmitry Torokhov 0 siblings, 1 reply; 7+ messages in thread From: Trilok Soni @ 2009-09-25 8:51 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input 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. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 2009-09-25 8:51 ` Trilok Soni @ 2009-09-28 17:02 ` Dmitry Torokhov 2009-09-28 17:05 ` Trilok Soni 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Torokhov @ 2009-09-28 17:02 UTC (permalink / raw) To: Trilok Soni; +Cc: linux-input 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. -- Dmitry ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 2009-09-28 17:02 ` Dmitry Torokhov @ 2009-09-28 17:05 ` Trilok Soni 2009-09-29 2:50 ` Barry Song 0 siblings, 1 reply; 7+ messages in thread From: Trilok Soni @ 2009-09-28 17:05 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: linux-input 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. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 2009-09-28 17:05 ` Trilok Soni @ 2009-09-29 2:50 ` Barry Song 2009-09-29 3:37 ` Dmitry Torokhov 0 siblings, 1 reply; 7+ messages in thread From: Barry Song @ 2009-09-29 2:50 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Trilok Soni, linux-input 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: private ioctls in input driver 2009-09-29 2:50 ` Barry Song @ 2009-09-29 3:37 ` Dmitry Torokhov 0 siblings, 0 replies; 7+ messages in thread From: Dmitry Torokhov @ 2009-09-29 3:37 UTC (permalink / raw) To: Barry Song; +Cc: Trilok Soni, linux-input On Tue, Sep 29, 2009 at 10:50:15AM +0800, Barry Song wrote: > 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? > This is exactly what I don't want to have in the input layer. These device-specific knobs belong with the hardware device. Take a look at psmouse and all it's protocol drivers and AT keyboard and so forth. They allow adjusting device-specific behavior via device-specific sysfs entries. Ioctls in evdev are fine if they are generic enough to not be tied to particular device. And as usual with ioctls we need to be very careful with 32/64 bit, endianness and accessibility (sysfs does not require any additional tools). -- Dmitry ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-09-29 3:37 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2009-09-29 3:37 ` Dmitry Torokhov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.