[PATCH] xf86VGAarbiter,vgaHW: Only wrap co-operating VGA drivers

[Chris Wilson]

On Fri, Sep 13, 2013 at 01:40:51PM +0200, Mark Kettenis wrote:
> > Date: Fri, 13 Sep 2013 11:09:45 +0100
> > From: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > On Fri, Sep 13, 2013 at 11:56:26AM +0200, Mark Kettenis wrote:
> > > Wouldn't it make sense to move all arbitration for KMS devices into
> > > the kernel?  For the broken intel devices that can't turn off legacy
> > > VGA access completely you'd then have the kernel report that it
> > > doesn't need any legacy resources such that the X server would skip
> > > the lock/unlock for that device.  But you'd still include it in the
> > > number of devices such that wrapping would happen and the driver for
> > > the non-KMS devices would still participate in arbitration in the
> > > traditional way.
> > 
> > The arbitration is in the kernel. X is simply requesting from the kernel
> > VGA access around every operation irrespective of whether the driver
> > requires device access (let alone VGA access) for that operation.
> 
> Not quite.  The code in libpciaccess that actually implements the
> OS-specific bits of the arbitration interface only passes through the
> requests if the kernel indicates that the device needs arbitration.
> 
> > X also disables DRI if the kernel reports there is more than one VGA
> > device in the system.
> 
> Again, not quite true.  It will happily do DRI for devices for which
> the kernel reports it doesn't need VGA legacy access.  Works (mostly)
> fine for radeon KMS, at least on OpenBSD-current.

Hmm, it only disables DRI devices with any decodes set, which on linux is
i915, nouveau, radeon and all unclaimed VGA devices prior to the first
use of the vga arbiter to lock vga resources, when there is more
than one of those devices present. So currently it disables DRI for i915,
radeon and nouveau on linux. Whether the binary drivers work around the
vgaarb issue, I do not know.

> Anyway, what I'm trying to say is that the kernel could indicate to
> libpciaccess that no arbitration is needed/wanted for devices managed
> by the intel KMS driver, since it doesn't allow direct access to the
> hardware in the first place.

Right, it seems possible that we can just disable the IO bit in PCI_COMMAND
and opt out of legacy vga arbitration altogether. So what's the purpose
of /dev/vga_arbiter?

> > > This would also fix situations where you have for example a Wayland
> > > Compositor running on your KMS device, but still want to run an X
> > > server on the VGA device.
> > 
> > Wayland (i.e. each wayland client) would need to learn a lot more about
> > the realities of hw before it is able to cooperate, in the same way as
> > unblocking DRI requires moving the vgaarb handling into each DRI client.
> 
> That would be the wrong model.  In the end, only the kernel has a
> complete picture.  And since clients only have access to the hardware
> through the kernel anyway, the kernel can actually do the full
> arbitration enabling legacy VGA access when necessary instead of
> relying on the clients to do this.

That would be equally true at the time the first arbiter support was
added. Yet the approach taken was the pessismitic one we have today.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre