Filip Hejsek <filip.hej...@gmail.com> writes: > On Tue, 2025-09-16 at 15:07 +0200, Markus Armbruster wrote: >> Filip Hejsek <filip.hej...@gmail.com> writes: >> >> > On Mon, 2025-09-15 at 08:35 +0200, Markus Armbruster wrote: >> > > Filip Hejsek <filip.hej...@gmail.com> writes: >> > > >> > > > On Fri, 2025-09-12 at 16:01 +0200, Markus Armbruster wrote: >> > > > > Cc: libvirt >> > > > > >> > > > > Filip Hejsek <filip.hej...@gmail.com> writes: >> > > > > >> > > > > > From: Szymon Lukasz <noh4...@gmail.com> >> > > > > > >> > > > > > [...] >> > > > > > >> > > > > > +## >> > > > > > +# @chardev-resize: >> > > > > >> > > > > This name doesn't tell me what is being resized. PATCH 04 uses >> > > > > "winsize", which is better. The (losely) related SIGWINCH suggests >> > > > > "window change" or "window size change". Below, you use "terminal >> > > > > size". >> > > > >> > > > How about chardev-console-resize? That would match the name of the >> > > > virtio event (VIRTIO_CONSOLE_RESIZE). >> > > >> > > Not bad. It could become slightly bad if we make devices other than >> > > "consoles" make us of it. Would that be possible? >> > >> > I don't think the size has any meaning for devices that are not >> > connected to a console, although the code does not care whether it >> > actually is a console and simply has a size for every chardev. >> >> Double-checking: the command works for any ChardevBackendKind, doesn't >> it? > > Yes. For some (e.g. stdio) it will clash with builtin resize detection, > but it can still be used (last update wins). > > Maybe using the command should be prohibited for some device types?
Depends on the command's intended use. In general, failing a command is better than silently not doing what it commands. If the command is "tell the guest the window size changed", and we can't, then failing the command is better than silently doing nothing. Howver, other considerations can trump this. If we want to use this command on any window size change without having to know the device type, having it silently do nothing for device types that don't support it can be more convenient. Fine as long as the behavior is clearly documented. >> > I guess I could also rename it to chardev-window-resize >> > or chardev-set-window-size. Let me know if you prefer one of these. >> >> I think I'd prefer "window" or "terminal". >> >> "resize" and "set size" suggest that the command initiates a size >> change. Not true, it notifies of a size change. Maybe >> "chardev-window-size-changed", "chardev-terminal-size-changed", >> "chardev-window-resized", or "chardev-terminal-resized". > > OK, then I'll use "chardev-window-size-changed". > >> > > > > >> > > > >> [...] >> Another question... 'vc' chardevs accept optional @rows, @cols (see >> ChardevVC). Is this the same size or something else? > > Well, yes and no. @cols + @rows control the actual size of the console > screen buffer, while the chardev size is only used to inform the guest > about the size. @cols and @rows can also be unset, in which case the > size will be determined automatically from display and font size. Thanks! > This patch series does not yet implement size propagation for the 'vc' > device. I have WIP patches for that, but there is something I'm not > sure how to do, so I will likely send an RFC first. Would it make sense to mention this gap in a commit message? >> > > A clearly invalid size. I guess it effectively means "unknown size". >> > > Should we document that? >> > >> > Probably. 0x0 is I think also the default size in the Linux kernel, but >> > I don't think the Linux kernel documents this. >> >> How does 0 x 0 behave compared to a valid size like 80 x 24? > > In these patches it is not treated specially (apart from being the > default). I think the Linux kernel doesn't treat it specially either. > Terminal programs generally interpret it as unknown size and use other > methods to obtain the size like environment variables, the terminfo > database, or defaulting to 80x24. Example: > > $ python -c 'import termios; termios.tcsetwinsize(0, (0,0))' > $ tput cols > 80 Do you think working this into the documentation would be useful? >> [...] >> > > > > Do we need a way to query the size? >> > > > >> > > > I don't think it is necessary. What would be the usecase for that? >> > > >> > > I don't know, but it's my standard question when I see an interface to >> > > set something without an interface to get it. Its purpose is to make us >> > > think, not to make us at the get blindly. >> > >> > I guess it might be useful for debugging. If the size is not propagated >> > correctly, one might query it to find out on which side the problem is. >> >> We have query-chardev. It doesn't return much. > > I'm not sure what you're implying. Shall I add the size there? If we could already query chardev configuration / state comprehensively, then I'd ask you to make it cover your new state bits, too. Since we don't, and there is no clear use case at this time, I'm not asking you to do that.
