Results 1 to 5 of 5
Hi..
Can anyone explain to me what exactly is happening in the input.c and evdev.c files in /drivers/input?
i know the following:
The driver of our input device calls the ...
- 05-14-2007 #1Just Joined!
- Join Date
- May 2007
- Posts
- 9
input subsytem
Hi..
Can anyone explain to me what exactly is happening in the input.c and evdev.c files in /drivers/input?
i know the following:
The driver of our input device calls the input_register_device.
This method creates sysfs entries and all...
This method in the input.c is doing what all exactly?
What are the linked lists maintained?
i have gone through the docs by Korah-Hartman and Brad.. Needed more info on how the input subsystem is exactly working ...
regards,,
tuxer_789
- 05-14-2007 #2
Hi,
May I know specifically for which input device r u writing the driver ?
Thx,
Vijay.
- 05-14-2007 #3Just Joined!
- Join Date
- May 2007
- Posts
- 9
- 05-14-2007 #4
I am not sure whether the below info is going to help you, just have look into it.
evdev
=====
evdev is the generic input event interface. It passes the events
generated in the kernel straight to the program, with timestamps. The
API is still evolving, but should be useable now.
This should be the way for GPM and X to get keyboard and mouse mouse
events. It allows for multihead in X without any specific multihead
kernel support. The event codes are the same on all architectures and
are hardware independent.
The devices are in /dev/input:
crw-r--r-- 1 root root 13, 64 Apr 1 10:49 event0
crw-r--r-- 1 root root 13, 65 Apr 1 10:50 event1
crw-r--r-- 1 root root 13, 66 Apr 1 10:50 event2
crw-r--r-- 1 root root 13, 67 Apr 1 10:50 event3
...
And so on up to event31.
Event interface
===============
Should you want to add event device support into any application (X, gpm,
svgalib ...). Here goes a description of the current state of things, which is going
to be extended, but not changed incompatibly as time goes:
You can use blocking and nonblocking reads, also select() on the
/dev/input/eventX devices, and you'll always get a whole number of input
events on a read. Their layout is:
struct input_event {
struct timeval time;
unsigned short type;
unsigned short code;
unsigned int value;
};
'time' is the timestamp, it returns the time at which the event happened.
Type is for example EV_REL for relative momement, REL_KEY for a keypress or
release. More types are defined in include/linux/input.h.
'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
list is in include/linux/input.h.
'value' is the value the event carries. Either a relative change for
EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
release, 1 for keypress and 2 for autorepeat.
Hmmmm... what u think...
Thx,
Vijay.
- 05-14-2007 #5Just Joined!
- Join Date
- May 2007
- Posts
- 9
hi vijay..
i already went through all that.. actually after going through many specs i guess i have gotten used to reading documentation and then understanding stuff.. lolz.. if you do find any comprehensive stuff plz fwd me..
thx,
tuxer_789


Reply With Quote

