Also, most questions deal with the status and future and my ideas about it. Necessarily they contain my own private opinions on this. People may disagree and I'm sure I don't have the best ideas about it or may even be completely wrong. I don't want to force anyone to agree with me.
Also, I was asked about MY opinions, so I'm just presenting them here.
You must be the owner of the current console to use svgalib.
Not running in a graphics capable console, and unable to find one.
However, though logged in not directly from the linux console, I am the owner of the console.
Yes, the documentation is short and/or confusing. Sorry, English is not my native tongue. Many people complain and want to write some better documentation. You are welcome to do so! However, up to now, either people found the documentation sufficient once they looked at the correct files or they just gave up. At least, I never heard from these people again.
Also, svgalib comes with source. If in doubt: read it.
Finally: Linux distributions include svgalib, but not the source and README's (or hide them so good noone finds them). Well, no problem, get full svgalib source, demos, readme's from svgalib-*.tar.gz on any Linux FTP server in your vicinity. Even if you don't dare to install or compile it, it contains the readme's.
Oh yes, there are some simple demos in the demos/ subdir. They should get you started.
When someone writes man(1) manual pages, a distribution might just install them. Please do not complain, write them, mail them to me.
Please understand that this is a free project. I will not go and buy a similar card and write a driver for you. I already wrote support for the hardware I have! I just do this as a hobby. Because I don't get paid for this I can not just buy card & docu and spend much much time supporting whatever graphics card on earth exists.
Also read below on the future of svgalib.
If you don't feel able to write a driver for whatever reason, please do not complain if other people don't do it for you (because you are not better than they are).
You must be the owner of the current console to use svgalib.
Not running in a graphics capable console, and unable to find one.
However, though logged in not directly from the linux console, I am the owner of the console.
The answer is difficult indeed: Yes, svgalib has been developing slowly in recent times. Also, I must admit that I have much too little time and stomach to push svgalib further.
In the .lsm file I still list myself as temporary maintainer. I did not write or invent svgalib at all. However, when Harm Hanemaayer had to stop working on it for a while, I agreed on collecting patches, enhancements, fixes in a single position and answering questions.
Personally, I must admit that svgalib is not perfect as of now. Most of its code is a bit weird because it was developed over a long time by many different people. More drivers are needed. Better stability is required.
Yes, again, it can be done. But the coding effort and overhead involved is incredibly high. Just think of the 1MB wasted for the virtual DOS session. Also it will make your Linux very unstable because it will have to switch to DOS often.
Due to my (limited) knowledge, this is exactly how M$ Win works if you
do not have a special Win driver. This is THE MAJOR reason for the
instability of the M$ Win OS. Do you want Linux to be as unstable?
Ok, good. Next question. ;-)
I liked this idea so much, I even started coding a frame buffer device once. After a short time, other people came out with the GGI idea. Right from their beginning they claimed to be the only source of wisdom. I tried to join our efforts, but failed. In general we have the same goals (read the GGI project pages for that).
Anyhow, at that time a flame war started. I don't really know why. I don't see I did anything else than offering my opinions, work and experience. But that should be judged by others.
Well, after some time I stopped bothering them. I was satisfied to learn later though that they actually came up with some conclusions I proposed first but weeks or months later. But let us leave the past alone.
When intending to contribute to svgalib, you should think about what you really want. I don't see that GGI is becoming available soon. GGI people told me the opposite again and again, ok, I still don't see it. Still out of a sudden, everything might be GGI infested, so you might consider contributing to GGI instead.
With svgalib you might be able to use your fruits earlier. And anyone (with supported hardware) can just use it right away without reinstalling kernel/X11 what else (maybe being unable to use something he did before).
Yes, this is what many people say. This is the common Unix way to do it. X does it.
But X has some drawbacks:
Still, an advantage of Linux is the ability to use old hardware for mission critical background jobs on the net (servers/routers/firewalls) on low price or otherwise even unusable hardware.
This imposes a bunch of overhead. If you just want access to the screen memory, it slows things down as hell. If you want just to use above's draw commands, it is ok!
However, you cannot change screen modes and rez as easily. This is IMHO THE drawback of X. For a picture viewer, you want 256 color high/true color modes on a per picture basis (also, insert any other application you like: movie viewers, a special game, a drawing program). Also, you want a small picture use a low rez s.t. it does not appear as a thumbnail, maybe use a high rez mode for a huge picture which you don't want to use on a permanent basis because it flickers like hell (and you don't want to use a panning virtual desktop too, I hated them at best).
This latter restriction can of course be circumvented by enlarging the picture. But this will need much time for a picture viewer already and certainly too much for smooth video or game animations.
Alas, there might be security holes, also the stability and performance issues (IRQ driven accelerator queue, CPU support for VGA memory paging) still exist, though one can expect an Xserver to be a generally well coded application.
Honestly. I don't know... My major problem is that at least I am really lacking the time. I have a few ideas, but they'll need time. Time which I don't have. Also, implementing them will need much effort. More than a single person has. Applications need to be recoded. Device drivers need to be written (which is a) much work and b) an author with the hardware is always needed).
Also, the future of svgalib is uncertain. Why develop a new API when noone will write applications for it? Why redesign the internals when noone will write a driver for it? For me the status quo right now is enough. I don't miss anything. I'd like to at least push svgalib into another direction, but I need people willing to contribute on the svgalib and application side.
i) Similar to the GGI people, I think the kernel must become the major control instance for VC switching. Also it is bad that root privilege is required for screen access.
Finally, it would be great if some memory paging could be used to automatically do VGA window paging as well as using interrupts for optimal usage of an accelerator queue WITHOUT any busy waiting.
Honestly, the latter two things can be done WITHOUT kernel support. The memory paging can be performed with well thought over mmap/munmap calls (just mmap the currently visible VGA window, munmap the others; if an unmapped window is accessed you get a SIGSEGV. Within the handler you can use Linux specifics to get hold of the faulting address in the signal handler and do appropriate remaps; You might say that the many user/kernel space transitions will cost time. Yes, but the faults will only occur occasionally, and the port accesses to do the window change on the card are usually much slower anyway.) For the usage of interrupts, yes, you must be in kernel space to do it.
But, a very simple device driver loadable module could just hook in an interrupt handler. An application registers with it and receives a signal when an interrupt occurs. I even think a beast like this already exists for dosemu. Simple thing, no main kernel changes are required.
However, for this handler, irq response might be bad. I dunno, but should be worth a try.
Unfortunately, doing this from user space does not interest me personally because I think its wrong. If you want to do it, go on though. I just don't feel like working on that myself.
ii) However, other than GGI, I'd tend more to a less invasive solution. Acceptance for this project is low. The Unix way to do it is that you don't do it. X accesses the hardware directly and that's it. This has no such permission problems (as the X server is always trusted), for performance and mode selection limits, there is no way to solve them, and on the few commercial systems which allow several X servers up at the same time (used by other users or running in different resolutions), stability is low. Any such commercial system I saw can be easily screw the console till the next reboot by switching between X servers quickly.
Thus, I'd propose to simply add a few hooks to the main kernel. The distributed kernel will not change in any respect, only gain a few K. It will just provide a means for a module to registers functions which will be called during certain console ioctl calls as well as during VC switches.
Then a (loadable for those who want it) module will hook into this and provide secure grafix VC switching.
Old applications (old svgalib, Xfree and X) will continue to work and coexist with new applications. Of course, they'll still suffer from the stability constraints of the old interface.
As a more detailed proposal, look on the VC switching module functions in ALPHA/scrdrv/fb.10Jun95.0030.tar.gz at tsx-11.mit.edu and mirrors.
I don't think the GGI way of declaring all other approaches as devil's work and replace everything as well as make any other application be forced to use their clean approach or not work is right. Live and let live. It is not sensible to assume that one is able to not use an Xfree or commercial Xserver and just stick to GGI applications right now.
This bad attitude of the GGI people will finally kill their project, if it didn't already. This is a pity because the general idea and concept is good and needed. When there is not any grafix interface within Linux in the future it is IMHO their and their attitudes fault. This is a dead end in Linux's and general OS development. And GGI is guilty.
iii) As kernel memory is not pageable and to reduce work in this critical area, only the absolute minimum code must go in the kernel memory. From my experience, all you need is a discrete set of modes to set from a table plus a flexible mmap() API and ioctl() calls to set a few basic things (video memory start offset, logical width, force a memory page offset to emulate vga_setpage in a svgalib emulation library)
Someone (sorry, forgot the name), made a related proposal which made me come up with this idea:
To support a certain grafix board, load a table into the kernel (could be either compiled into the module or loaded by a setup tool at system boot). The table will contain an entry for each port used by the card with the following data:
The advantages are obvious: From this card specific table, generic routines can be written to
The mode tables to setup a certain mode on the card are then stored by a bunch of byte code for this machine. Together with a few more tiny commands (say: 'return OK if non-zero', 'return FAIL if non-zero', 'set' (set a register to a value (maybe just -1) in case it is non-zero in any bit)) it would even be possible to add some detection code which will ensure the selected card is really there.
YES, this will add overhead and slow things down. But you gain much by means of portability, the access of the card's ports is slow anyway and will certainly outweigh anything here. Also, it is only used for mode setup which is slow anyway.
Detect any supported hardware from usermode.
Read a nice written config file of mode timings, compile above byte code and store it into the kernel at system boot time. All this is done from usermode. The kernel will just keep the byte code for EXACTLY your setup.
The utility could be enhanced to allow for interactive mode setup and fine tuning. Once set, the data is stored into a nice config file.
That utility will be required to be run by root. But this is no problem. It is just used during installation/boot time.
That utility would be the almost sole place for card specific code.
The utility will report all i/o port accesses done by the BIOS. This info can be used to write a basic driver. Probably you'll just need a data file to do it. With the right utilities, Joe blow user can support his board in a basic fashion.
iv) For the VC switching under kernel control, a major objection against it is that it will need much in kernel memory. And yes, VC switching is done in an interrupt handler and to store/restore grafix screen you need to copy it to memory. Alas, you cannot access an application's memory because it might be paged away and Linux can page it back in from the irq handler environment. Also, even when executing a kernel call, application A cannot read application B's memory if it is not accidently in memory (because it can not page back in any of B's memory).
I found the following work around: We do NOT store/restore grafix screen in the IRQ. Instead, we only store the single 64K page which the kernel uses for its text console. Also, we only need one such 64K for all possible grafix VC's. We'd also need to store any other per application stats (accelerator state, color lookup table) but this will again only be a few K. Don't worry about that. For each Textconsole the kernel already allocates several K for the screen contents.
Now, during a VC switch when a grafix console is active, the kernel stores these 64K away and sets the card back to textmode. Then operation continues as usual. Actually the rest of the screen contents just remains in VGA memory and is not copied ANYWHERE!
In case another (old style) grafix application acquires the card in grafix by an ioctl() or a (new style) grafix application gets a page fault by accessing some vga memory or makes an ioctl to access the card, we allocate new memory pages for the screen contents, copy them and put them into the memory tables of the application which actually owns this grafix console. We cannot reliably access pageable memory of another application, but we can give new pageable memory to another application!
To speedup the grafix display of a switched to application if it does not make any screen accesses, we send it a signal. In response it shall make some dummy call.
In a future version one could actually add a hook to schedule which will make an update next time the application is scheduled.
The worst thing that will happen for an application blocked in an uninteruptible I/O operation or simply crashed is that the grafix VC of this application will NOT be displayed (instead you see it's ASCII VC). As the application is broken this seems ok to me. Any other application is NOT affected at all.
I had this basically running in that fb snapshot above. Alas, I never did come to a non Mach32 driver for it. (Because I only have a mach32, and a vga driver is boring anyway because you only have one 64K page there anyway). Nevertheless, you might the find source interesting.
The next applies more or less to both a newer user mode svgalib or some in kernel stuff:
v) For the accelerator, all discussions with people using other cards yielded the following results:
It is guaranteed by the kernel that no VC switch will be done during this. The kernel will timeout such a 64K bunch after some time and reset the card s.t. the application cannot block the console with such a command for more then a second or something. In that case the accelerator will get confused (or at least in another state than the application expects it). Again, it is the application's bug. We don't care. But any other application gets a freshly reset accelerator.
The ordinary Unix API (select, fcntl) can be used to block for completion of certain grafix commands and such. Standard libc API (fwrite, fput etc..) can be used to maintain a long queue in the application and not bother the kernel with tiny accel calls.
A user space library will be required to hide the hardware differences of the cards from the applications.
vi) One might write a new API. But beware, we do NOT want to reinvent X11. IMHO we need a list of modes, a call to set such a mode, a way to find out details about modes, and get direct screen access.
Then provide an API to the accelerator. (like I said above, set fg/bg draw polylines, etc..) Make it simple.
We can add convenience functions to draw certain arcs, triangles and such. (esp. to allow progs to use them and make that newer svgalib see if they work on that card or not).
But nothing more. If we make a full featured API it will also end up adding much overhead. Then one could just use X. We do not want that. An svgalib application doesn't do much line grafix. Then you could just use X. It sets a mode and gets direct screen access. Maybe uses the accelerator for a few basic screen blits.
If a complex API is designed nevertheless, it should be compatible to something. Apart from an obvious binary compatible svgalib API emulator for old apps. I'd suggest Open/GL. It is THE standard. The world does not need yet another graphics API. But when Open/GL apps run out of the box we can only benefit.
Also talk to people writing commercial games and ask what they want. I already heard that Win's Games API (DirectX) sucks. We should do better, so ask people what they need.
Also people, I'm sorry to say, but talking and talking about it doesn't help either. I know, you read about suggestions and want to send me your comments, but just discussing doesn't help. And if you don't want to code anything and never coded something, your opinions are easily wrong and it just wastes time to read them and esp. answering or discussing them because it yields nothing.
It just reminds me of the endless GGI discussions about how a system call to draw a filled polygon might look when there was no working GGI at all and not even a concept to talk to an accelerator, nor anyone knowing the singlest bit about a graphics accelerator. Still, everyone thought he knew how the syscall must look for optimal performance (easy implementation) & best use to the application. Oh, this was now two years ago. GGI still does not support a call to draw a filled polygon using the accelerator, BTW. Great!
Also, people may not like it, because it is common for Unix to say that just X is it. I don't like to code things for the waste basket or to get yelled at as being a jerk for coding it.
On the other hand, now writing this down did again interest me in it, I might just go and start writing it again as my time permits. Just to show myself it will work, and then give it to the public. Maybe someone likes it, maybe not. After all, if Linus announced what Linux is now when he wrote that first multitasking kernel which printed A's in one and B's in the other task, people would have put him in a padded cell too.
He just liked to play around with it and to show that it could be done maybe. This is what Linux is: Playing around and showing it can be done. Not install a CD and flood the internet with wisdom how it could be improved without ever coding a line or just yell at each other.
And actually, reapplied on this FAQ it makes itself pointless. I'm sorry for that, but I get these questions asked again and again. So, I'll stop blathering here. This is all I had to say.
Linux, just do it.