Video Driver Questions

Hi,
I am working with modifying the DDK Mirror Driver sample, and have
seen some interesting behaviors that I don’t understand.
When I attempt a user-mode BitBlt() from the mirror’s DC, the call
doesn’t result in a call to DrvCopyBits() in my driver (at least not
directly). The call that actually provides the core functionality is
EngCopyBits() in win32k.sys. I did specify HOOK_BITBLT and HOOK_COPYBITS
(and the other rendering functions) for the hooks set by
EngAssociateSurface() in DrvEnableSurface().
So why is the CopyBits call handled by the GDI Engine instead of my
driver?

Also, I hooked all the rendering functions in this mirror driver, and
coded them all to return TRUE (so that it would look my driver drew to
the surface when, in fact, it hadn’t done anything), and I then
performed the BitBlt() to a compatable DC and then wrote the bitmap
contents out to a file. Since all rendering functions were returning
TRUE, but not actually drawing to the mirror surface, I expected this
“screen shot” to be blank (all black), but it was a regular screen shot.
Obviously, my driver is not what’s drawing to the mirror surface, even
though it is hooking all rendering calls.
Does anyone know why the driver isn’t hooking & handling the calls as
expected?

Erik

P.S. The DrvXxx calls (including DrvCopyBits() and DrvBitBlt() are
invoked part of the time, but not in the case I explained above. The
times they are invoked, though, are never a result of the BitBlt() call
from the DDK sample mirror app (ddmlapp.exe). Also, the call where I
copy the bytes from the mirror surface to a compatable DC looks like
this:

HDC hdc = CreateDC(“DISPLAY”,
deviceName, // is:“\.\DISPLAY2”, obtained
from EnumDisplayDevices()
NULL,
NULL);

// we should be hooked as layered at this point
HDC hdc2 = CreateCompatibleDC(hdc);

// call DrvCreateDeviceBitmap
HBITMAP hbm = CreateCompatibleBitmap(hdc, GetDeviceCaps(hdc,
HORZRES), GetDeviceCaps(hdc, VERTRES));

SelectObject(hdc2, hbm);

BitBlt(hdc2, 0, 0, GetDeviceCaps(hdc, HORZRES),
GetDeviceCaps(hdc, VERTRES), hdc, 0, 0, SRCCOPY);

CreateBMPFile(“C:\Working\MirrorDriver\Screenshot-Mirror.bmp”,
CreateBitmapInfoStruct(hbm), hbm, hdc2);

Erik,

in the docs it says that DrvCopyBits is called as a “function that
translates between device-managed raster surfaces and GDI standard-format
bitmaps.” if you use EngAssociateSurface, it is not device managed but
engine managed. to get a device managed surface you must use
EngModifySurface and provide the surface details to the engine so that it
knows that it is device managed. EngAssociateSurface tells the GDI that it
can do the drawing for you. Since you tell it that it can do the drawing,
why would it call you for these parts? So to get these calls, implement
DrvCreateDeviceBitmap and DrvDeleteDeviceBitmap and then you will be called
for the bitmaps, then you will have the behavior you expect. If I remember
correctly, if you don’t implement these properly, you will crash the
machine: BSOD because the pointers are invalid that you give back. There is
a lot of work to implementing DDB, so think about this first.

Jeff

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Shaw, Erik
(Xetron)
Sent: Monday, July 18, 2005 3:05 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Video Driver Questions

Hi,
I am working with modifying the DDK Mirror Driver sample, and have
seen some interesting behaviors that I don’t understand.
When I attempt a user-mode BitBlt() from the mirror’s DC, the call
doesn’t result in a call to DrvCopyBits() in my driver (at least not
directly). The call that actually provides the core functionality is
EngCopyBits() in win32k.sys. I did specify HOOK_BITBLT and HOOK_COPYBITS
(and the other rendering functions) for the hooks set by
EngAssociateSurface() in DrvEnableSurface().
So why is the CopyBits call handled by the GDI Engine instead of my
driver?

Also, I hooked all the rendering functions in this mirror driver, and
coded them all to return TRUE (so that it would look my driver drew to
the surface when, in fact, it hadn’t done anything), and I then
performed the BitBlt() to a compatable DC and then wrote the bitmap
contents out to a file. Since all rendering functions were returning
TRUE, but not actually drawing to the mirror surface, I expected this
“screen shot” to be blank (all black), but it was a regular screen shot.
Obviously, my driver is not what’s drawing to the mirror surface, even
though it is hooking all rendering calls.
Does anyone know why the driver isn’t hooking & handling the calls as
expected?

Erik

P.S. The DrvXxx calls (including DrvCopyBits() and DrvBitBlt() are
invoked part of the time, but not in the case I explained above. The
times they are invoked, though, are never a result of the BitBlt() call
from the DDK sample mirror app (ddmlapp.exe). Also, the call where I
copy the bytes from the mirror surface to a compatable DC looks like
this:

HDC hdc = CreateDC(“DISPLAY”,
deviceName, // is:“\.\DISPLAY2”, obtained
from EnumDisplayDevices()
NULL,
NULL);

// we should be hooked as layered at this point
HDC hdc2 = CreateCompatibleDC(hdc);

// call DrvCreateDeviceBitmap
HBITMAP hbm = CreateCompatibleBitmap(hdc, GetDeviceCaps(hdc,
HORZRES), GetDeviceCaps(hdc, VERTRES));

SelectObject(hdc2, hbm);

BitBlt(hdc2, 0, 0, GetDeviceCaps(hdc, HORZRES),
GetDeviceCaps(hdc, VERTRES), hdc, 0, 0, SRCCOPY);

CreateBMPFile(“C:\Working\MirrorDriver\Screenshot-Mirror.bmp”,
CreateBitmapInfoStruct(hbm), hbm, hdc2);


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com