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