Bug 246267 - -novtswitch doesn't seem to work
Summary: -novtswitch doesn't seem to work
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server   
(Show other bugs)
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-29 18:04 UTC by jmccann
Modified: 2015-01-14 23:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-06 22:50:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
partial fix (1.23 KB, text/plain)
2007-06-29 21:09 UTC, jmccann
no flags Details

Description jmccann 2007-06-29 18:04:10 UTC
-novtswitch            don't immediately switch to new VT

sudo /usr/bin/Xorg :102 -novtswitch

Still immediately switches to new VT.

Or is there another way to make this work.  I'm testing some user switching
stuff and I'd like to start an Xorg server in the "background".  Thanks.

Comment 1 jmccann 2007-06-29 21:09:12 UTC
Created attachment 158265 [details]
partial fix

This seems to fix the bug in the initialization where the VT is activated when
it shouldn't be.  However, there is another bug somewhere that assumes that the
VT was switched to and corrupts the current VT... looking for it.

Comment 2 Ray Strode [halfline] 2007-06-29 21:21:44 UTC
yea I talked to ajax about this before and he said the switch didn't really
work, so it's at least not a surprise.

Comment 3 jmccann 2007-06-29 21:34:07 UTC
Seems to go awry at dix/main.c:785
    if (!(*pfnInit)(i, pScreen, argc, argv))

Comment 4 jmccann 2007-06-29 21:47:58 UTC
Occurs with nv, intel, and nvidia drivers.

Comment 5 Adam Jackson 2007-07-02 20:21:08 UTC
The deal is, the driver's init function expects that it has the hardware.  So
the only sense in which novtswitch is meaningful, is when you're starting the X
server on a card that the kernel is not using for the virtual terminal head.

You can't start an Xorg server "in the background", because many parts of
initialization can fail, and you can't know whether you'll succeed or not
without going ahead and touching the hardware.  The best you could do is a
deferred launch that just waits to start the new server until its VT is brought
foreground; but that's not actually going to hide much latency.

Comment 6 jmccann 2007-07-05 15:18:57 UTC
Ajax, thanks for the explaination.  So, yeah, it sounds like this approach won't

Comment 7 Adam Jackson 2007-07-06 22:50:06 UTC
Closing as WONTFIX.  I think it's something that needs consideration upstream,
but we're not going to solve that problem here.

Note You need to log in before you can comment on or make changes to this bug.