Display driver timers

Hi all,

I’m developing a display driver for Windows XP that needs to read an
I/O port from the graphic adapter every 500ms (that has to be done
from the display driver).

For that, I’ll need to schedule a timer function that will be called
every 500ms, but since I’m linking against win32k.sys, I don’t see any
interface I can use.

I’m thinking about solving it like this:

  1. Reading win32k.sys’ import table and use imports from ntoskrnl
  2. Loading another driver from the disk using EngLoadImage.

I know it’s a bit hacky but what is the best method in your opinion?
Thanks in advance for your help!

David.

David Pilger wrote:

I’m developing a display driver for Windows XP that needs to read an
I/O port from the graphic adapter every 500ms (that has to be done
from the display driver).

Why?

For that, I’ll need to schedule a timer function that will be called
every 500ms, but since I’m linking against win32k.sys, I don’t see any
interface I can use.

I’m thinking about solving it like this:

  1. Reading win32k.sys’ import table and use imports from ntoskrnl
  2. Loading another driver from the disk using EngLoadImage.

I know it’s a bit hacky but what is the best method in your opinion?

The best method is to do this in your miniport, which has full access to
the kernel API. You can have your display driver trigger the timer with
an ioctl. If you absolutely insist, you can pass a function pointer or
a pseudo-COM interface with the ioctl and have the miniport call back
into it.


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

Not an expert in the video driver arena, but I thought that there were some
restrictions about referencing pointers (e.g. callback function pointers) in
session space (e.g. video driver code) from any arbitrary context?


Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> David Pilger wrote:
>>
>> I’m developing a display driver for Windows XP that needs to read an
>> I/O port from the graphic adapter every 500ms (that has to be done
>> from the display driver).
>
> Why?
>
>> For that, I’ll need to schedule a timer function that will be called
>> every 500ms, but since I’m linking against win32k.sys, I don’t see any
>> interface I can use.
>>
>> I’m thinking about solving it like this:
>> 1. Reading win32k.sys’ import table and use imports from ntoskrnl
>> 2. Loading another driver from the disk using EngLoadImage.
>>
>> I know it’s a bit hacky but what is the best method in your opinion?
>
> The best method is to do this in your miniport, which has full access to
> the kernel API. You can have your display driver trigger the timer with
> an ioctl. If you absolutely insist, you can pass a function pointer or
> a pseudo-COM interface with the ioctl and have the miniport call back
> into it.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

Skywing wrote:

Not an expert in the video driver arena, but I thought that there were
some restrictions about referencing pointers (e.g. callback function
pointers) in session space (e.g. video driver code) from any arbitrary
context?

“Session space”? I’m not quite sure what you mean. It’s all kernel
code – it’s one big happy family.


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

Session space is part of the kernel address space that is “instanced” per TS
session, where win32k.sys and things that talk to it (like the display
driver and kernel mode printer drivers live). My recollection is that you
can’t just arbitrarily reference session space from any arbitrary context
from normal kernel code (though you can reference normal system space from
session space). Ivan Brugiolo or one of the other display drivers veterans
can probably correct me if they’re listening and I’m wrong, but that’s my
understanding of it.


Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Skywing wrote:
>> Not an expert in the video driver arena, but I thought that there were
>> some restrictions about referencing pointers (e.g. callback function
>> pointers) in session space (e.g. video driver code) from any arbitrary
>> context?
>>
>
> “Session space”? I’m not quite sure what you mean. It’s all kernel
> code – it’s one big happy family.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

Skywing wrote:

Session space is part of the kernel address space that is “instanced”
per TS session, where win32k.sys and things that talk to it (like the
display driver and kernel mode printer drivers live). My recollection
is that you can’t just arbitrarily reference session space from any
arbitrary context from normal kernel code (though you can reference
normal system space from session space). Ivan Brugiolo or one of the
other display drivers veterans can probably correct me if they’re
listening and I’m wrong, but that’s my understanding of it.

Ah, I see what you mean. Still, I would expect a display driver and its
miniport to always live in the same space.


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

My understanding is that the miniport is (necessarily) in regular system
space because it needs to handle requests (like interrupts) in an arbitrary
context, whereas the display driver is only called upon from the correct
session. However, again, not super familiar with display driver stuff.


Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Skywing wrote:
>> Session space is part of the kernel address space that is “instanced”
>> per TS session, where win32k.sys and things that talk to it (like the
>> display driver and kernel mode printer drivers live). My recollection
>> is that you can’t just arbitrarily reference session space from any
>> arbitrary context from normal kernel code (though you can reference
>> normal system space from session space). Ivan Brugiolo or one of the
>> other display drivers veterans can probably correct me if they’re
>> listening and I’m wrong, but that’s my understanding of it.
>>
>
> Ah, I see what you mean. Still, I would expect a display driver and its
> miniport to always live in the same space.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

Yes, it’s not possible to access data that is present on session space
from outside of it (gracefully encountered bsods 0xCF, 0xD1).

I’ve managed to create an export DLL (kernel DLL) that is linking
against ntoskrnl.exe and load it from my display driver, but I could
not use Timers, DPCs and WorkItems becuase the code is reffererncing
session-space data and callbacks (The DLL itself is loaded into
session-space)

I’ll try to allocate a chunk from NonPagedPool, and copy the function
code & data to that region and see if it works. Do you have any other
ideas on how to get out of session-space? I’ll might copy the whole
DLL into NonPagedPool :slight_smile:

David.

On 7/24/07, Skywing wrote:
> My understanding is that the miniport is (necessarily) in regular system
> space because it needs to handle requests (like interrupts) in an arbitrary
> context, whereas the display driver is only called upon from the correct
> session. However, again, not super familiar with display driver stuff.
>
> –
> Ken Johnson (Skywing)
> Windows SDK MVP
> http://www.nynaeve.net
> “Tim Roberts” wrote in message news:xxxxx@ntdev…
> > Skywing wrote:
> >> Session space is part of the kernel address space that is “instanced”
> >> per TS session, where win32k.sys and things that talk to it (like the
> >> display driver and kernel mode printer drivers live). My recollection
> >> is that you can’t just arbitrarily reference session space from any
> >> arbitrary context from normal kernel code (though you can reference
> >> normal system space from session space). Ivan Brugiolo or one of the
> >> other display drivers veterans can probably correct me if they’re
> >> listening and I’m wrong, but that’s my understanding of it.
> >>
> >
> > Ah, I see what you mean. Still, I would expect a display driver and its
> > miniport to always live in the same space.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

You might expect that, but Skywing is right. The different sessions have
different instance data, each mapped into the same virtual address range in
kernel mode, which is backed differently from session to session. This
allows the code in win32k to very cheaply run against multiple sessions.

  • Jake Oshins
    Windows Kernel Team

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Skywing wrote:
>> Session space is part of the kernel address space that is “instanced”
>> per TS session, where win32k.sys and things that talk to it (like the
>> display driver and kernel mode printer drivers live). My recollection
>> is that you can’t just arbitrarily reference session space from any
>> arbitrary context from normal kernel code (though you can reference
>> normal system space from session space). Ivan Brugiolo or one of the
>> other display drivers veterans can probably correct me if they’re
>> listening and I’m wrong, but that’s my understanding of it.
>>
>
> Ah, I see what you mean. Still, I would expect a display driver and its
> miniport to always live in the same space.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>