display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>>I can’t use DDML because nothing is going to the display per se (it’s

>going to rdpdd.sys through terminal server).
Sorry for being an intruder but I needed some help regarding DDML
… As u have mentioned it in ur post I would be very obliged if u can
guide me a little abt DDML … Actually I have posted my query twice on the
list but still no satisfactory answer…
Actually I need comprehansive documentation of DDMl which cant find in DDK
documentation… Where did u get info abt it. .
thanks in anticipation


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

There is a terminal services client for our hand held OS, however, we want
to scale specific applications very specific ways (and perhaps include and
exclude certain parts of different screens). We actually have an old DOS
based product (character based) that works this way where you can include
and exclude certain fields. We’re trying to emulate that behavior as much
as possible in a GUI environment.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Barila, Phil
Sent: Wednesday, June 13, 2001 16:58
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: xxxxx@intel.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@connectrf.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

There don’t seem to be many display driver writers on this list, so I’m not
sure how much help we’ll be to you, but I hope someone else knows how to
solve the problem you are trying to solve.

I’ll admit right now that I don’t still understand the problem. You
mentioned Terminal Services, and I am just not getting what you are trying
to use it for. Is your app executing locally to the hand-held, or remotely
on the TS? TS enables you to execute a GUI app on a remote CPU. It won’t
help you much if you are just trying to get the remote CPU to exec a process
for you. There are *much* better ways to get REXEC functionality than TS.

If it’s on the TS, is it possible to just rewrite the GUI of your app to do
what you want? Again, I don’t really understand the problem, but if you
explain it well enough for *me* to understand, you might stir *someone* to
think up the right solution.

Phil

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Thursday, June 14, 2001 4:46 AM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

There is a terminal services client for our hand held OS, however, we want
to scale specific applications very specific ways (and perhaps include and
exclude certain parts of different screens). We actually have an old DOS
based product (character based) that works this way where you can include
and exclude certain fields. We’re trying to emulate that behavior as much
as possible in a GUI environment.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Barila, Phil
Sent: Wednesday, June 13, 2001 16:58
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I don’t know much about TS, but intercepting all display driver calls may be
a tall order! The first thing to do is to read the “Graphics Drivers”
section of the DDK documentation, and take a look at some of the samples at
your \ddk\src\video directory. Display drivers are plain vanilla DLLs, they
do not follow WDM or WinNT device driver models; there are no IRPs, no
driver stacks, no interrupts to handle, no DPCs, and so on. There’s just the
calls, the data structures, and the iron.

And be prepared for the eventuality of having to write a whole lot of code!

I am assuming, from what I understand, that what he wants to do is to
intercept DDI calls, munge them, package them into some sort of packet, and
ship them out to the remote machine. This can be done, but it’s a big job,
because there are so many entry points to negotiate: DrvXxxxx, EngXxxxx,
DdXxxxx, D3dXxxxx, OpenGL MCD and ICD, Wgl, and more. Then you’re going to
have to allow for punting to the native display driver. Then you’re going to
have to handle bitmap caching. Then you’re going to have to make sure that
when your display driver punts to the GDI, that the GDI has a consistent
view of your remotes. Then you have the issue of handling multiple monitors.
Then you have Dos Box issues. Then you have to negotiate dynamic mode
changes. Then you’ll bump into people who drive their hardware directly from
Ring 3, without going through the display driver. Then you may have to
support negotiation and synchronization between the 2D and 3D drivers, and
that negotiation is often private to the graphics chip vendor and not
documented, and it changes from chip to chip and from machine to machine.

And much more. I don’t know, are you sure you want to go that way ? Sounds
to me like a lot of work! You may be opening a Pandora’s box by starting
this kind of project.

But hey, if you find a decent way of going about it, more power to you! Hope
this helps,

Alberto.

-----Original Message-----
From: Barila, Phil [mailto:xxxxx@intel.com]
Sent: Thursday, June 14, 2001 12:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

There don’t seem to be many display driver writers on this list, so I’m not
sure how much help we’ll be to you, but I hope someone else knows how to
solve the problem you are trying to solve.

I’ll admit right now that I don’t still understand the problem. You
mentioned Terminal Services, and I am just not getting what you are trying
to use it for. Is your app executing locally to the hand-held, or remotely
on the TS? TS enables you to execute a GUI app on a remote CPU. It won’t
help you much if you are just trying to get the remote CPU to exec a process
for you. There are *much* better ways to get REXEC functionality than TS.

If it’s on the TS, is it possible to just rewrite the GUI of your app to do
what you want? Again, I don’t really understand the problem, but if you
explain it well enough for *me* to understand, you might stir *someone* to
think up the right solution.

Phil

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Thursday, June 14, 2001 4:46 AM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

There is a terminal services client for our hand held OS, however, we want
to scale specific applications very specific ways (and perhaps include and
exclude certain parts of different screens). We actually have an old DOS
based product (character based) that works this way where you can include
and exclude certain fields. We’re trying to emulate that behavior as much
as possible in a GUI environment.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Barila, Phil
Sent: Wednesday, June 13, 2001 16:58
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Alberto makes many good points. I know even less than “not much”
about TS.

However, if a display driver is what’s needed…

Display drivers are plain vanilla DLLs, they do not follow WDM or
WinNT device driver models; there are no IRPs, no driver stacks, no
interrupts to handle, no DPCs, and so on.

yes, IRPs happen to the video port. Interrupts in the video miniport.
You will need a miniport but it doesn’t need to do much if there is no
hardware.

And be prepared for the eventuality of having to write a whole lot
of code!

If you’re talking about intercepting calls intended for another
display driver - yes that would be a big job and yes, there would be
many entry points to take care of, perhaps even including DirectDraw.

However, if we’re simply talking about a ‘normal’ display driver
(albeit without display hardware on the system) i.e. one which is seen
by the system and is attached to the desktop - then things are
somewhat simpler. A barebones GDI display driver may be enough. You
don’t have to support bitmap caching. Specify only a minimum set of
display modes - if you support one only then, possibly, you won’t get
dynamic mode changes (I’ve never tried making a display driver with
only one mode, but I have one with as few a four). I don’t think dynamic
mode changes are much of a problem anyway. Not sure, but DosBoxes
might not be a problem. Yes, need to be careful if you’re doing any
punting - you’ll probably get called back when GDI breaks the call up
into simpler ones. Multiple displays - I assume we’re taking about
Win2k and attaching this display to the desktop and that portion of
the desktop go to the handheld. In that case, multiple displays
shouldn’t be a problem. Multiple displays on NT4 would be more of a
problem.

It might be worth looking at the video mirror driver to get an idea of
what a barebones display driver might look like. There are even
comments in there to indicate when and where to put bits on the wire.
The Readme.txt in the mirror\App directory lists the minumum Drv
functions.

Btw, installing such driver is something I’m not sure about. I asked
this about the mirror driver about a week ago. How does such a
(display) driver get installed (i.e. how to you make it be installed)
when there is no hardware? Dumb question - probably a blind spot on
my part.

I’m also not sure if this is what you want to do. It’s a little more
info anyway - hope some of it helps.

Gordon


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Actually, you’ve got it just about right except for the packaging part. In
Terminal Services, there is a display driver called rdpdd.sys that is a
display driver itself. It actually does the capturing, packaging and
routing to rdp which then does the transmission to the remote machine. I
don’t want to have to deal with the packaging and such, so what I’d like to
do is sit in the display driver chain before rdpdd.sys. This way I can muck
w/ the GDI calls before rdpdd. After I have my fun, rdpdd will get the call
(at this point, all should be transparent to rdpdd) and away the call goes
as normal.

I thank you for the suggestions. I have been reading the DDK docs and
looking at the source code. I suppose this being my first time ever looking
into writing a device driver makes this information seem overwhelming. I
had a feeling that reading the DDK docs to learn to write a device driver
was like reading MSDN to learn how to program C++ and Windows (that didn’t
work for me anyhow). I was hoping that there was a way that was little more
clear cut, but perhaps. It can’t always be easy :>

I thank you very much for the response and suggestions.

Bill

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Thursday, June 14, 2001 13:47
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

I don’t know much about TS, but intercepting all display driver calls may be
a tall order! The first thing to do is to read the “Graphics Drivers”
section of the DDK documentation, and take a look at some of the samples at
your \ddk\src\video directory. Display drivers are plain vanilla DLLs, they
do not follow WDM or WinNT device driver models; there are no IRPs, no
driver stacks, no interrupts to handle, no DPCs, and so on. There’s just the
calls, the data structures, and the iron.

And be prepared for the eventuality of having to write a whole lot of code!

I am assuming, from what I understand, that what he wants to do is to
intercept DDI calls, munge them, package them into some sort of packet, and
ship them out to the remote machine. This can be done, but it’s a big job,
because there are so many entry points to negotiate: DrvXxxxx, EngXxxxx,
DdXxxxx, D3dXxxxx, OpenGL MCD and ICD, Wgl, and more. Then you’re going to
have to allow for punting to the native display driver. Then you’re going to
have to handle bitmap caching. Then you’re going to have to make sure that
when your display driver punts to the GDI, that the GDI has a consistent
view of your remotes. Then you have the issue of handling multiple monitors.
Then you have Dos Box issues. Then you have to negotiate dynamic mode
changes. Then you’ll bump into people who drive their hardware directly from
Ring 3, without going through the display driver. Then you may have to
support negotiation and synchronization between the 2D and 3D drivers, and
that negotiation is often private to the graphics chip vendor and not
documented, and it changes from chip to chip and from machine to machine.

And much more. I don’t know, are you sure you want to go that way ? Sounds
to me like a lot of work! You may be opening a Pandora’s box by starting
this kind of project.

But hey, if you find a decent way of going about it, more power to you! Hope
this helps,

Alberto.

-----Original Message-----
From: Barila, Phil [mailto:xxxxx@intel.com]
Sent: Thursday, June 14, 2001 12:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

There don’t seem to be many display driver writers on this list, so I’m not
sure how much help we’ll be to you, but I hope someone else knows how to
solve the problem you are trying to solve.

I’ll admit right now that I don’t still understand the problem. You
mentioned Terminal Services, and I am just not getting what you are trying
to use it for. Is your app executing locally to the hand-held, or remotely
on the TS? TS enables you to execute a GUI app on a remote CPU. It won’t
help you much if you are just trying to get the remote CPU to exec a process
for you. There are *much* better ways to get REXEC functionality than TS.

If it’s on the TS, is it possible to just rewrite the GUI of your app to do
what you want? Again, I don’t really understand the problem, but if you
explain it well enough for *me* to understand, you might stir *someone* to
think up the right solution.

Phil

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Thursday, June 14, 2001 4:46 AM
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

There is a terminal services client for our hand held OS, however, we want
to scale specific applications very specific ways (and perhaps include and
exclude certain parts of different screens). We actually have an old DOS
based product (character based) that works this way where you can include
and exclude certain fields. We’re trying to emulate that behavior as much
as possible in a GUI environment.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Barila, Phil
Sent: Wednesday, June 13, 2001 16:58
To: NT Developers Interest List
Subject: [ntdev] RE: display driver questions

I can’t tell if you are trying to write a Terminal Services client for your
hand-held OS or something else. But it sounds like the problem you are
trying to solve would be solved if there was a Terminal Services client for
your hand-held OS. Is this correct?

-----Original Message-----
From: Bill Buchanan [mailto:xxxxx@connectrf.com]
Sent: Wednesday, June 13, 2001 1:40 PM
To: NT Developers Interest List
Subject: [ntdev] display driver questions

Hello,
First off, apologies as I am extremely new to the device driver world (been
an application guy for 6+ years). Our R&D team is researching a way to
accomplish a seemingly small task. That task being, a way to allow our
users to scale our Win32 applications to fit onto hand held devices. We’d
like to do this using Terminal Server to run and display the data on the
hand helds.

It sounds like what I need to do is write a “dummy” display driver and
insert it into the display driver chain so that I can intercept all GDI
calls and reformat them according to very specific instructions from our
users. After that, I can pass it along to the “real” display driver. I
can’t use DDML because nothing is going to the display per se (it’s going to
rdpdd.sys through terminal server).

Does this sound feasible? If so, can someone give me some clues as to how I
might get started writing this dummy display driver? I have the DDK and the
book by Newcomer but I’m getting nowhere fast. Any help is greatly
appreciated. Thank you.

Bill Buchanan


You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@connectrf.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> Actually, you’ve got it just about right except for the packaging part.
In

Terminal Services, there is a display driver called rdpdd.sys that is a
display driver itself. It actually does the capturing, packaging and
routing to rdp which then does the transmission to the remote machine. I

BTW - how does RDP works? By sending the bitmap deltas like pcANYWHERE?
Or by sending the “draw primitive” commands like X11?

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hello :
Gordon i guess u have been messing up with Mirror
Display Drivers. Keeping in view ur comments

It might be worth looking at the video mirror driver
to get an idea of
what a barebones display driver might look like.
There are even
comments in there to indicate when and where to put
bits on the wire.
I have tried to study the mirror sample but
could not find a way to use it significantly to send
display info on the wire. I hope u have come upto
something

xxxxx@iee.org wrote:


It might be worth looking at the video mirror driver
to get an idea of
what a barebones display driver might look like.
There are even
comments in there to indicate when and where to put
bits on the wire.


Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

irfan bashir:

Hello :
Gordon i guess u have been messing up with Mirror
Display Drivers. Keeping in view ur comments
> It might be worth looking at the video mirror driver
> to get an idea of
> what a barebones display driver might look like.
> There are even
> comments in there to indicate when and where to put
> bits on the wire.
I have tried to study the mirror sample but
could not find a way to use it significantly to send
display info on the wire. I hope u have come upto
something

well, I’ve worked on a number of fully fledged display drivers but I havn’t
actually messed with Mirror Display Drivers other than to try and
understand how they are installed and glancing over the code in the sample
driver. (The best description that I’ve found is the one I mentioned
before: http://www.microsoft.com/hwdev/video/gdidispa.htm.)

It seemed to me, looking at the sample mirror driver code, that it might be
a good starting off point for what you wanted to do. Apart from that, it
also gives a fairly good picture of what a barebones display driver, of any
sort, might look like.

Unfortunately for you I also get the impression that very few people have
actually worked on display mirror drivers.

In the absence of any directly relevant infomation here are a few general
things which might help you but which I appreciate may already be known to
you:

First: You can communicate from user-mode to the display driver using
“driver escapes”. These are simple synchronous calls, strictly from
user-mode to display driver.

You would add a line like this to your display driver’s DrvFn table:

{INDEX_DrvEscape, (PFN) DrvEscape},

…and create the function “DrvEscape” in your display driver. This
function will get called when the user-mode application calls ExtEscape.
The user-mode application passes down an escape code (defined by you) plus
buffers to transfer data in to and/or out of the driver.

You might find this mechanism useful for setting up or controlling your
display driver. Note that you can only use it if the user-mode application
can create a DC (“Device Context”) on that “display”. This is usually the
case and I assume it’s also the case with mirror drivers although I’ve
never actually tried it on mirror drivers. (To get a DC you enumerate the
displays in user-mode and, having found the correct display, you call the
GDI function CreateDC passing down the name of the display.)

Second: The display driver can dynamically load and call other dll’s.

Third: If you find that you need to access normal kernel functions as
defined in NTDDK.h be aware that you can’t call them from the display
driver. You can, however, call ntddk.h functions from the video miniport
(which is callable from the display driver using EngDeviceIoControl). It
should be said that, strictly, the miniport
is only supposed to use VideoPort functions. If you find that you do have
to call ntddk.h functions from the video miniport you’ll discover
that you can’t #include video.h and ntddk.h in the same module. To get
around this I suggest you use a separate module in your video miniport
which #includes ntddk.h and put all functions which call ntddk functions
in
there.

I realise none of this relates to getting stuff “on the wire” but it might
help you think about how you might architect a display mirror
driver/miniport pair to do what you want. If what I’ve said is unclear -
ignore it! - it’s almost certainly irrelevant to your goal.

And, apologies if I’ve only repeated the obvious.

Gordon


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com