Find the answer to your Linux question:
Results 1 to 5 of 5

Thread: input subsytem

Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Arrow input subsytem

    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 ...


  2. #2

    May I know specifically for which input device r u writing the driver ?


  3. #3
    Quote Originally Posted by vijay_kernel View Post

    May I know specifically for which input device r u writing the driver ?

    I want to grab all input events sent out by evdev... lets say.. it could work as input-device event logger...

  4. $spacer_open
  5. #4
    I am not sure whether the below info is going to help you, just have look into it.


    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...


  6. #5


    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..


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts