Created attachment 93782 [details] bumblebees xorg.conf.nvidia Using bumblebee with a nvidia discrete card. intel-output-virtual -b works fine. As nvidia exports 2 displays: VGA-0 and HDMI-0, intel-output-virtual export both as VIRTUAL1 and VIRTUAL2. This is expected. As this is a optimus setup, VGA-0 does not really exits. So, in order to get it right this /etc/bumblebee/xorg.conf.nvidia is attached. This solves the problem: nvidia only have HDMI-0 (VGA-0 is gone). And it now corresponds to VIRTUAL1. The problem is that intel-virtual-output is exporting more modes than it exists. When plugin 1280x1024 display this is what xrandr sees in the nvidia xorg: $ DISPLAY=:8 xrandr Screen 0: minimum 8 x 8, current 1280 x 1024, maximum 16384 x 16384 HDMI-0 connected primary (normal left inverted right x axis y axis) 1280x1024 60.0 + 75.0 1024x768 75.0 60.0 800x600 75.0 60.3 640x480 75.0 59.9 And this is what intel-virtual-output exports: VIRTUAL1 connected (normal left inverted right x axis y axis) VIRTUAL1.658-1920x1080 60.0 VIRTUAL1.638-1280x1024 75.0 1280x1024 60.0 VIRTUAL1.659-1280x720 60.0 VIRTUAL1.639-1024x768 75.0 VIRTUAL1.660-1024x768 70.1 1024x768 60.0 VIRTUAL1.641-800x600 75.0 VIRTUAL1.661-800x600 72.2 800x600 60.3 VIRTUAL1.643-640x480 75.0 VIRTUAL1.662-640x480 72.8 640x480 59.9 note that this problem only exists when avoid the unexistent VGA-0 in nvidia xorg. When VGA-0 is present, intel-virutal-output exports the correct modes.
Created attachment 93783 [details] DISPLAY=:8 xrandr --verbose (nvidia)
Created attachment 93784 [details] xrandr --verbose (intel)
That's odd, i-v-o doesn't generate any modes, it just copies what is reported on the target. I wonder if invalid modes are also reported by RandR?
No, I cannot see a Mode->Status being exported across RandR, so... diff --git a/tools/virtual.c b/tools/virtual.c index 2539425..641ec95 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 capture the output of intel-virtual-output -a -b -f
Created attachment 93799 [details] debug information from intel-virtual-output -a -f -b
The extra modes (such as 1920x1080) are being reported by the remote HDMI-0, with a later output reconfiguration event in which the modes are pruned. After that, the modes on VIRTUAL1 reported by xrandr -d :0 should match those on HDMI-0 reported by xrandr -d :8 There is some oddity calculating the remote screen size when disabling VIRTUAL1, but that seems orthogonal to the problem at hand.
I noticed now that sometimes (after rebbot), it works fine and others (mostly) does not. Most of the time, I get the 1920x1080 mode as in the first post. When this happens, either no mode works or just the VIRTUAL1.6??-1280x1024. A few times, I got no 1920x1080 mode. When this happens, everything works fine (as it does when using an alternative xorg.conf with VIRTUAL2). I am going to try to get both logs on each case to see if it will help. -rsd
Created attachment 93858 [details] intel-virtual-output -a -f -d with debug that eventually works
ok, I found out something interesting. When intel-virtual-output is called, it has the 1920x1080 mode as reported. After a few calls to: xrandr --output VIRTUAL1 --left-of LVDS1 --mode 1280x1024 It eventually deleted the 1920 mode and displayed the correct mode. This happened right after the xrandr call. It still didnt work. In the next call it went back to add 1920. So, I put the xrandr --mode into a watch command and another xrandr to display the modes. Evetually it worked fine and the display showed up. So, it might be some kind of race condition that triggered it. The full log is attached.
The HDMI-0 output sends ~13 output changed notifications as it flips between having 1920x1080 and not. i-v-o is just responding to those events from the remote display :8 and querying what modes are reported by the HDMI-0 output. The modes are not being injected locally (via display :0), so I would focus on why HDMI-O keeps changing its mind.
I understand what you are saying. Wouldn't this changes reflect in "xrandr -d :8" ? It never showed up a 1920x1080 mode there. Another interesting thing. If I remove the HDMI connector, nvidia fallsback to a 800x600 only mode (the same happens when bumblebee starts with no heads). The VIRTUAL1 display shouldn't fall to 800x600 also?
(In reply to comment #11) > I understand what you are saying. > > Wouldn't this changes reflect in "xrandr -d :8" ? > It never showed up a 1920x1080 mode there. I think if you rewrote xrandr to monitor notifications, then you would also see it occur. It's certainly odd. The only thing I am confident about is that those modes are being generated on the remote :8 display and reported on HDMI-0. I have no idea why, and they also occur on the first read of modes. One thing that does occur, is that i-v-o uses the equivalent of xrandr --current (which does not force a reprobe of the outputs). > Another interesting thing. > If I remove the HDMI connector, nvidia fallsback to a 800x600 only mode (the > same happens when bumblebee starts with no heads). > The VIRTUAL1 display shouldn't fall to 800x600 also? No. Aiui, the fallback mode is just a mode set on no outputs, it is just the framebuffer size set when nothing is connected. (In -intel, we also provide a similar fallback.) Since there is nothing connected on any output, i-v-o reports nothing connected. (Checking xrandr -d :0/:8 should confirm that.)
If this is a problem with nvidia driver, I am fine with that :) This is what xrand reports when removing the cable: display :8 Screen 0: minimum 8 x 8, current 1280 x 1024, maximum 16384 x 16384 HDMI-0 connected primary (normal left inverted right x axis y axis) 800x600 60.3 + display :0 Screen 0: minimum 8 x 8, current 1280 x 1024, maximum 16384 x 16384 HDMI-0 connected primary (normal left inverted right x axis y axis) 800x600 60.3 + raul@nostromo:~$ xrandr -d :0; echo ;xrandr -d :8 Screen 0: minimum 320 x 200, current 3200 x 1080, maximum 32767 x 32767 LVDS1 connected primary 1920x1080+1280+0 (normal left inverted right x axis y axis) 344mm x 193mm 1920x1080 60.0*+ 59.9 1680x1050 60.0 59.9 1600x1024 60.2 1400x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1360x768 59.8 60.0 1152x864 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) VIRTUAL1 connected (normal left inverted right x axis y axis) VIRTUAL1.658-1920x1080 60.0 VIRTUAL1.638-1280x1024 75.0 1280x1024 60.0 VIRTUAL1.659-1280x720 60.0 VIRTUAL1.639-1024x768 75.0 VIRTUAL1.660-1024x768 70.1 1024x768 60.0 VIRTUAL1.641-800x600 75.0 VIRTUAL1.661-800x600 72.2 800x600 60.3 VIRTUAL1.643-640x480 75.0 VIRTUAL1.662-640x480 72.8 640x480 59.9 VIRTUAL2 disconnected (normal left inverted right x axis y axis)
One thing I did notice was that we discard a few output notifies as they have duplicate timestamps. Maybe that upset things? Try: diff --git a/tools/virtual.c b/tools/virtual.c index 2539425..238ec76 100644 --- a/tools/virtual.c +++ b/tools/virtual.c @@ -939,7 +939,7 @@ static int context_update(struct context *ctx) return 0; DBG(("%s timestamp %ld (last %ld)\n", DisplayString(dpy), res->timestamp, ctx->display->timestamp)); - if (res->timestamp == ctx->display->timestamp && + if (res->timestamp == ctx->display->timestamp && 0 && res->timestamp != res->configTimestamp) { /* mutter be damned */ XRRFreeScreenResources(res); return 0;
With this patch I couldn't reproduce the 1920 behaviour again. I will keep testing a little longer to be sure.
It seems I talked too soon. I found out more info about the behaviour. It might be related to this particular display: LG Electronics L1753T When using i-v-o with the display connected, but OFF, everything works fine as expected. There is no 1920 mode in VIRTUAL1. "xrandr --output VIRTUAL1 --mode 1280x1024" works at first call. When using i-v-o with the display ON, the 1920 is present. "xrandr --output VIRTUAL1 --mode 1280x1024" will only work if called twice and fast (maybe ~1s between calls). In this test I called 7 paused times and the last two fast enough to test this behaviour. When I comment the xorg.conf.nvidia option: Option "IgnoreDisplayDevices" "CRT,TV" The display goes to VIRTUAL2 and it will always work independent of wether the monitor is ON or OFF. I am going to attach the logs for future referende and indexing.
Created attachment 93941 [details] log of i-v-o when ran with the monitor ON log of i-v-o when ran with the monitor on. xrandr --output VIRTUAL1 --mode 1280x1024 will always work.
I've also poked around a bit in virtual.c, you might as well if that improves the experience.
Created attachment 93942 [details] log of i-v-o when ran with the monitor OFF log of i-v-o when ran with the monitor OFF. xrandr --output VIRTUAL1 --mode 1280x1024 will only work when called fast enough. In this logs the 1st to 6th calls are paused and din't work. Only the timing between the 6th and 7rh was fast enought to wotk.
Created attachment 93943 [details] log of i-v-o as VIRTUAL2 In this log the xorg.conf.nvidia ha the option commented: # Option "IgnoreDisplayDevices" "CRT,TV" This causes the VGA-0 to show as VIRTUAL1 and HDMI-0 goes to VIRTUAL2. There was a brief moment that HDMI-0 showed a 1920x1080 resolution and it went away right after. VIRTUAL2 reflect HDMI-0 correctly and xrandr --output VIRTUAL2 --mode 1280x1024 always works.
Created attachment 93944 [details] Xorg.8.log for monitor ON
Created attachment 93945 [details] Xorg.8.log for monitor OFF
Created attachment 93946 [details] Xorg.8.log when using VIRTUAL2
(In reply to comment #18) > I've also poked around a bit in virtual.c, you might as well if that > improves the experience. It solves all issues. Perfectly! When starting with no display connected (800x600) and connecting it later VIRTUAL1 changes accordlying. The same goes when unplugging. The situation when the monitor is connected, but OFF (1920 issue) is possible to see the VIRTUAL1 going to 1920 and right after reseting to 1280. Great job, Chris!
Ok, sounds like we have the behaviour we need. Please do let me know if you spot anything else that can be fixed or improved.
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.