On Fri, Mar 5, 2010 at 5:35 AM, Eric Anholt <e...@anholt.net> wrote: > On Wed, 24 Feb 2010 15:54:16 -0500 (EST), Ari Entlich <atrig...@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. _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
