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.
Kindly elaborate more.
Thanks,
Aniroop
--
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
