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;
};
--
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
