Hi, > > 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 Various qemu display devices exist in vga and non-vga variants. So we can sidestep the vgaarb issues by using one of those, so igd is the only CLASS_DISPLAY_VGA device in the system. That causes some other problems though. First the vga variants are supported better by the firmware because it is easy to create a simple framebuffer with them. With the non-vga variants you usually don't have a display until the linux kms driver loads. Also the vgaarb will not pick them up, so they will not be considered as primary display. With the vga variants primary selection by ordering the devices works for me. kms drivers for both igd and emulated graphics must be loaded. fbcon will pick up whatever vgaarb declared as boot device. cheers, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
