How to name a device object in video miniport driver?

OSR_Community_User · March 17, 2005, 12:16am

I am going to have a user-mode application to talk with video miniport
driver by IOCTL. I have to specify the device object name when I use
CreateFile in user-mode application. However, there are no video port
routines that can be used to create a device object. I cannot use
IoCreateDevice either. So I am unable to specify a name for the device
object.

So my question is, how to name a device object in video miniport driver?

Can anyone give me some hints on that? Thank you.

Lei

OSR_Community_User · March 17, 2005, 4:13am

Generally, we solve this sort of situation by wrapping the IOCTL with an
GDI Escape (using the ExtEscape function call, which ends up in your
drivers DrvEscape), so your user applicaiton would call the escape for the
DISPLAY, and the display driver would call the IOCTL using the handle that
we’re given early on in the driver initialization. Thus avoiding actually
exposing a “Video” device, which is not how Microsoft intended things, and
that’s why you can’t call the ioCreateDevice.

–
Mats

xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:

I am going to have a user-mode application to talk with video miniport
driver by IOCTL. I have to specify the device object name when I use
CreateFile in user-mode application. However, there are no video port
routines that can be used to create a device object. I cannot use
IoCreateDevice either. So I am unable to specify a name for the device
object.

So my question is, how to name a device object in video miniport driver?

Can anyone give me some hints on that? Thank you.

Lei

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

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000ECE6

OSR_Community_User · March 17, 2005, 10:16am

Thanks Mats.

Actually, I plan to intercept the GDI calls in a mirror driver. Will
the primary video driver work well if I frequently call ExtEscape? I
just want the communicate with the mirror driver.

I am thinking about allocating a block of memory in miniport driver to
record the GDI function calls. This block of memory is shared with
display driver so that it can put down which DrvXxxx functions are
called. The memory is also shared with a user-mode application, which
polls it to see what happens in the driver.

So I also wonder whether this method will be effective eoungh since
polling may be frequent.

Thank you.

Lei

On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
wrote:
>
>
> Generally, we solve this sort of situation by wrapping the IOCTL with an
> GDI Escape (using the ExtEscape function call, which ends up in your
> drivers DrvEscape), so your user applicaiton would call the escape for the
> DISPLAY, and the display driver would call the IOCTL using the handle that
> we’re given early on in the driver initialization. Thus avoiding actually
> exposing a “Video” device, which is not how Microsoft intended things, and
> that’s why you can’t call the ioCreateDevice.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:
>
> > I am going to have a user-mode application to talk with video miniport
> > driver by IOCTL. I have to specify the device object name when I use
> > CreateFile in user-mode application. However, there are no video port
> > routines that can be used to create a device object. I cannot use
> > IoCreateDevice either. So I am unable to specify a name for the device
> > object.
> >
> > So my question is, how to name a device object in video miniport driver?
> >
> > Can anyone give me some hints on that? Thank you.
> >
> > Lei
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT0000ECE6
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · March 17, 2005, 10:32am

So, if you want to “poll”, why don’t you do it the other way around.
Presumably your mirror driver will be called with the same information as
the ordinary display driver.

So here’s what I’d do:
Create a memory region in the display driver (by calling an IOCTL to your
Miniport, that allocates a suitable memory region and returns the address
for it to your display driver).
Then have the user-mode application call a GDI escape which says “I’d like
to be told when there is some GDI calls to process”.

This GDI escape either takes an event as input, or creates an event that
is passed to the display driver.
The user app then waits for the it’s event.

When a GDI drawing call is made to your display driver, you set the event
after you’ve filled the information into your buffer.

When the application wakes up after the event, it calls another GDI Escape
to “Fetch all GDI calls since last call”. This GDI call also resets the
event flag, so that next call to WaitForEvent (WaitForSingleObject or
whatever you use) will wait again.

Does that sound like something you could use?

This way, the user-mode application isn’t polling to see if anything
changed, only fetching information when something ACTUALLY changed.

There’s a lot that can be done to optimise the above for particular types
of operations, but as a basic principle, I think it would be efficient and
work.

–
Mats

xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:

Thanks Mats.

Actually, I plan to intercept the GDI calls in a mirror driver. Will
the primary video driver work well if I frequently call ExtEscape? I
just want the communicate with the mirror driver.

I am thinking about allocating a block of memory in miniport driver to
record the GDI function calls. This block of memory is shared with
display driver so that it can put down which DrvXxxx functions are
called. The memory is also shared with a user-mode application, which
polls it to see what happens in the driver.

So I also wonder whether this method will be effective eoungh since
polling may be frequent.

Thank you.

Lei

On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
wrote:
> >
> >
> > Generally, we solve this sort of situation by wrapping the IOCTL with
an
> > GDI Escape (using the ExtEscape function call, which ends up in your
> > drivers DrvEscape), so your user applicaiton would call the escape for
the
> > DISPLAY, and the display driver would call the IOCTL using the handle
that
> > we’re given early on in the driver initialization. Thus avoiding
actually
> > exposing a “Video” device, which is not how Microsoft intended things,
and
> > that’s why you can’t call the ioCreateDevice.
> >
> > –
> > Mats
> >
> > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:
> >
> > > I am going to have a user-mode application to talk with video
miniport
> > > driver by IOCTL. I have to specify the device object name when I use
> > > CreateFile in user-mode application. However, there are no video port
> > > routines that can be used to create a device object. I cannot use
> > > IoCreateDevice either. So I am unable to specify a name for the
device
> > > object.
> > >
> > > So my question is, how to name a device object in video miniport
driver?
> > >
> > > Can anyone give me some hints on that? Thank you.
> > >
> > > Lei
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > > ForwardSourceID:NT0000ECE6
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000ED46

OSR_Community_User · March 17, 2005, 10:54am

Great, it sounds like a good way to go. Thank you very much.

I think the most difficult thing in this scheme is that there might be
one or more GDI calls invoked between two GDI escape command sent by
the user-application. So I still have to keep track of what happen
after the previous event is set. How do you think about it.

And another question is will the GDI escape goes to the primary driver
and cause some unexpected error?

Best,
Lei

On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
wrote:
>
>
> So, if you want to “poll”, why don’t you do it the other way around.
> Presumably your mirror driver will be called with the same information as
> the ordinary display driver.
>
> So here’s what I’d do:
> Create a memory region in the display driver (by calling an IOCTL to your
> Miniport, that allocates a suitable memory region and returns the address
> for it to your display driver).
> Then have the user-mode application call a GDI escape which says “I’d like
> to be told when there is some GDI calls to process”.
> - This GDI escape either takes an event as input, or creates an event that
> is passed to the display driver.
> The user app then waits for the it’s event.
>
> When a GDI drawing call is made to your display driver, you set the event
> after you’ve filled the information into your buffer.
>
> When the application wakes up after the event, it calls another GDI Escape
> to “Fetch all GDI calls since last call”. This GDI call also resets the
> event flag, so that next call to WaitForEvent (WaitForSingleObject or
> whatever you use) will wait again.
>
> Does that sound like something you could use?
>
> This way, the user-mode application isn’t polling to see if anything
> changed, only fetching information when something ACTUALLY changed.
>
> There’s a lot that can be done to optimise the above for particular types
> of operations, but as a basic principle, I think it would be efficient and
> work.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:
>
> > Thanks Mats.
> >
> > Actually, I plan to intercept the GDI calls in a mirror driver. Will
> > the primary video driver work well if I frequently call ExtEscape? I
> > just want the communicate with the mirror driver.
> >
> > I am thinking about allocating a block of memory in miniport driver to
> > record the GDI function calls. This block of memory is shared with
> > display driver so that it can put down which DrvXxxx functions are
> > called. The memory is also shared with a user-mode application, which
> > polls it to see what happens in the driver.
> >
> > So I also wonder whether this method will be effective eoungh since
> > polling may be frequent.
> >
> > Thank you.
> >
> > Lei
> >
> >
> > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > wrote:
> > >
> > >
> > > Generally, we solve this sort of situation by wrapping the IOCTL with
> an
> > > GDI Escape (using the ExtEscape function call, which ends up in your
> > > drivers DrvEscape), so your user applicaiton would call the escape for
> the
> > > DISPLAY, and the display driver would call the IOCTL using the handle
> that
> > > we’re given early on in the driver initialization. Thus avoiding
> actually
> > > exposing a “Video” device, which is not how Microsoft intended things,
> and
> > > that’s why you can’t call the ioCreateDevice.
> > >
> > > –
> > > Mats
> > >
> > > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:
> > >
> > > > I am going to have a user-mode application to talk with video
> miniport
> > > > driver by IOCTL. I have to specify the device object name when I use
> > > > CreateFile in user-mode application. However, there are no video port
> > > > routines that can be used to create a device object. I cannot use
> > > > IoCreateDevice either. So I am unable to specify a name for the
> device
> > > > object.
> > > >
> > > > So my question is, how to name a device object in video miniport
> driver?
> > > >
> > > > Can anyone give me some hints on that? Thank you.
> > > >
> > > > Lei
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > > ForwardSourceID:NT0000ECE6
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT0000ED46
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · March 17, 2005, 11:10am

Ok. so I would use a circular buffer mechanism, where the “read” pointer is
ONLY updated when you ask for the data, and the write pointer is only
updated when your display driver is called. So, everything between the read
pointer and the write pointer is “fair game” to give to your user-mode app.

I guess your mirror driver will have a separate display-name (or Monitor
name), which you can use to call CreateDC to get a hDC to your own display
driver. This is what you use to call your ExtEscape. You shouldn’t call the
escape on the main monitor (Display1 or Display0 for instance), as that
would probably not have the desired effect. [It should handel “unexpected”
Escape calls properly, but it may do funny things if you happen to match
something that means something to that display driver].

–
Mats
xxxxx@lists.osr.com wrote on 03/17/2005 03:54:01 PM:

Great, it sounds like a good way to go. Thank you very much.

I think the most difficult thing in this scheme is that there might be
one or more GDI calls invoked between two GDI escape command sent by
the user-application. So I still have to keep track of what happen
after the previous event is set. How do you think about it.

And another question is will the GDI escape goes to the primary driver
and cause some unexpected error?

Best,
Lei

On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
wrote:
> >
> >
> > So, if you want to “poll”, why don’t you do it the other way around.
> > Presumably your mirror driver will be called with the same information
as
> > the ordinary display driver.
> >
> > So here’s what I’d do:
> > Create a memory region in the display driver (by calling an IOCTL to
your
> > Miniport, that allocates a suitable memory region and returns the
address
> > for it to your display driver).
> > Then have the user-mode application call a GDI escape which says “I’d
like
> > to be told when there is some GDI calls to process”.
> > - This GDI escape either takes an event as input, or creates an event
that
> > is passed to the display driver.
> > The user app then waits for the it’s event.
> >
> > When a GDI drawing call is made to your display driver, you set the
event
> > after you’ve filled the information into your buffer.
> >
> > When the application wakes up after the event, it calls another GDI
Escape
> > to “Fetch all GDI calls since last call”. This GDI call also resets the
> > event flag, so that next call to WaitForEvent (WaitForSingleObject or
> > whatever you use) will wait again.
> >
> > Does that sound like something you could use?
> >
> > This way, the user-mode application isn’t polling to see if anything
> > changed, only fetching information when something ACTUALLY changed.
> >
> > There’s a lot that can be done to optimise the above for particular
types
> > of operations, but as a basic principle, I think it would be efficient
and
> > work.
> >
> > –
> > Mats
> >
> > xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:
> >
> > > Thanks Mats.
> > >
> > > Actually, I plan to intercept the GDI calls in a mirror driver. Will
> > > the primary video driver work well if I frequently call ExtEscape? I
> > > just want the communicate with the mirror driver.
> > >
> > > I am thinking about allocating a block of memory in miniport driver
to
> > > record the GDI function calls. This block of memory is shared with
> > > display driver so that it can put down which DrvXxxx functions are
> > > called. The memory is also shared with a user-mode application, which
> > > polls it to see what happens in the driver.
> > >
> > > So I also wonder whether this method will be effective eoungh since
> > > polling may be frequent.
> > >
> > > Thank you.
> > >
> > > Lei
> > >
> > >
> > > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > > wrote:
> > > >
> > > >
> > > > Generally, we solve this sort of situation by wrapping the IOCTL
with
> > an
> > > > GDI Escape (using the ExtEscape function call, which ends up in
your
> > > > drivers DrvEscape), so your user applicaiton would call the escape
for
> > the
> > > > DISPLAY, and the display driver would call the IOCTL using the
handle
> > that
> > > > we’re given early on in the driver initialization. Thus avoiding
> > actually
> > > > exposing a “Video” device, which is not how Microsoft intended
things,
> > and
> > > > that’s why you can’t call the ioCreateDevice.
> > > >
> > > > –
> > > > Mats
> > > >
> > > > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:
> > > >
> > > > > I am going to have a user-mode application to talk with video
> > miniport
> > > > > driver by IOCTL. I have to specify the device object name when I
use
> > > > > CreateFile in user-mode application. However, there are no video
port
> > > > > routines that can be used to create a device object. I cannot use
> > > > > IoCreateDevice either. So I am unable to specify a name for the
> > device
> > > > > object.
> > > > >
> > > > > So my question is, how to name a device object in video miniport
> > driver?
> > > > >
> > > > > Can anyone give me some hints on that? Thank you.
> > > > >
> > > > > Lei
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
xxxxx@3dlabs.com
> > > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > > ForwardSourceID:NT0000ECE6
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > > ForwardSourceID:NT0000ED46
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000ED56

OSR_Community_User · March 17, 2005, 11:40am

Thanks for you kind help. I think you have almost solve both problems
for me. I just need to have my user-mode application work fast enough
so that the circular buffer will not overflow.

Since I am a new driver writer, I have not gone through all the DrvXxx
functions. I think they sometimes have to deal with a large block of
data, which comes from certain user-mode process. Could I map the
pointer to this block of data back to user mode, rather then copy it
into my circultar buffer? And how can I make it in display driver?

It wil be perfect if this problem is also solved.
Thank you again.

Best,
Lei

On Thu, 17 Mar 2005 16:10:10 +0000, Mats PETERSSON
wrote:
>
>
> Ok. so I would use a circular buffer mechanism, where the “read” pointer is
> ONLY updated when you ask for the data, and the write pointer is only
> updated when your display driver is called. So, everything between the read
> pointer and the write pointer is “fair game” to give to your user-mode app.
>
> I guess your mirror driver will have a separate display-name (or Monitor
> name), which you can use to call CreateDC to get a hDC to your own display
> driver. This is what you use to call your ExtEscape. You shouldn’t call the
> escape on the main monitor (Display1 or Display0 for instance), as that
> would probably not have the desired effect. [It should handel “unexpected”
> Escape calls properly, but it may do funny things if you happen to match
> something that means something to that display driver].
>
> –
> Mats
> xxxxx@lists.osr.com wrote on 03/17/2005 03:54:01 PM:
>
> > Great, it sounds like a good way to go. Thank you very much.
> >
> > I think the most difficult thing in this scheme is that there might be
> > one or more GDI calls invoked between two GDI escape command sent by
> > the user-application. So I still have to keep track of what happen
> > after the previous event is set. How do you think about it.
> >
> > And another question is will the GDI escape goes to the primary driver
> > and cause some unexpected error?
> >
> > Best,
> > Lei
> >
> > On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
> > wrote:
> > >
> > >
> > > So, if you want to “poll”, why don’t you do it the other way around.
> > > Presumably your mirror driver will be called with the same information
> as
> > > the ordinary display driver.
> > >
> > > So here’s what I’d do:
> > > Create a memory region in the display driver (by calling an IOCTL to
> your
> > > Miniport, that allocates a suitable memory region and returns the
> address
> > > for it to your display driver).
> > > Then have the user-mode application call a GDI escape which says “I’d
> like
> > > to be told when there is some GDI calls to process”.
> > > - This GDI escape either takes an event as input, or creates an event
> that
> > > is passed to the display driver.
> > > The user app then waits for the it’s event.
> > >
> > > When a GDI drawing call is made to your display driver, you set the
> event
> > > after you’ve filled the information into your buffer.
> > >
> > > When the application wakes up after the event, it calls another GDI
> Escape
> > > to “Fetch all GDI calls since last call”. This GDI call also resets the
> > > event flag, so that next call to WaitForEvent (WaitForSingleObject or
> > > whatever you use) will wait again.
> > >
> > > Does that sound like something you could use?
> > >
> > > This way, the user-mode application isn’t polling to see if anything
> > > changed, only fetching information when something ACTUALLY changed.
> > >
> > > There’s a lot that can be done to optimise the above for particular
> types
> > > of operations, but as a basic principle, I think it would be efficient
> and
> > > work.
> > >
> > > –
> > > Mats
> > >
> > > xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:
> > >
> > > > Thanks Mats.
> > > >
> > > > Actually, I plan to intercept the GDI calls in a mirror driver. Will
> > > > the primary video driver work well if I frequently call ExtEscape? I
> > > > just want the communicate with the mirror driver.
> > > >
> > > > I am thinking about allocating a block of memory in miniport driver
> to
> > > > record the GDI function calls. This block of memory is shared with
> > > > display driver so that it can put down which DrvXxxx functions are
> > > > called. The memory is also shared with a user-mode application, which
> > > > polls it to see what happens in the driver.
> > > >
> > > > So I also wonder whether this method will be effective eoungh since
> > > > polling may be frequent.
> > > >
> > > > Thank you.
> > > >
> > > > Lei
> > > >
> > > >
> > > > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > > > wrote:
> > > > >
> > > > >
> > > > > Generally, we solve this sort of situation by wrapping the IOCTL
> with
> > > an
> > > > > GDI Escape (using the ExtEscape function call, which ends up in
> your
> > > > > drivers DrvEscape), so your user applicaiton would call the escape
> for
> > > the
> > > > > DISPLAY, and the display driver would call the IOCTL using the
> handle
> > > that
> > > > > we’re given early on in the driver initialization. Thus avoiding
> > > actually
> > > > > exposing a “Video” device, which is not how Microsoft intended
> things,
> > > and
> > > > > that’s why you can’t call the ioCreateDevice.
> > > > >
> > > > > –
> > > > > Mats
> > > > >
> > > > > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51 AM:
> > > > >
> > > > > > I am going to have a user-mode application to talk with video
> > > miniport
> > > > > > driver by IOCTL. I have to specify the device object name when I
> use
> > > > > > CreateFile in user-mode application. However, there are no video
> port
> > > > > > routines that can be used to create a device object. I cannot use
> > > > > > IoCreateDevice either. So I am unable to specify a name for the
> > > device
> > > > > > object.
> > > > > >
> > > > > > So my question is, how to name a device object in video miniport
> > > driver?
> > > > > >
> > > > > > Can anyone give me some hints on that? Thank you.
> > > > > >
> > > > > > Lei
> > > > > >
> > > > > > —
> > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > osronline.com/article.cfm?id=256
> > > > > >
> > > > > > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com
> > > > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > > > > ForwardSourceID:NT0000ECE6
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > > ForwardSourceID:NT0000ED46
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT0000ED56
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · March 17, 2005, 11:53am

You probably could re-map the data to your process, however if the code in
the calling process does something like:

memset(block, 0xFF, size);
BitBlt(…, block, size, …);
memset(block, 0xEE, size);
BitBlt(…, block, size, …);

What happens if your application sees BOTH bitblt in one of your chunks of
data because your “copy data from mirror driver” user mode application had
a lower priority than the above code (perhaps because Windows decides to
boost priority of the app above).

Now both of your bitblt operations will have 0xEE as the data, rather than
0xFF for the first and 0xEE for the second.

Another option of things going wrong would be:

xx = malloc(size);
…
BitBlt(… xx, …);
free(xx);
…

Now what memory do you have in your user-app?

You would be much better off copying this data in your driver, whilst it’s
still locked down by the upper GDI layer. [There is of course a performance
impact of this, but if you do it right, using a “AllocateForUserMode” call
in your driver, you may be able to pass the data straight to the user-mode
app without a second copy operation. You may have to invent some way of
indicating to the user-app that it has a block of data that it needs to
look at and then free up, but I’m sure that can be done.]

–
Mats

xxxxx@lists.osr.com wrote on 03/17/2005 04:38:29 PM:

Thanks for you kind help. I think you have almost solve both problems
for me. I just need to have my user-mode application work fast enough
so that the circular buffer will not overflow.

Since I am a new driver writer, I have not gone through all the DrvXxx
functions. I think they sometimes have to deal with a large block of
data, which comes from certain user-mode process. Could I map the
pointer to this block of data back to user mode, rather then copy it
into my circultar buffer? And how can I make it in display driver?

It wil be perfect if this problem is also solved.
Thank you again.

Best,
Lei

On Thu, 17 Mar 2005 16:10:10 +0000, Mats PETERSSON
wrote:
> >
> >
> > Ok. so I would use a circular buffer mechanism, where the “read”
pointer is
> > ONLY updated when you ask for the data, and the write pointer is only
> > updated when your display driver is called. So, everything between the
read
> > pointer and the write pointer is “fair game” to give to your user-mode
app.
> >
> > I guess your mirror driver will have a separate display-name (or
Monitor
> > name), which you can use to call CreateDC to get a hDC to your own
display
> > driver. This is what you use to call your ExtEscape. You shouldn’t call
the
> > escape on the main monitor (Display1 or Display0 for instance), as that
> > would probably not have the desired effect. [It should handel
“unexpected”
> > Escape calls properly, but it may do funny things if you happen to
match
> > something that means something to that display driver].
> >
> > –
> > Mats
> > xxxxx@lists.osr.com wrote on 03/17/2005 03:54:01 PM:
> >
> > > Great, it sounds like a good way to go. Thank you very much.
> > >
> > > I think the most difficult thing in this scheme is that there might
be
> > > one or more GDI calls invoked between two GDI escape command sent by
> > > the user-application. So I still have to keep track of what happen
> > > after the previous event is set. How do you think about it.
> > >
> > > And another question is will the GDI escape goes to the primary
driver
> > > and cause some unexpected error?
> > >
> > > Best,
> > > Lei
> > >
> > > On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
> > > wrote:
> > > >
> > > >
> > > > So, if you want to “poll”, why don’t you do it the other way
around.
> > > > Presumably your mirror driver will be called with the same
information
> > as
> > > > the ordinary display driver.
> > > >
> > > > So here’s what I’d do:
> > > > Create a memory region in the display driver (by calling an IOCTL
to
> > your
> > > > Miniport, that allocates a suitable memory region and returns the
> > address
> > > > for it to your display driver).
> > > > Then have the user-mode application call a GDI escape which says
“I’d
> > like
> > > > to be told when there is some GDI calls to process”.
> > > > - This GDI escape either takes an event as input, or creates an
event
> > that
> > > > is passed to the display driver.
> > > > The user app then waits for the it’s event.
> > > >
> > > > When a GDI drawing call is made to your display driver, you set the
> > event
> > > > after you’ve filled the information into your buffer.
> > > >
> > > > When the application wakes up after the event, it calls another GDI
> > Escape
> > > > to “Fetch all GDI calls since last call”. This GDI call also resets
the
> > > > event flag, so that next call to WaitForEvent (WaitForSingleObject
or
> > > > whatever you use) will wait again.
> > > >
> > > > Does that sound like something you could use?
> > > >
> > > > This way, the user-mode application isn’t polling to see if
anything
> > > > changed, only fetching information when something ACTUALLY changed.
> > > >
> > > > There’s a lot that can be done to optimise the above for particular
> > types
> > > > of operations, but as a basic principle, I think it would be
efficient
> > and
> > > > work.
> > > >
> > > > –
> > > > Mats
> > > >
> > > > xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:
> > > >
> > > > > Thanks Mats.
> > > > >
> > > > > Actually, I plan to intercept the GDI calls in a mirror driver.
Will
> > > > > the primary video driver work well if I frequently call
ExtEscape? I
> > > > > just want the communicate with the mirror driver.
> > > > >
> > > > > I am thinking about allocating a block of memory in miniport
driver
> > to
> > > > > record the GDI function calls. This block of memory is shared
with
> > > > > display driver so that it can put down which DrvXxxx functions
are
> > > > > called. The memory is also shared with a user-mode application,
which
> > > > > polls it to see what happens in the driver.
> > > > >
> > > > > So I also wonder whether this method will be effective eoungh
since
> > > > > polling may be frequent.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Lei
> > > > >
> > > > >
> > > > > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Generally, we solve this sort of situation by wrapping the
IOCTL
> > with
> > > > an
> > > > > > GDI Escape (using the ExtEscape function call, which ends up in
> > your
> > > > > > drivers DrvEscape), so your user applicaiton would call the
escape
> > for
> > > > the
> > > > > > DISPLAY, and the display driver would call the IOCTL using the
> > handle
> > > > that
> > > > > > we’re given early on in the driver initialization. Thus
avoiding
> > > > actually
> > > > > > exposing a “Video” device, which is not how Microsoft intended
> > things,
> > > > and
> > > > > > that’s why you can’t call the ioCreateDevice.
> > > > > >
> > > > > > –
> > > > > > Mats
> > > > > >
> > > > > > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51
AM:
> > > > > >
> > > > > > > I am going to have a user-mode application to talk with video
> > > > miniport
> > > > > > > driver by IOCTL. I have to specify the device object name
when I
> > use
> > > > > > > CreateFile in user-mode application. However, there are no
video
> > port
> > > > > > > routines that can be used to create a device object. I cannot
use
> > > > > > > IoCreateDevice either. So I am unable to specify a name for
the
> > > > device
> > > > > > > object.
> > > > > > >
> > > > > > > So my question is, how to name a device object in video
miniport
> > > > driver?
> > > > > > >
> > > > > > > Can anyone give me some hints on that? Thank you.
> > > > > > >
> > > > > > > Lei
> > > > > > >
> > > > > > > —
> > > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > > osronline.com/article.cfm?id=256
> > > > > > >
> > > > > > > You are currently subscribed to ntdev as:
> > xxxxx@3dlabs.com
> > > > > > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > > >
> > > > > > > ForwardSourceID:NT0000ECE6
> > > > > >
> > > > > > —
> > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > osronline.com/article.cfm?id=256
> > > > > >
> > > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
xxxxx@3dlabs.com
> > > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > > ForwardSourceID:NT0000ED46
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > > ForwardSourceID:NT0000ED56
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000ED76

OSR_Community_User · March 17, 2005, 12:16pm

There are four useful GDDI routines.

EngAllocPrivateUserMem(),
EngFreePrivateUserMem(),

EngAllocUserMem(),
EngFreeUserMem().

Althought the WINDDK does say that it is a must to free the allocated
memory in kernel mode, it mentions that we cannot use EngFreeUserMem()
for EngFreePrivateUserMem().

I think it will be a better way to issue another GDI escape to tell
the display driver to free the memory.

By the way, where can I know the priority of those GDI calls? It will
a problem if there are a lot of high priority GDI calls block my
escape command.

Thanks,

Lei

On Thu, 17 Mar 2005 16:52:18 +0000, Mats PETERSSON
wrote:
>
>
> You probably could re-map the data to your process, however if the code in
> the calling process does something like:
>
> memset(block, 0xFF, size);
> BitBlt(…, block, size, …);
> memset(block, 0xEE, size);
> BitBlt(…, block, size, …);
>
> What happens if your application sees BOTH bitblt in one of your chunks of
> data because your “copy data from mirror driver” user mode application had
> a lower priority than the above code (perhaps because Windows decides to
> boost priority of the app above).
>
> Now both of your bitblt operations will have 0xEE as the data, rather than
> 0xFF for the first and 0xEE for the second.
>
> Another option of things going wrong would be:
>
> xx = malloc(size);
> …
> BitBlt(… xx, …);
> free(xx);
> …
>
> Now what memory do you have in your user-app?
>
> You would be much better off copying this data in your driver, whilst it’s
> still locked down by the upper GDI layer. [There is of course a performance
> impact of this, but if you do it right, using a “AllocateForUserMode” call
> in your driver, you may be able to pass the data straight to the user-mode
> app without a second copy operation. You may have to invent some way of
> indicating to the user-app that it has a block of data that it needs to
> look at and then free up, but I’m sure that can be done.]
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 03/17/2005 04:38:29 PM:
>
> > Thanks for you kind help. I think you have almost solve both problems
> > for me. I just need to have my user-mode application work fast enough
> > so that the circular buffer will not overflow.
> >
> > Since I am a new driver writer, I have not gone through all the DrvXxx
> > functions. I think they sometimes have to deal with a large block of
> > data, which comes from certain user-mode process. Could I map the
> > pointer to this block of data back to user mode, rather then copy it
> > into my circultar buffer? And how can I make it in display driver?
> >
> > It wil be perfect if this problem is also solved.
> > Thank you again.
> >
> > Best,
> > Lei
> >
> > On Thu, 17 Mar 2005 16:10:10 +0000, Mats PETERSSON
> > wrote:
> > >
> > >
> > > Ok. so I would use a circular buffer mechanism, where the “read”
> pointer is
> > > ONLY updated when you ask for the data, and the write pointer is only
> > > updated when your display driver is called. So, everything between the
> read
> > > pointer and the write pointer is “fair game” to give to your user-mode
> app.
> > >
> > > I guess your mirror driver will have a separate display-name (or
> Monitor
> > > name), which you can use to call CreateDC to get a hDC to your own
> display
> > > driver. This is what you use to call your ExtEscape. You shouldn’t call
> the
> > > escape on the main monitor (Display1 or Display0 for instance), as that
> > > would probably not have the desired effect. [It should handel
> “unexpected”
> > > Escape calls properly, but it may do funny things if you happen to
> match
> > > something that means something to that display driver].
> > >
> > > –
> > > Mats
> > > xxxxx@lists.osr.com wrote on 03/17/2005 03:54:01 PM:
> > >
> > > > Great, it sounds like a good way to go. Thank you very much.
> > > >
> > > > I think the most difficult thing in this scheme is that there might
> be
> > > > one or more GDI calls invoked between two GDI escape command sent by
> > > > the user-application. So I still have to keep track of what happen
> > > > after the previous event is set. How do you think about it.
> > > >
> > > > And another question is will the GDI escape goes to the primary
> driver
> > > > and cause some unexpected error?
> > > >
> > > > Best,
> > > > Lei
> > > >
> > > > On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
> > > > wrote:
> > > > >
> > > > >
> > > > > So, if you want to “poll”, why don’t you do it the other way
> around.
> > > > > Presumably your mirror driver will be called with the same
> information
> > > as
> > > > > the ordinary display driver.
> > > > >
> > > > > So here’s what I’d do:
> > > > > Create a memory region in the display driver (by calling an IOCTL
> to
> > > your
> > > > > Miniport, that allocates a suitable memory region and returns the
> > > address
> > > > > for it to your display driver).
> > > > > Then have the user-mode application call a GDI escape which says
> “I’d
> > > like
> > > > > to be told when there is some GDI calls to process”.
> > > > > - This GDI escape either takes an event as input, or creates an
> event
> > > that
> > > > > is passed to the display driver.
> > > > > The user app then waits for the it’s event.
> > > > >
> > > > > When a GDI drawing call is made to your display driver, you set the
> > > event
> > > > > after you’ve filled the information into your buffer.
> > > > >
> > > > > When the application wakes up after the event, it calls another GDI
> > > Escape
> > > > > to “Fetch all GDI calls since last call”. This GDI call also resets
> the
> > > > > event flag, so that next call to WaitForEvent (WaitForSingleObject
> or
> > > > > whatever you use) will wait again.
> > > > >
> > > > > Does that sound like something you could use?
> > > > >
> > > > > This way, the user-mode application isn’t polling to see if
> anything
> > > > > changed, only fetching information when something ACTUALLY changed.
> > > > >
> > > > > There’s a lot that can be done to optimise the above for particular
> > > types
> > > > > of operations, but as a basic principle, I think it would be
> efficient
> > > and
> > > > > work.
> > > > >
> > > > > –
> > > > > Mats
> > > > >
> > > > > xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14 PM:
> > > > >
> > > > > > Thanks Mats.
> > > > > >
> > > > > > Actually, I plan to intercept the GDI calls in a mirror driver.
> Will
> > > > > > the primary video driver work well if I frequently call
> ExtEscape? I
> > > > > > just want the communicate with the mirror driver.
> > > > > >
> > > > > > I am thinking about allocating a block of memory in miniport
> driver
> > > to
> > > > > > record the GDI function calls. This block of memory is shared
> with
> > > > > > display driver so that it can put down which DrvXxxx functions
> are
> > > > > > called. The memory is also shared with a user-mode application,
> which
> > > > > > polls it to see what happens in the driver.
> > > > > >
> > > > > > So I also wonder whether this method will be effective eoungh
> since
> > > > > > polling may be frequent.
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Lei
> > > > > >
> > > > > >
> > > > > > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > Generally, we solve this sort of situation by wrapping the
> IOCTL
> > > with
> > > > > an
> > > > > > > GDI Escape (using the ExtEscape function call, which ends up in
> > > your
> > > > > > > drivers DrvEscape), so your user applicaiton would call the
> escape
> > > for
> > > > > the
> > > > > > > DISPLAY, and the display driver would call the IOCTL using the
> > > handle
> > > > > that
> > > > > > > we’re given early on in the driver initialization. Thus
> avoiding
> > > > > actually
> > > > > > > exposing a “Video” device, which is not how Microsoft intended
> > > things,
> > > > > and
> > > > > > > that’s why you can’t call the ioCreateDevice.
> > > > > > >
> > > > > > > –
> > > > > > > Mats
> > > > > > >
> > > > > > > xxxxx@lists.osr.com wrote on 03/17/2005 05:15:51
> AM:
> > > > > > >
> > > > > > > > I am going to have a user-mode application to talk with video
> > > > > miniport
> > > > > > > > driver by IOCTL. I have to specify the device object name
> when I
> > > use
> > > > > > > > CreateFile in user-mode application. However, there are no
> video
> > > port
> > > > > > > > routines that can be used to create a device object. I cannot
> use
> > > > > > > > IoCreateDevice either. So I am unable to specify a name for
> the
> > > > > device
> > > > > > > > object.
> > > > > > > >
> > > > > > > > So my question is, how to name a device object in video
> miniport
> > > > > driver?
> > > > > > > >
> > > > > > > > Can anyone give me some hints on that? Thank you.
> > > > > > > >
> > > > > > > > Lei
> > > > > > > >
> > > > > > > > —
> > > > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > > > osronline.com/article.cfm?id=256
> > > > > > > >
> > > > > > > > You are currently subscribed to ntdev as:
> > > xxxxx@3dlabs.com
> > > > > > > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > > > > >
> > > > > > > > ForwardSourceID:NT0000ECE6
> > > > > > >
> > > > > > > —
> > > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > osronline.com/article.cfm?id=256
> > > > > > >
> > > > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > > > > >
> > > > > >
> > > > > > —
> > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > osronline.com/article.cfm?id=256
> > > > > >
> > > > > > You are currently subscribed to ntdev as:
> xxxxx@3dlabs.com
> > > > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > > > > ForwardSourceID:NT0000ED46
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > > > ForwardSourceID:NT0000ED56
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> > ForwardSourceID:NT0000ED76
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · March 17, 2005, 12:35pm

xxxxx@lists.osr.com wrote on 03/17/2005 05:15:36 PM:

There are four useful GDDI routines.

EngAllocPrivateUserMem(),
EngFreePrivateUserMem(),

EngAllocUserMem(),
EngFreeUserMem().

Althought the WINDDK does say that it is a must to free the allocated
memory in kernel mode, it mentions that we cannot use EngFreeUserMem()
for EngFreePrivateUserMem().

I think it will be a better way to issue another GDI escape to tell
the display driver to free the memory.

Yes, it’s probably better with a “Free my buffer escape”. You could use
this as an indication that the user is about to wait again too, so you
reset your event at this point, avoiding two different escape calls.

By the way, where can I know the priority of those GDI calls? It will
a problem if there are a lot of high priority GDI calls block my
escape command.

There’s no priority between different GDI calls, but an application running
at high priority when calling GDI will obviously continue running at high
priority during and after the GDI call. If your user-mode app is at lower
priority than the app calling GDI, your app will not get to call GDI until:
A) The higher priority app decides to wait for something (keypress, mouse
movement, network packet, file-read, or whatever)
B) Windows decides the high priority app has been hogging the CPU for long
enough and lowers it’s priority.
C) The higher priority app exits.

Your user-mode app should be able to cope with the buffer being full (that
part isn’t particularly hard), and your driver must have some strategy for
what to do when the buffer becomes full (easy solution: Throw away stuff
that is oldest, but beware of pointer wrap in the circular buffer).
Unfortunately, you can not stop dead at this point, because that could
potentially deadlock your machine. GDI is not re-entrant, so any app
calling into GDI will have acquire a lock. If the lock is currently held,
any other app trying to acquire the lock will have to wait. If your
user-mode app is required to call into the driver to free up some buffer
space, and some other app is currently in the driver waiting for
buffer-space to appear, you’d be locked dead, because your user-app can’t
get in there, and the other app can’t get out until your user-app gets in
there. Catch 22.

–
Mats

Thanks,

Lei

On Thu, 17 Mar 2005 16:52:18 +0000, Mats PETERSSON
wrote:
> >
> >
> > You probably could re-map the data to your process, however if the code
in
> > the calling process does something like:
> >
> > memset(block, 0xFF, size);
> > BitBlt(…, block, size, …);
> > memset(block, 0xEE, size);
> > BitBlt(…, block, size, …);
> >
> > What happens if your application sees BOTH bitblt in one of your chunks
of
> > data because your “copy data from mirror driver” user mode application
had
> > a lower priority than the above code (perhaps because Windows decides
to
> > boost priority of the app above).
> >
> > Now both of your bitblt operations will have 0xEE as the data, rather
than
> > 0xFF for the first and 0xEE for the second.
> >
> > Another option of things going wrong would be:
> >
> > xx = malloc(size);
> > …
> > BitBlt(… xx, …);
> > free(xx);
> > …
> >
> > Now what memory do you have in your user-app?
> >
> > You would be much better off copying this data in your driver, whilst
it’s
> > still locked down by the upper GDI layer. [There is of course a
performance
> > impact of this, but if you do it right, using a “AllocateForUserMode”
call
> > in your driver, you may be able to pass the data straight to the
user-mode
> > app without a second copy operation. You may have to invent some way of
> > indicating to the user-app that it has a block of data that it needs to
> > look at and then free up, but I’m sure that can be done.]
> >
> > –
> > Mats
> >
> > xxxxx@lists.osr.com wrote on 03/17/2005 04:38:29 PM:
> >
> > > Thanks for you kind help. I think you have almost solve both problems
> > > for me. I just need to have my user-mode application work fast enough
> > > so that the circular buffer will not overflow.
> > >
> > > Since I am a new driver writer, I have not gone through all the
DrvXxx
> > > functions. I think they sometimes have to deal with a large block of
> > > data, which comes from certain user-mode process. Could I map the
> > > pointer to this block of data back to user mode, rather then copy it
> > > into my circultar buffer? And how can I make it in display driver?
> > >
> > > It wil be perfect if this problem is also solved.
> > > Thank you again.
> > >
> > > Best,
> > > Lei
> > >
> > > On Thu, 17 Mar 2005 16:10:10 +0000, Mats PETERSSON
> > > wrote:
> > > >
> > > >
> > > > Ok. so I would use a circular buffer mechanism, where the “read”
> > pointer is
> > > > ONLY updated when you ask for the data, and the write pointer is
only
> > > > updated when your display driver is called. So, everything between
the
> > read
> > > > pointer and the write pointer is “fair game” to give to your
user-mode
> > app.
> > > >
> > > > I guess your mirror driver will have a separate display-name (or
> > Monitor
> > > > name), which you can use to call CreateDC to get a hDC to your own
> > display
> > > > driver. This is what you use to call your ExtEscape. You shouldn’t
call
> > the
> > > > escape on the main monitor (Display1 or Display0 for instance), as
that
> > > > would probably not have the desired effect. [It should handel
> > “unexpected”
> > > > Escape calls properly, but it may do funny things if you happen to
> > match
> > > > something that means something to that display driver].
> > > >
> > > > –
> > > > Mats
> > > > xxxxx@lists.osr.com wrote on 03/17/2005 03:54:01 PM:
> > > >
> > > > > Great, it sounds like a good way to go. Thank you very much.
> > > > >
> > > > > I think the most difficult thing in this scheme is that there
might
> > be
> > > > > one or more GDI calls invoked between two GDI escape command sent
by
> > > > > the user-application. So I still have to keep track of what
happen
> > > > > after the previous event is set. How do you think about it.
> > > > >
> > > > > And another question is will the GDI escape goes to the primary
> > driver
> > > > > and cause some unexpected error?
> > > > >
> > > > > Best,
> > > > > Lei
> > > > >
> > > > > On Thu, 17 Mar 2005 15:31:26 +0000, Mats PETERSSON
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > So, if you want to “poll”, why don’t you do it the other way
> > around.
> > > > > > Presumably your mirror driver will be called with the same
> > information
> > > > as
> > > > > > the ordinary display driver.
> > > > > >
> > > > > > So here’s what I’d do:
> > > > > > Create a memory region in the display driver (by calling an
IOCTL
> > to
> > > > your
> > > > > > Miniport, that allocates a suitable memory region and returns
the
> > > > address
> > > > > > for it to your display driver).
> > > > > > Then have the user-mode application call a GDI escape which
says
> > “I’d
> > > > like
> > > > > > to be told when there is some GDI calls to process”.
> > > > > > - This GDI escape either takes an event as input, or creates an
> > event
> > > > that
> > > > > > is passed to the display driver.
> > > > > > The user app then waits for the it’s event.
> > > > > >
> > > > > > When a GDI drawing call is made to your display driver, you set
the
> > > > event
> > > > > > after you’ve filled the information into your buffer.
> > > > > >
> > > > > > When the application wakes up after the event, it calls another
GDI
> > > > Escape
> > > > > > to “Fetch all GDI calls since last call”. This GDI call also
resets
> > the
> > > > > > event flag, so that next call to WaitForEvent
(WaitForSingleObject
> > or
> > > > > > whatever you use) will wait again.
> > > > > >
> > > > > > Does that sound like something you could use?
> > > > > >
> > > > > > This way, the user-mode application isn’t polling to see if
> > anything
> > > > > > changed, only fetching information when something ACTUALLY
changed.
> > > > > >
> > > > > > There’s a lot that can be done to optimise the above for
particular
> > > > types
> > > > > > of operations, but as a basic principle, I think it would be
> > efficient
> > > > and
> > > > > > work.
> > > > > >
> > > > > > –
> > > > > > Mats
> > > > > >
> > > > > > xxxxx@lists.osr.com wrote on 03/17/2005 03:16:14
PM:
> > > > > >
> > > > > > > Thanks Mats.
> > > > > > >
> > > > > > > Actually, I plan to intercept the GDI calls in a mirror
driver.
> > Will
> > > > > > > the primary video driver work well if I frequently call
> > ExtEscape? I
> > > > > > > just want the communicate with the mirror driver.
> > > > > > >
> > > > > > > I am thinking about allocating a block of memory in miniport
> > driver
> > > > to
> > > > > > > record the GDI function calls. This block of memory is shared
> > with
> > > > > > > display driver so that it can put down which DrvXxxx
functions
> > are
> > > > > > > called. The memory is also shared with a user-mode
application,
> > which
> > > > > > > polls it to see what happens in the driver.
> > > > > > >
> > > > > > > So I also wonder whether this method will be effective eoungh
> > since
> > > > > > > polling may be frequent.
> > > > > > >
> > > > > > > Thank you.
> > > > > > >
> > > > > > > Lei
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 17 Mar 2005 09:12:54 +0000, Mats PETERSSON
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Generally, we solve this sort of situation by wrapping the
> > IOCTL
> > > > with
> > > > > > an
> > > > > > > > GDI Escape (using the ExtEscape function call, which ends
up in
> > > > your
> > > > > > > > drivers DrvEscape), so your user applicaiton would call the
> > escape
> > > > for
> > > > > > the
> > > > > > > > DISPLAY, and the display driver would call the IOCTL using
the
> > > > handle
> > > > > > that
> > > > > > > > we’re given early on in the driver initialization. Thus
> > avoiding
> > > > > > actually
> > > > > > > > exposing a “Video” device, which is not how Microsoft
intended
> > > > things,
> > > > > > and
> > > > > > > > that’s why you can’t call the ioCreateDevice.
> > > > > > > >
> > > > > > > > –
> > > > > > > > Mats
> > > > > > > >
> > > > > > > > xxxxx@lists.osr.com wrote on 03/17/2005
05:15:51
> > AM:
> > > > > > > >
> > > > > > > > > I am going to have a user-mode application to talk with
video
> > > > > > miniport
> > > > > > > > > driver by IOCTL. I have to specify the device object
name
> > when I
> > > > use
> > > > > > > > > CreateFile in user-mode application. However, there are
no
> > video
> > > > port
> > > > > > > > > routines that can be used to create a device object. I
cannot
> > use
> > > > > > > > > IoCreateDevice either. So I am unable to specify a name
for
> > the
> > > > > > device
> > > > > > > > > object.
> > > > > > > > >
> > > > > > > > > So my question is, how to name a device object in video
> > miniport
> > > > > > driver?
> > > > > > > > >
> > > > > > > > > Can anyone give me some hints on that? Thank you.
> > > > > > > > >
> > > > > > > > > Lei
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > Questions? First check the Kernel Driver FAQ at
http://www.
> > > > > > > > > osronline.com/article.cfm?id=256
> > > > > > > > >
> > > > > > > > > You are currently subscribed to ntdev as:
> > > > xxxxx@3dlabs.com
> > > > > > > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > > > > > >
> > > > > > > > > ForwardSourceID:NT0000ECE6
> > > > > > > >
> > > > > > > > —
> > > > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > > osronline.com/article.cfm?id=256
> > > > > > > >
> > > > > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > > > > To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > > > > > >
> > > > > > >
> > > > > > > —
> > > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > > > osronline.com/article.cfm?id=256
> > > > > > >
> > > > > > > You are currently subscribed to ntdev as:
> > xxxxx@3dlabs.com
> > > > > > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > > >
> > > > > > > ForwardSourceID:NT0000ED46
> > > > > >
> > > > > > —
> > > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > osronline.com/article.cfm?id=256
> > > > > >
> > > > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > > > osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
xxxxx@3dlabs.com
> > > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > > > > ForwardSourceID:NT0000ED56
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > > > To unsubscribe send a blank email to
xxxxx@lists.osr.com
> > > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at http://www.
> > > osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> > > ForwardSourceID:NT0000ED76
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000ED82

OSR_Community_User · March 17, 2005, 3:00pm

> Your user-mode app should be able to cope with the buffer being full (that

part isn’t particularly hard), and your driver must have some strategy for
what to do when the buffer becomes full (easy solution: Throw away stuff
that is oldest, but beware of pointer wrap in the circular buffer).
I think it is not that easy to cope with buffer being full in my
user-mode app, since this buffer is maintained by the kernel-mode
driver. Can the display driver notice the user-mode app before the app
is able to issue succeeding GDI escape command?

And looks like I don’t have to bother miniport driver to allocate
memory. The EngAllocMem() routine can be used to allocate memory from
nonpaged pool. But the problem is where I can store the pointer to the
block of memory in display driver…

anyway, thanks a lot for your help.

Lei

OSR_Community_User · March 18, 2005, 4:09am

What do you mean “Where can I store a pointer to the block of memory?”. The
obvious place for this type of information would be in your PDEV.

–
Mats

-------- Notice --------
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
message by anyone else is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of the message, or any
action taken by you in reliance on it, is prohibited and may be unlawful.
If you have received this message in error, please delete it and contact
the sender immediately. Thank you.

xxxxx@lists.osr.com wrote on 03/17/2005 08:00:05 PM:

> Your user-mode app should be able to cope with the buffer being full
(that
> part isn’t particularly hard), and your driver must have some strategy
for
> what to do when the buffer becomes full (easy solution: Throw away
stuff
> that is oldest, but beware of pointer wrap in the circular buffer).
I think it is not that easy to cope with buffer being full in my
user-mode app, since this buffer is maintained by the kernel-mode
driver. Can the display driver notice the user-mode app before the app
is able to issue succeeding GDI escape command?

And looks like I don’t have to bother miniport driver to allocate
memory. The EngAllocMem() routine can be used to allocate memory from
nonpaged pool. But the problem is where I can store the pointer to the
block of memory in display driver…

anyway, thanks a lot for your help.

Lei

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

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000EDAE

OSR_Community_User · March 18, 2005, 4:16am

> I think it is not that easy to cope with buffer being full in my

user-mode app, since this buffer is maintained by the kernel-mode
driver. Can the display driver notice the user-mode app before the app
is able to issue succeeding GDI escape command?

I wouldn’t start logging GDI commands in your mirror driver until you’ve at
least seen one Escape from your user-mode app. That way, you know that the
user-mode app is available to receive the data when it’s getting logged. Of
course, that does cause a problem if you want to know what has been drawn
on the screen before you started logging. If you need that, you’ll need to
create a big enough buffer to cope with the drawing that happens before
your app gets running. You may still get a full buffer at some point, so
you MUST be able to cope with the user-app not requesting the content of
the buffer because some other app is running at the time. I don’t have a
specific solution for that, but the “easy” method is to “loose” the old
drawing stuff.

–
Mats

OSR_Community_User · March 18, 2005, 8:55am

One way may to do it be to use a circular buffer: you lose the
older stuff, but only when the system’s overloaded, and the
chucking is automatic. You can also allow the user to configure
the size of the buffer upfront.

Or you can be a bit more aggressive and implement a chain of
buffers: if you run out of a buffer, you grab another one. The
problem of course is that if the app’s not running you risk
clogging the system pretty fast, specially with high performance
graphics.

Alberto.

----- Original Message -----
From: “Mats PETERSSON”
To: “Windows System Software Devs Interest List”

Sent: Friday, March 18, 2005 4:15 AM
Subject: Re: [ntdev] How to name a device object in video
miniport driver?

>
>
>
>
>
>
>> I think it is not that easy to cope with buffer being full in
>> my
>> user-mode app, since this buffer is maintained by the
>> kernel-mode
>> driver. Can the display driver notice the user-mode app
>> before the app
>> is able to issue succeeding GDI escape command?
>
> I wouldn’t start logging GDI commands in your mirror driver
> until you’ve at
> least seen one Escape from your user-mode app. That way, you
> know that the
> user-mode app is available to receive the data when it’s
> getting logged. Of
> course, that does cause a problem if you want to know what has
> been drawn
> on the screen before you started logging. If you need that,
> you’ll need to
> create a big enough buffer to cope with the drawing that
> happens before
> your app gets running. You may still get a full buffer at some
> point, so
> you MUST be able to cope with the user-app not requesting the
> content of
> the buffer because some other app is running at the time. I
> don’t have a
> specific solution for that, but the “easy” method is to
> “loose” the old
> drawing stuff.
>
> –
> Mats
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com

OSR_Community_User · March 18, 2005, 10:04am

> One way may to do it be to use a circular buffer: you lose the

older stuff, but only when the system’s overloaded, and the
chucking is automatic. You can also allow the user to configure
the size of the buffer upfront.

Or you can be a bit more aggressive and implement a chain of
buffers: if you run out of a buffer, you grab another one. The
problem of course is that if the app’s not running you risk
clogging the system pretty fast, specially with high performance
graphics.

Not a particularly pleasing idea, filling the entire kernel space with
buffers, eh? If the user-mode app isn’t responding, it’s highly possible
that it will not do so for a while. It’s probably much better to have a big
buffer in the first place, than to dynamically expand the buffer(s). At the
very least, limit the number of buffers so that it doesn’t go too far.

But one thing that I think might work is if there are later commands that
entirely cover earlier commands (such as blits that don’t use the
destination as an input, or fill’s), the older ones can be deleted [this is
probably better seen as an optimisation than a way to reduce the space].
This culling should be done continually, so that the buffer is always
“unique”. Unfortunately, a lot of drawing is done based on the previous
surface, so it’s unlikely to give great gains in anything but special cases
(where it may well be very useful).

–
Mats

Alberto.

OSR_Community_User · March 18, 2005, 10:24am

I agree with Mats that the buffer in the driver should have limited
size. Otherwise the machine may crash easily as long as my user-mode
app never starts. It is an annoying problem.

But how about writing the user-mode app as a service? It can run
before the user logs in. However, I am not quite sure whether it will
starts before the drawing begins.

Can we capture the entire screen by simply using some Win32 API? If
yes, we can start intercepting drawing command after doing that.

Lei

On Fri, 18 Mar 2005 15:03:16 +0000, Mats PETERSSON
wrote:
>
>
> > One way may to do it be to use a circular buffer: you lose the
> > older stuff, but only when the system’s overloaded, and the
> > chucking is automatic. You can also allow the user to configure
> > the size of the buffer upfront.
> >
> > Or you can be a bit more aggressive and implement a chain of
> > buffers: if you run out of a buffer, you grab another one. The
> > problem of course is that if the app’s not running you risk
> > clogging the system pretty fast, specially with high performance
> > graphics.
>
> Not a particularly pleasing idea, filling the entire kernel space with
> buffers, eh? If the user-mode app isn’t responding, it’s highly possible
> that it will not do so for a while. It’s probably much better to have a big
> buffer in the first place, than to dynamically expand the buffer(s). At the
> very least, limit the number of buffers so that it doesn’t go too far.
>
> But one thing that I think might work is if there are later commands that
> entirely cover earlier commands (such as blits that don’t use the
> destination as an input, or fill’s), the older ones can be deleted [this is
> probably better seen as an optimisation than a way to reduce the space].
> This culling should be done continually, so that the buffer is always
> “unique”. Unfortunately, a lot of drawing is done based on the previous
> surface, so it’s unlikely to give great gains in anything but special cases
> (where it may well be very useful).
>
> –
> Mats
> >
> > Alberto.
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · March 18, 2005, 10:41am

I have another question about the memory mapping.

Before I used the ExtEscape in user-mode, I printed the starting
address of the input buffer. I also printed the address of input
buffer in the DrvEscape() routine. However, I am quite confused that
both addresses turned out to be the same.

Why the kernel-mode driver and user-mode application share the same
value? Is the GDI routines running in the virtual memory space of the
user-mode app?

Thank you.

Lei

OSR_Community_User · March 18, 2005, 10:45am

xxxxx@lists.osr.com wrote on 03/18/2005 03:24:21 PM:

I agree with Mats that the buffer in the driver should have limited
size. Otherwise the machine may crash easily as long as my user-mode
app never starts. It is an annoying problem.

But how about writing the user-mode app as a service? It can run
before the user logs in. However, I am not quite sure whether it will
starts before the drawing begins.

Yes, I would think that a service would be the best solution for this. The
service will NOT be guaranteed to start before the driver has started (in
fact, I can almost guarantee that the driver is loaded/running before the
service is running).

Can we capture the entire screen by simply using some Win32 API? If
yes, we can start intercepting drawing command after doing that.

Sure. I beleive you just call CreateDC with a NULL parameter (it may be
some other Win32 call) to get a handle to the entire screen. Then bitcopy
from that handle. Search for “PrintScreen” or “ScreenCopy” on the web, and
you’ll find someone’s source code for how to get to the whole screen.

–
Mats

Lei

On Fri, 18 Mar 2005 15:03:16 +0000, Mats PETERSSON
wrote:
> >
> >
> > > One way may to do it be to use a circular buffer: you lose the
> > > older stuff, but only when the system’s overloaded, and the
> > > chucking is automatic. You can also allow the user to configure
> > > the size of the buffer upfront.
> > >
> > > Or you can be a bit more aggressive and implement a chain of
> > > buffers: if you run out of a buffer, you grab another one. The
> > > problem of course is that if the app’s not running you risk
> > > clogging the system pretty fast, specially with high performance
> > > graphics.
> >
> > Not a particularly pleasing idea, filling the entire kernel space with
> > buffers, eh? If the user-mode app isn’t responding, it’s highly
possible
> > that it will not do so for a while. It’s probably much better to have a
big
> > buffer in the first place, than to dynamically expand the buffer(s). At
the
> > very least, limit the number of buffers so that it doesn’t go too far.
> >
> > But one thing that I think might work is if there are later commands
that
> > entirely cover earlier commands (such as blits that don’t use the
> > destination as an input, or fill’s), the older ones can be deleted
[this is
> > probably better seen as an optimisation than a way to reduce the
space].
> > This culling should be done continually, so that the buffer is always
> > “unique”. Unfortunately, a lot of drawing is done based on the previous
> > surface, so it’s unlikely to give great gains in anything but special
cases
> > (where it may well be very useful).
> >
> > –
> > Mats
> > >
> > > Alberto.
> > >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000F07E

OSR_Community_User · March 18, 2005, 10:45am

Lei

You can use this to save a bitmap of the desktop. if you are using a mirror
driver, and you attach to the desktop, use the sample app in the ddk and it
shows you how to get a HDC to you driver. Hope this helps.

Jeff

int getDesktopImage()
{
//Source window handle
HWND hDesktopWnd = GetDesktopWindow();
if (!hDesktopWnd)
{ AfxMessageBox(“failed at hDesktopWnd”);
return 0;
}

int nScreenWidth = 0;
int nScreenHeight = 0;
WINDOWINFO windinfo;
windinfo.cbSize = sizeof(WINDOWINFO);
if (!GetWindowInfo(hDesktopWnd, &windinfo))
{ AfxMessageBox(“Error getting window info”);
return 0;
}

nScreenHeight = windinfo.rcClient.bottom - windinfo.rcClient.top;
nScreenWidth = windinfo.rcClient.right - windinfo.rcClient.left;

//Source window DC
HDC hDesktopDC = GetDC(hDesktopWnd);
if (!hDesktopDC)
{ AfxMessageBox(“failed at hDesktopDC”);
return 0;
}

//Output DC
HDC hCaptureDC = CreateCompatibleDC(hDesktopDC);
if (!hCaptureDC)
{ AfxMessageBox(“failed at hCaptureDC”);
return 0;
}

HBITMAP hCaptureBitmap = CreateCompatibleBitmap(hDesktopDC, nScreenWidth,
nScreenHeight);
if (!hCaptureBitmap)
{ AfxMessageBox(“failed at hCaptureBitmap”);
return 0;
}

if (SelectObject(hCaptureDC, hCaptureBitmap) == HGDI_ERROR)
{ AfxMessageBox(“failed at SelectObject”);
return 0;
}

SendMessage(hDesktopWnd, WM_PRINT, (WPARAM)hCaptureDC, PRF_CLIENT);

if
(!BitBlt(hCaptureDC,0,0,nScreenWidth,nScreenHeight,hDesktopDC,0,0,SRCCOPY))
{ AfxMessageBox(“failed at BitBlt”);
return 0;
}

SaveBitmap(_T(“theDesktop.bmp”), hCaptureBitmap);

ReleaseDC(hDesktopWnd,hDesktopDC);

DeleteDC(hCaptureDC);

DeleteObject(hCaptureBitmap);
return 1;
}

void SaveBitmap(char *szFilename,HBITMAP hBitmap)
{ HDC hdc=NULL;
FILE* fp=NULL;
LPVOID pBuf=NULL;
BITMAPINFO bmpInfo;
BITMAPFILEHEADER bmpFileHeader;
do
{ hdc = GetDC(NULL);
ZeroMemory(&bmpInfo, sizeof(BITMAPINFO));
bmpInfo.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);

int retget = GetDIBits(hdc, hBitmap, 0, 0, NULL, &bmpInfo,
DIB_RGB_COLORS);
//CString myMsg;
//myMsg.Format(“retget is %d \n bmpInfo.bmiHeader.biSizeImage %d”,
retget, bmpInfo.bmiHeader.biSizeImage);
//AfxMessageBox(myMsg);

if(bmpInfo.bmiHeader.biSizeImage <= 0)
{ bmpInfo.bmiHeader.biSizeImage = bmpInfo.bmiHeader.biWidth *
abs(bmpInfo.bmiHeader.biHeight) * (bmpInfo.bmiHeader.biBitCount + 7)/8;
}

//myMsg.Format(“bmpInfo.bmiHeader.biSizeImage %d”,
bmpInfo.bmiHeader.biSizeImage);
//AfxMessageBox(myMsg);

if((pBuf = malloc(bmpInfo.bmiHeader.biSizeImage))==NULL)
{ AfxMessageBox(TEXT(“Unable to Allocate Bitmap Memory”));
break;
}

bmpInfo.bmiHeader.biCompression = BI_RGB;
if (GetDIBits(hdc, hBitmap, 0, bmpInfo.bmiHeader.biHeight, pBuf,
&bmpInfo, DIB_RGB_COLORS) <= 0)
{
// /*
LPVOID lpMsgBuf;
FormatMessage(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
GetLastError(),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
(LPTSTR) &lpMsgBuf,
0,
NULL
);
// Process any inserts in lpMsgBuf.
// …
// Display the string.
MessageBox(NULL, (LPCTSTR)lpMsgBuf, “Error”, MB_OK |
MB_ICONINFORMATION);
// Free the buffer.
LocalFree(lpMsgBuf);
// */
}
if((fp = fopen(szFilename,“wb”))==NULL)
{ AfxMessageBox(TEXT(“Unable to Create Bitmap File”));
break;
}
if (pBuf == (void*)0x00ffffff)
{ AfxMessageBox(TEXT(“pointer is invalid caught here”));
break;
}
bmpFileHeader.bfReserved1 = 0;
bmpFileHeader.bfReserved2 = 0;
bmpFileHeader.bfSize = sizeof(BITMAPFILEHEADER) +
sizeof(BITMAPINFOHEADER) + bmpInfo.bmiHeader.biSizeImage;
bmpFileHeader.bfType = ‘MB’;
bmpFileHeader.bfOffBits = sizeof(BITMAPFILEHEADER) +
sizeof(BITMAPINFOHEADER);
fwrite(&bmpFileHeader, sizeof(BITMAPFILEHEADER), 1, fp);
fwrite(&bmpInfo.bmiHeader, sizeof(BITMAPINFOHEADER), 1, fp);
fwrite(pBuf, bmpInfo.bmiHeader.biSizeImage, 1, fp);
} while(false);
if(hdc)
{ ReleaseDC(NULL,hdc);
}
if(pBuf)
{ if (pBuf != (void*)0x00ffffff)
{ free(pBuf);
}
}
if(fp)
{ fclose(fp);
}
}

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Lei Zhang
Sent: Friday, March 18, 2005 10:24 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to name a device object in video miniport
driver?

I agree with Mats that the buffer in the driver should have limited
size. Otherwise the machine may crash easily as long as my user-mode
app never starts. It is an annoying problem.

But how about writing the user-mode app as a service? It can run
before the user logs in. However, I am not quite sure whether it will
starts before the drawing begins.

Can we capture the entire screen by simply using some Win32 API? If
yes, we can start intercepting drawing command after doing that.

Lei

On Fri, 18 Mar 2005 15:03:16 +0000, Mats PETERSSON
wrote:
>
>
> > One way may to do it be to use a circular buffer: you lose the
> > older stuff, but only when the system’s overloaded, and the
> > chucking is automatic. You can also allow the user to configure
> > the size of the buffer upfront.
> >
> > Or you can be a bit more aggressive and implement a chain of
> > buffers: if you run out of a buffer, you grab another one. The
> > problem of course is that if the app’s not running you risk
> > clogging the system pretty fast, specially with high performance
> > graphics.
>
> Not a particularly pleasing idea, filling the entire kernel space with
> buffers, eh? If the user-mode app isn’t responding, it’s highly possible
> that it will not do so for a while. It’s probably much better to have a
big
> buffer in the first place, than to dynamically expand the buffer(s). At
the
> very least, limit the number of buffers so that it doesn’t go too far.
>
> But one thing that I think might work is if there are later commands that
> entirely cover earlier commands (such as blits that don’t use the
> destination as an input, or fill’s), the older ones can be deleted [this
is
> probably better seen as an optimisation than a way to reduce the space].
> This culling should be done continually, so that the buffer is always
> “unique”. Unfortunately, a lot of drawing is done based on the previous
> surface, so it’s unlikely to give great gains in anything but special
cases
> (where it may well be very useful).
>
> –
> Mats
> >
> > Alberto.
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

You are currently subscribed to ntdev as: xxxxx@resolutions.ws
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · March 18, 2005, 10:53am

xxxxx@lists.osr.com wrote on 03/18/2005 03:40:40 PM:

I have another question about the memory mapping.

Before I used the ExtEscape in user-mode, I printed the starting
address of the input buffer. I also printed the address of input
buffer in the DrvEscape() routine. However, I am quite confused that
both addresses turned out to be the same.

Why the kernel-mode driver and user-mode application share the same
value? Is the GDI routines running in the virtual memory space of the
user-mode app?

Yes, the ExtEscape will just map[1] the user-mode address into kernel space
as is, and keep the virtual address. And yes, it will most likely run in
the virtual space of the application that is running at the moment, and
whilst you probably shouldn’t rely on that being the case, I’d say that the
most likely scenario is that all GDI calls are performed completely under
the task that was running when the call started. [Of course, if you fire
off a DMA-transfer, and wait for an interrupt from the graphics chip to
come back with the appropriate KeWaitForSingleObject, some other task will
probably run for the duration of the wait, as that’s what the OS is
supposed to do in that situation].

[1]I’m not even sure that it needs to be “mapped” at all. It may just be
that GDI is passing the original address, and as long as we’re still in the
same task, it wouldn’t matter. Kernel mode can always access user-space…
But not the other way around.

–
Mats

Thank you.

Lei

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

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT0000F08E