EngCreateBitmap <-> Pointer to bitmap bits

[Sadik Oezkul]

I use in my display driver the EngCreateBitmap function. I want to
create an engine managed surface and want all drawing operations done
by the GDI (via EngXXX functions)

HBITMAP EngCreateBitmap(
IN SIZEL sizl,
IN LONG lWidth,
IN ULONG iFormat,
IN FLONG fl,
IN PVOID pvBits);

My problem is: I want to use the bitmap bits pointer in my user mode
application. How can I use the last parameter pvBits in a user mode
application?

1) Should I allocate the memory in the user mode and somehow give the
pointer to the display driver?

2) Should I allocate the memory in the driver (via shared memory using
export dll for example)? How should I reference this pointer in the
user mode application in this case?

3) Does GDI allocate this memory for me? In that case, how can I
give/use this pointer to/in my application?

Thanks

My code:

HSURF APIENTRY DrvEnableSurface(
DHPDEV dhpdev)
{
PPDEV ppdev;
HSURF hsurf;
DHSURF dhsurf;

SIZEL sizl = { cx,cy};

ppdev = (PPDEV) dhpdev;

ppdev->hsurfEng = (HSURF) EngCreateBitmap(sizl, sizl.cy,
BMF_16BPP, BMF_TOPDOWN,
pProblemBuffer); <----------

if (ppdev->hsurfEng == NULL)
{
return NULL;
}

EngAssociateSurface(ppdev->hsurfEng, ppdev->hdevEng,
HOOK_BITBLT | HOOK_STRETCHBLT | HOOK_TEXTOUT |
HOOK_STROKEPATH);

return ppdev->hsurfEng;
}

[Maxim S. Shatskih]

Applications can only use the surfaces which they asked to be created, not
some surface created by the driver at driver's will.
So, the app must be coded to call CreateBitmap or CreateCompatibleBitmap
and then draw on it.
CreateBitmap creates an engine-managed surface in the app's memory.
CreateCompatibleBitmap first calls DrvCreateDeviceBitmap to create a
driver-allocated surface, and, if this fails - then it falls back to the same
as CreateBitmap.

I can hardly imagine why EngCreateBitmap is ever needed. Using it inside
DrvCreateDeviceBitmap is the same as not implementing DrvCreateDeviceBitmap at
all :). And, besides this use, the bitmap created by EngCreateBitmap cannot be
exposed to user mode.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

"Sadik Oezkul" <soe...@gmx.net> wrote in message
news:80baa752.05040...@posting.google.com...

[vipin]

You may want to have a custom escape defined in the driver to get the data
transferred out via ExtEscape.

Hope this helps
Vipin

"Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
news:d30d0e$22k1$1...@gavrilo.mtu.ru...

[Ivan Brugiolo [MSFT]]

While that suggestion would work, I guess the original poster
wants a Drv-Managed SURFOBJ, so that he can fetch the bits
from an application, or from one other driver.
I can see this having interesting applications for Mirror Drivers
and for remoting the display driver operations

In your DrvEnableSurface you could create a section via NtCreateSection,
and, subsequently, map the section in the system space for regular
EngXXX operations, and, map that in user-mode via some
DrvEscape/DrvDrawEscape.
Once the section is mapped, you can call EngCreateBitmap
to get the SURFOBJ with the "private" pvbits.
That would still be a STYPE_BITMAP SURFOBJ
Then, you can create a STYPE_DEVICE SURFOBJ,
with EngCreateDeviceSurface, and associate that with the STYPE_BITMAP
surfobj.

This way win32k.sys will call the Driver for the callbacks
specified in the EngCreateDeviceSurface, and, in each of the implemented
DrvXXX functions,
you can punt-to-Eng using the STYPE_BITMAP SURFOBJ.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"vipin" <vi...@nospam.com> wrote in message
news:uOrXKby...@TK2MSFTNGP10.phx.gbl...

[Sadik Oezkul]

What I want is:
- I want that all drawing operations are done by GDI (via EngXXX fncs)
- But at the same time I want to hook all these drawing commands by
passing my hooking flag to EngAssociateSurface.

What will be the difference between the following 2 methods? They are
both running in my case. But I didn´t understand the clou in using the
command EngCreateDeviceSurface in addition to EngCreateBitmap.

Method 1)
HSURF APIENTRY DrvEnableSurface(DHPDEV dhpdev)
{

ppdev->hsurfEng = (HSURF) EngCreateBitmap(sizl, sizl.cy,
BMF_16BPP, BMF_TOPDOWN,

pBitsBuffer);

if (ppdev->hsurfEng == NULL)
{
return NULL;
}

EngAssociateSurface(ppdev->hsurfEng, ppdev->hdevEng,
HOOK_BITBLT | HOOK_STRETCHBLT | HOOK_TEXTOUT | HOOK_STROKEPATH);

return ppdev->hsurfEng;
}

Method 2)
HSURF APIENTRY DrvEnableSurface(DHPDEV dhpdev)
{

ppdev->hsurfEng = (HSURF) EngCreateBitmap(sizl, sizl.cy,
BMF_16BPP, BMF_TOPDOWN,

pBitsBuffer);

if (ppdev->hsurfEng == NULL)
{
return NULL;
}

hsurf = EngCreateDeviceSurface(ppdev->hsurfEng ,
sizl,
BMF_16BPP);

EngAssociateSurface(hsurf, ppdev->hdevEng,
HOOK_BITBLT | HOOK_STRETCHBLT | HOOK_TEXTOUT | HOOK_STROKEPATH);

return hsurf;
}

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<Ohga2B8...@TK2MSFTNGP12.phx.gbl>...

> While that suggestion would work, I guess the original poster
> wants a Drv-Managed SURFOBJ, so that he can fetch the bits
> from an application, or from one other driver.
> I can see this having interesting applications for Mirror Drivers
> and for remoting the display driver operations
>
> In your DrvEnableSurface you could create a section via NtCreateSection,
> and, subsequently, map the section in the system space for regular
> EngXXX operations, and, map that in user-mode via some
> DrvEscape/DrvDrawEscape.
> Once the section is mapped, you can call EngCreateBitmap
> to get the SURFOBJ with the "private" pvbits.
> That would still be a STYPE_BITMAP SURFOBJ
> Then, you can create a STYPE_DEVICE SURFOBJ,
> with EngCreateDeviceSurface, and associate that with the STYPE_BITMAP
> surfobj.
>
> This way win32k.sys will call the Driver for the callbacks
> specified in the EngCreateDeviceSurface, and, in each of the implemented
> DrvXXX functions,
> you can punt-to-Eng using the STYPE_BITMAP SURFOBJ.
>
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>

[Ivan Brugiolo [MSFT]]

In the EngCreateDeviceSurface case, your display driver receives
whatever you passed to as the DHSURF param as the SURFOBJ::dhsurf.
This creates an extra indirection level for your DrvXXX calls.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Sadik Oezkul" <soe...@gmx.net> wrote in message

news:80baa752.0504...@posting.google.com...

[Sadik Oezkul]

Does this extra indirection level mean
- a better speed performance
- or the possibility to be called for all GDI drawing operations?

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<uvvT0nc...@tk2msftngp13.phx.gbl>...

[Ivan Brugiolo [MSFT]]

You might measure on your own the performances.

For the second question, I don't follow.
A display driver can implement 92 entry points
(uses for everthing from font management, color dithering, mode changes),
as returned in DrvEnableDriver, and then, it can expose other capabilities,
in different places. For example, you can filter capabilities when you
specify
the Hooks flags in EngAssociateSurface.
Then, there is the problem of mapping between GDI calls and DDI calls,
and the problem of being at all called for GDI calls.
For example, if you have a layered window,
or any other kind of Eng-managed SURFOBJ,
the display driver will not be called at all.
Certain GDI calls are translated in internal Eng calls, so that the display
driver will have only a final DrvBitBlt call.
Many GDI calls maps always to few DDI calls.
If your purpose it to be called for every GDI call, then, probably
the display driver is not the best place to sit.
This does not consider or account for DirectDraw/Direct3d operations,
where your Display Driver might not be called at all.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Sadik Oezkul" <soe...@gmx.net> wrote in message
news:80baa752.0504...@posting.google.com...

[Sadik Oezkul]

Sorry.
I´m trying to understand the purpose of using this extra indirection
level and the advantages of this method over the first method
(EngCreateBitmap + EngAssociateSurface vs. EngCreateBitmap +
EngCreateDeviceSurface + EngAssociateSurface).

In which method does GDI map the calls to fewer DDI calls?
And in which one will the display driver be called for every single
drawing operation?

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<O1PzknpR...@TK2MSFTNGP12.phx.gbl>...

[Ivan Brugiolo [MSFT]]

The extra indirection will not help getting more or less DDI calls,
since that is not the mechanism that controls that.
It's for your convenience in associating a driver-supplied context
to the SURFOBJ.

If you want fewer DDI calls, then just support DrvBitBlt.
All the processing will be made by NtGdi, and then NtGdi will
inform you of the final Blt to the destination SURFOBJ

Forget about the display driver being called for every GDI operation.
The mapping if non straight forward, due to several levels of the
architecture.
You may also have DDI calls that have to explicitely triggered GDI call
(for example, the WindowProc of the desktop window runs in Win32k.sys)

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Sadik Oezkul" <soe...@gmx.net> wrote in message

news:80baa752.05042...@posting.google.com...