qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH for 6.1 1/2] ui/gtk: add a keyboard fifo to the VTE consoles


From: Gerd Hoffmann
Subject: Re: [PATCH for 6.1 1/2] ui/gtk: add a keyboard fifo to the VTE consoles
Date: Wed, 21 Jul 2021 14:39:42 +0200

  Hi,

> +static void gd_vc_send_chars(VirtualConsole *vc)
> +{
> +    uint32_t len, avail;
> +    const uint8_t *buf;
> +
> +    len = qemu_chr_be_can_write(vc->vte.chr);
> +    avail = fifo8_num_used(&vc->vte.out_fifo);
> +    if (len > avail) {
> +        len = avail;
> +    }
> +    while (len > 0) {
> +        uint32_t size;
> +
> +        buf = fifo8_pop_buf(&vc->vte.out_fifo, len, &size);
> +        qemu_chr_be_write(vc->vte.chr, (uint8_t *)buf, size);
> +        len -= size;
> +        avail -= size;
> +    }
> +    /*
> +     * characters are pending: we send them a bit later (XXX:
> +     * horrible, should change char device API)
> +     */
> +    if (avail > 0) {
> +        timer_mod(vc->vte.kbd_timer,
> +                  qemu_clock_get_ms(QEMU_CLOCK_VIRTUAL) + 1);
> +    }

There is ChardevClass->chr_accept_input() which gets called when you can
send more data, so there is no need to use a timer for that.

Typical workflow is to only read data when it can be pushed forward to
the guest, so when the guest stops reading data qemu stops doing so too,
effectively forwarding the stalls.  Which works fine for things like tcp
sockets.  Not so much for user input though.

So, yes, just throw away data is the only option we have here.  Adding a
reasonable-sized fifo makes sense too to cover bulky input, so you can
cut+paste a longish URL even if the guest accepts only a few chars at a
time (16550 fifo is 16 chars IIRC ...).

I would suggest to keep things simple, just throw away what you can't
store in the fifo, I don't see the point taking different actions
depending on how long the stalls are lasting (patch 2/2).

take care,
  Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]