From: Karsten Petersen <karsten.petersen@informatik.tu-chemnitz.de>
  To  : GGI <ggi-develop@eskimo.com>
  Date: Fri, 17 Jul 1998 13:23:55 +0200 (CEST)

scitech and linux

Hi!

sorry for spamming the list again, but i think this is somewhat important.

forwarding
Karsten aka TI

EMail:  kapet@informatik.tu-chemnitz.de
  WWW:  http://www.tu-chemnitz.de/~kapet/
 Talk:  kapet@dollerup.csn.tu-chemnitz.de
 Fido:  2:249/5050.19

---------- Forwarded message ----------
Date: Thu, 16 Jul 1998 18:49:30 -0800
From: Kendall Bennett <KendallB@scitechsoft.com>
To: linux-kernel@vger.rutgers.edu
Cc: Linus Torvalds <torvalds@transmeta.com>,
    Josh Vanderhoof <joshv@planet.net>
Subject: V86 BIOS works; but we need an IOPL solution!!

Hi all,

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