On Fri, Aug 15, 2014 at 1:49 AM, Dmitry Torokhov
<dmitry.torokhov@xxxxxxxxx> wrote:
> On Fri, Aug 15, 2014 at 12:55:35AM +0530, Aniroop Mathur wrote:
>> On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
>> <dmitry.torokhov@xxxxxxxxx> wrote:
>> > On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@xxxxxxxxx> wrote:
>> >>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>> >><dmitry.torokhov@xxxxxxxxx> wrote:
>> >>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>> >><aniroop.mathur@xxxxxxxxx> wrote:
>> >>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>> >>>><dmitry.torokhov@xxxxxxxxx> wrote:
>> >>>>> 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.
>> >>>>>
>> >>>>
>> >>>>How to use bitmasks to distinguish between two events ?
>> >>>>In below code, I can only see type and code as
>> >>>>identification variables.
>> >>>>Can we use bitmask too here ?
>> >>>>
>> >>>>fd = open("/dev/uinput", O_RDWR);
>> >>>>
>> >>>
>> >>> You need to open 2 separate file descriptors.
>> >>>
>> >>
>> >>2 separate file descriptors like below ?
>> >>int fd1 = open("/dev/uinput", O_RDWR);
>> >>int fd2 = open("/dev/uinput", O_RDWR);
>> >>
>> >>But my reading data will still come in struct input_event as mentioned
>> >>above.
>> >>It has only time, type, code and value.
>> >>So, how we can use bitmask here ?
>> >>
>> >>struct input_event {
>> >>struct timeval time;
>> >>__u16 type;
>> >>__u16 code;
>> >>__s32 value;
>> >> };
>> >
>> > By opening 2 fds you'll end up creating 2 separate input devices with separate evdev nodes, etc, so you will not mix up input events.
>> >
>> > I think at this time you should just try actually using uinput and that should clear things for you.
>> >
>>
>> Can you please explain what do you mean by separate evdev nodes ?
>> Do you mean two separate evdev nodes for uinput ?
>> But as we discussed before, there is only one node in case of uinput
>> i.e. /dev/uinput.
>
> Uinput allows to creating input devices driven from userspace. You can
> create as many separate input devices as you want by opening
> /dev/uinput several times since it creates a device per file descriptor.
> Each of these input devices will get evdev attached to it and will get
> it's own /dev/input/eventX node created.
>
> Really, please try using uinput, it will clear a lot if things for you.
> For example, see what http://www.freedesktop.org/wiki/Evemu/ does.
>
Thank you Mr. Torokhov for the discussion and answering my queries. :)
I will try to explore more.
Good day !
> 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
