Re: [Question: Drivers/input/evdev.c] What is the use of write function in evdev_fops?

On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
[off-list ref] wrote:

On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur [off-list ref] wrote:

quoted

On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur

[off-list ref] wrote:

quoted

quoted

On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Wed, Aug 13, 2014 at 11:41:20PM +0530, Aniroop Mathur wrote:

quoted

Hello Mr. Torokhov :)

On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

Hi Aniroop,

On Wed, Aug 13, 2014 at 10:16:34PM +0530, Aniroop Mathur wrote:

quoted

Dear Mr. Torokhov and Linux-Input Community,
Greetings of the day !! :)

I have not seen some good use of write function in input

subsystem.

quoted

quoted

quoted

quoted

I am trying find the good uses of write function in Input

subsystem,

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

to write the recorded data back into buffer.

You are right, majority of times you are reading from the

buffer.

quoted

quoted

Still,

quoted

quoted

quoted

sometimes you want to control hardware state, for example,

toggle

quoted

quoted

keyboard LED.

quoted

quoted

quoted

That can be achieved by writing appropriate event to the event

device.

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

hardware to toggle led.
Similarly, it can be done for cases like sound (EV_SND, force
feedback(EV_FF), etc
Right ?

Yes.

quoted

quoted

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.

quoted

quoted

Instead if we use accel and gyro separate device nodes,
there is no such problem because device nodes itself are

different.

quoted

quoted

:)

quoted

quoted

So for such case, I think simulation through proper device node is

better.

quoted

Even though there is only one /dev/input/uinput every user (an

entity

quoted

quoted

quoted

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