EngLockSurface / Graphics Driver question

NTDEV
1

Hi all.
I’m currently having a problem when debugging 2 graphics drivers…
Essentially the problem occurs in the following scenario in the
DrvEnableSurface entry point:

  1. Call EngCreateDeviceSurface, passing a DHSURF value
  2. Send the return value (HSURF) from EngCreateDeviceSurface to
    EngLockSurface
  3. Try and reference the resulting SURFOBJ’s dhpdev member

Now in one driver, this works fine, and EngLockSurface returns a SURFOBJ
with the correct dhpdev value set (to the PDEV pointer I returned from
DrvEnablePDEV).

In the other driver, the dhpdev value is not the correct pointer.
Instead it is a pointer to some internal (undocumented) GDI structure…

In the driver that works correctly, the DrvEnableSurface entry point is
called directly from win32k!PDEVOBJ::bMakeSurface. However in the failing
driver, win32k!PDEVOBJ::bMakeSurface calls win32k!PanEnableSurface. The
function that is called depends on a value in a function table, and I
haven’t traced where it is set yet…

Now for the interesting tidbit:
PanEnableSurface calls DrvEnableSurface, and then takes the return value
from DrvEnableSurface and calls EngLockSurface on the HSURF. Once the
EngLockSurface routine has completed, PanEnableDriver manually sets the
SURFOBJ dhpdev pointer to the correct value. So I’m guessing that
Microsoft (or perhaps someone else) knows of this oddity and why it
would happen…

So I guess my question is to see if anyone knows:

  1. Why would PanEnableSurface be called instead of the driver’s
    DrvEnableSurface entry point directly? (I thought it was related to the
    GCAPS_PANNING flag, but both drivers set this flag).
  2. The reason behind EngLockSurface’s two different behaviors?

Thanks for the help!

sean