This is mostly solved, for linux, by bug #968. Several other patches exist
against XFree86; example implementations:
Both of these are unusable as-is because the 'usbev' driver they use is lifted
straight from GPL'd code (though the itsopen solution omits the license header).
The rest is MIT clean though, and the evdev driver in bug #968 replaces the
Targetting 6.9 for this, as it's low-impact and widely desired in the user
For Ubuntu, we're using the evdev driver, and a novtswitch PLUS sharevts patch
which I'll attach in a second.
Created attachment 1699 [details] [review]
inhibit initial/final vt switches
wow, that's so much less ugly. however that looks like just the noswitchvt
patch, is the sharevts one not needed? also, i looked in the ubuntu changelog
but couldn't find an attribution for those patches.
there's one piece of the community solution that i'm still not sure about:
--- xc/programs/Xserver/hw/xfree86/common/xf86pciBus.c Wed May 16 04:56:06 2001
+++ xc.1st/programs/Xserver/hw/xfree86/common/xf86pciBus.c Mon Aug 20 10:10:26 2001
@@ -534,9 +534,11 @@
ErrorF("pciIoAccessDisable: 0x%05lx\n", *(PCITAG *)arg);
((pciArg*)arg)->ctrl &= ~SETBITS;
this is _extremely_ dirty, basically this turns pciIoAccessDisable into a nop.
apparently this is to work around lockups when one server shuts down. how
gross. need to look at the gentoo patches to figure out if they have a better
the sharevts and novtswitch patches in ubuntu look good to go, between those and
evdev i think we're mostly sorted for multiseat. but i do want to figure out
that PCI hack.
Created attachment 1749 [details] [review]
this merges the noswitchvt and sharevts patches from debian, and ports them
forward to head. minor changes were needed to account for egbert's work on OS
restore of console fonts.
still no idea how these should be attributed...
Authored by Daniel Stone, copyright © 2004 Canonical Ltd. Happy to licence
under the same terms currently governing lnx_init.c.
Created attachment 1853 [details] [review]
updated to apply against cvs rev 1.4.
Created attachment 1891 [details] [review]
you'll also need this one in order to not have it crap all over the PCI bus on
start; without this, the other displays just freeze as the last X server to
start randomly obliterates all other display devices on the PCI bus. usage is
-isolateDevice PCI:1:0:0, f.e.
so is there any reason we can't do isolateDevice behaviour by default?
yeah, some devices get cranky if you isolate it down to them; they'll just hang
solid at startup (this was the case for me with a cirrus gd5446, nvidia riva128,
tseng et6000, ark 2000pv, s3 vision964; they only work when you don't pass -iD.
starting the server and loading that device without -iD (a normal run) first
seems to improve the situation a little, but not much -- it's extremely fiddly.
okay, so we need novtswitch + sharevts + isolatedevice, but none of them on by
default. i'll make a rollup patch against HEAD later this week, and i'd like to
get some pretty wide testing before landing it all.
Created attachment 3024 [details] [review]
add mimetype for Hancom Hangul Document and Template
so, exactly one week later, here's your rollup patch against 220.127.116.11. gonna
do some quick build and boot tests with it, and then (hopefully) commit.
applied. leaving this open since it assuredly doesn't work yet for someone...
closing. please open new bugs if you hit issues with multiseat support.
what is the earliest version that supports this?
*** Bug 4514 has been marked as a duplicate of this bug. ***
pulling this off the blocker list for 7.0, so transitive evdev bugs aren't
marked as blocking 7.0.
Well, I cant say I understand what 'multiseat' is supposed to mean :-/
But I'm pretty sure I found a bug in these patches.
From my understanding; the -noswitchvt stuff ensures that X doesnt
just automatically switch the active console to its VT, that works.
But any calls to XOpenDisplay at this point block; maybe I missed the point
but to me the -noswitchvt stuff is very usefull because I intend to stay
in bootsplash untill the heavy X based applications finish loading up
and displaying themselves in X... and *then* chvt into the X terminal
(so as to minimize graphical glitches at startup on an embedded device).
Is this a bug or just impossible to achieve because of some hardware
dependancy ? (i.e. I cant get a Display handle if X has never taken over
the console yet).
BTW: maybe its an issue with my setup ? I'm running xorg 6.8.2 + the above
noswitchvt patch on a via epia lookalike board.
multiseat is supporting multiple users on the same machine through multiple
input devices (i.e. the logical polar opposite of multihead; multifoot wasn't
sensible, and the other suggested names weren't quite tell-your-boss-about-it-safe).
and yeah, you probably won't be able to accept client connections until after
you've done the VT switch, because the driver defers initialisation until then;
so it may very well fail, in which case you don't want to have already accepted