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

[Dave Airlie]

On Fri, Mar 5, 2010 at 5:35 AM, Eric Anholt <eric at anholt.net> wrote:
> On Wed, 24 Feb 2010 15:54:16 -0500 (EST), Ari Entlich <atrigent at ccs.neu.edu> 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.

Dave.