Linux Uinput: Simple Example

linux uinput: simple example?

You should also be writing a sync event after the actual event. In your writer side code:

struct input_event ev = {0};
ev.type = EV_ABS;
ev.code = ABS_X;
ev.value = 42;

usleep(1500);

memset(&ev, 0, sizeof(ev));
ev.type = EV_SYN;
ev.code = 0;
ev.value = 0;

ret = write(fd, &ev, sizeof(ev));

getchar();

How to generate key strokes events with the Input Subsystem

There is nothing wrong with above 2 programs. The problem here is, that this program creates a new input device (probably somewhere in "/dev/input") and that X cannot register the input device fast enough so that it can fetch the input. A simple "sleep(1);" (with the appropriate "#include <unistd.h>") after the creation of the input device solves the problem. To be (probably unnecessary) specific, after changing the code the program will behave as expected because now X had ample time to realize there's a new input device. Add the sleep() statement after below code segment.

    // create the device via an IOCTL call 
    if(ioctl(fd_key_emulator, UI_DEV_CREATE))
    {
        std::cout << "Error in ioctl : UI_DEV_CREATE : " << strerror(errno) << std::endl;
    }
    // add 1 second sleep.
    sleep (1);

    // now fd_key_emulator represents the end-point file descriptor of the new input device.

now program is working as expected.

[Update]:
Reference link is removed due to it is generated error 404, then later it is redirecting to a malicious web site.

Documentation for uinput

Well, it takes some investigation effort for such subtle things. From
drivers/input/misc/uinput.c and include/uapi/linux/uinput.h files you can see bits for UI_SET_* definitions, like this:

• MSC
• REL
• LED

etc.

Run next command in kernel sources directory:

$ git grep --all-match -e 'MSC' -e 'REL' -e 'LED' -- Documentation/*

or use regular grep, if your kernel doesn't have .git directory:

$ grep -rl MSC Documentation/* | xargs grep -l REL | xargs grep -l LED

You'll get this file: Documentation/input/event-codes.txt, from which you can see:

EV_MSC: Used to describe miscellaneous input data that do not fit into other types.

EV_MSC events are used for input and output events that do not fall under other categories.

A few EV_MSC codes have special meaning:

• MSC_TIMESTAMP: Used to report the number of microseconds since the last reset. This event should be coded as an uint32 value, which is allowed to wrap around with no special consequence. It is assumed that the time difference between two consecutive events is reliable on a reasonable time scale (hours). A reset to zero can happen, in which case the time since the last event is unknown. If the device does not provide this information, the driver must not provide it to user space.

I'm afraid this is the best you can find out there for UI_SET_MSCBIT out there.

---

Related Topics