On 6/1/06, D. Hazelton <[email protected]> wrote:
VT switch to a VT where X is running. X will still require a VT and assume it
has good access to the graphics system. While currently it has no problems,
when drmcon becomes a reality there will have to be a state switch between
the consoles settings and the setting for the VT running X.
I forgot to include comments on VT's.
We need to reconsider how VT's are implemented. I would like to remove
them from the kernel. Now don't get too excited, I also want to
replace them with a system that would function the same for a normal
user.
There is only one VT system in the kernel. Making it support more that
one user requires a gigantic patch (18,000 lines). That patch has been
floating around for years and has never been merged. I don't think it
makes sense to extend the existing VT code even further to support
multiuser.
My proposal would be to switch to the concept of splitting console as
I described earlier. There would only be one in-kernel system
management console and it wouldn't support VT's. The system management
console is not meant for normal use.
Normal consoles would be implemented via user space processes. These
processes would provide the VT swap feature that people are used to.
They would also be accelerated via DRM. Since they are user space apps
it is easy to support multiuser by having multiple processes.
Getting rid of the VT implementation inside of the kernel lets us move
towards the single state in the hardware goal. The current in-kernel
VT design forces the "save your state, now I'll load mine" behavior.
That behavior is evil and it is the source of a lot of problems and it
should be removed. VT's were a good idea on VGA cards with 14
registers, now cards have 300 registers, a coprocessor, 512MB, etc.
There is simply too much state to swap.
In this model there would be no change at the normal user level,
Ctrl-Atl-num at a normal user console will still get you another
session. A hot key would display the system management console,
another would make it disappear.
--
Jon Smirl
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
