Screen geometry for VMs
69 views
Skip to first unread message
Alex
Sep 27, 2016, 2:47:36 PM9/27/16
to qubes-users
Hi everybody,
I'm back with a brand-new workstation setup to try Qubes on. I bought a
Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
using Qubes R3.2 fully updated as of now, with XFCE.
Long story short, dom0 is able to use all six monitors in the
configuration I set up (two rows, three monitors each row) - it was not
that easy, had to manually fix the numbers in
~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml because the
graphical display configuration tool kept being a couple of pixels off,
and it was very frustrating.
Anyway my problem is with AppVMs. Once they are started, it seems like
their virtual screen is "clipped" with respect to that of dom0. Namely,
when I try to perform any mouse action on windows in the first two
monitors (top-left and top-middle), nothing happens in the appVM windows
contents (i.e. they do not react to any event, hover nor click).
I've had this problem before, and that was when the screen geometry
changed after the VMs were started - I used to have a Qubes laptop, and
changing the display placement in dom0 after VMs were started did result
in clipped "virtual screens".
My question is: does Qubes R3.2 support notifying screen change event to
AppVM? would that be a security problem? Is there a way for me to "tell"
specific AppVMs that dom0's screen geometry has changed, maybe telling
the new situation too?
Simpler; since my situation is fixed (i.e. I won't be adding nor moving
any monitors around), can I fix this once and for all by copying the
same geometry I put in my user's XFCE configuration into some global
XFCE file? I noticed that VMs are started with the login-screen display
geometry, but that is changed to the actual displays.xml settings once
the user logs in, so maybe setting that as the default geometry could
change the virtual screen seen by AppVMs... Could that work?
TIA,
--
Alex
I'm back with a brand-new workstation setup to try Qubes on. I bought a
Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
using Qubes R3.2 fully updated as of now, with XFCE.
Long story short, dom0 is able to use all six monitors in the
configuration I set up (two rows, three monitors each row) - it was not
that easy, had to manually fix the numbers in
~/.config/xfce4/xfconf/xfce-perchannel-xml/displays.xml because the
graphical display configuration tool kept being a couple of pixels off,
and it was very frustrating.
Anyway my problem is with AppVMs. Once they are started, it seems like
their virtual screen is "clipped" with respect to that of dom0. Namely,
when I try to perform any mouse action on windows in the first two
monitors (top-left and top-middle), nothing happens in the appVM windows
contents (i.e. they do not react to any event, hover nor click).
I've had this problem before, and that was when the screen geometry
changed after the VMs were started - I used to have a Qubes laptop, and
changing the display placement in dom0 after VMs were started did result
in clipped "virtual screens".
My question is: does Qubes R3.2 support notifying screen change event to
AppVM? would that be a security problem? Is there a way for me to "tell"
specific AppVMs that dom0's screen geometry has changed, maybe telling
the new situation too?
Simpler; since my situation is fixed (i.e. I won't be adding nor moving
any monitors around), can I fix this once and for all by copying the
same geometry I put in my user's XFCE configuration into some global
XFCE file? I noticed that VMs are started with the login-screen display
geometry, but that is changed to the actual displays.xml settings once
the user logs in, so maybe setting that as the default geometry could
change the virtual screen seen by AppVMs... Could that work?
TIA,
--
Alex
johny...@sigaint.org
Sep 27, 2016, 3:13:57 PM9/27/16
to qubes-users
> I'm back with a brand-new workstation setup to try Qubes on. I bought a
> Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
> using Qubes R3.2 fully updated as of now, with XFCE.
Six monitors??? Wow!
> Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
> using Qubes R3.2 fully updated as of now, with XFCE.
Can I come over and hang out at your place?
JJ
Marek Marczykowski-Górecki
Sep 27, 2016, 3:19:23 PM9/27/16
to Alex, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Sep 27, 2016 at 08:47:27PM +0200, Alex wrote:
> Hi everybody,
> I'm back with a brand-new workstation setup to try Qubes on. I bought a
> Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
> using Qubes R3.2 fully updated as of now, with XFCE.
Wow...
The problem is that gui-agent have hardcoded maximum of 4 outputs[1].
The number is totally arbitrary, can be changed to anything. Any ideas
for better value? Apparently 4 isn't large enough...
Another possible problem: what is your total resolution (across all the
outputs)? The max supported is 32767x32767.
[1]
https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/xf86-video-dummy/src/dummy.h#L16
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJX6sY0AAoJENuP0xzK19csapIH+wTveF24xDCycE8nFMeM9Xyv
L4XS/rVPNYsBT3LzNBXkAXVNDFqFOWSK6/biRayQa6G3FpkxbXtxspvNPDXMLgBB
x381ZPjGF3MumL+kUIj9ouElFXmkedqVpifi6xe91DcwPzx79hCetmnIDgYfhnJS
q5hFCvjVKGaLnYez2TicvgjLXYR1wHKu65MhCPTppWDWhAhqQe57T5vFiwkKe/N9
aAWkvxcW8v5+GWFLGffgnnduxEAbe7HKgLlKfoT+o3LgYGYwNB5OnNvK7RwAfuIZ
eTwyIMIJbGiGP2AsOQH7DWsU9cQaK9LG4LvimuXE/TipUPWPDObfv8vSTZkmwXc=
=OHC9
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Sep 27, 2016 at 08:47:27PM +0200, Alex wrote:
> Hi everybody,
> I'm back with a brand-new workstation setup to try Qubes on. I bought a
> Matrox C680 and hooked up six monitors to its DisplayPort outputs. I'm
> using Qubes R3.2 fully updated as of now, with XFCE.
The problem is that gui-agent have hardcoded maximum of 4 outputs[1].
The number is totally arbitrary, can be changed to anything. Any ideas
for better value? Apparently 4 isn't large enough...
Another possible problem: what is your total resolution (across all the
outputs)? The max supported is 32767x32767.
[1]
https://github.com/QubesOS/qubes-gui-agent-linux/blob/master/xf86-video-dummy/src/dummy.h#L16
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJX6sY0AAoJENuP0xzK19csapIH+wTveF24xDCycE8nFMeM9Xyv
L4XS/rVPNYsBT3LzNBXkAXVNDFqFOWSK6/biRayQa6G3FpkxbXtxspvNPDXMLgBB
x381ZPjGF3MumL+kUIj9ouElFXmkedqVpifi6xe91DcwPzx79hCetmnIDgYfhnJS
q5hFCvjVKGaLnYez2TicvgjLXYR1wHKu65MhCPTppWDWhAhqQe57T5vFiwkKe/N9
aAWkvxcW8v5+GWFLGffgnnduxEAbe7HKgLlKfoT+o3LgYGYwNB5OnNvK7RwAfuIZ
eTwyIMIJbGiGP2AsOQH7DWsU9cQaK9LG4LvimuXE/TipUPWPDObfv8vSTZkmwXc=
=OHC9
-----END PGP SIGNATURE-----
Alex
Sep 27, 2016, 3:40:23 PM9/27/16
to qubes...@googlegroups.com
On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote:
> Wow... The problem is that gui-agent have hardcoded maximum of 4
> outputs[1]. The number is totally arbitrary, can be changed to
> anything. Any ideas for better value? Apparently 4 isn't large
> enough...
That's good to know, and that explains the weird clipping - the usable
> Wow... The problem is that gui-agent have hardcoded maximum of 4
> outputs[1]. The number is totally arbitrary, can be changed to
> anything. Any ideas for better value? Apparently 4 isn't large
> enough...
monitors are actually the ones connected to port 0-3 (i.e. the FIRST
four monitors).
> Another possible problem: what is your total resolution (across all
> the outputs)? The max supported is 32767x32767.
hi-res (i.e. 4K) monitors :)
So should I be able to recompile gui-agent with a maximum of 6 monitors,
that should work, you say? But I'd really love to stick with the
automatic upgrades :/ This workstation has actually been build for work,
so I'd avoid too much software customization...
Would that be ok to use a maximum of 16, just to say another number? It
seems that the increased memory usage would still be negligible.
Btw thank you Marek for your speedy response.
Since my setup seems to have sparked some curiosity, here's a just-shot
badly lit photo of it: http://tinypic.com/r/etd2kn/9 yes, that Ikea lamp
is my version of ambi-light and I do not like to have a desk. The stand
is a large-panel-TV stand from Amazon, converted to a multi-monitor
stand with a couple horizontal iron bars, and my keyboard is on a
stand-alone cart (was from an IKEA office chair), and the mouse is that
blue 3d-printed thing on the top-right corner of the keyboard. It's an
IBM trackpoint, with 3d-printed holder and cap, and it's incredibly
useful in avoiding repetitive strain injuries coming from standard mice.
The keyboard is a Model M from Unicomp, but they don't make any with a
trackpoint where I like it most - on the top right.
--
Alex
Marek Marczykowski-Górecki
Sep 27, 2016, 4:26:06 PM9/27/16
to Alex, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Tue, Sep 27, 2016 at 09:40:15PM +0200, Alex wrote:
> On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote:
> > Wow... The problem is that gui-agent have hardcoded maximum of 4
> > outputs[1]. The number is totally arbitrary, can be changed to
> > anything. Any ideas for better value? Apparently 4 isn't large
> > enough...
> That's good to know, and that explains the weird clipping - the usable
> monitors are actually the ones connected to port 0-3 (i.e. the FIRST
> four monitors).
>
> > Another possible problem: what is your total resolution (across all
> > the outputs)? The max supported is 32767x32767.
> That's not a problem - my actual resolution is 3840x2048. I don't like
> hi-res (i.e. 4K) monitors :)
>
> So should I be able to recompile gui-agent with a maximum of 6 monitors,
> that should work, you say? But I'd really love to stick with the
> automatic upgrades :/ This workstation has actually been build for work,
> so I'd avoid too much software customization...
>
> Would that be ok to use a maximum of 16, just to say another number? It
> seems that the increased memory usage would still be negligible.
Yes, I think that would be ok.
> On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote:
> > Wow... The problem is that gui-agent have hardcoded maximum of 4
> > outputs[1]. The number is totally arbitrary, can be changed to
> > anything. Any ideas for better value? Apparently 4 isn't large
> > enough...
> That's good to know, and that explains the weird clipping - the usable
> monitors are actually the ones connected to port 0-3 (i.e. the FIRST
> four monitors).
>
> > Another possible problem: what is your total resolution (across all
> > the outputs)? The max supported is 32767x32767.
> That's not a problem - my actual resolution is 3840x2048. I don't like
> hi-res (i.e. 4K) monitors :)
>
> So should I be able to recompile gui-agent with a maximum of 6 monitors,
> that should work, you say? But I'd really love to stick with the
> automatic upgrades :/ This workstation has actually been build for work,
> so I'd avoid too much software customization...
>
> Would that be ok to use a maximum of 16, just to say another number? It
> seems that the increased memory usage would still be negligible.
Tracking it here:
https://github.com/QubesOS/qubes-issues/issues/2338
> Btw thank you Marek for your speedy response.
>
> Since my setup seems to have sparked some curiosity, here's a just-shot
> badly lit photo of it: http://tinypic.com/r/etd2kn/9 yes, that Ikea lamp
> is my version of ambi-light and I do not like to have a desk. The stand
> is a large-panel-TV stand from Amazon, converted to a multi-monitor
> stand with a couple horizontal iron bars, and my keyboard is on a
> stand-alone cart (was from an IKEA office chair), and the mouse is that
> blue 3d-printed thing on the top-right corner of the keyboard. It's an
> IBM trackpoint, with 3d-printed holder and cap, and it's incredibly
> useful in avoiding repetitive strain injuries coming from standard mice.
> The keyboard is a Model M from Unicomp, but they don't make any with a
> trackpoint where I like it most - on the top right.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
20KpD2g0XN19VOqtCKifCTRWI12CFJUAwQaSEAQQXDhiqm2tNo/TlHH4Vqrjdgsx
67XaydHLqCdeIXiOktGw8V1A+IfcfM2pSD/YAqGTjBwuR7ricXp7Mr5QC1jrAQV8
9giBoWEwGyUl348YqQyacSYaiv58S9e4iuDE94OtkgipRW1SIkSpC20l/taozVV6
Xjq44gp1s5SDFzKCng84An7RNM+NeI360lzkzDWxdkW6u2lq7oHwzYDEBCu3QJhB
vOCvN8ydr8RXJ9+KfX0iIN8sC1KM6Q583Bmmg4qc1Kp69aiyGQZjVQcCgoE69l8=
=Vegr
-----END PGP SIGNATURE-----
Alex
Oct 4, 2016, 12:57:30 PM10/4/16
to qubes...@googlegroups.com
I've seen that the ticket has been closed, and I tried to update
qubes-gui-vm in a template from the testing repo.
Guess what, now the windows put in the last 2 monitors do work =)
I'll let you know if anything bad happens, but as of now nothing seems
off. Thank you Marek again for your quick fix!
--
Alex
On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote:
qubes-gui-vm in a template from the testing repo.
Guess what, now the windows put in the last 2 monitors do work =)
I'll let you know if anything bad happens, but as of now nothing seems
off. Thank you Marek again for your quick fix!
--
Alex
On 09/27/2016 09:19 PM, Marek Marczykowski-Górecki wrote:
Alex
Oct 4, 2016, 4:29:25 PM10/4/16
to qubes...@googlegroups.com
On 10/04/2016 06:57 PM, Alex wrote:
> I've seen that the ticket has been closed, and I tried to update
> qubes-gui-vm in a template from the testing repo.
>
> Guess what, now the windows put in the last 2 monitors do work =)
>
> I'll let you know if anything bad happens, but as of now nothing seems
> off. Thank you Marek again for your quick fix!
>
Another update: a problem I originally believed was due to
> I've seen that the ticket has been closed, and I tried to update
> qubes-gui-vm in a template from the testing repo.
>
> Guess what, now the windows put in the last 2 monitors do work =)
>
> I'll let you know if anything bad happens, but as of now nothing seems
> off. Thank you Marek again for your quick fix!
>
broken/missing drivers in dom0 has solved itself with the new
qubes-gui-vm package (from r3.2-current-testing)!
Since I started using the 6 monitor setup, video playback in
youtube@firefox was extremely slow, and starting to buffer for ~1 minute
after just 3 seconds of playback. When using the motherboard-integrated
Intel video adapter with just 1 monitor, everything was fine, so I
believed there were some problems with dom0's radeon drivers.
Turns out that it may have had something to do with the geometry; now
that the AppVMs are able to see the full rectangle of the 6 monitors
(and not the L-shaped piece of tetris that resulted from the previous
limit of 4 monitors), video playback is as smooth as ever. Inside
firefox, at the diagnostic page "about:support", I still see that
hardware acceleration is disabled, but the difference in video playback
is terrific.
Think of unexpected consequences of a humble arbitrary limit...
--
Alex
Wojtek Porczyk
Oct 4, 2016, 4:51:57 PM10/4/16
to Alex, qubes...@googlegroups.com
On Tue, Oct 04, 2016 at 10:29:16PM +0200, Alex wrote:
> starting to buffer for ~1 minute after just 3 seconds of playback.
This seems like poor Tor circuit. Isn't this firefox in a VM connected through
> starting to buffer for ~1 minute after just 3 seconds of playback.
sys-whonix?
--
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
Alex
Oct 5, 2016, 2:20:15 AM10/5/16
to qubes...@googlegroups.com
On 10/04/2016 10:51 PM, Wojtek Porczyk wrote:
> On Tue, Oct 04, 2016 at 10:29:16PM +0200, Alex wrote:
>> starting to buffer for ~1 minute after just 3 seconds of playback.
>
> This seems like poor Tor circuit. Isn't this firefox in a VM
> connected through sys-whonix?
No, these machines are not routed through a TOR circuit. And I have a
> On Tue, Oct 04, 2016 at 10:29:16PM +0200, Alex wrote:
>> starting to buffer for ~1 minute after just 3 seconds of playback.
>
> This seems like poor Tor circuit. Isn't this firefox in a VM
> connected through sys-whonix?
100Mbit vdsl link to the Internet, which did not experience any speed
issue: other computers in the network, not running Qubes but Fedora 24,
were playing youtube videos just fine.
The problem solved itself after forcing an update of qubes-gui-vm (and
only this package) from the stable repo to the version in
current-testing, which solved the multi-monitor problem (I have 6
monitors, and qubes-gui-vm only managed up to 4). I guess it may have
something to do with screen geometry.
--
Alex
Achim Patzner
Oct 5, 2016, 7:31:58 AM10/5/16
to qubes...@googlegroups.com
Am 05.10.2016 um 08:20 schrieb Alex:
> The problem solved itself after forcing an update of qubes-gui-vm (and
> only this package) from the stable repo to the version in
> current-testing, which solved the multi-monitor problem (I have 6
> monitors, and qubes-gui-vm only managed up to 4). I guess it may have
> something to do with screen geometry.
Actually for the first time in ages the screen dimension is not 0 x 0 mm
> The problem solved itself after forcing an update of qubes-gui-vm (and
> only this package) from the stable repo to the version in
> current-testing, which solved the multi-monitor problem (I have 6
> monitors, and qubes-gui-vm only managed up to 4). I guess it may have
> something to do with screen geometry.
in xrandr so the dimensions are coming through. There always was a
metric shitton of utilities and libraries dividing by these values
without testing them first and I guess somewhere along the way nearly
every program picked up something that would do it. Sometimes
repeatedly. Divisions by zero are expensive.
Achim
Reply all
Reply to author
Forward
0 new messages