On Tue, Nov 25, 2014 at 3:11 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > At Fri, 14 Nov 2014 20:39:15 +0100, > Takashi Iwai wrote: >> >> At Fri, 14 Nov 2014 12:29:17 -0500, >> Alex Deucher wrote: >> > >> > On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> > > At Fri, 14 Nov 2014 10:40:08 -0500, >> > > Alex Deucher wrote: >> > >> >> > >> On Fri, Nov 14, 2014 at 5:09 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: >> > >> > At Fri, 14 Nov 2014 19:33:00 +1000, >> > >> > Dave Airlie wrote: >> > >> >> >> > >> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@xxxxxxx> wrote: >> > >> >> > Hi Alex, >> > >> >> > >> > >> >> > we've got a few bug reports about the behavior of radeon driver on >> > >> >> > machines with Intel+AMD "switchable graphics" (no Muxless). So far, >> > >> >> > it seems that the sane only way to make the machine working is to get >> > >> >> > back to the old vgaswitcheroo behavior via radeon.runpm=0. Without >> > >> >> > it, radeon GPU gives a spurious output as connected, eventually >> > >> >> > crashes GNOME. (Also, from the nature of the switchable graphics, >> > >> >> > vgaswitcheroo looks more intuitive to me.) >> > >> >> >> > >> >> vgaswitcheroo only matters if there is a MUX, the point of it is to drive >> > >> >> the MUX. >> > >> >> >> > >> >> dynamic poweroff makes more sense, switcheroo on/off switch was >> > >> >> just a hack. >> > >> > >> > >> > Well, I find the current form fairly unintuitive, at least, for the >> > >> > switchable (not optimus) graphics. >> > >> > With dynamic PM, the card is activated on demand. So you may enable >> > >> > outputs of both cards at any time, right? >> > >> > >> > >> > Currently, all outputs from both cards are exposed in Xrandr, >> > >> > e.g. LVDS1 DP1, HDMI1, VGA1, LVDS-1-1, HDMI-1-2, DisplayPort-1-2, and >> > >> > VGA-1-1. How can user-space know which one should be activated and >> > >> > which not, when you can use effectively only a single card? >> > >> > >> > >> >> > How are such machines supposed to work with the recent system? Is PX >> > >> >> > wrongly detected on them, or something else missing? >> > >> >> >> > >> >> It sounds like the connector is wrongly detected and that should be what >> > >> >> is fixed. >> > >> > >> > >> > Yeah, that's a problem indeed. In the bug report, both LVDS1 and >> > >> > LVDS-1-1 are reported to be connected at the same time while the >> > >> > latter doesn't get any real size and position. We didn't trace >> > >> > whether this is the culprit of crash of GNOME, but at least, it looks >> > >> > fairly weird. >> > >> > >> > >> > I forgot to give the original bug report: >> > >> > http://bugzilla.opensuse.org/show_bug.cgi?id=904417 >> > >> > >> > >> > and the xrandr output is found at >> > >> > http://bugzilla.opensuse.org/show_bug.cgi?id=904417#c18 >> > >> >> > >> It's not clear to me from the bug report what that problem is. What >> > >> exactly is gnome complaining about? >> > > >> > > It simply crashes by some reason, showing a sad face and complaining >> > > something is wrong. (And it's GNOME, not easy to get a proper log >> > > like kernel :) >> > > Some users complained about blank output, but I'm not sure whether >> > > this is the same cause. >> > > >> > >> The X logs look fine. >> > > >> > > I couldn't see any errors there, too. So it's just a wild guess, so >> > > far... >> > > >> > >> From the >> > >> xrandr output, LVDS1 (connected to the intel) is connected and active. >> > >> LVDS-1-1 (connected to the radeon) is connected but not active. That >> > >> should be a perfectly reasonable configuration. If LVDS-1-1 is not >> > >> active, the radeon kernel driver will power down the GPU until the >> > >> user either activates the panel or uses the dGPU as an offscreen >> > >> renderer. >> > > >> > > Note that the xrandr output was taken on icewm or else. So, right, >> > > this might be non-issue. But, I guess now that the issue will happen >> > > when LVDS-1-1 is activated at the same time with LVDS. GNOME tries to >> > > activate all connected outputs at the same time as default. >> > > >> > >> There are plenty of cases when you may have a secondary GPU with >> > >> attached displays that are not active. If gnome barfs on this it >> > >> should be fixed in gnome. >> > > >> > > Yeah, GNOME has definitely a problem about it. At least, it shouldn't >> > > crash badly. >> > > >> > > But, it's still not clear to me how the activation of the radeon GPU >> > > is supposed to work in switchable graphics case. For PX or Otpimus, >> > > it's clear. But for switchable case, there is no offload rendering. >> > > If you enable the output on radeon GPU while Intel output is being >> > > used, what's going on? Shouldn't they be handled exclusively, as user >> > > expected? >> > >> > You can still do offload rendering with a switchable system, it just >> > happens to also have a mux which you can use or not use. That's how >> > it works today. >> > >> > If you enable the outputs on both gpus, they will both power up the >> > display hw on the GPU, but only the signals from the gpu selected by >> > the mux will actually make it to the display. >> >> Yes, that's the problem. The desktop expects that the connected >> output can be shown properly at the desired place and size. (GNOME >> will try to place all connected outputs from left to right as default, >> IIRC.) >> But, in this case, it's not informed that some connected outputs are >> actually not visible. >> >> > Does the attached hack help? It basically attempts to determine >> > whether the mux is switched to the radeon or not and report >> > disconnected or not for the local displays. To handle handle it >> > properly, vgaswitcheroo would need to track the signal and ddc/hpd >> > muxes and propagate them to the drivers. >> >> Thanks! I'll provide a test KMP including this patch to reporters to >> give a try. > > Got a positive feedback, the patch works. Thanks! Great! Just sent it to Dave for -fixes. Alex > > > Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
