On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:
> Hello Mr. Torokhov :)
>
> On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
> <dmitry.torokhov@xxxxxxxxx> wrote:
> > Hi Aniroop,
> >
> > On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:
> >> Dear Mr. Torokhov and Linux-Input Community,
> >> Greetings of the day !! :)
> >>
> >> I have not seen some good use of write function in input subsystem.
> >> I am trying find the good uses of write function in Input subsystem,
> >> but could not find the solution over internet.
> >> Can you please help in answering my query below:
> >>
> >> As you know, in evdev.c file, fops is defined as below
> >> struct file_operations evdev_fops = {
> >> .read = evdev_read,
> >> .write = evdev_write,
> >> ...
> >> }
> >>
> >> So in what cases, evdev_write function is used ?
> >> One case I can think of is that, it can be used in input device simulator
> >> to write the recorded data back into buffer.
> >
> > You are right, majority of times you are reading from the buffer. Still,
> > sometimes you want to control hardware state, for example, toggle keyboard LED.
> > That can be achieved by writing appropriate event to the event device.
> >
>
> Okay. :)
> So it means application upon receiving some key value,
> it can write EV_LED type of event to keyboard input device node
> and if dev->event function is defined in driver, driver can request
> hardware to toggle led.
> Similarly, it can be done for cases like sound (EV_SND, force
> feedback(EV_FF), etc
> Right ?
Yes.
>
> > For simulators I think uinput is suited the best.
> >
>
> As i know, in case of uinput, there is only one device node
> /dev/uinput or /dev/input/uinput.
> and to distinguish the events, we can use event type and code.
>
> But, if we are simulating multiple devices together like
> accelerometer, gyro, mag, light, compass, etc
> then any two devices can have same event type and code.
> Like accel and gyro can both have EV_REL and REL_X/Y/Z.
> In such a case, we won't be able to distinguish between accel and gyro events.
>
> Instead if we use accel and gyro separate device nodes,
> there is no such problem because device nodes itself are different. :)
> So for such case, I think simulation through proper device node is better.
Even though there is only one /dev/input/uinput every user (an entity
opening that device node) will end up creating it's very own and
separate input device, with separate bitmasks, events, etc, etc.
Thanks.
--
Dmitry
--
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
