make fbdev/fbcon switchable per driver?

[Daniel Vetter]

On Mon, Jan 30, 2017 at 10:45:22AM -0700, Alex Williamson wrote:
> On Mon, 30 Jan 2017 09:15:50 +0100
> Gerd Hoffmann <kraxel at redhat.com> wrote:
> 
> >   Hi,
> > 
> > > The vgaarb code has a concept of a vga_default_device(), it's rather
> > > PCI-centric, but maybe better than nothing.  This is typically the
> > > first VGA class code device found with I/O and MMIO enabled.  If fbcon
> > > defaulted to running on the vga_default_device(), a user could select
> > > which to use by re-ordering the VM hardware.  
> > 
> > The qemu drivers don't register as vgaarb clients though.  Which easily
> > explains why igd always wins the primary selection, no matter how you
> > order your hardware.
> > 
> > So, should they register?  The drivers don't need access to the vga
> > registers[1][2].
> 
> The VGA arbiter sets up a notifier on the PCI bus and will add any VGA
> class code devices it finds.  So even if the driver doesn't
> participate, it'll still be tracked and might be marked as primary.  If
> a graphics driver claims a VGA device that does not depend on VGA
> region access then the driver should configure the device not to claim
> VGA accesses (maybe only relevant for integrated graphics - i915 gets
> this wrong), and register with the arbiter to opt-out of VGA
> arbitration.  Picking a "primary" can be done w/o any of that latter if
> we agree on the arbiter algorithm of picking the first device with VGA
> routing to it (or it can be overridden by arch/platform code).  Thanks,

Fyi we don't get this wrong, we indeed need vga access in some cases.
Broken hw :( The other issue is that the X server asks for vga access (or
at least did in the past) for every render op, even if it's a kms driver.
Which makes X crawl if you have multi-gpu system. Those two things
combined means vgaarb is essentially dead on any system with intel gfx.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch