From: Steffen S. <s.s...@ph...> - 2000-05-08 10:11:05
|
Hello all, having moved the KGI project home to sourceforge now, I found some time give KGI-0.9 a try running true multihead with XFree86 4.0. I first prepared two XF86Config files for each head, which _independently_ worked somewhat. (Startup has become even slower, and it seems as if each server is initializing all video cards found). Next I prepared KGI-0.9 from the current repository state, and found there has been a bug introduced in the keyboard driver when making it behave as the old driver in terms of hot-plugging keyboards. This messes up the scancodes on the second keyboard, so it is unuseable. I will commit the fix soon. Then I booted KGI-0.9 (with null display driver enabled) logged on and created a node for tty17. A simple cat /dev/tty17 with some input on the second keyboard did get me the input, so the keyboard and null display driver seem to work ok on my machine. Next I configured XDM to run two servers, each with it's own config, one on tty7, and one on tty17. Firing up XDM as in inittab, it actually ran two X servers. However, only the first display was working as expected. Exiting one server, it somehow left _both_ cards mapped to the same address region, so I assume they do some PCI I/O region remapping on server startup. But why not mapping it back on exit? Anyway, as a result I had one or the other card showing console output, both being messed up. After reboot, I tried to run both servers manually, and I somehow got them up and running, each having it's own mouse and keyboard. Both worked nicely as long as you stayed inside the server, but when exiting, the console was messed up again. So, the disappointing bottom line is that XFree86-4.0 seems not to restore video hardware state completely, or messes it up due to a bug. Therefore the underlying console driver might get confused after the server exited. However, even if that would have worked, there is another issue I came about when configuring XDM: xterm and some other programs expect /dev/console to be owned by the user sitting on the console. So, even if we map /dev/console to tty's on a per-work-place basis, how do we manage to map ownership and permissions? Does anyone have any suggestions? Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
From: Marcus S. <ma...@st...> - 2000-05-08 17:26:05
|
Steffen Seeger <s.s...@ph...> writes: > However, even if that would have worked, there is another issue I came about > when configuring XDM: > > xterm and some other programs expect /dev/console to be owned by the user > sitting on the console. So, even if we map /dev/console to tty's on a > per-work-place basis, how do we manage to map ownership and permissions? Hmm? xterm doesn't even touch /dev/console on any Linux-system I've seen, and I doubt many other regular user application do either. Exactly what problems are you experiencing? //Marcus -- -------------------------------+------------------------------------ Marcus Sundberg | http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: ma...@st... |
From: Steffen S. <s.s...@ph...> - 2000-05-09 05:55:51
|
Marcus Sundberg wrote: > > Steffen Seeger <s.s...@ph...> writes: > > > However, even if that would have worked, there is another issue I came about > > when configuring XDM: > > > > xterm and some other programs expect /dev/console to be owned by the user > > sitting on the console. So, even if we map /dev/console to tty's on a > > per-work-place basis, how do we manage to map ownership and permissions? > > Hmm? xterm doesn't even touch /dev/console on any Linux-system I've > seen, and I doubt many other regular user application do either. > Exactly what problems are you experiencing? The two scripts /usr/X11/lib/X11/xdm/TakeConsole /usr/X11/lib/X11/xdm/GiveConsole give the following notice: # Reassign ownership of the console to root, this should disallow # assignment of console output to any random users's xterm and change permissions and ownership on /dev/console. It seems as there is some security issue involved, e.g. xterm and may be xconsole requiring correct ownership of /dev/console before attaching to the console. There is a similar mechanism (see /etc/security/console.perms) used to control access to joysticks, mice, serial lines, etc.). So, my concern is (as with other device files in /dev/ that virtualize workplace local devices), that if running two independent sessions from xdm the session started later will take over devices of the first, unless the device sets have no common elements. Also, applications that require user-local preferences (e.g. what is your preferred sound output device) will fail if you are not logged on to the same head as during configuration. What I do imagine is something like /proc/self for workplace local devices. But do not yet know if that is actually enough... Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... TU-Chemnitz http://www.tu-chemnitz.de/~sse --------------- The GGI Project: http://www.ggi-project.org ------------------- |