/qubes-issues

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X11 in AppVMs defaults to 24hz refresh rate #3175

Open
Yethal opened this Issue Oct 14, 2017 · 21 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
  Release 3.2 updates
5 participants
@Yethal @marmarek @0spinboson @tonsimple @andrewdavidwong
@Yethal

Yethal commented Oct 14, 2017

Qubes OS version (e.g., R3.2):

3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

All of them (tested on fedora-23, fedora-25, debian-8)

Steps to reproduce the behavior:

  1. Launch terminal in templateVM
  2. Open /etc/X11/xorg-qubes.conf file
  3. Search for refresh rate

Expected behavior:

Refresh rate in the config file is equal to maximum supported refresh rate of the monitor (60hz)

Actual behavior:

Refresh rate is 24hz

General notes:

Changing the refresh rate manually to 60hz and restarting all vms caused the entire GUI to become more responsive. No idea why 24hz is used by default.

Related issues:
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 14, 2017

Member

That's interesting - there should be a range, not a single value. Also the thing that is set to "24" is color depth, not refresh rate. The later is calculated dynamically based on your screen resolution and available clock speed (see /usr/bin/qubes-run-xorg.sh).
Can you post here xorg-qubes.conf before and after the change?
Member

marmarek commented Oct 14, 2017

That's interesting - there should be a range, not a single value. Also the thing that is set to "24" is color depth, not refresh rate. The later is calculated dynamically based on your screen resolution and available clock speed (see /usr/bin/qubes-run-xorg.sh).
Can you post here xorg-qubes.conf before and after the change?
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 14, 2017

Before

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
	VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
	VertRefresh 23-24
	Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
	Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
		Modes "QB1920x2160" 
        EndSubSection
EndSection


Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

After

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
	VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
	VertRefresh 59-60
	Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
	Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
		Modes "QB1920x2160" 
        EndSubSection
EndSection


Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

The only value I changed was VertRefresh from 23-24 to 59-60

Yethal commented Oct 14, 2017 •
edited
Edited 1 time
  • @Yethal Yethal edited Oct 14, 2017 (most recent)

Before

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
	VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
	VertRefresh 23-24
	Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
	Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
		Modes "QB1920x2160" 
        EndSubSection
EndSection


Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

After

`Section "ServerLayout"   
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0  
        InputDevice "qubesdev"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "dummyqbs"
	VideoRam 65536
EndSection

Section "Monitor"
        Identifier "Monitor0"
        HorizSync 49-50
	VertRefresh 59-60
	Modeline "QB1920x2160" 96 1920 1921 1922 1923 2160 2161 2162 2163 
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
	Monitor    "Monitor0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24 
		Modes "QB1920x2160" 
        EndSubSection
EndSection


Section "InputDevice"
        Identifier  "qubesdev"
        Driver      "qubes"
EndSection`

The only value I changed was VertRefresh from 23-24 to 59-60

@andrewdavidwong andrewdavidwong added bug C: gui-virtualization labels Oct 14, 2017

@andrewdavidwong andrewdavidwong added this to the Release 3.2 updates milestone Oct 14, 2017

@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 15, 2017

Thanks for noticing -- definitely makes for a better UX :)

0spinboson commented Oct 15, 2017 •
edited
Edited 1 time
  • @0spinboson 0spinboson edited Oct 15, 2017 (most recent)

Thanks for noticing -- definitely makes for a better UX :)
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 15, 2017

Member

Ok, but you know that /etc/X11/xorg-qubes.conf is regenerated (from /etc/X11/xorg-qubes.conf.template) before each X server startup, right?
Member

marmarek commented Oct 15, 2017

Ok, but you know that /etc/X11/xorg-qubes.conf is regenerated (from /etc/X11/xorg-qubes.conf.template) before each X server startup, right?
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 15, 2017

I assumed as much. Which would imply that the %VREFR_START% and %VREFR_END% variables are improperly calculated by qubes-run-xorg.sh script. THe only thing that comes to my mind is that the script may take into account refresh rate at max resolution supported by the GPU (my GPU uses HDMI 1.4 so 24hz at 4K is max) instead of the refresh rate at the resolution actually used by the screen (which is 60hz). That would explain the 24hz refresh rate.

Yethal commented Oct 15, 2017 •
edited
Edited 1 time
  • @Yethal Yethal edited Oct 15, 2017 (most recent)

I assumed as much. Which would imply that the %VREFR_START% and %VREFR_END% variables are improperly calculated by qubes-run-xorg.sh script. THe only thing that comes to my mind is that the script may take into account refresh rate at max resolution supported by the GPU (my GPU uses HDMI 1.4 so 24hz at 4K is max) instead of the refresh rate at the resolution actually used by the screen (which is 60hz). That would explain the 24hz refresh rate.
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 15, 2017

Mine was also set at 23-24hz, while that GPU supports both 2160p30hz over hdmi, and 2160p60 over DP.

0spinboson commented Oct 15, 2017

Mine was also set at 23-24hz, while that GPU supports both 2160p30hz over hdmi, and 2160p60 over DP.
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 15, 2017

Does it support 2880p24 over dp?

Yethal commented Oct 15, 2017

Does it support 2880p24 over dp?
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 15, 2017

Not that card, no. (HD 7750)

0spinboson commented Oct 15, 2017

Not that card, no. (HD 7750)
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 15, 2017

Out of ideas then. I'll probably hardcode this value in the template until a better solution comes up.

Yethal commented Oct 15, 2017 •
edited
Edited 1 time
  • @Yethal Yethal edited Oct 15, 2017 (most recent)

Out of ideas then. I'll probably hardcode this value in the template until a better solution comes up.
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 18, 2017

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless.
Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?

0spinboson commented Oct 18, 2017

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless.
Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 18, 2017

Member

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless.
Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?

R4.0? If so, remember to add -t pv option to xl console. Then, you can check why GUI haven't started.
Member

marmarek commented Oct 18, 2017

So I'm also out of ideas, though at a much more elementary level, because I'm much more hopeless.
Why, when I set 'VREFR_START=59', does the template become unaccessible in any way (including xl console), even though it boots fine, after the first shutdown?

R4.0? If so, remember to add -t pv option to xl console. Then, you can check why GUI haven't started.
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 18, 2017

Okay. vrefresh out of range. / dummyqbs no valid modes found.
Xorg.0.txt

Edit: I've also tried 39-40Hz and 29-30Hz, both lead to the same issue. Could this have something to do with bandwidth limitations of some sort?

0spinboson commented Oct 18, 2017 •
edited
Edited 1 time
  • @0spinboson 0spinboson edited Oct 18, 2017 (most recent)

Okay. vrefresh out of range. / dummyqbs no valid modes found.
Xorg.0.txt

Edit: I've also tried 39-40Hz and 29-30Hz, both lead to the same issue. Could this have something to do with bandwidth limitations of some sort?
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 19, 2017

Member

Try setting some wide range and see what value will actually be used.
Member

marmarek commented Oct 19, 2017

Try setting some wide range and see what value will actually be used.
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 19, 2017

When I set the range to 0-60 and boot, ~/.local/share/xorg/Xorg.0.log tells me that it's running at 3840*2160 at 23.1Hz vertical refresh rate.

0spinboson commented Oct 19, 2017 •
edited
Edited 1 time
  • @0spinboson 0spinboson edited Oct 19, 2017 (most recent)

When I set the range to 0-60 and boot, ~/.local/share/xorg/Xorg.0.log tells me that it's running at 3840*2160 at 23.1Hz vertical refresh rate.
@tonsimple

This comment has been minimized.

Show comment
Hide comment
@tonsimple

tonsimple Oct 19, 2017

Okay, I've been poking around due to my own weird dual-headed refresh rate / vsync woes (#3194) , and even with both monitors set to refresh rate of 60 HZ (in the main Dom0 display settings menu) /etc/X11/xorg-qubes.conf inside VMs reads:

Section "Monitor"
Identifier "Monitor0"
HorizSync 49-50
VertRefresh 46-47
Modeline "QB3840x1080" 192 3840 3841 3842 3843 1080 1081 1082 1083
EndSection

Weird.
Shouldn't it allow for at least 60 HZ, given that minimum supported monitor refresh rate is 60 HZ?

tonsimple commented Oct 19, 2017

Okay, I've been poking around due to my own weird dual-headed refresh rate / vsync woes (#3194) , and even with both monitors set to refresh rate of 60 HZ (in the main Dom0 display settings menu) /etc/X11/xorg-qubes.conf inside VMs reads:

Section "Monitor"
Identifier "Monitor0"
HorizSync 49-50
VertRefresh 46-47
Modeline "QB3840x1080" 192 3840 3841 3842 3843 1080 1081 1082 1083
EndSection

Weird.
Shouldn't it allow for at least 60 HZ, given that minimum supported monitor refresh rate is 60 HZ?
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 20, 2017

That's certainly suggestive of a bandwidth issue of some sort -- looks like it's exactly double the refresh rate, at half the pixels.

0spinboson commented Oct 20, 2017

That's certainly suggestive of a bandwidth issue of some sort -- looks like it's exactly double the refresh rate, at half the pixels.
@tonsimple

This comment has been minimized.

Show comment
Hide comment
@tonsimple

tonsimple Oct 22, 2017

@0spinboson
yep, and trying to hardcode it in the /etc/X11/xorg-qubes.conf.template prevents the GUI from working (qubes 3.2), presumably to same "out of range" shtick.

The system tested on is running a monitor at 144 HZ (displayport) and another at 60 HZ via HDMI (it's a dual head config) so it should "handle" at least 60 HZ

Very weird.

tonsimple commented Oct 22, 2017

@0spinboson
yep, and trying to hardcode it in the /etc/X11/xorg-qubes.conf.template prevents the GUI from working (qubes 3.2), presumably to same "out of range" shtick.

The system tested on is running a monitor at 144 HZ (displayport) and another at 60 HZ via HDMI (it's a dual head config) so it should "handle" at least 60 HZ

Very weird.
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 22, 2017

Quote from qubes-run-xorg.sh script:
DUMMY_MAX_CLOCK=300 #hardcoded in dummy_drv

Is this the root cause here?

Yethal commented Oct 22, 2017

Quote from qubes-run-xorg.sh script:
DUMMY_MAX_CLOCK=300 #hardcoded in dummy_drv

Is this the root cause here?
@0spinboson

This comment has been minimized.

Show comment
Hide comment
@0spinboson

0spinboson Oct 23, 2017

for you, possibly. For me, it was that the preferred_hsync was set too low for my screen size / refresh rate. When I increase that to 134kHz, it supports 36.1Hz vertical, which is the upper limit allowed by that dummy_max_clock=300 setting. I don't know why that exists, though. Is it to protect the (graphics card) memory against flooding (when running multiple VMs?)?

0spinboson commented Oct 23, 2017

for you, possibly. For me, it was that the preferred_hsync was set too low for my screen size / refresh rate. When I increase that to 134kHz, it supports 36.1Hz vertical, which is the upper limit allowed by that dummy_max_clock=300 setting. I don't know why that exists, though. Is it to protect the (graphics card) memory against flooding (when running multiple VMs?)?
@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Oct 23, 2017

Member

I think this is technical limitation of dummy driver used in the VM, without any apparent reason (other than no one have implemented support for other values). Tracking from where it came, leads to initial commit of dummy driver back in 2003.

There is an upstream commit from 2015 making it configurable, I'll port it to our driver. For now, you can switch "dummyqbs" to "dummy" driver in xorg-qubes.conf.template to test it. You'll loose xrandr support, but you'll get configurable clock speed.
Member

marmarek commented Oct 23, 2017

I think this is technical limitation of dummy driver used in the VM, without any apparent reason (other than no one have implemented support for other values). Tracking from where it came, leads to initial commit of dummy driver back in 2003.

There is an upstream commit from 2015 making it configurable, I'll port it to our driver. For now, you can switch "dummyqbs" to "dummy" driver in xorg-qubes.conf.template to test it. You'll loose xrandr support, but you'll get configurable clock speed.
@Yethal

This comment has been minimized.

Show comment
Hide comment
@Yethal

Yethal Oct 27, 2017

Switching driver to dummy caused qubes-run-xorg to write VertRefresh 0-1 to xorg-qubes.conf

Yethal commented Oct 27, 2017

Switching driver to dummy caused qubes-run-xorg to write VertRefresh 0-1 to xorg-qubes.conf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment