Wrong formula in gui-configuration doc?

[qubist]

Hi,

Is the formula in https://www.qubes-os.org/doc/gui-configuration/ both
wrong and incomplete?

The correct calculation (for 8-bit displays) seems to be:

(3840 * 2160 + 1920 * 1080) * 4 / 1024 = 40500

If e.g. the 4K screen is 10-bit, this means 1.25 bytes, i.e.

((3840 * 2160) * 1.25 + ( 1920 * 1080 )) * 4 / 1024 = 48600

The doc does not address 10-bit displays.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It doesn't matter what your display is using, the memory allocated in VM
for the frame buffer is 32-bits per pixel.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYljLoACgkQ24/THMrX
1yyBjQf/dtV0qWxhSK0CXl+YSe5CxeZRygU8fyWikqHFfvd3z61Um7z7YFAMyJES
SzW18+VzTZEVWqjvlnX5h34L4VZ2KenXr+4kuP33vRFS0B583cLvwEAvJ8f+3ddR
P5Xc4IyvZTOJ/PL4RKeLOSM5SSCh8yayPOKWntGruhny1BccIkuCKnV/npVclfR5
tJVXoUCeV/ic+/L1rVo1Y7F4qHmLFmS7QQLoiyPT6pbWTQDJwdnChrRk+fAQr8QA
KGcYMZ56Omtp8Qjox6WNzo0+gYBchXrLgJEuWwEiIP0hJEqxtkGWNRygkCh3qp6S
miAnRC85zcHveqiJN24GbLX3qI8csA==
=Htm+
-----END PGP SIGNATURE-----

[qubist]

On Mon, 22 Apr 2024 00:01:30 +0200 Marek Marczykowski-Górecki wrote:

> It doesn't matter what your display is using, the memory allocated in
> VM for the frame buffer is 32-bits per pixel.

When using a 4K 10-bit display (note the bpp):

root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info
pipe src=3840x2160+0+0, dither=no, bpp=30
pipe src=0x0+0+0, dither=no, bpp=0
pipe src=0x0+0+0, dither=no, bpp=0

When using a 2K 8-bit display:

root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info
pipe src=0x0+0+0, dither=no, bpp=0
pipe src=1920x1080+0+0, dither=no, bpp=24
pipe src=0x0+0+0, dither=no, bpp=0

Also, according to 'xrandr --verbose", max bpc is 12.

How do you read this?

If it is always 32 bits, it would mean 2-bit alpha for 10-bit display.
Or does Qubes OS even support 10/30-bit color?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

VMs do not see nor care what display is connected. From the VM point of
view it's always 32 bits per pixel (3x8 + 8 padding, as alpha is not
supported).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmSncACgkQ24/THMrX
1yxtzwf8CShXlR8j4651qFqPti6tHfL2gs9Jred4yvi3xdoZ9KLnGMZYUFoR/QN/
yZlfklge0foJHDDpOUcB+Q+Ku2SfS0Did6yUMaHQVwGH1X8zXkcLYOwIICOR2FDv
9uwdqpLEVLZK3Qmsu9RDGSs83dlub1KXzWtPaW1eMfDbxrYj5OJGjPpqsB4dT4MI
YroowdXAV3+7pWt7Snb6MhRMgUKRHrXlxjLa5yl+CKZaB0eIfDMh2Dbs+0X581S9
z0j9JyUWte/BdQc6E0+EwCSpvn3qZfNazFC4hDb83J/mHlf7Uu5hT4oYBmPPsshq
LztovCmualC9aA+w6Sbm0HGLMg/wkw==
=Dgxd
-----END PGP SIGNATURE-----

[qubist]

On Mon, 22 Apr 2024 13:31:03 +0200 Marek Marczykowski-Górecki wrote:

> VMs do not see nor care what display is connected.

But what I am pasting is from dom0. Or are you saying it doesn't see it
either?

It is still not clear whether if it is possible to use 10/30-bit color.
Should I ask somewhere else?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Apr 22, 2024 at 01:01:55PM -0000, qubist wrote:
> On Mon, 22 Apr 2024 13:31:03 +0200 Marek Marczykowski-Górecki wrote:
>
> > VMs do not see nor care what display is connected.
>
> But what I am pasting is from dom0. Or are you saying it doesn't see it
> either?

The formula on
https://www.qubes-os.org/doc/gui-configuration/#video-ram-adjustment-for-high-resolution-displays
is about informing VMs how much memory they need to allocate for video
ram. I know it's a bit unintuitive as the value is set on dom0, but it's
because the value on dom0 is the default for all VMs, so you can set it once
instead of on every VM separately.

> It is still not clear whether if it is possible to use 10/30-bit color.

You can use such display, but VMs won't see wider color space, they will
still use 8 bits per color (and dom0 will covert to whatever format your
display uses).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmY7sACgkQ24/THMrX
1yw2SwgAie0fWITCQGUo2kOFHJePtSRF1FNAHpEe/09MNSPvdk8YXmSLhtL7AAtX
L7c2kpQt21TeA6v871T4mc43pkWVY/5Q7utnQamP0gtHx/8lmXQBfZJb96J1bIWy
v8e9ek/Z/2fbHD4xdYyKnfOvVon7QqTO02bNBH9cnuD+iPEzjXpe7fsIU9hZZB8u
aKFcduKCuA6kGvUcE6FUzRGeRAF1JYAyr4rUBNlSnLjZ5rTz28UfBQmpgDTHoAyF
nXH8aw3TfiD7DOugJGpxWph5pLXe5QYj2Pk1wuApPLL1BX4XUWstNLW/jQwrvK8G
ohuSCGRZzGG1fu45Vcvcc2UcRa/RmQ==
=wGMh
-----END PGP SIGNATURE-----

[qubist]

Thanks for explaining.

If only one of the displays is currently in use (and the whole desktop
fits in it), does it make sense to reduce the the allocated video RAM
to its requirements only (the qvm feature value)?

I am asking because this can be done through a simple script in dom0,
triggered by a shortcut key (e.g. one switches from display1 to
display2, or to dual screen and back).

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

If you don't set the value at all, VM will allocate based on currently
connected displays. But changing the value requires restarting relevant
VMs, so if you care about connecting external display without restarting
all VMs, then no, you cannot lower it. But if you don't care about the
need to restart, then you may not need to set the value manually at all.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmapIACgkQ24/THMrX
1yy7IggAi7ksQ5QEG3hrwZIAvrZWeC3gvpfhw0iyqXxpnWo87IgfjSeElT5QHh8H
8WCQmj3BahldgcSfWvJeGJ5wuPiB+qpVQeX5emydC2XfENmyG8b3lfrVIn14uxvg
4rCW6GbRP24UZmU0Ed+1WRGE/4MkFjMfTg+na8NUE7mwUJJQOoHwoJzDjvuf4/oh
vm1wzwwvugieV+EsCA4c+a/qfrYWFMxwqXQbv85OzLiSCDMKW4jSf/DX4Jw2KUHn
4AJh7hy3lBcME6bjLbq+Cippkbm7xb8Jlu87uUbRIKCiJZdW5VOPuOUe8CTOH+yQ
86oB1V6CxQqMw+3cEQeC01vjS3+9ow==
=am77
-----END PGP SIGNATURE-----

[qubist]

On Mon, 22 Apr 2024 15:48:02 +0200 Marek Marczykowski-Górecki wrote:

> If you don't set the value at all, VM will allocate based on currently
> connected displays.

Hm. This raises a few questions:

1. Does it mean https://www.qubes-os.org/doc/gui-configuration/ is
irrelevant/outdated?

2. What happens with allocation if one switches from one display setup
to another while VM(s) are running?

3. What about headless VMs (no guivm)? Is video memory allocated for
them too? (thus wasting resources)

4. A somewhat difficult setup:

Due to both displays having different resolutions and because I have
been unable to find a way to set different DPI per display, currently,
it is necessary to do this when switching to the only-2K display or
dual-screen setup:

xrandr --output DP-2 --scale 2x2

Without that, everything on the 2K screen is overscaled and working
side-by-side is not possible.

Does that somehow influence the formula in the docs (because
effectively the pixels on DP-2 become x4 less)?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Apr 22, 2024 at 04:37:54PM -0000, qubist wrote:
> On Mon, 22 Apr 2024 15:48:02 +0200 Marek Marczykowski-Górecki wrote:
>
> > If you don't set the value at all, VM will allocate based on currently
> > connected displays.
>
> Hm. This raises a few questions:
>
> 1. Does it mean https://www.qubes-os.org/doc/gui-configuration/ is
> irrelevant/outdated?

No, please read the text leading to the formula, not just the formula
itself...

> 2. What happens with allocation if one switches from one display setup

> to another while VM(s) are running?o

Read that page...

> 3. What about headless VMs (no guivm)? Is video memory allocated for
> them too? (thus wasting resources)

No.

> 4. A somewhat difficult setup:
>
> Due to both displays having different resolutions and because I have
> been unable to find a way to set different DPI per display, currently,
> it is necessary to do this when switching to the only-2K display or
> dual-screen setup:
>
> xrandr --output DP-2 --scale 2x2
>
> Without that, everything on the 2K screen is overscaled and working
> side-by-side is not possible.
>
> Does that somehow influence the formula in the docs (because
> effectively the pixels on DP-2 become x4 less)?

What matters is the pixel count, not pixel size.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmk2gACgkQ24/THMrX
1yxhQgf/aUFI437ylLXN16RLu64tg+wUPR6xt8Vl/xwNKdZzW5HjEp7Beuo/ew3A
oa1ZdP0mIZTV/bRXRNw0wjnFYgNrb58Eq+N7whw0z5l61ZCrojIRDY7/yfOzPh9+
+x7uCUEYwytpsRftjZUwzyeq2jza3GeMup0Ql5f4C6nEOcDcJDqbGvqnx3h1V3yq
DExNy+3x2M9Ag/ttWbvsHc0+uqEl+Z/tzsPrjrTHFMALwlQWn7q7QHKoHeWtkc9J
2YBWLcUeWoGV3fsZBk+hTT1DW81/buqH1ABnymVPYEQXzhJXHV868G+bahpZIEK7
yJICgk1FMilShTsIpglERVdSAr/2Zg==
=XwaZ
-----END PGP SIGNATURE-----

[qubist]

Thanks. Had a closer look now.

On Mon, 22 Apr 2024 18:42:16 +0200 Marek Marczykowski-Górecki wrote:

> What matters is the pixel count, not pixel size.

But which pixel count?

The pixel count reported by xrandr with the 2 screens side by side (4K
primary) is:

user@dom0:~ > xrandr --verbose | grep "Screen 0" | sed -e 's/.*current//' -e 's/\,.*//'
7680 x 2160 (which means 64800 KiB for gui-videoram-min)

which is different from 3840 * 2160 + 1920 * 1080 (i.e. 48600 KiB).

So, the 2 formulas in the doc still give different result and it is not
clear which one is correct.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It's about the pixel count as seen by the applications, which may not
necessarily be the display resolution if scaling is involved.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmuXQACgkQ24/THMrX
1yx0zgf/UbIX8w0XBGy0iqObsS8A/jWjtj4c3aCvLCgWfxhnWyUjyyyKZYMpEwqT
lT98KrrFUynnjCW0c3ywzuR9T2ESV7NQqsoj85tRSLEnDHAG4wjgw0x6RyMbqPrN
undP4RWV/sdO60a8u3t55lfxxnnbjeXmaNHNWgNtRiqAixjJiFbhlJ3FT8/NYcd9
YJQ67RRDj4GdPbCQptzYlvoepTiQ3nxkaKakPv92/tKGntIDvfyVz3tiyiSnY+zD
AMXV+TIAB6pf26mwpja551WyEq3eB3iNzFIpSrrKAPD5I5kHrlNfrrqPoh+OdN5T
dnugSim2/6x2ku7XP7ekW+vYapl4gA==
=+ylP
-----END PGP SIGNATURE-----

[qubist]

On Mon, 22 Apr 2024 21:24:36 +0200 Marek Marczykowski-Górecki wrote:

> It's about the pixel count as seen by the applications, which may not
> necessarily be the display resolution if scaling is involved.

Are you saying that scaling means preserving the original pixel count
(i.e. apps draw on the original, unscaled canvas) and then the whole
thing is scaled down in real time? Is this how xrandr works?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Let me clarify it this way: when using scaling, you will see for example

eDP-1 connected primary 1920x1080+0+1200 (normal left inverted right x axis y axis) 309mm x 174mm
2560x1440 60.00*+ 59.99 59.99 59.96 59.95
...

Use the 1920x1080 in the formula, not 2560x1440

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnjHMACgkQ24/THMrX
1yy6PwgAiyBrVYEnreVgRyBq6/NNQUZR8rd3b5rjzixDdZMRrNfPZ7F1rX+ww+jn
c3iROIcepGTzPogM7bBQJpco+Qa5jEcp5mfyN6z62D8IBvP6hZZNwcVY80o3lCzZ
DhvVuvz49bA00CW98gppo9SjNT9v15YKW+NVVim7qtPsMTAglz1tNx9hbnsCtB9m
oP2k816/AAbSvdaqAbcYqjP/T8Vcety+k3zH5bZ2ZAooQTXulZ49b74inl9nUFWJ
KzKtPY7zkw+cyYwwYIVEpNSMkEePMhHUHaeQHgN7wsMHuP91SD2SB4DthvujIuqq
BB9gOHSF8K5Vt2RJtjiDsG5EMW6hAQ==
=Foc3
-----END PGP SIGNATURE-----

[qubist]

I see this (essential lines only):

# Only primary (4K) screen connected:

user@dom0:~ > xrandr
DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
3840x2160 60.00*+ 29.98 24.99 24.00

# Only secondary (2K) screen connected w/ scale 2x2:
# (note: No idea why the weird dimensions in mm, it's a big screen)

DP-2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 16mm x 9mm
1920x1080 60.00* 50.00 59.94 24.00 23.98

# Both, side by side, 4K primary, 2K secondary w/ scale 2x2:

DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
3840x2160 60.00*+ 29.98 24.99 24.00
...
DP-2 connected 3840x2160+3840+1080 (normal left inverted right x axis y axis) 16mm x 9mm
1920x1080 60.00* 50.00 59.94 24.00 23.98


What is the formula?


P.S.

FWIW, the secondary (2K) screen is connected via HDMI, however xrandr
always shows HDMI-1 and HDMI-2 as disconnected and "thinks" the
secondary screen is on DP-2 (while there is only one physical
DisplayPort). No idea if this is a bug or even related in any way.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, Apr 23, 2024 at 11:47:42AM -0000, qubist wrote:
> I see this (essential lines only):
>
> # Only primary (4K) screen connected:
>
> user@dom0:~ > xrandr
> DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
> 3840x2160 60.00*+ 29.98 24.99 24.00
>
> # Only secondary (2K) screen connected w/ scale 2x2:
> # (note: No idea why the weird dimensions in mm, it's a big screen)
>
> DP-2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 16mm x 9mm
> 1920x1080 60.00* 50.00 59.94 24.00 23.98
>
> # Both, side by side, 4K primary, 2K secondary w/ scale 2x2:
>
> DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
> 3840x2160 60.00*+ 29.98 24.99 24.00
> ...
> DP-2 connected 3840x2160+3840+1080 (normal left inverted right x axis y axis) 16mm x 9mm
> 1920x1080 60.00* 50.00 59.94 24.00 23.98
>
>
> What is the formula?

(3840 + 3840) * 2160 * 4 / 1024

And even easier, you should have a top line in xrandr output with
"current ... x ..." - that's the total size you are after.

> P.S.
>
> FWIW, the secondary (2K) screen is connected via HDMI, however xrandr
> always shows HDMI-1 and HDMI-2 as disconnected and "thinks" the
> secondary screen is on DP-2 (while there is only one physical
> DisplayPort). No idea if this is a bug or even related in any way.

It's probably related how those connectors are routed, maybe there is
some internal converter. But could be also mislabeled outputs in the
driver.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnqGkACgkQ24/THMrX
1ywg1gf9HJQJnkXOOXV/a7ttUlwm5lINhwZ7KSAqOqCX8rklWZqeVtal4ywDeld6
1G9jpL7u+yq3qZZgPYJPOoEK5VNfI5VTDFICN9xrelwJDZsZvLlrWc9qU4ddB+FW
yEYcCoEGsK9GGYrieFhBQaVOtmSlcvyWVnfhLaHdiL8JfL0GTx8DiF7ZxJbDM28h
7VAdPJPsivunchjKdww+d5gvpFEv3ISxOR790EL8nOCmIypBpJ7cEvmz7/qF9DY1
iyggJ340yYHVyeRu9aHG2/KfHT04GFcHqN2YQBj/f3xj9H07Qm77DVD4mM59d7h9
ktWLlI0YQmGgNMXPeEk7Wa416g6o+w==
=Icq+
-----END PGP SIGNATURE-----

[qubist]

Thank you.

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

At least Intel GPUs only support DisplayPort. Those that have HDMI
outputs have a protocol converter.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYoOz0ACgkQsoi1X/+c
IsEEhhAAsAvkG1j9TGZtH7Mi31Rf0nwuerC1A6c+gtMOgdylKzhsDiZK6xtu4VRS
oDlyHcn/cLAlHVyUYD0Al0Viq5TIgm7VbIKFDVe+wBkg0snCPSgBRr8Glk2lBxCL
2Q1fl118FefAZMdbf58D0GJXylEccxlwOZgbimOkMIFDGUetMSP1o6uGJe8/ElLh
JSpPAXkmTTE3gt67k7dU9dJ1DGkDBTmIz3O/MKg7xgUQ8ahqjQzrgcC48Hm8cSda
KK4+m/3Ht/BcMfr7X6HZGZnVu01vMgQUV9YE+pK8yqAcKWYYycMOSjZ9BbfZoNCc
5tDMgGoR+F674BiJyqkh9FbnP08xt0AI8nXN9cyjQ9cgvXtuK8gFRoj6qJgUFjYy
BEKda0ACwMTarQqomLj+HX2CMO/RWgt7hTqAx4RlY8Z30KbdvUApOLQOGkeiLo/+
CkFijoMSnMrKVbTPqLI9c1CIOX7lijQKzThEJYhVWxrvKnr/+1Go2HgW/JcSb/QO
58Qhg6D9NFPXO1HT+F/NtWpFb30s8GmTz4B5QhyY5UTfi9GmM2/w8AtDcG8v9B6s
+n3200wOxVwn+4Hjnc9CmVXpWgs/6aHuKq6sxTL/NIG1fw7imF51l6FrSog3+EsP
J6jdnYLapzDGFT3fOt0XBB51uHX4Dr/fTYPs73s/+fMNAEH2UFc=
=zg/0
-----END PGP SIGNATURE-----