Hi, all
Long time I maintain Linux 2.4.XX kernel tree , wich support multiple
consoles.
Ground priciple:
linus tree kernel has 64 virtual consoles == virtual terminal.
All 64 accessible by one user.
Tuned 2.4.XX-backstreet-ruby kernel has same 64 virtual consoles but one
user
can use only range of consoles. Current I use different terminology:
virtual
terminlal (VT) == 8 virtual consoles (VC), Each VT may be bounded with
independ
keyboard. Normal (non root) user can access only VC inside their VT. Root
can
access all 64 VC.
XFree86 is suid root process. XFree86 can access any VC. So XFree86 with
parameter vtXX can choose right keyboard, if exist multiple VT == 8 VC.
Current 2.4.XX-backstreet-ruby support only one text-mode console VGA, but
XFree86 do not ask for text mode console. We can use stealth DUMMY console
,
which emulate addidtional VT and bounded with additional keyboards.
files:
http://startx.times.lv/
broken project:
http://linuxconsole.sf.net
linuxconsole.bkbits.com
partialy worked project, same console code
fbdev.bkbits.com
Aivils Stoss
please replay to me to. I do not feel like xf86 developer.
p.s.
Why I should pacth PCI-handling of XFree or Why XFree search and freezy
innocent VGA adapters?
I just rewrite:
http://sourceforge.net/mailarchive/message.php?msg_id=2907175
"> >does anyone know why you'd want this kind of locking going on anyway?
is
> >it to avoid two x servers trying to drive the same head?
> Don't know.
I'd guess it has to do with braid-deadness of older VGA-compatible PCI/AGP
hardware. There might be no other way to init the chips (change mode, even
change single palette entry) than to go trough the VGA-compatible I/O
ports. This range is legacy address decoded by the PCI devices. Since
these legacy I/O ranges cannot be relocated (like normal MMIO I/O in PCI),
only one PCI device (in system) may have it's legacy VGA address decoders
enabled at single instance. This means that for most older hardware, one
needs to specifically disable the I/O decoders on _all_ other VGA
compatible PCI devices for the duration of programming the one that is
really required. If more than one PCI device will attempt at decoding the
same legacy I/O range (0x3d0-smt), serious brain damage would occur (could
prompt a #SERR on PCI). Only the recent graphics chips may be programmed
purely through MMIO I/O and even then they might require some short setup
before going into that mode.
(at least) because of this reason, xf86 has no choice but disable all I/O
decoders on all VGA-compatible devices, and it goes a bit further by
disabling all VGA-compatible PCI devices that it will not drive just to be
on the safe side.
Unless there is some system-provided common arbitration for these legacy
ranges, this is the only way (from xf86's point of view). The right place
for linux would be the kernel, although this might upset some xf86 folk
since their code also does a lot of other stuff as well (like run the BIOS
code init from previously disabled PCI display hardware to get it up and
running, DDC probing if otherwise not possible).
In my opinion a more generic resource management for this would be nice in
the kernel but atm xf86 assumes (rightly so) that it will be the only
application doing graphics stuff. This is difficult to solve (although in
my opinion possible).
Feel free to correct me if you feel that the technical data is inaccurate,
I've currently trying to understand the lower levels of PCI and AGP
eventually and don't claim to be an expert on it.
Aleksandr Koltsoff"
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
