Bug 2116534

That appears to be a bad interaction between some upstream changes
and a downstream patch.

Downstream:
  MdeModulePkg: TerminalDxe: add other text resolutions (RHEL only)

Upstream:
  96e1d337e010 ArmVirtPkg: clear PcdConOut{Row,Column}
  5a17629902d8 OvmfPkg: clear PcdConOut{Row,Column}
  b807174fecac MdeModulePkg/GraphicsConsoleDxe: add modes

Specifically 96e1d337e010 makes the firmware default to the largest text
resolution available, which is 100x31 chars (aka 800x600 pixels) for
upstream TerminalDxe.

The downstream patch adds a longish list of modes to TerminalDxe.
And the combination of the two leads to a *huge* default text mode:

---------------------- cut here ------------------
UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
     BLK0: Alias(s):
          PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> mode
Available modes for console output device.
  Col    80 Row    25   
  Col    80 Row    50   
  Col   100 Row    25   
  Col   100 Row    31   
  Col   104 Row    32   
  Col   120 Row    33   
[ ... ]
  Col  1024 Row   227  *
Shell>
---------------------- cut here ------------------

This happens only in case there is no (ovmf-supported) display
device present as it is typically the case on aarch64, but it
is also reproducable on x64 with '-vga none'.

In case a display device is present the mode list is the
intersection of the modes supported by TerminalDxe and
GraphicsConsoleDxe, which is a much smaller list with the
default qemu configuration:

---------------------- cut here ------------------
Shell> mode
Available modes for console output device.
  Col    80 Row    25   
  Col   100 Row    31   
  Col   128 Row    40   
  Col   160 Row    42  *
Shell>
---------------------- cut here ------------------

So, here we stand and I'm not sure how to continue best as
all the options I see have some drawbacks:

(1) Drop the downstream patch.  Will have the effect that the
    text mode is 100x31 max in case a serial console is present.
    (without serial console only GraphicsConsoleDxe capabilities
    matter, you'll get more modes then).
    The largest text mode continues to be used by default.

(2) Revert the upstream patches setting PcdConOut{Row,Column} to
    zero.  That will make 80x25 the default text mode.  Higher
    resolutions will be available but not be used unless explicitly
    selected.

(3) Cut down the mode list in the downstream patch.  The tricky part
    here is to figure something sensible given we have contradicting
    requirements for vga vs. serial.  For a vga display it clearly
    makes sense to use as much as possible of the available screen
    space.  For the serial console it makes sense to restrict things
    to something which fits into typical terminals ...
    - 1024 cols is insane high.
    - 80 cols is rather small (greetings from the 90-ies).
    - 100 cols should be ok with the screen sizes we have these
      days.  Code styles tend to go from 80 cols to 100 cols too,
      so apparently that is the new minimum ;)
    - How about 128 cols?  Or 160 cols?

Cc'ing some folks for comments / ideas.

I would take option (1): although 100x31 is a strange number it is close
to what you propose in (3) and totally enough IMO.  This option seems to
be the least amount of maintenance work.

But this is just my taste...
Does anybody use the serial console on a VM to do actual work where higher
text mode resolutions would be useful?

"pick the largest resolution in the firmware" works well for users only as long as "the largest resolution" is driven from the host side. That's the case with the graphics display devices supported by qemu, but not with the serial console per se. In case the guest has both graphics and serial, the former limits the latter too, so ultimately the host dictates the resolution for both, but if the former falls away, the latter can run wild.

The reason for really wide terminal resolutions is debugging in the UEFI shell, and capturing the output in tmux or screen. Some commands produce wide output (tabular output, or just output that really benefits from not being broken up into many-many short lines). So normally you'd not strictly need these large resolutions, but it's really nice to have them around for when you need to debug something in the UEFI shell (consider the commands "drivers", "devices", "dh -d -v", and so on).

For *me personally*, that rules out option (1).

A further problem I suspect with option (1) is that with OVMF, you *cannot not* have a serial terminal in practice -- or at least I think all default domain configs will include one. Therefore if you drop the downstream-only patch altogether, per (1), then TerminalDxe will limit ConSplitterDxe, even though GraphicsConsoleDxe would like to pick the largest available resolution. I think that might break user experience too.

Option (2) is not superb because it regresses user experience in the common case, for the sake of a less frequent developer case (debugging).

A variant of option (2) would be to preserve the explicit PcdConOut{Row,Column} settings in the ArmVirt / OVMF DSC files, but (a) use something fixed rather than "pick max available", *and* (b) make that "something fixed" significantly larger than 80x25. This would strike a compromise between end-user experience and the debugging use case: start out with a *usably large screen* by default, but still have the option to raise the terminal size. I realize this is, simultaneously, a variant of option (3), where we try to figure out the best default resolution.

Option (3) is not great because in some cases the "reduced max default" can still be too large, and in other cases it could prove too small (for developers / debugging), without the option to enlarge.

The root problem (= TerminalDxe's resolution list cannot be directly limited from the host side) reduces all of these options to just workarounds. Personally I would favor myself as a developer, and go with the option (2) variant that I outline above -- i.e., set PcdConOut{Row,Column} to 100x31 (800x600 px), or 128x31 (1024x600 px), or 128x40 (1024x768 px).

(In reply to Laszlo Ersek from comment #3)

> A further problem I suspect with option (1) is that with OVMF, you *cannot
> not* have a serial terminal in practice -- or at least I think all default
> domain configs will include one. Therefore if you drop the downstream-only
> patch altogether, per (1), then TerminalDxe will limit ConSplitterDxe, even
> though GraphicsConsoleDxe would like to pick the largest available
> resolution. I think that might break user experience too.

NB *if* I'm wrong about this, *and* you don't expect your users to collect UEFI shell debugging output for you, then option (1) is likely the most viable.

> The reason for really wide terminal resolutions is debugging in the UEFI
> shell, and capturing the output in tmux or screen. Some commands produce
> wide output (tabular output, or just output that really benefits from not
> being broken up into many-many short lines). So normally you'd not strictly
> need these large resolutions, but it's really nice to have them around for
> when you need to debug something in the UEFI shell (consider the commands
> "drivers", "devices", "dh -d -v", and so on).

Hwo to you use that in practice?  With a serial console only?  Or with both
vga+serial and a high-res gfx resolution so you get high-res text modes too?

There is also the option to query the terminal for the current size and add
that to the TerminalDxe text mode list.  Should work nicely with serial-only.
With vga+serial there is a high chance that the mode is dropped when
ConSplitterDxe builds the mode list intersection though.

(In reply to Gerd Hoffmann from comment #5)
> > The reason for really wide terminal resolutions is debugging in the
> > UEFI shell, and capturing the output in tmux or screen. Some
> > commands produce wide output (tabular output, or just output that
> > really benefits from not being broken up into many-many short
> > lines). So normally you'd not strictly need these large resolutions,
> > but it's really nice to have them around for when you need to debug
> > something in the UEFI shell (consider the commands "drivers",
> > "devices", "dh -d -v", and so on).
>
> Hwo to you use that in practice?  With a serial console only?  Or with
> both vga+serial and a high-res gfx resolution so you get high-res text
> modes too?

I tend to use both OVMF and ArmVirtQemu with gfx+serial both
(virtio-gpu-pci with ArmVirtQemu), so yes, I used to set the gfx
resolution in the Setup TUI to the maximum that my physical screen would
accommodate, including window manager decorations, WM taskbar etc. That
would usually yield a large enough, but not too large terminal size too.
Something like 200x47 textual (1600x900 graphical).

I've just retested that -- yes, it works nicely on my end. For example,
the "devices" command outputs lines such as:

> Shell> devices
>      T   D
>      Y C I
>      P F A
> CTRL E G G #P #D #C  Device Name
> ==== = = = == == === =========================================================
> [...]
>   D6 D - -  1  1   0 PciRoot(0x0)/Pci(0x2,0x4)/Pci(0x0,0x0)/Scsi(0x0,0x0)/HD(3,GPT,7901B9BA-B0C0-4623-9DDF-C7E5FEFE7657,0x264800,0xC59B000)
> [...]

(this is the longest line; 139 characters)

> There is also the option to query the terminal for the current size
> and add that to the TerminalDxe text mode list.  Should work nicely
> with serial-only.

Great idea :) I hacked xterm controlling (resizing) sequences into
TerminalDxe, but not querying ones! :)

One gotcha is that in "screen", the terminal resizing does not work, so
the querying might not work either. What I usually do for "screen" is,
first launch the guest with "virsh start --console --paused", get into
the UEFI shell, resize all outputs with a command like "mode 200 47",
then power off the guest with "reset -s", then rerun the same "virsh"
command, but this time from within a screen session started in the same
terminal. Yes, quite cumbersome.

Worse, "screen"'s terminal capture to a log file doesn't work for all
use cases. The "dh -d -v" command outputs a highly colorized text, which
is nice to read on-screen, but the captured logfile is chock-full of
control sequences. So in such cases, I even avoid "screen", and just cut
and paste from the xterm scrollback directly, into a text file -- that
gets rid of the colorization nicely, giving me the plaintext that I'm
after. And for this clipboard operation, I find a wide terminal even
more helpful.

Example (excerpt):

> Shell> dh -d -v -p SimpleNetwork
> Handle dump by protocol 'SimpleNetwork'
> DA: Dns4ServiceBinding(7D03D7A0) Dns6ServiceBinding(7D03EC20) 28BE27E5-66CC-4A31-A315-DB14C3744D85(7D03FF30) FA3CDE4C-87C2-427D-AEDE-7DD096C88C58(7D041630) ECEBCB00-D9C8-11E4-AF3D-8CDCD426C973(7D043170) HttpServiceBinding(7D04C7A0) B95E9FDA-26DE-48D2-8807-1F9107AC5E3A(7D052030) Tcp6ServiceBinding(7D0607C0) TCPv4ServiceBinding(7D063BC0) Mtftp6ServiceBinding(7D0640A0) Dhcp6ServiceBinding(7D067C30) Udp6ServiceBinding(7D06B820) Ip6Config(7D06FF70) Ip6ServiceBinding(7D06F020) MTFTPv4ServiceBinding(7D072020) DHCPv4ServiceBinding(7D0780A0) UDPv4ServiceBinding(7D07BE20) IPv4Config2(7D080600) IPv4ServiceBinding(7D0800A0) ARPServiceBinding(7D0A26A0) E4F61863-FE2C-4B56-A8F4-08519BC439DF(7D1C8918) ManagedNetworkServiceBinding(7D1C8E40) VlanConfig(7D1C9C30) DevicePath(7D6D0298)   PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1) SimpleNetwork(7D1CA428)
>    Controller Name    : Virtio Network Device
>    Device Path        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)
>    Controller Type    : BUS
>    Configuration      : NO
>    Diagnostics        : NO
>    Managed by         :
>      Drv[93]          : VLAN Configuration Driver
>      Drv[94]          : MNP Network Service Driver
>      Drv[97]          : IP4 Network Service Driver
>      Drv[9B]          : IP6 Network Service Driver
>      Drv[A0]          : UEFI PXE Base Code Driver
>      Drv[A1]          : UEFI PXE Base Code Driver
>      Drv[A8]          : UEFI HTTP Boot Driver
>      Drv[A9]          : UEFI HTTP Boot Driver
>    Parent Controllers :
>      Parent[B9]       : Virtio Network Device
>    Child Controllers  :
>      Child[DB]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(D79DF6B0-EF44-43BD-9797-43E93BCF5FA8)
>      Child[DC]        : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x806, VlanId=0)
>      Child[DD]        : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x800, VlanId=0)
>      Child[E4]        : MNP (MAC=52-54-00-3E-37-5F, ProtocolType=0x86DD, VlanId=0)
>      Child[DE]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(9FB1A1F3-3B71-4324-B39A-745CBB015FFF)
>      Child[E5]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/VenHw(5BEDB5CC-D830-4EB2-8742-2D4CC9B54F2C)
>      Child[F7]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv4(0.0.0.0)
>      Child[FF]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000)
>      Child[106]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv4(0.0.0.0)/Uri()
>      Child[109]        : PciRoot(0x0)/Pci(0x2,0x0)/Pci(0x0,0x0)/MAC(5254003E375F,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000)/Uri()

> (1) Drop the downstream patch.  Will have the effect that the

Commented the patch for now (to have the resgression fixed while the disconssion is ongoing).
Builds done, rpms should be in rawhide and f36 updates testing soon.

> > There is also the option to query the terminal for the current size
> > and add that to the TerminalDxe text mode list.  Should work nicely
> > with serial-only.
> 
> Great idea :) I hacked xterm controlling (resizing) sequences into
> TerminalDxe, but not querying ones! :)

Quick + dirty hack works.

The tricky issue is how long to wait for a response.  If the timeeout
is too short you risk the terminal response being interpreted as key
strokes later on, but a longer timeout increases the boot time ...

> One gotcha is that in "screen", the terminal resizing does not work, so
> the querying might not work either.

Pawel is checking out these patches, investigating how well they work with
various terminal emulators.  Most apps work fine, some don't.

Trying screen / tmux too is a good idea.

I suspect screen doesn't work due to supporting split screens and
responding in a sensible way to resize requests with split screen
active is hard.  The "Terminator" emulator which supports split screens
too doesn't respond to resize requests either.  And I wouldn't be
surprised if tmux falls into that group too.

Just returning what the current size is is much easier and in fact many
terminal apps (vim, mutt, ...) depend on that working.

(In reply to Gerd Hoffmann from comment #8)
> > > There is also the option to query the terminal for the current size
> > > and add that to the TerminalDxe text mode list.  Should work nicely
> > > with serial-only.
> > 
> > Great idea :) I hacked xterm controlling (resizing) sequences into
> > TerminalDxe, but not querying ones! :)
> 
> Quick + dirty hack works.
> 
> The tricky issue is how long to wait for a response.  If the timeeout
> is too short you risk the terminal response being interpreted as key
> strokes later on, but a longer timeout increases the boot time ...
> 
> > One gotcha is that in "screen", the terminal resizing does not work, so
> > the querying might not work either.
> 
> Pawel is checking out these patches, investigating how well they work with
> various terminal emulators.  Most apps work fine, some don't.
> 
> Trying screen / tmux too is a good idea.
> 
> I suspect screen doesn't work due to supporting split screens and
> responding in a sensible way to resize requests with split screen
> active is hard.  The "Terminator" emulator which supports split screens
> too doesn't respond to resize requests either.  And I wouldn't be
> surprised if tmux falls into that group too.

I use a terminal normal emulator (alacritty) and a tiling window manager (sway).
This probably behaves in the same way, because the window sizes is dictated
by the WM and the terminal emulator can't resize itself.

> 
> Just returning what the current size is is much easier and in fact many
> terminal apps (vim, mutt, ...) depend on that working.

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.