Mirror display driver questions

Hi,

I read a lot of emails about Mirror display driver and it was very useful for my implementation.

I have a mirror driver working with file shared memory, it calls EngMapFile( L"\??\c:\CxVideo.dat", … ); on DrvEnableSurface(…). It was simpler and I need implement other stuff to see all the system working. (divided the screen (chunks), get the update chunks, send them to network). In the other peer, receive the chunks and ‘paint’ it.

I have two questions, because I am facing some problems:

i) I’d like to use shared map between user app and driver. I know that the video mini port can allocate memory, I’d like to know how can I map it to user app. Just pass the pointer?? Is it safe? The user app will only read the memory but is it allowed? If somebody shows me the path, major points to study.

ii) are all the calls of Drv* functions exclusive? Is it work like a message quere with calls of DrvBitBlt(…), DrvCopyBits(…), etc… I am asking because when I call ExtEscape(…) and DrvEscape will be invoked, can it run concurrency with other Drv* Function?

iii) When I am changing the video mode, my machine is rebooting. I guess that it is because memory is mapped. However, I am unmapping it in DrvDisableSurface(…). What kind of behavior I have to manage to handle this.

Thank’s for any help and sorry about my english mistakes.

Guilherme

xxxxx@ieee.org wrote:

I have two questions, because I am facing some problems:

i) I’d like to use shared map between user app and driver. I know that the video mini port can allocate memory, I’d like to know how can I map it to user app. Just pass the pointer?? Is it safe? The user app will only read the memory but is it allowed? If somebody shows me the path, major points to study.

As long as you are mapping a file, why don’t you just use
CreateFileMapping in the user mode app? Each one will get a pointer to
the same memory that is valid in the proper context.

You can’t pass a kernel address to user mode. You could map the memory
into the process, but CreateFileMapping was designed to do that in this
case.

ii) are all the calls of Drv* functions exclusive? Is it work like a message quere with calls of DrvBitBlt(…), DrvCopyBits(…), etc… I am asking because when I call ExtEscape(…) and DrvEscape will be invoked, can it run concurrency with other Drv* Function?

GDI driver calls are serialized.

iii) When I am changing the video mode, my machine is rebooting. I guess that it is because memory is mapped. However, I am unmapping it in DrvDisableSurface(…). What kind of behavior I have to manage to handle this.

An automatic reboot means that you have encountered a “blue screen”. In
XP, the default setting is to reboot automatically instead of showing
the scary blue screen. Go to the system control panel applet, pick
Advnaced, Startup and Recovery Settings, and turn off “Automatically
restart”. You can also change the memory dump to “kernel memory dump”,
so that you can get enough to analyze.

Or, you could just attach a kernel debugger. Then, your blue screen
will break into the debugger, and you can see what is the issue.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thank you for your answer Tim. I will attach a debug tomorrow, I know that I
need to prepare the environment for that and I don’t have all the cables
here.

My problem with FileMapping born when I sent my software to test it with a
friend and it didn’t work because he didn’t have drive “C:” in his computer
( he installed windows on F:). It makes me think, if the user doesn’t have
drive C: or doesn’t have enough space in his disk, it won’t run.

I decided to study a way to map memory using another method. I know that
FileMapping is the easiest way, but It isn’t 100% guaranteed.

As you told and I imagined it’s not allowed to pass a pointer from kernel to
user scope. How can I map the memory into the process? Can you detail a bit
more the steps?

Thank you for the others answers.

Regards, cox

Guilherme Cox wrote:

My problem with FileMapping born when I sent my software to test it
with a friend and it didn’t work because he didn’t have drive “C:” in
his computer ( he installed windows on F:). It makes me think, if the
user doesn’t have drive C: or doesn’t have enough space in his disk,
it won’t run.

The drive letter thing is certainly a solvable problem. The special
name \SystemRoot is symbolically linked to the Windows directory,
wherever it lives.

If there isn’t enough disk to create a file for mapping, then there
won’t be enough disk to back the memory with a swap file, either.
Graceful failure is certainly an option.

I decided to study a way to map memory using another method. I know
that FileMapping is the easiest way, but It isn’t 100% guaranteed.

No memory allocation method is 100% guaranteed. Can’t be done. Running
out of non-paged pool is more likely that running out of disk space
these days.

As you told and I imagined it’s not allowed to pass a pointer from
kernel to user scope. How can I map the memory into the process? Can
you detail a bit more the steps?

Your mirror miniport can use VideoPortMapMemory to do this, but I would
argue that the mapped file is a better solution.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.