Hello, Thank you for this long and extremely informative mail! I am going to save this as "documentation" for many things concerning svgalib :) Dr. Michael Weller wrote: >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.) I figured it out soon after I sent the mail. Sorry for bothering you... >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. thats easy to see.. >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). I figured out that too.. and my application is working fine with that... :) >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). fork() is something I didnot think about.. Thanx a lot for that hint! >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. This seems to be the best solution. >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). Oh yeah.. Believe me it is doing something sensible. I am just keeping it as a small surprise untill it is ready eventhough it is nothing great... :):) >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). No..Its not security. >> 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(). tcsetattr() doesnot return an error.It succeeds. And the next tcgetattr() also provides the same flags as was specified in tcsetattr() but stty shows different set of flags when the program comes out... That sounds strange! I have to explore this too.. and svgalib uses ioctl()s and not tcsetattr(), right? >I think some small (but complete) example of what you want to do is >required I will come back later as "anonymous" with the complete solution for some strange reasons.... >> 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. Ok.. I didnot mean to say that svgalib should imitate the monster called X in all its ways... just the console-allocation part so that the applications will have more power on the console that way. It is good that games based on svgalib works on the current console or any such svga-based programs. But what about applications which need more control on the console-switching and console-allocation? >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) But I think it is doable without a potential DOS or any security implications. >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. thats interesting. But how about letting applications specify what they want... I would like to hack a bit more and may be submit a patch (again as anonymous :-) if the svgalib gurus like Michael thinks it is a good thing. >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. I agree with you there again! The availability of both the options is good and important! >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. I am interested to do that but I will miss 'mutt'... and using webmail is painful. The small archive itself says volumes about the traffic :) >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. ok.. Thanx again for the mail!!! l8er, vijo.