Find the answer to your Linux question:
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 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2007
    Posts
    9

    Arrow 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

  2. #2
    Just Joined! vijay_kernel's Avatar
    Join Date
    Apr 2007
    Posts
    77
    Hi,

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

    Thx,
    Vijay.

  3. #3
    Just Joined!
    Join Date
    May 2007
    Posts
    9
    Quote Originally Posted by vijay_kernel View Post
    Hi,

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

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

  4. #4
    Just Joined! vijay_kernel's Avatar
    Join Date
    Apr 2007
    Posts
    77
    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.

  5. #5
    Just Joined!
    Join Date
    May 2007
    Posts
    9

    Smile

    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

Posting Permissions

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