From: Dr. Michael Weller (eowmob@exp-math.uni-essen.de)
Date: Mon 20 Mar 2000 - 13:35:18 IST
On Sun, 19 Mar 2000, vijo wrote:
> 2. vga_init() seems to be using both SIG{USR1,USR2} But I have a text
> console based program which uses these signals to manage the VC-switch.
> With vga_init() I am loosing the control over these signals. Is there
> way not to let svgalib have these signal handlers. It is *absolutely*
> necessary for the text based program to be in full charge of VC-switch.
> (I had a glance at the svgalib source code.. but just to get things
> fast, can u tell me where exactly sighandlers are set up etc?)
Hmm, the setup should be in vga.c, any editor will easily find you the
sigaction syscalls. (Uhmm... sorry to rant, but if you are modifying
things at this level, you should well know that signals are setup with
signal() or sigaction() (where the first is a more simplified
compatibility function of the second). An "fgrep sigaction *.c" in the
source dir would have shown you that sigaction is used in a SETSIG
#define which is used to setup the signals you are interested in in
__svgalib_takevtcontrol in vga.c in probably less than 1 or 2
minutes.)
Also, svgalib sets up the console behind the kernels back. It is
absolutely necessary that the kernel does not switch VCs because it would
not work right anyway. Svgalib cannot life without these signals.
Now, I understand, you want svgalib to just not switch VCs. vga_lockvc()
would do just that. To avoid the possible race conditions between
vga_init() and vga_lockvc(), from the source, it should be ok to call
vga_lockvc() BEFORE vga_init() (admittedly this is beyond the specs of
svgalib).
In case the vc was switched away, vga_lockvc() will block until it is
switched back. If you don't like that, you could fork() off a subprocess
before vga_lockvc() which will just do the right ioctrl on the console to
force a switch back (it might do that in a loop until the parent signals
it came through vga_lockvc() to fight race conditions).
When returning to textmode, you can just take over the console and signals
again by the ioctl() and sigaction calls intended to do that.
Actually svgalib currently resets the mode found on vga_init(). So if
unattended VC switches weren't allowed, they won't be reenabled.
You could also reinstall your signal handlers after textmode. It means,
however, if you going to enter graphmode again, you need to reinstall
svgalibs handlers (or make your signal handlers just not change VC's in
graphmode).
To deal with issues like that, I *STRONGLY* encourage you to fork() off a
child process when you want to do graphics which will do all the graphics.
Only that child process must do any graphics issues. If it terminates, VC
control will automatically fall back to your text application. For the
next graphics period, just start a new child.
Your major problem is here that your text application and svgalib are
fighting for the same resources and there is no kernel in here to
arbitrate this thing.
I'm still wondering what you are trying to do and if it sensible at all.
Why do you want to disallow VC switches and thus hinder your users to do
several things at once (after all, unix is multitasking).
I can only imagine you want your users not to be able to see other VCs for
some security issues. But if they are on the console with physical access
to the machine this is a pretty pointless issue. If you think they are to
stupid to deal with VC switching... well, arrange for fewer VC's
(maybe 1 only) created at bootup.
If they use some remote tool, dual head etc to access the same machine,
don't do that. It is a stupid attempt in hardware to overcome the
limitations of MS products. Just give them a serial or X terminal (the
latter could be an elcheapon old machine with linux).
> 3. Before exiting from svgalib-based routine, calling vga_setmode(TEXT)
> and then trying tcsetattr() didnot change the terminal attributes. Any
> idea why is this?
It should work. Actually svgalib does this to restore your original
settings. However it might be your file descriptor to the console was
changed (maybe just reopen it or get an own dup of stdin). Did you check
return values of tcsetattr() to see why it did not work? What parameter
did you pass to tcsetattr(), btw? You should not try to setup a a termios
struct from scracth (which is too complex) only modify infos got with
tcgetattr().
I think some small (but complete) example of what you want to do is
required.
> 4. What is the rationale behind starting vga on the current VC? Why not
> use the XFree86 way of getting hold of a new vt? that way, programs can
> have better control of vcs..
Well, why not? The rationale is I'm logged in on a virtual console and do
some graphics. I run a graphical program in that session and it does some
graphics.. It is the same session.. Why open a new virtual console?
There is nothing else going on that other session..
Xwindows is different. It is not an application in the true sense. It is a
server for applications. Even here, your rationale has flaws. What if you
run a startx without a trailing '&' ? The textconsole where Xfree
was started is still there but doesn't do anything sensible.. Actually
the startx script of Xfree is pretty bad anyway. If X is running already
it should detect that and start new Xservers :1, :2, ... instead it
now screws up. I used to have modified startx scripts, but got to lazy to
reinstal them again and again after updates.. Still the XFree86 startup
code is bad.
Another reason is that at the point svgalib was designed, there was no
means in the kernel to allocate and switch to a new, free VC.
Yet another reason is that you typically do not want people which do not
have a VC already to start a new one. (Consider some logged into your
machine from that net while you are on the console and he launches X11 and
svgalib applications).
Lo and behold, svgalib has now code to get a new VC if it does not have
one already. It makes some checks to ensure only people which are logged
in on some vc can open a new one.
So, you can just close CTTY, std* or ensure they are no real vc's and
svgalib will happily get a new one (and switch to it (and back from it on
exit)). If you don't like that, it's easy to allocate a new one and
make CTTY and stdin point to it before calling vga_init() and again
svgalib will happily use it.
So the point is: the current rationale allows for both things. If svgalib
would always allocate a new VC, there were no way to make it not get a new
one.
Michael.
P.S.: There is very little traffic on this list. If you are dealing with
svgalib at this low level, you should probably really be subscribed.
For the more recent development there is also a web based discussion
forum which you might find more convenient. Use www.svgalib.org as a
starting point.
--
Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST