multiseat

Jon Smirl jonsmirl at gmail.com
Thu Jul 28 12:14:52 PDT 2005


On 7/28/05, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Thursday, July 28, 2005 7:52 am, Adam Jackson wrote:
> > > Benh already has a working prototype of VGA arbitration for the
> > > kernel. It was discussed at Kernel Summit this year.
> >
> > The arbitration idea is lovely but it assumes that the card gives a
> > damn when you tell it not to decode the VGA space, and there are many
> > video cards that will stick their fingers in their ears and go LA LA
> > LA I CAN'T HEAR YOU when you try.  You could assert that those cards
> > are broken, but that's sort of the point: hardware is broken and will
> > actively defeat attempts to be used in a multiseat setup.
> 
> As a result, I think it's reasonable to limit multiseat setups to a sane
> subset of cards that X supports.  If a card needs the VGA registers to
> be enabled during runtime for use by the driver, it seems especially
> broken to me.
> 
> Other than that though, VGA registers should only need to be available
> for card posting--once that's done, VGA stuff shouldn't happen at all,
> right?  Can we do things like screen blanking without it though?
> 
> The unfortunate thing is that VGA routing is both dependent on the card
> behaving well (i.e. honoring the VGA_EN bit) and potentially
> programming host<->PCI or PCI<->PCI bridges correctly to route legacy
> VGA I/O accesses.  This is  obviously very bridge dependent, so the
> kernel needs bridge drivers that export sane programming interfaces.

Ben's plan is to group the video cards into two categories, good and
bad. Bad cards need VGA at run time, good cards do not.  You can have
one bad card and as many good ones as you want. Posting is
sequentialized so that each card can use the VGA ports.

On super fancy machines you can have one bad card per bus since the
bridges can be used to isolate them.  You'll probably still have to
access them sequentially because of the A000 memory hole.


> 
> Jesse
> 


-- 
Jon Smirl
jonsmirl at gmail.com



More information about the xorg mailing list