On 2/20/25 10:20, Philippe Mathieu-Daudé wrote:
Hi,
QEMU provides the global '-g' CLI option:
$ qemu-system-foo --help
-g WxH[xDEPTH] Set the initial graphical resolution and depth
This option is used to pass resolution/depth information to guest
firmwares in the machines defined in the following files:
hw/ppc/mac_newworld.c
hw/ppc/mac_oldworld.c
hw/ppc/prep.c
hw/ppc/spapr.c
hw/sparc/sun4m.c
hw/sparc64/sun4u.c
Examples:
- hw/ppc/spapr.c:1102:
_FDT(fdt_setprop_cell(fdt, c, "qemu,graphic-width", graphic_width));
- hw/sparc64/sun4u.c:716:
fw_cfg_add_i16(fw_cfg, FW_CFG_SPARC64_WIDTH, graphic_width);
Obviously we have default values, which are different per architecture!
Clearly these ought to be machine properties.
Yes, we should have an easy way for machine to allow, in addition to -M
graphics=BOOLEAN, the structured property -M
graphics.{width,height,depth,enabled}. Then '-g' can desugar to -M
graphics.width=WW,graphics.height=HH,graphics.depth=BB.
It is also used to set TYPE_NUBUS_MACFB properties in hw/m68k/q800.c.
Here i suppose we could directly use '-global nubus-macfb.width=value'
etc. although I'm not sure it is the recommended way.
Should we start deprecating '-g' as a whole?
Only if it's unused/useless. If the option is useful it could also be
used for EDID, for example (adding Gerd).
Global variables are hard to track, and the one-off nature of the option
makes it hard to figure out (without looking at the code) which machine
support it.
However, if the properties were available and introspectable via QOM,
then it wouldn't matter if the -g sugar remains as an isolated "case
QEMU_OPTION_g:" in system/vl.c. For an example see -boot/-smp or
-no-reboot/-no-shutdown.
Paolo
