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