On Mon, Sep 15, 2025 at 10:41:44AM +0200, Maximilian Immanuel Brandtner wrote: > On Fri, 2025-09-12 at 09:50 +0100, Daniel P. Berrangé wrote: > > On Fri, Sep 12, 2025 at 04:41:02AM -0400, Michael S. Tsirkin wrote: > > > On Fri, Sep 12, 2025 at 05:39:45AM +0200, Filip Hejsek wrote: > > > > The goal of this series is to have a resizable terminal into a > > > > guest > > > > without having to set up networking and using, e.g. ssh. > > > > > > > > The virtio spec allows a virtio-console device to notify the > > > > guest about > > > > terminal resizes in the host. Linux Kernel implements the driver > > > > part of > > > > the spec. This series implement the device part in QEMU. > > > > > > > > This series adds support for a resizable terminal if a virtio > > > > console > > > > device is connected to the stdio backend. > > > > > > > > This series also introduces resize messages that can be sent over > > > > QMP to > > > > notify QEMU about the size of the terminal connented to some > > > > chardev. > > > > In the libvirt setting, it will allow to implement a resizable > > > > terminal > > > > for virsh console and other libvirt clients. > > > > > > > > This patch series was originally authored by Szymon Lukasz and > > > > submitted > > > > to qemu-devel about 5 years ago. The previous submission can be > > > > found at > > > > < > > > > https://lists.nongnu.org/archive/html/qemu-devel/2020-06/msg09591. > > > > html>. > > > > I have updated the patches to be compatible with latest master > > > > and made > > > > a few small changes of my own, including the addition of Windows > > > > support. > > > > > > > > Probably the most important change I made is the swapping of rows > > > > and > > > > cols fields in resize messages. I would like to hear some > > > > feedback on > > > > this change from reviewers. The problem is that for a long time, > > > > the > > > > Linux kernel used a different field order from what was specified > > > > in the > > > > virtio spec. The kernel implementation was apparently merged > > > > around 2010, > > > > while the virtio spec came in 2014, so when a previous version of > > > > this > > > > patch series was being discussed here on this mailing list in > > > > 2020, it > > > > was decided that QEMU should match the Linux implementation, and > > > > ideally, > > > > the virtio spec should be changed. > > > > > > > > However, recently, the Linux kernel implementation was changed to > > > > conform > > > > to the spec: > > > > <https://git.kernel.org/linus/5326ab737a47278dbd16ed3ee7380b26c70 > > > > 56ddd>. > > > > As a result, to be compatible with latest kernel releases, QEMU > > > > needs to > > > > also use the field order matching the specification. I have > > > > changed the > > > > patch to use the spec-compliant order, so it works correctly with > > > > latest > > > > kernels now. > > > > > > > > > > Well this is not in any release yet. If you want me to revert that > > > one, let me know ASAP. Maximilian? > > > > > > > That leaves the issue of older kernels. There are about 15 years' > > > > worth > > > > of kernel versions with the swapped field order, including the > > > > kernel > > > > currently shipped in Debian stable. The effects of the swapped > > > > dimensions > > > > can sometimes be quite annoying - e.g. if you have a terminal > > > > with > > > > 24 rows, this will be interpreted as 24 columns, and your shell > > > > may limit > > > > line editing to this small space, most of which will be taken by > > > > your > > > > prompt. The patch series in its current form provides no way to > > > > disable > > > > the console size functionality, > > > > > > Well I see the console-size property, no? > > > > At least in the case of libvirt managed VMs, this series does > > nothin by default, as they won't be using the 'stdio' chardev, > > they'll require libvirt to first wire up the new QMP command, > > and then apps using libvirt to call it. So in that sense, it'll > > take a while before the effects are seen by users. > > Correct me if I'm wrong on this, but shouldn't the 'pty' chardev also > be able to take advantage of the same size change mechanisms as the > 'stdio' chardev (receiving SIGWINCH and being able to use the ioctl > TIOCGWINSZ)? If so the work for the 'stdio' chardev should probably be > replicated for the 'pty' chardev.
Yes, if using a suitable client app, it ought to work for 'pty' I think. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
