I can't imagine any way this static variable will mess up with multiple
threads. At worst not exactly 10 messages will be printed but that seems
really harmless. Every processor writes to memory a number larger than
it read, so eventually every processor will see a number >= 10 even if
there was absolutely no synchronization.
On 10/28/2014 12:18 PM, Derek Foreman wrote:
On 28/10/14 03:20 AM, Ran Benita wrote:
On Mon, Oct 27, 2014 at 09:26:39AM -0500, Derek Foreman wrote:
Log a message when the kernel event queue overflows and events are dropped.
After 10 messages logging stops to avoid flooding the logs if the condition
is persistent.
---
src/evdev.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/evdev.c b/src/evdev.c
index 1b4ce10..c786537 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -912,6 +912,7 @@ evdev_sync_device(struct evdev_device *device)
static void
evdev_device_dispatch(void *data)
{
+ static int overflows = 0;
Does libinput allow static variables? Usually when there's a library
context, it should be possible to use the library from multiple threads,
if they use different contexts.
So maybe this counter should be inside `device` instead of static?
I'm not sure libinput is completely thread safe, but that's an easy
change to make.
I'd like to put it in struct libinput to preserve the current behaviour
- but that puts an evdev specific wart in an otherwise generic structure.
Any objections?
Ran
struct evdev_device *device = data;
struct libinput *libinput = device->base.seat->libinput;
struct input_event ev;
@@ -924,6 +925,15 @@ evdev_device_dispatch(void *data)
rc = libevdev_next_event(device->evdev,
LIBEVDEV_READ_FLAG_NORMAL, &ev);
if (rc == LIBEVDEV_READ_STATUS_SYNC) {
+ if (overflows < 10) {
+ overflows++;
+ log_info(libinput, "Kernel evdev event queue "
+ "overflow for %s\n", device->devname);
+ if (overflows == 10)
+ log_info(libinput, "No longer logging "
+ "evdev event queue
overflows\n");
+ }
+
/* send one more sync event so we handle all
currently pending events before we sync up
to the current state */
--
2.1.1
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
