There’s zero non-Microsoft documentation on how to write a display driver,
not that I know of. The DDK documentation is pretty decent and it talks
about a lot of the things you will need. There’s one precious volume that’s
been long out of print, which has a pretty decent explanation on Rops: eons
ago Microsoft used to ship little blue and white booklets with their
software, and they shipped the Windows 3.0 DDK with a “Device Drivers
Writing Manual”, or some other name that looks like that. That booklet had a
real nice explanation of ROPs and stuff.
One other source of real information, which even today I would recommend to
people starting in the art, is the IBM 8514 Windows 3.1 or Win95 driver
source - that is, if you can get hold of it. The Win95 8514 driver listing
had a lot of stuff implemented, and it had a 'Rop compiler" in it, that
source code has a lot of information.
But let me abuse of the goodwill of the NTDEV readers and see if I can
explain ROPs to you.
When you do a BitBlt, there’s three entities involved: the source bitmap,
the destination bitmap, and a repetitive pattern. Call it S, D and P. Now,
each bit of each pixel can be a 0 or a 1 (Rops work bit by bit). So, if you
think of a bit blt as a function of three Boolean variables (P, S and D),
there are 256 such functions, you get them by building a truth table: the
output of the function is the bit that goes out to the destination. For
example take Rop 0xCC, which is a straight Source to Destination Copy:
P S D Result
1 1 1 1
1 1 0 1
1 0 1 0
1 0 0 0
0 1 1 1
0 1 0 1
0 0 1 0
0 0 0 0
If you read the Result column, you will see that binary 11001100, or hex CC,
is the same as if we copied the source to the Result: that is, R=S. As
another example, ROP 0xF0 is what we call a “Pattern Blt”, which is, copy
the pattern into the destination:
P S D Result
1 1 1 1
1 1 0 1
1 0 1 1
1 0 0 1
0 1 1 0
0 1 0 0
0 0 1 0
0 0 0 0
You see that binary 11110000, which is hex F0, is basically copying the
pattern into the result. You see that there are 256 combinations of bits
possible for the Result, leading to 256 different Raster Operations. Another
example, if you wanted a Rop that does an AND of source and destination,
S&D, you would write:
P S D Result
1 1 1 1
1 1 0 0
1 0 1 0
1 0 0 0
0 1 1 1
0 1 0 0
0 0 1 0
0 0 0 0
Which is Rop 0x88. If you need a masked invert using the pattern as a key,
you would code
P S D Result
1 1 1 0
1 1 0 1
1 0 1 0
1 0 0 1
0 1 1 1
0 1 0 0
0 0 1 1
0 0 0 0
That is, Rop 0x5A. And so on. These different bit combinations, of course,
lead to a number of pretty nifty graphics effects. The spec says that the
output of a BitBlt is the result of applying the Rop, on a bit by bit basis,
on the Source, Pattern and Destination bits, to get the required result.
If you know a bit of logic design, you may see that Rops can be implemented
rather economically with sets of multiplexers driven from a “Rop Register”
which will contain the Rop code. So, your typical contemporary graphics chip
will implement all 256 Rops in hardware.
The difference between GDI managed surface or Driver managed surface is
whether the GDI is able to directly write to the surface, or whether it must
go through the driver. So, in a driver managed surface, the GDI does not
know the format of the surface, hence it cannot write to it - it must ask
the driver to write to the surface, which may involve asking the hardware
chip to do it. The Windows graphic subsystem supports a number of
lower-level calls (EngXxxxYyyy) which assume a certain number of GDI-known
pixel formats: if your surface is compatible with those, the GDI can write
to your surface. This simplifies writing a driver, because you get a kind of
a “safety net” of calls you can eventually punt to, that is, provided that
those routines understand your surface’s format. If not, you must implement
the whole nine yards.
There’s a huge amount more behind these simple-minded explanations ! I
suggest you read the DDK documentation and wade through the source listings,
or, if you can, get hold of an ancient DDK where you will find drivers
written for chips that implement way less functionality than today’s
sophisticated all-singing all-dancing graphics chips - those old listings
might show you a trick or two that you won’t find documented in a modern
driver.
Hope this helps !
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Rick Jones
Sent: Thursday, April 08, 2004 9:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Writing a display driver
I’m trying to create a virtual display driver i.e. a bitblt/copybit of raw
bitmaps. I’ve read the DDK and looked at the sample code. I have written
drivers before, but not a display drive. The DDK does a fairly good job
describing the GDI/DDI architecture, but some things are just not obvious.
For example the DrvBitBlt, and how ROPs are used or even what the raster
operands used/defined are. Also how I define my surface object (GDI managed
or driver managed). Is there any other documentation that describes how to
write a display driver, or white papers that someone can point me at?
Thanks,
Rick
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.