Writing display drivers.

[Rick Jones]

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

 

[Dave August]

Ahhh Display Drivers..

Walter could(should?) write another book about these.

Sadly Display Driver work is still pretty black magic, you almost have to
been doing then since 3.11 to 'grok' what's happening. Wait till you get
apps that send you a ROP where the RPN is different from the number

Good luck.

Dave August

 

[Calvin Guan]

Ahhh Display Drivers..That's was terrible. One can't imagine how huge it is until he/she has
accessed to the source code.

-
Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

 

[Tim Roberts]

Ahhh Display Drivers..

Walter could(should?) write another book about these.

Sadly Display Driver work is still pretty black magic, you almost have to
been doing then since 3.11 to 'grok' what's happening. Wait till you get
apps that send you a ROP where the RPN is different from the number

Fortunately, Windows NT eliminates the RPN half of the ROP. The driver
just gets the ROP byte.

Your basic GDI driver is not all that hard to handle. The problem is that
a driver today has to handle a raft of extra stuff (DirectDraw, Direct3D,
transparency) that truly is black magic.

 

[Tim Roberts]

I'm trying to create a virtual display driver i.e. a bitblt/copybit of raw
bitmaps.

May I ask what problem you are trying to solve? In many cases, it can be
easier to do this with a simple user-mode app, doing periodic BitBlts
straight from the desktop surface.

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.

Raster operations are basically Boolean functions that define how the three
participants in a bitblt (source, pattern, destination) are defined. Given
three binary sources, there are 8 ways to combine them.

D S P | Result
-------------------
0 0 0 |
1 0 0 |
0 1 0 |
1 1 0 |
0 0 1 |
1 0 1 |
0 1 1 |
1 1 1 |

For each combination, you decide what you want the resulting bit value to
be when that combination is encountered. The ROP is the resulting set of
bits, read from bottom to top.

Let's say, for example, that we want the final result to be the source
pixel XORed with the destination pixel:

D S P | Result
-------------------
0 0 0 | 0
1 0 0 | 1
0 1 0 | 1
1 1 0 | 0
0 0 1 | 0
1 0 1 | 1
0 1 1 | 1
1 1 1 | 0

Reading from the bottom (even though this is a palindrome), the result is
0x66, and that is the ROP for D-XOR-S.

To copy the source straight into the destination, the ROP is 0xCC. That's
SRCCOPY. To invert the destination, the ROP is 0x55. That's DSTINVERT.

Although all 256 are possible, only about 10 are encountered in normal
system use, and 5 account for 90% of all blits (CC, F0, 55, 5A, B8).

Also how I define my surface object (GDI managed or driver managed).

If your surface looks like a DIB, then you almost certainly want to let GDI
do most or all of the actual drawing. That means GDI-managed.

 

[Rick Jones]

Tim,

I need to do this a display driver. I want the raw bitmap or series of
bitmap (not DIB format) of the screen based on the drawing requests from
GID.

Rick

 

[Tim Roberts]

I need to do this a display driver. I want the raw bitmap or series of
bitmap (not DIB format) of the screen based on the drawing requests from
GID.

Again, this still doesn't say what you are actually trying to do. All this
says is how you think you need to do it. Tell us what you are trying to
construct; perhaps one of us can come up with an easier solution.

What bitmap format are you using that is not a DIB? As long as you have an
RGB format where the scanlines are multiples of dwords, it is a DIB. You
really, really, really want to arrange things so that GDI can do the
drawing, and that means making your frame buffer a DIB. Even if you have
to translate it to, for example, YUV, you would still be better off making
the frame buffer a DIB.

 

[vipin aravind]

BTW Is it difficult to write a filter driver on top of display drivers? So
it can filter out the information.

vipin

 

[Tim Roberts]

BTW Is it difficult to write a filter driver on top of display drivers? So
it can filter out the information.

Yes, it is difficult. GDI drivers are not WDM drivers, so the
LowerFilter/UpperFilter thing does not apply. Instead, you have to BECOME
the primary display driver, and load the original display driver by hand.

It's a pain.

 

[vipin aravind]

I work on printer drivers and its so easy to do there both in the NT4 kernel
mode and 2k and above user-mode printer drivers.
So I was wondering why it won't be the same way for display drivers because
the entry points supported are the same for both with the
exception that some entry points for the display drivers aren't applicable
in case of printer drivers.
thank you
vipin

 

[Lev Kazarkin]

Tim is quite correct. It's a tough job to hook
the real hardware video driver.
The hook is also prone to problems induced by
video hardware/driver replacement.

But why not to try so called mirror driver?
It is not bound to particular primary (secondary either)
video driver. More important is a fact that mirror driver
may intercept all rendering done to the screen.
Hence it knows the exact update region each time.
Thus we no longer have to continually poll and grab the
entire screen. We always know when the update is needed
and what is the exact upate region.

By the way, this is the approach used by VNC applications
(NetMeeting, for example). Furthermore, this technology may open
invaluable opportunities for ultimate optimization to the
process if desktop updates are to be posted over
a network or recorded.