major changes to input handling in preparation for pasting, which will

require support for large blocks of input:

output which cannot be written to the tty (pty) is no longer
discarded. instead, the display module is responsible for keeping the
buffer alive until it has been entirely consumed. one simple (and
smart) way to ensure this is to refuse to process events that could
generate new input text as long as there is unwritten data. this works
as long as there is an earlier layer of buffering (for fbcon, kernel;
for x11, xlib). a direct-on-x-protocol display implementation will
have to do its own buffer management.

this architecture allows pasting to be performed direct from a buffer
owned by the display module, which could reside in static or shared
memory, or even as a memory-mapped file. it also facilitates reuse of
the code in non-tty-connected settings.

1 files changed, 2 insertions, 4 deletions

diff --git a/fbcon.c b/fbcon.c
index 7ea5412..cdec03d 100644
--- a/fbcon.c
+++ b/fbcon.c
@@ -154,7 +154,7 @@ int uudisp_fd_set(struct uudisp *d, int tty, void *fds)
 {
 	struct priv *p = (struct priv *)&d->priv;
 	if (p->ms >= 0) FD_SET(p->ms, (fd_set *)fds);
-	FD_SET(p->kb, (fd_set *)fds);
+	if (!d->inlen) FD_SET(p->kb, (fd_set *)fds);
 	return p->kb > tty ? p->kb+1 : tty+1;
 }
 
@@ -165,10 +165,8 @@ void uudisp_next_event(struct uudisp *d, void *fds)
 
 	get_fb_size(d);
 
-	d->inlen = 0;
-	d->intext = d->inbuf;
-
 	if (FD_ISSET(p->kb, (fd_set *)fds)) {
+		d->intext = d->inbuf;
 		d->inlen = read(p->kb, d->inbuf, sizeof d->inbuf);
 		if (d->inlen < 0) d->inlen = 0;
 	}