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);
Thread1:
struct input_event ev;
memset(&ev, 0, sizeof(ev));
ev.type = EV_KEY;
ev.code = KEY_D;
ev.value = 1;
ret = write(fd, &ev, sizeof(ev));
Thread2:
struct input_event ev;
memset(&ev, 0, sizeof(ev));
ret = read(fd, &ev, sizeof(ev));
int type = ev.type;
int code = ev.value;
int value = ev.value;
Thanks
-- Aniroop
> 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
