| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2811.1 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Fri May 25 1990 09:49 | 11 |
|
The DECwindows output drivers do not do output. They do a couple real
simple management jobs - like allocate the device. All the real work
is done by the server which directly talks to the device.
If you want to talk directly to the hardware through a driver - try
VADRIVER from VWS and/or the DOP interface. There is a VCB02
technical manual - I don't have the order number offhand.
_Fred
|
| 2811.2 | Purpose and use of the QIOs? | CSC32::R_SOMBERG | | Fri May 25 1990 11:52 | 12 |
| Thanks for the reply. I think I missed the point. There are few
comments in chapter 6 that may seems that the output driver talks with
the hardware, e.g. in 6.1 "The output driver for a color (GPX)
workstation interprets direct memory access (DMA) packets from the
server and presents the packet data to the graphics hardware."
and "The driver may contain routines, macros, and services to execute
draw requests, copy data between dost memory and video memory,...".
So what is the purpose and use of the three QIOs documented in this
chapter?
Thanks, Reuven.
|
| 2811.3 | | STAR::KLEINSORGE | Fred Kleinsorge, VMS Development | Fri May 25 1990 12:23 | 9 |
| Isn't it obvious, ALL workstations require a device driver, the
VMS/DECwindows architecture *requires* it :-)
Seriously, from my looking into the servers a while back, everything
of any interest is done in the DDX layer of the server. Very, very
little is done in the device driver. But someone in the server group
could give you a specific answer about what things are actually done
by the driver.
|
| 2811.4 | | STAR::MCLEMAN | Jeff McLeman, VMS development | Fri May 25 1990 14:12 | 4 |
| From what I understand, the output driver does things like load the color
map, cursor, and feeds the raw hardware with data from the DDX.
Jeff
|
| 2811.5 | | CSC32::R_SOMBERG | | Fri May 25 1990 15:15 | 2 |
| So when and how to use those three qios documeted in chapter 6.
|
| 2811.6 | | PAXVAX::MIANO | My parents think I'm in college | Fri May 25 1990 16:06 | 17 |
| > The DECwindows output drivers do not do output. They do a couple real
> simple management jobs - like allocate the device. All the real work
> is done by the server which directly talks to the device.
Wait a minute. The GPX servers do NOT access the hardware directly. All
the smarts for doing this is in the driver. The server figures out what
needs to get done and packetizes the information. The packets are
inserted on an interlocked queue and the driver removes them (this is
where the GPD and GPB's come in). The driver then parses the packets
and does what is necessary to the hardware.
The same is not true of other servers. The SPX and MFB servers DO
access the hardware directly. These drivers are pretty dumb -- their
main purpose is to perform the vertical sync functions and other
managment functions described in other notes (cursor, etc).
I'm sorry; I have no information about the QIO's in chapter 6.
|
| 2811.7 | | CSC32::R_SOMBERG | | Fri May 25 1990 19:28 | 2 |
| Thanks for .6 -- I'll do some 'digging' around to find out the
structure of GPD & GPB (as they are not in appendix A) and the QIOs.
|