Fix (partially) setting resolution on sys-gui #253
Conversation
When running sys-gui, there are two X servers. The one on :1 is actually connected to dom0, adjust resolution/monitor layout there. The internal one likely need adjustment too, but leave that for later This hopefully will be enough to unbreak sys-gui with QubesOS#251
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025112313-4.3&flavor=pull-requests Test run included the following:
Upload failures
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2025111104-4.3&flavor=update
Failed tests25 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/158999#dependencies 17 fixed
Unstable testsDetailsPerformance TestsPerformance degradation:21 performance degradations
Remaining performance tests:85 tests
|
This allows Xephyr to automatically resize on resolution change. On the other hand, this breaks multi-monitor support in sys-gui even more... It used to be all monitors combined into a single screen in sys-gui (with no metadata about the split), and no way to dynamically change the layout (including dynamically connecting/disconnecting some). Now the first one will work, including dynamic resolution change, but all the others will be ignored (remain black). This dynamic resolution change makes it work again with late gui-daemon connection, see QubesOS#251 Since sys-gui is mostly fallback option in case sys-gui-gpu cannot be used for some reason, it can have limitations.
marmarek
force-pushed
the
sys-gui-monitor-layout
branch
from
c3d45a4 to
caf05d1
Compare
2 participants
When running sys-gui, there are two X servers. The one on :1 is actually
connected to dom0, adjust resolution/monitor layout there. The internal
one likely need adjustment too, but leave that for later
This hopefully will be enough to unbreak sys-gui with
#251