You probably want to poll for events with libevdev_has_event_pending.
https://www.freedesktop.org/software/libevdev/doc/0.5/group__events.html
You probably want to poll for events with libevdev_has_event_pending.
https://www.freedesktop.org/software/libevdev/doc/0.5/group__events.html
Did that too, still the lockup issue persisted.
Their sample code:
struct libevdev *dev = NULL;
int fd;
int rc = 1;
fd = open("/dev/input/event0", O_RDONLY|O_NONBLOCK);
rc = libevdev_new_from_fd(fd, &dev);
if (rc < 0) {
fprintf(stderr, "Failed to init libevdev (%s)\n", strerror(-rc));
exit(1);
}
printf("Input device name: \"%s\"\n", libevdev_get_name(dev));
printf("Input device ID: bus %#x vendor %#x product %#x\n",
libevdev_get_id_bustype(dev),
libevdev_get_id_vendor(dev),
libevdev_get_id_product(dev));
if (!libevdev_has_event_type(dev, EV_REL) ||
!libevdev_has_event_code(dev, EV_KEY, BTN_LEFT)) {
printf("This device does not look like a mouse\n");
exit(1);
}
do {
struct input_event ev;
rc = libevdev_next_event(dev, LIBEVDEV_READ_FLAG_NORMAL, &ev);
if (rc == 0)
printf("Event: %s %s %d\n",
libevdev_event_type_get_name(ev.type),
libevdev_event_code_get_name(ev.type, ev.code),
ev.value);
} while (rc == 1 || rc == 0 || rc == -EAGAIN);
Is definitely doing the polling in a blocking way. I think this is intended to be run on a separate thread, and you pass the inputs to your main application thread via some other mechanism.
If your using the polling function, you should be able to do it in a single thread, but then you have to periodically check in between doing other work.
The separate thread did the trick for the most part, now I'm having a different issue, where I'll likely need a debugger. Let's hope Seer works for me and I don't have to spend a month to learn GDB, just so I don't spend 30 mins every time I need to search for a feature I don't know.
Excellent, feel free to open a new thread for your new problem then.
I used CLion on Linux, it does a good job of wrapping GDB and making it painless. Learning GDB is a valuable skill though.
Can you share your code somehow? The second call definitely shouldn't be blocking.
Ask the main part of your question in the title. This should be concise but informative.
Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.
Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.
Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient