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

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

[Aniroop Mathur]

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.

Thanks and Regards,
Aniroop Mathur

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

[Dmitry Torokhov]

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.

For simulators I think uinput is suited the best.

Thanks.

-- 
Dmitry

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

[Aniroop Mathur]

Hello Mr. Torokhov :)

On Wed, Aug 13, 2014 at 10:36 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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 ?

> 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.
Is my point of view correct ?

Please share your opinion too.

Thanks,
Aniroop

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

[Dmitry Torokhov]

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@gmail.com> 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.

Thanks.

-- 
Dmitry

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

[Aniroop Mathur]

On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> 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@gmail.com> 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

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

[Dmitry Torokhov]

On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
><dmitry.torokhov@gmail.com> 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@gmail.com> 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

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

[Aniroop Mathur]

On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> 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@gmail.com> 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;
 };

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

[Dmitry Torokhov]

On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
><dmitry.torokhov@gmail.com> wrote:
>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
><aniroop.mathur@gmail.com> wrote:
>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>><dmitry.torokhov@gmail.com> 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@gmail.com> 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.


Thanks.

-- 
Dmitry

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

[Aniroop Mathur]

On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> wrote:
>>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>><aniroop.mathur@gmail.com> wrote:
>>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>>><dmitry.torokhov@gmail.com> 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@gmail.com> 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.
>

Two separate evdev nodes for uinput ?
But as we discussed before, there is only one node in case of uinput
i.e. /dev/uinput.
Sorry, I really do not understand how can there be two separate evdev nodes
for uinput case.

Thanks

--
Aniroop

> I think at this time you should just try actually using uinput and that should clear things for you.
>
>
> Thanks.
>
> --
> Dmitry

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

[Aniroop Mathur]

On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>><dmitry.torokhov@gmail.com> wrote:
>>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>><aniroop.mathur@gmail.com> wrote:
>>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>>>><dmitry.torokhov@gmail.com> 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@gmail.com> 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

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

[Dmitry Torokhov]

On Fri, Aug 15, 2014 at 12:55:35AM +0530, Aniroop Mathur wrote:
> On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
> >>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
> >><dmitry.torokhov@gmail.com> wrote:
> >>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
> >><aniroop.mathur@gmail.com> wrote:
> >>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
> >>>><dmitry.torokhov@gmail.com> 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@gmail.com> 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.

Uinput allows to creating input devices driven from userspace. You can
create as many separate input devices as you want by opening
/dev/uinput several times since it creates a device per file descriptor.
Each of these input devices will get evdev attached to it and will get
it's own /dev/input/eventX node created.

Really, please try using uinput, it will clear a lot if things for you.
For example, see what http://www.freedesktop.org/wiki/Evemu/ does.

Thanks.

-- 
Dmitry

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

[Aniroop Mathur]

On Fri, Aug 15, 2014 at 1:49 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Fri, Aug 15, 2014 at 12:55:35AM +0530, Aniroop Mathur wrote:
>> On Thu, Aug 14, 2014 at 1:12 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On August 13, 2014 12:28:46 PM PDT, Aniroop Mathur <aniroop.mathur@gmail.com> wrote:
>> >>On Thu, Aug 14, 2014 at 12:50 AM, Dmitry Torokhov
>> >><dmitry.torokhov@gmail.com> wrote:
>> >>> On August 13, 2014 12:10:16 PM PDT, Aniroop Mathur
>> >><aniroop.mathur@gmail.com> wrote:
>> >>>>On Thu, Aug 14, 2014 at 12:28 AM, Dmitry Torokhov
>> >>>><dmitry.torokhov@gmail.com> 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@gmail.com> 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.
>
> Uinput allows to creating input devices driven from userspace. You can
> create as many separate input devices as you want by opening
> /dev/uinput several times since it creates a device per file descriptor.
> Each of these input devices will get evdev attached to it and will get
> it's own /dev/input/eventX node created.
>
> Really, please try using uinput, it will clear a lot if things for you.
> For example, see what http://www.freedesktop.org/wiki/Evemu/ does.
>


Thank you Mr. Torokhov for the discussion and answering my queries. :)
I will try to explore more.

Good day !


> Thanks.
>
> --
> Dmitry

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

[Peter Hutterer]

On Fri, Aug 15, 2014 at 02:01:48AM +0530, Aniroop Mathur wrote:
[...]
> >> >>
> >> >>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.
> >
> > Uinput allows to creating input devices driven from userspace. You can
> > create as many separate input devices as you want by opening
> > /dev/uinput several times since it creates a device per file descriptor.
> > Each of these input devices will get evdev attached to it and will get
> > it's own /dev/input/eventX node created.
> >
> > Really, please try using uinput, it will clear a lot if things for you.
> > For example, see what http://www.freedesktop.org/wiki/Evemu/ does.
> >
> 
> 
> Thank you Mr. Torokhov for the discussion and answering my queries. :)
> I will try to explore more.

I recommend you look at libevdev if you're planning to use uinput. evemu
uses that now too and it makes a whole bunch of stuff easier and less likely
to go wrong.
http://freedesktop.org/wiki/Software/libevdev/

specifically:
http://www.freedesktop.org/software/libevdev/doc/1.2/group__uinput.html

Cheers,
   Peter

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

[Aniroop Mathur]

On Mon, Aug 18, 2014 at 7:27 AM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> On Fri, Aug 15, 2014 at 02:01:48AM +0530, Aniroop Mathur wrote:
> [...]
>> >> >>
>> >> >>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.
>> >
>> > Uinput allows to creating input devices driven from userspace. You can
>> > create as many separate input devices as you want by opening
>> > /dev/uinput several times since it creates a device per file descriptor.
>> > Each of these input devices will get evdev attached to it and will get
>> > it's own /dev/input/eventX node created.
>> >
>> > Really, please try using uinput, it will clear a lot if things for you.
>> > For example, see what http://www.freedesktop.org/wiki/Evemu/ does.
>> >
>>
>>
>> Thank you Mr. Torokhov for the discussion and answering my queries. :)
>> I will try to explore more.
>
> I recommend you look at libevdev if you're planning to use uinput. evemu
> uses that now too and it makes a whole bunch of stuff easier and less likely
> to go wrong.
> http://freedesktop.org/wiki/Software/libevdev/
>
> specifically:
> http://www.freedesktop.org/software/libevdev/doc/1.2/group__uinput.html
>
> Cheers,
>    Peter
>

Thanks a lot Mr. Peter for your suggestion and input for this query. :)

Have a good day !

Cheers,
Aniroop