Created attachment 92417 [details] Ouput of intel-virtual-output -b -a -f I just tried out the new intel-virtual-output tool as replacement for screenclone. Currently I'm using it on my Lenovo T510 with Optimus with a triple-head setup (VGA on the left, notebook in the center, VIRTUAL on the right). I start the setup with the following commands: kathib@kathib-notebook:~$ sudo optirun true kathib@kathib-notebook:~$ intel-virtual-output -b -a -f and then use "arandr" to set the screen resolutions and positions of the monitors. The problem is, that intel-virtual-output offers only "800x600" as screen resolution for VIRTUAL5. With this screen resolution the tripel-head setup works like a charm. But 800x600 is a really sick resolution so I tried to add a newmode to xrandr: kathib@kathib-notebook:~/xorg_debug$ sudo cvt 1280 1024 60 # 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync kathib@kathib-notebook:~/xorg_debug$ sudo xrandr --newmode "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync kathib@kathib-notebook:~/xorg_debug$ sudo xrandr --addmode VIRTUAL5 1280x1024_60.00 After this I changed the resolution of VIRTUAL5 with "arandr" to 1280x1024 which ends with no signal on the 3rd Monitor. You find the output of intel-virtual-output in the attachement (intel-virtual-output.log), debugging in tools/virtual.c was enabled. I then have to kill and restart intel-virtual-output to get the 3rd monitor working with 800x600 again. Any ideas why intel-virtual-output offers only 800x600 and why it does not work with the newmode of xrandr? Thanks!
Created attachment 92418 [details] xrandr after the 1280x1024 was added with "xrandr --addmode"
Created attachment 92419 [details] xrandr output before intel-virtual-output was started
Created attachment 92420 [details] xrandr output after intel-virtual-output was started, but before "xrandr --addmode"
Created attachment 92421 [details] Xorg.0.log
For starters there were quite a few bugs fixed in i-v-o in the releases since .904, so that would be a wise first step. However, i-v-o only reports the modes it finds on the remote screen, which is the likely source of difficulty. If you compile i-v-o manually, you can change diff --git a/tools/virtual.c b/tools/virtual.c index f0915a4..e94e5f5 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -65,7 +65,7 @@ #include <fcntl.h> #include <assert.h> -#if 0 +#if 1 #define DBG(x) printf x #else #define DBG(x) and see exactly what is going on.
Hey Chris, thanks for your fast response! I just compiled the .907 and tried again (debugging enabled) and get the same result. With screenclone I had also the problem that it just offers 800x600 but then I just added 1280x1024 with xrandr --addmode and it worked (Ubuntu 12.10). The output of i-v-o is the same as with .904 (failed to find suitable mode for DP-2), in the attachment you find the i-v-o debug output and the Xorg.0.log Any ideas how I can get this work or maybe a hint where I should search? Thanks for your effort!
Created attachment 92430 [details] intel-virtual-output -a -b -f (version .907)
Created attachment 92431 [details] Xorg.0.log (version .907)
Ok, looks like I miss the copy of the new mode from the VIRTUAL to the remote screen. To confirm you can do a "xrandr -d :0 --verbose, xrandr -d :8 --verbose" once everything is et.
Created attachment 92434 [details] output of xrandr -d :0 --verbose after init with i-v-o and xrandr --admode
Created attachment 92435 [details] output of xrandr -d :8 --verbose after init with i-v-o and xrandr --admode
Created attachment 92436 [details] [review] Clone from virtual to remote Perhaps not the most elegant solution, but I think this should do the trick
Hey, during make && make install I get the following compile errors: virtual.c: In function ‘context_update’: virtual.c:1130:9: error: invalid type argument of unary ‘*’ (have ‘XRRModeInfo’) m = *src->mode; ^ virtual.c:1132:58: error: ‘mode’ undeclared (first use in this function) "%s.%ld-%s", clone->src.name, (long)src->mode.id, mode->name); ^ virtual.c:1132:58: note: each undeclared identifier is reported only once for each function it appears in Have I missed something?
Created attachment 92438 [details] [review] Clone from virtual to remote And compile tested.
Created attachment 92439 [details] [review] Clone from virtual to remote Now really compile tested (with DBG enabled).
Compiled fine now, but still has the same problem. The output of xrandr -d :8 --verbose changed: 1280x1024 gets added to VIRTUAL5 (shouldn't it be added to DP-2?).
Created attachment 92440 [details] Output of xrandr -d :0 --verbose with patched i-v-o
Created attachment 92441 [details] Output of xrandr -d :8 --verbose with patched i-v-o
Created attachment 92442 [details] output of patched i-v-o
(In reply to comment #16) > Compiled fine now, but still has the same problem. > The output of xrandr -d :8 --verbose changed: > 1280x1024 gets added to VIRTUAL5 (shouldn't it be added to DP-2?). It should be on both. The DBG output shows that we create a mode and try to add it to DP-2, but subsequent use of that mode fails. Since it is not in the xrandr --verbose output that suggests the new mode was rejected.
Pushed a couple of minor patches to xf86-video-intel.git. Could you please recapture the DBG output with the latest i-v-o? I am hoping that this will at least report an XErrorEvent, as it seems to be acting correctly locally when I try to add modes.
The other thing to test is whether adding the mode via "xrandr -d :8" works. If the nvidia xserver doesn't accept the mode, then something is incompatible with the mode itself.
I just tested if xrandr -d :8 --addmode is working, but sadly it's not: kathib@kathib-notebook:~$ xrandr -d :8 --addmode DP-2 1024x768_60.00 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 18 (RRAddOutputMode) Serial number of failed request: 35 Current serial number in output stream: 36 Updated to xrandr 1.4.1, updated to nvidia 319.32 but no changes. I will try a fresh install in the afternoon and report if it's working then. Thanks for your help!
Finally finished fresh install of Lubuntu 13.10, but still the same problem. I will try tomorrow if I can find a fix.
Do you know why it is unable to find an EDID on the monitor? I presume you have had a higher resolution working on that monitor before?
(Hopefully) Having fixed the mode propagation from VIRTUAL to remote, I believe the remaining issue here is simply that the nvidia driver is pruning the modes you want to use. Please do reopen if it remains an issue with either a different monitor, or if you find a way to force nvidia to accept the modes. Thanks.
Finally I found a solution to solve the problem. As you expected the problem was the EDID of the monitor. Earlier NVIDIA drivers ignored the EDID and allowed own ModeLines in the xorg.conf or added via xrandr. But since 304 (I think, not sure) NVIDIA uses the EDID and reject every self created ModeLine. So I changed now a few lines in my /etc/bumblebee/xorg.conf.nvidia (Monitor Section) file: HorizSync 35-81 VertRefresh 35-76 Option "ModeValidation" "AllowNonEdidModes" Option "ModeValidation" "NoDFPNativeResolutionCheck” The HorizSync and VertRefresh was needed in my case because NVIDIA didn't allow 60Hz without these lines. The "ModeValidation" lines are telling the NVIDIA driver that it should accept self created ModeLines even if they are not appear in the EDID. I think it's possible to delete some lines in my xorg.conf.nvidia file and still get the same effect, but I haven't tested this. @Chris: Thanks for your help and the fast patch for xrandr ModeLines!
Created attachment 92671 [details] Working xorg.conf
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.