Date: Sat, 17 Dec 94 14:48:57 MST From: terry@cs.weber.edu (Terry Lambert) To: kurto@tiny.mcs.usu.edu, sos@kmd-ac.dk Cc: hackers@freebsd.org, mark@grondar.za Subject: Re: Using graphics under syscons (src) Message-ID: <9412172148.AA23962@cs.weber.edu>
next in thread | raw e-mail | index | archive | help
Soren writes: > > Also in a previous message you mentioned that directly going to the hardware > > required root privs. How about extending syscons to support a more general > > VGA driver with ioctl's for setting various VGA registers, this would allow > > for mode-x programming, etc. > > Hmm, the problem is one have to decide where to stop this, you VERY > quickly get into situations where you have to treat diffent VGA chips > differently, and I have _*NO*_ intention of trying to support all > possible video hardware (try ask the XFree guys about this :-) > I do however see that we need a way of allowing writes to the VGA > registers of "normal" hardware. As I remember the ibcs/sysv ioctl > set has some functions for this. The problem here is speed, if you > wan't "live" graphics you want speed over security, and then you > HAVE to have access directly to the hardware so you will need root > privs. Another way was to allow access to specific port numbers, > but I dont think the kernel supports this at this time (or if it > ever will). Another way to allow access to the ardware directly is using a mapping into the applications virtual address space of the device memory or device memory backing store (depending on if the application on a particular virtual console owned the real console), with the backing store being used instead of the device memory if the thing didn't own the real hardware. This gets around the mapping aspect of the "root priveledges" problem. The other component of the "root priveledges" problem is modifications to hardware state by knowledge of registers/state control through ports, as wired into particular programs. This requires a hardware abstraction. By default, I agree with Soren; the support of special modes for VGA chips is too complex to use by default. HOWEVER, the modes are not "too difficult period", just "too difficult for this to be the default behaviour". This is a subtle distinction. The suggestion I would make would be to abstract the VGA interface from the card interface. In its simplest form, this would result in knowing the contents of typically write-only registers so that mode settings could always be restored *IF* the mode setting was done through the abstraction. The second level of support would include emulation of VGA modes and SupreVGA by way of an INT-10 abstraction interface using a VM86() call of some kind. Thus it would be possible to select modes from a list of available modes without wiring explicit knowledge of the hardware into a driver -- the trade of being the requirement for VM86() support. A third level of support could be obtained by providing a kernel environment emulation framework. This sounds more complicated than it is. Basically, you provide an environment so that NT and Windows 95 (both protected mode OS's) video drivers *think* they are running in their native environment. Then you simply use manufacturer supplied drivers. The upshot is that the actual work done in all these cases does not include card-specific drivers. There *ought* to be the possibility of card specific drivers, however -- what I have, in the past, called "moving DDX into the kernel". The end result of the majority of this work would be the ability to remove knowledge of specific cards from, among other things, generic X support, and to abstract it from the console code (there is currently a limitation on the support of loading ISO8859-1 character sets on console hardware that I believe should be removed). As a final incentive for change,DOS emulation and things like "DOOM" require access to the hardware. But do they really? What they want is something that looks to the program like it has access to the hardware. In reality, what it wants is the top level of the hardware abstraction; but in fact, the underlying driver could be any user supplied driver. Including a driver that acted as a client to X, or one that mapped a region of a cards linear frame buffer as a VGA card, and allowed relocation of the origin of the rectangle within X by virtue of window geometry notification... the applications for video under X and mpeg/quicktime/CDTV should be obvious. Finally, a library front end to the abstraction, in the form of a callable "INT10(3)" interface would make porting from DOS simplistic. > > ps - as far as a game I would like to see, how about practically any > > of the older arcade games. especially joust, any pacman, etc. > > This tend to be the trend in all answers I've got :-) Star Castle! 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9412172148.AA23962>