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