On Wed, 24 Feb 2010 15:54:16 -0500 (EST), Ari Entlich <[email protected]> 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. Beyond master setting, there's nothing left in my Enter/LeaveVT. Hide cursors on Leave, set video mode on Enter. There are two other function calls left in there, but I don't think they particularly deserve to live. > Even if the answer to question #1 is yes, the X server still needs to > be able to decide whether to use VT_PROCESS_AUTO, i.e. it needs to be > able to check whether KMS is being used. Not having done any X > hacking, this is proving to have quite a learning curve for me. Here > are some of the preliminary assumptions I'm making and some of the > things I've determined by grepping through the code (lots of these > things will be obvious to most of you, just bear with me): Is your VT switching code going to handle resetting my modes correctly? I don't think that's the case today.
pgpmVYvnpgfqc.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
