[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy
From: |
Eli Zaretskii |
Subject: |
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] |
Date: |
Mon, 24 Jan 2022 18:52:20 +0200 |
> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: ijackson@chiark.greenend.org.uk, luangruo@yahoo.com,
> 53432@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 16:35:17 +0100
>
> >> The advantage of splitting into "keyboard" and "other things" buffers
> >> would be, that the keyboard buffer doesn't overrun, whatever burst of
> >> D-Bus or file notification events arrives.
> >
> > But the disadvantage is that we will immediately be facing a problem
> > of priority in handling input from more than one source.
>
> "Key strokes first!" :-)
But it isn't only the key strokes, it's also all the events sent to us
by the window-system. Now tell me why, say, an expose event should be
more important than a file-notification event, and not the other way
around?
> An alternative approach could be to restrict how many burst events are
> put into the beyboard buffer. Let's say that D-Bus and file notification
> events are allowed to fill that buffer until (KBD_BUFFER_SIZE - 512)
> events (arbitrary number). This would let place for key strokes, mouse
> events and alike.
That's what Po Lu was suggesting, AFAIU: limit the number of queued
file-notification events to not more than some threshold.
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], (continued)
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/22
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Eli Zaretskii, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages],
Eli Zaretskii <=
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Eli Zaretskii, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/25
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/23
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy, Eli Zaretskii, 2022/01/22