Startx on current VT

OK, I have a little problem here. I want to use startx to launch my desktop but I want it to launch on the current VT and not on VT8. I know I can force it by running startx -- vt1 (if VT1 is active terminal) and that also works. It's just that when I do this it becomes impossible to switch to the other terminals using Ctrl+Alt+Fx (just does nothing). The only thing that happens when I try is that my keyboard becomes unresponsive so unless I can manage to shutdown X using the mouse I am stuck and have to reboot.

Any clues what I could do to get this working? I am using the proprietary Nvidia driver which I feel might be related.
 
Tiny correction: After forcing the VT to the current one trying to switch is not needed to make the keyboard unresponsive. It's just not working but when i kill the XServer there will be garbage input in the originally running terminal.

I also actually have an idea how to fix it but it won't be nice. Basically it seems to be about moving getty out of the way and avoiding conflict while X uses the VT so there would be a suid wrapper around startx that removes the current VT from /etc/ttys, runs init q, puts the VT back, temporarily drops root and launches startx, waits for startx to exit and runs init q again. Even if this works it would be beyond ugly but i really need the ability to startx whereever i want otherwise it breaks a good part of my familiar setup. Clues or better ideas are still very much welcome.
 
Why or how would this break your set up?

I am used to having quite a lot of terminals active. Multiple of them graphical. It's somewhat hard to explain but in general i have a set of scripts that extend login to act as kind of a login / display manager hybrid and if i can't put X on the current VT when the graphics flag is chosen things get messy (extra logic needed to figure out where to put them, no effective way to control where they end up, it's needed to reserve terminals beforehand and limit graphical logins to that amount).

It's something i have been using for years so changing it would feel bad. Besides i am pretty happy with how well the scripts ported over from Linux and it's just this tiny aspect that's left so i don't want to give up. I might end up just patching the login binary though. I don't really like the idea of moving from scripts to binaries but if i can't figure out anything else i might as well just go that route instead of adding an additional suid binary. The extra control gained by having full control over login would have it's upsides too i guess.
 
You should try to use multiple desktops instead of running multiple Vt with Xorg. Almost all desktop managers have that option.
Also using big curved monitor helps a lot when you need to have all information in front of you.
 
You should try to use multiple desktops instead of running multiple Vt with Xorg. Almost all desktop managers have that option.
Also using big curved monitor helps a lot when you need to have all information in front of you.

That sadly doesn't really do what i want. Those X servers need to run under different users but i agree more and/or larger screens is never a bad idea.
 
That sadly doesn't really do what i want. Those X servers need to run under different users but i agree more and/or larger screens is never a bad idea.

I think what VladBG is saying is that if you start a single Xorg server and then run a window manager with workspaces, you're basically replicating the functionality of switching between VTs.
 
I think what VladBG is saying is that if you start a single Xorg server and then run a window manager with workspaces, you're basically replicating the functionality of switching between VTs.

Yes, i understood that. It's just that i really want to replicate the functionality and keep the different desktops cleanly separated. It's also not like i don't already have workspaces.


Thank you, i will do that. I think already heard/seen this somewhere but it has been a while for sure and maybe there is some aspect i have missed back then.

To be honest if there is any way (even one that isn't exactly beautiful) i can keep my old setup i will probably not opt for an alternative. I feel like using the virtual terminals / login this way is putting back meaning into old functionality (as well as avoiding a display manager - which with the exception of maybe xdm and slim seem like complete overkill to me - while keeping the convenience) that has very much been forgotten about. I mean what use do they have (at least on a desktop system) these days outside of being a rescue option in case the graphical interface broke? Authentication is done by the display manager while login (or rather getty as login only gets involved after a username has been entered) just sits there being idle.
 
This might interest you, recently someone on freebsd-hackers@freebsd.org has asked if it's possible to run 2 instances of Xorg server on 2 virtual consoles. One solution was involving x11/xdm, the other one confirms it's possible, but doesn't provide how it's done ( subscriber Theron Tarigo - is more active on the mailing list ).

With no more details from the mails it might not apply what you have in mind, but you could join that thread, maybe they can assist you on your setup. Your Thread Keyboard input settings.76783 could become obsolete.
 
This might interest you, recently someone on freebsd-hackers@freebsd.org has asked if it's possible to run 2 instances of Xorg server on 2 virtual consoles. One solution was involving x11/xdm, the other one confirms it's possible, but doesn't provide how it's done ( subscriber Theron Tarigo - is more active on the mailing list ).

With no more details from the mails it might not apply what you have in mind, but you could join that thread, maybe they can assist you on your setup. Your Thread Keyboard input settings.76783 could become obsolete.

Thank you for alerting me to this. I am not active on the mailinglists (yet?) and would likely have missed those posts otherwise. Concerning the problem in question i am a little further already than when i made this thread. As seemingly pointed out on the mailinglists also it's very well possible to run 2 (or more) instances. It just has to be done on the "right" VTs and/or appropriate precautions have to taken to avoid whatever already uses the VT to interfere with X input handling.

Where i am still stuck is running X on the same VT where startx was executed (regardless of there being another instance running or not) but i think mickey put me on a hot trail when he pointed out the -keeptty option. I lack the time to test it right now but theoretically it makes a lot of sense. If startx actually detaches from the terminal (which i didn't think it would until then) and my observation is right that if there is anything running on the target VT closing the input descriptor is crucial for X to work there this might very well be the reason why my tries to do what seemed to work in other constellations (i.e. closing input) proved futile here.

A last resort (if everything else leads to a dead end) would be hacking together a couple lines of suid code that executes startx on some unused VT while targeting the current one. Not exactly something i'd fancy but one has to do what one has to do. Before i resort to this i'll dig into the mailinglists for sure but firstly i'll have to see how far -keeptty gets me or if xinit maybe really makes more of a difference to startx than i thought it did.
 
This might interest you, recently someone on freebsd-hackers@freebsd.org has asked if it's possible to run 2 instances of Xorg server on 2 virtual consoles. One solution was involving x11/xdm, the other one confirms it's possible, but doesn't provide how it's done ( subscriber Theron Tarigo - is more active on the mailing list ).

T-Daemon, actually he did and this saved my day. :)

Code:
#/usr/local/etc/X11/xdm/Xservers
:0 local /usr/local/bin/X vt09 -nolisten tcp :0
:1 local /usr/local/bin/X vt10 -nolisten tcp :1
 
Back
Top