Re: [PATCH 0/2] x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

["Bruno Prémont" <bonbons@linux-vserver.org>]

On Fri, 22 August 2014 Andreas Noever <andreas.noever@gmail.com> wrote:
> > For Andreas's system the discrete nvidia GPU has no I/O enabled
> > according to PCI_COMMAND flags while the integrated intel one does have
> > them (that's why the Intel GPU is chosen).
> >
> > Unfortunately I don't know what makes his system choke at boot time as
> > he did not provide logs for the failing case.
> Attached dmesg for the failing case (obtained via ssh).
>
> Without blacklisting a small horizontal bar of vertical green bars
> appears (no x, no console).

It's good to know that it's just the graphics (console / X) that are not
displaying properly.

> If nouveau is blacklisted then I get a console, but X will not start
> (No devices found).

The console you get is EFIFB (on the nvidia GPU to which display is routed).

Here the reason why X does not start is probably that i915 did not find
its VBIOS tables nor any connected monitor and thus X thinks "no active
output => I don't start".
Though your X would be able to start if it did not find xf86-video-intel
(intel_drv.so) and/or did find/had an explicit reference to xf86-video-fbdev
(fbdev_drv.so).

If under OSX you told your system to start on intel GPU (I think there
is an option in this direction) you system would probably boot fine as the
initial choice by vgaarb would match gmux/switcheroo settings.

> If i915 is blacklisted then I do not get a console. The screen just
> freezes after a few boot messages.

This is more interesting.

Initially you had efifb printing kernel logs until nouveau gets loaded
by udev and replaces efifb. From there on possibly applegmux does not
take over correctly (it may need both i915 and nouveau active to properly
route framebuffer to panel or connector).

Though your X should be telling the same thing as for nouveau blacklisted
as nvidia GPU is not the one having boot_vga set...

If not it may be worth finding out in what state your system exactly is
with regards to graphics.

> What is vga_default_device() used for? Is it supposed to hold the
> device that is controlling the (boot) screen? Why can't we just read
> the configuration from vga_switcheroo/gmux?

For systems not using vga_switcheroo:
  vga_default_device represents the PCI GPU that was used to boot (and
  normally handles legacy VGA I/O).
  It's never changed after boot (except eventually when a GPU gets
  hotplugged)

For systems with vga_switcheroo
  vga_default_device represents the active GPU (the one that would be
  handling legacy VGA I/O if used - and the one controlling the output
  connectors)
  vga_switcheroo is actively changing vga_default_device.


gmux is a driver for vga_switcheroo to perform the low-level platform
operations allowing switching (outputs) from one GPU to the other.


So a guess on my side would be that with both i915 and nouveau loaded
you may be able to get your display working if you can tell X to
switch GPU twice (and thus end up with matching vga_default_device
and device selected by gmux) - though I don't know how one asks for this
switch to happen.

> > If there is no better way to detect the proper legacy VGA device the
> > only remaining option would be to perform the screen_info testing in
> > vga_arb_device_init() enclosed in arch #ifdef...

I will propose a patch in this direction later this weekend.

Bruno