Date: Mon, 19 Dec 1994 08:50:05 +0000 (GMT) From: "Soeren Schmidt" <sos@kmd-ac.dk> To: terry@cs.weber.edu (Terry Lambert) Cc: kurto@tiny.mcs.usu.edu, sos@kmd-ac.dk, hackers@freebsd.org, mark@grondar.za Subject: Re: Using graphics under syscons (src) Message-ID: <199412190749.AA25920@dkuug.dk> In-Reply-To: <9412172148.AA23962@cs.weber.edu> from "Terry Lambert" at Dec 17, 94 02:48:57 pm
next in thread | previous 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.
Yes, this would work for "normal" VGA modes (ie. less then 64K memory).
>
> 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.
You're kidding right :-)
>
> 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.
Hmm, this is kind of what syscons supports now, it does all the
"standard VGA" things and modes, and can restore a known state if these
restrictions is held. BUT if one uses a "unknown card specific SVGA mode"
then it gives up. You can allways write a routine that works for your
card in a higher res then...
> 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.
Yes, I've thought about that too, only one problem remains, the selection
of memory, many BIOS'es dont have a function to do bankselecting etc..
> 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.
This could be a way forward, anybody having some docs on this ??
> 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.
Yes, they do !! Emulation at this level would slow down things to a halt...
> 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.
Indeed, this would make life simpler.
0
>
> > > 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-).
Notet !
>
> Terry Lambert
> terry@cs.weber.edu
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Soren Schmidt (sos@FreeBSD.org | sos@kmd-ac.dk) FreeBSD Core Team
So much code to hack -- so little time
..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199412190749.AA25920>