multi-master [was Re: Improving VT switching with KMS]

Dave Airlie airlied at
Thu Mar 4 15:09:42 PST 2010

On Fri, Mar 5, 2010 at 5:35 AM, Eric Anholt <eric at> wrote:
> On Wed, 24 Feb 2010 15:54:16 -0500 (EST), Ari Entlich <atrigent at> wrote:
>> Hey all!
>> So I'm that annoying guy who keeps asking questions on the irc channel
>> about VT switching and KMS. I suppose I am now moving that discussion
>> here so as to (hopefully) get more responses.
>> So I made a kernel patch which allows (at least as far as the VT
>> subsystem is concerned) a VT switch to happen even if the VT being
>> switched away from is managed by a process. Since this new VT mode is
>> basically a cross between VT_AUTO and VT_PROCESS, I just called it
>> VT_PROCESS_AUTO. My impression (and the impression of a couple of
>> other people who I've asked) is that this is now safe to do with KMS.
> For working X Servers, we need to be able to get the master handoff
> correct, so this doesn't seem safe.  But I think the real problem there
> is that we need multi-master support, not serialized-master-handoff
> support -- some client opening in an X Server while switched away should
> get GL and be able to use it just like on an active X Server.

How do you distinguish a new master from a new non-master? how
do you become a master? how do you distinguish a new non-master
for master (a) and master (b)  and retain interface compat. etc.

I originally aimed for this but gave up when I got too far down the rats hole.
The big thing is you want an unauthorised client to become a master,
but you don't want anyone to become a master. Like maybe
if we go to one drm device node per master it might be workable.

Though I'm happy to listen to any proposal anyone might come up with.


More information about the xorg-devel mailing list