We have now completed the work on getting the V86 real mode BIOS
support working for our drivers, and hence now have a complete,
functioning version of our SuperVGA Kit graphics library for Linux.
Soon we expect to get our SciTech MGL Graphics Library running under
Linux as well (both it and the SuperVGA Kit are free with source
code). Now that we have the core components ported across, this means
that we will now be able to bring our SciTech Display Doctor device
driver technology across to Linux also allowing Linux to support
virtually every graphics card on the market and that has shipped in
the past.
However there is one big snag in all this, and that is that due to
the 0x3FF I/O port bitmap limitation in the current Linux kernels,
the V86 mode BIOS functions fault when I/O ports higher than 0x3FF
are accessed. The code we used (based on Josh Vandehoof's Linux Real
Mode Interface) emulated I/O instructions for I/O ports that cause a
fault, however this emulation code is too slow for BIOS code that is
executing timing sensitive loops. One of the most common cards in
question is ATI based graphics cards, and I have tested the latest
3DRage Pro PCI and AGP boards. With emulated I/O the BIOS on these
cards fails.
To determine if the I/O port emulation was indeed the cause of the
problem, I hacked up my version of the 2.0.35 kernel to support an
8Kb I/O bitmap size. Once I got past the hurdles of making this work
and fixing some bugs in the ioperm() system call, I verified that the
ATI BIOS does indeed work properly when full I/O access is granted to
the V86 task.
So now we are faced with the problem that in order to allow our
software to function 100% under Linux, many users will need to
compile a custom version of the kernel from patches that we supply.
Ideally we would like to avoid this problem if at all possible, by
finding a valid solution to the problem and having it included in the
standard kernel distributions. So what is the solution? The only
plausible solution to this problem is to modify the kernel such that
the task running V86 code can have it's I/O bitmap extended to the
full 8Kb while the remainder of the kernel continues to use the
smaller 0x3FF I/O port bitmap range. I don't think we really want the
kernel to be bloated such that every task gets a full 8Kb I/O bitmap
(as my current patched kernel does).
So I am proposing that such a project be started and somehow get
accepted into the standard kernels. To start with people with more
knowledge than me are going to have to either code this new
functionality, or provide me with pointers on how to go about
modifying the kernel sources to support such a feature.
So, comments, suggestions and criticisms please??
BTW: The ATI 3DRage Pro cards are the same ones that have caused
problems when I tried to run VESA graphics modes under the DOSEMU
emulator. Hence I suspect that if this is fixed in the kernel
graphics support for DOSEMU programs will be greatly enhanced which
would be a good thing.
Regards,
+--------------------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+--------------------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+--------------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html