On 5/31/2016 6:54 PM, Sergey Bylokhov wrote:
On 31.05.16 18:49, Semyon Sadetsky wrote:
Can you please provide the output of the test from the CR before/after
the fix on your system?
it is not necessary. You can run the provided test before and the fix
and see that the list returned by getDisplayModes() is identical to
xrandr output for any screen number on linux. There is nothing else to
prove for this bug fix.
I cannot do that because I have no multi-monitor linux configuration.
And you mentioned that on you system the output is different from what
was added to the bug description. So provide it here or add as a
comment to JBS.
I don't have access to such hardware as well. I'm using linux VMs with
several virtual screens. Adding a new screen to a VM configuration can
be done in 10 seconds in most VMMs.
The result of the getDisplayModes() for 2-screen Ubuntu VM before the
fix looked like:
for device[0]: <current screen 0 mode>, <<the rest modes of
screen-0>>,<<all modes of screen-1>>
for device[1]: <current screen 1 mode>
--Semyon
============================
Compile and run it on a system with two displays. Here is output when
both display are switched on (note: only current resolutions are
listed):
Device: X11GraphicsDevice[screen=0]
Resolutions:
966x1280
Device: X11GraphicsDevice[screen=1]
Resolutions:
920x1280
============================
Then try to switch one of the displays (e.g., System
Settings->Displays etc.) off and run the test again. The test output
looks like:
Device: X11GraphicsDevice[screen=0]
Resolutions:
966x1280
960x1280
768x1024
600x800
480x640
============================
the list of supported modes changed and my question was: what
happens
when these modes will be passed to setDisplayMode() (of course
modes
and setDisplayMode should be from one GraphicsDevice object).
the same as before the fix.
---
Do you see any other concerns to the fix?
