How does a kernel driver control a DirectX?

NTDEV
1

I am working on a driver that needs to write data to a Directx overlay and
flip the overlay. I looked at using DxApi to access the overlay but it does
not appear to be available on my target (embedded unit). To test this I
used some test code to get the IDirectDrawKernel interface from the DirectX
object.
The code run successfully on my development pc but returns S_FALSE on the
target.
So I have some questions.

  1. Does the display have to have a videoport to use DxAPI stuff? - my
    target does not have a video port according to the DXCapsViewer but it does
    have overlay support.

  2. Where does the videoport support come from - my video driver or DirectX?
    The video chip is a Via Twister S3 chip and I am running DirectX 8.1.

  3. So assuming I can not use Dxapim, can my driver use the standard directX
    user mode calls to Lock/Unlock the overlay and flip? If not then what
    can I use?

Thanks
Tom

2

Tom wrote:

I am working on a driver that needs to write data to a Directx overlay and
flip the overlay. I looked at using DxApi to access the overlay but it does
not appear to be available on my target (embedded unit).

Does that mean Windows CE or Window XP Embedded? Or something else?

  1. Does the display have to have a videoport to use DxAPI stuff? - my
    target does not have a video port according to the DXCapsViewer but it does
    have overlay support.

  2. Where does the videoport support come from - my video driver or DirectX?
    The video chip is a Via Twister S3 chip and I am running DirectX 8.1.

The videoport support comes from the video miniport driver. The S3
Twister definitely has videoport hardware.

  1. So assuming I can not use Dxapim, can my driver use the standard directX
    user mode calls to Lock/Unlock the overlay and flip? If not then what
    can I use?

The standard DirectX calls are user-mode. If you can engineer things to
have a user-mode helper, you will probably end up with a more generic
and flexible solution.

–

3

> Does that mean Windows CE or Window XP Embedded? Or something else?

The embedded system is XP embedded but I have run the DXCaps Viewer on XPE,
standard XP sp1 and Windows 2000 (on the same hardware) and in all cases it
showed MaxVideoPorts as 0. I tried the DXapi call on XPE and Win2000 and
failed on both. I also tried an QueryInterface for IDirectDrawKernel
interface from a simple user app. The app worked on my development PC
(DxCaps shows a MaxVideoPort =1 on the development PC) but failed on my
embedded system.

So for now I am just working on standard XP and once I get the driver
running will test on XPE.

The videoport support comes from the video miniport driver. The S3
Twister definitely has videoport hardware.

The embedded system uses an ETX module made by Kontron and uses the Via
Twister T chips - VT8606 and VT82C686B. I am using the “Twister XP2K
139362_1 NoHotKey logod” driver from the S3 website (direct to it from the
Via website).

Given the Dxcaps viewer shows no available Videoports what should I check
for next?

The standard DirectX calls are user-mode. If you can engineer things to
have a user-mode helper, you will probably end up with a more generic
and flexible solution.

I need to control the overlay in my driver so do not want to make a user
mode helper. The driver needs to get a lock on an overlay backbuffer (so
the PCI chip can DMA the data to the overlay) then Unlock and flip the
overlay backbuffer. The only reference I have seen to a driver controlling
an overlay used the DxApi which does not appear to work on my embedded
system.

Can you tell me what functions I can use in the driver to control the
directx overlay or an article or sample to look at?

Thanks
Tom

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Tom wrote:
>
> >I am working on a driver that needs to write data to a Directx overlay
and
> >flip the overlay. I looked at using DxApi to access the overlay but it
does
> >not appear to be available on my target (embedded unit).
> >
>
> Does that mean Windows CE or Window XP Embedded? Or something else?
>
> >1. Does the display have to have a videoport to use DxAPI stuff? - my
> >target does not have a video port according to the DXCapsViewer but it
does
> >have overlay support.
> >
> >2. Where does the videoport support come from - my video driver or
DirectX?
> > The video chip is a Via Twister S3 chip and I am running DirectX 8.1.
> >
> >
>
> The videoport support comes from the video miniport driver. The S3
> Twister definitely has videoport hardware.
>
> >3. So assuming I can not use Dxapim, can my driver use the standard
directX
> >user mode calls to Lock/Unlock the overlay and flip? If not then what
> >can I use?
> >
> >
>
> The standard DirectX calls are user-mode. If you can engineer things to
> have a user-mode helper, you will probably end up with a more generic
> and flexible solution.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

4

Tom wrote:

>The videoport support comes from the video miniport driver. The S3
>Twister definitely has videoport hardware.
>
>

The embedded system uses an ETX module made by Kontron and uses the Via
Twister T chips - VT8606 and VT82C686B. I am using the “Twister XP2K
139362_1 NoHotKey logod” driver from the S3 website (direct to it from the
Via website).

Given the Dxcaps viewer shows no available Videoports what should I check
for next?

Please allow me to eat my own words. I just checked the register specs
to confirm, and in fact the ProSavage and Twister chips do NOT have
videoport hardware. I thought all of the Savage engines had it. That’s
what I get for not checking before I post.

So, the driver’s answer is correct.

I need to control the overlay in my driver so do not want to make a user
mode helper.

Well, if the kernel mode APIs won’t solve your problem, then I would
think the user mode alternative would start to look pretty darned
attractive. A simple high-priority thread, blocked waiting for a signal
from your driver, could do this pretty easily. It could pass the
overlay surface addresses down to the kernel driver during its
initialization; you wouldn’t have to defer the drawing to user-mode.

–

5

Thanks for the reply on the videoport issue. Where did you get the
information to see that the Twister chip did not have videoport support? I
am getting differnent computer module that uses the Intel 82815 graphics
chip so maybe it will have videoport support.

I am surprised that is no way for a driver, other then DxAPI (the only thing
I have found), to call directx functions.

Your idea on have the user thread wait for a signal sounds interesting just
concerned about what will happen if the driver tries to use a surface before
the thread gets it ready.

Thanks again.
Tom

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Tom wrote:
>
> >
> >
> >>The videoport support comes from the video miniport driver. The S3
> >>Twister definitely has videoport hardware.
> >>
> >>
> >
> >The embedded system uses an ETX module made by Kontron and uses the Via
> >Twister T chips - VT8606 and VT82C686B. I am using the “Twister XP2K
> >139362_1 NoHotKey logod” driver from the S3 website (direct to it from
the
> >Via website).
> >
> >Given the Dxcaps viewer shows no available Videoports what should I check
> >for next?
> >
> >
>
> Please allow me to eat my own words. I just checked the register specs
> to confirm, and in fact the ProSavage and Twister chips do NOT have
> videoport hardware. I thought all of the Savage engines had it. That’s
> what I get for not checking before I post.
>
> So, the driver’s answer is correct.
>
> >I need to control the overlay in my driver so do not want to make a user
> >mode helper.
> >
>
> Well, if the kernel mode APIs won’t solve your problem, then I would
> think the user mode alternative would start to look pretty darned
> attractive. A simple high-priority thread, blocked waiting for a signal
> from your driver, could do this pretty easily. It could pass the
> overlay surface addresses down to the kernel driver during its
> initialization; you wouldn’t have to defer the drawing to user-mode.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

6

Tom wrote:

Thanks for the reply on the videoport issue. Where did you get the
information to see that the Twister chip did not have videoport support?

I spent a number of years under contract to S3, doing all of their
legacy display driver maintenance (where “legacy” meant “anything their
internal driver team no longer found interesting”), and their XFree86
driver for Linux. I gathered a rather complete collection of Savage
chip specs.

It was a good gig. It ended, along with any excitement the company
might have had, when they got bought by VIA.

I am getting differnent computer module that uses the Intel 82815 graphics
chip so maybe it will have videoport support.

Since I have a disease that renders me unable to avoid answering
technical questions, I looked this up. The 82815 also lacks a videoport.

You can download the 82815 graphics chip spec from Intel’s web site. In
my opinion, Intel has done an outstanding job of collecting and
organizing their technical documentation.

I am surprised that is no way for a driver, other then DxAPI (the only thing
I have found), to call directx functions.

Really? Other than the capture-driver-preview-to-videoport model, it is
difficult for me to come up with scenarios in which driver access to
DirectX makes sense. User interface is supposed to be a user-mode concept.

Your idea on have the user thread wait for a signal sounds interesting just
concerned about what will happen if the driver tries to use a surface before
the thread gets it ready.

I’m committing heresy here, but in practical terms, this is never a
problem. Locking a surface is, for the most part, purely decorative.
Surfaces in device memory never move, and every graphics controller
today is able to accept DMA data at arbitrary times (although this
wasn’t the case 5 years ago).

–

7

I received the other computer module and just like you said it has no
videoport. I will still try the module as I was also hitting some PCI DMA
issues to see if the intel chips do better then the VIA chips.

What I thought to do with the driver was something like this. (May only
need 2 buffers instead of three.)

  1. DMA to buffer 1. Get pointer to buffer 2. Flip buffer 3 to display.
  2. Start dma to buffer 2 and flip buffer 1 to the display get pointer to
    buffer 3.
  3. Dma to buffer 3, Flip buffer 2 to display, get pointer to buffer 1
    go back to step 1.

So you are saying the pointers to the overlays will stay constant and all I
need to do is flip the buffer to the display at the correct time. Great!

Thanks
Tom

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Tom wrote:
>
> >Thanks for the reply on the videoport issue. Where did you get the
> >information to see that the Twister chip did not have videoport support?
> >
>
> I spent a number of years under contract to S3, doing all of their
> legacy display driver maintenance (where “legacy” meant “anything their
> internal driver team no longer found interesting”), and their XFree86
> driver for Linux. I gathered a rather complete collection of Savage
> chip specs.
>
> It was a good gig. It ended, along with any excitement the company
> might have had, when they got bought by VIA.
>
> >I am getting differnent computer module that uses the Intel 82815
graphics
> >chip so maybe it will have videoport support.
> >
> >
>
> Since I have a disease that renders me unable to avoid answering
> technical questions, I looked this up. The 82815 also lacks a videoport.
>
> You can download the 82815 graphics chip spec from Intel’s web site. In
> my opinion, Intel has done an outstanding job of collecting and
> organizing their technical documentation.
>
> >I am surprised that is no way for a driver, other then DxAPI (the only
thing
> >I have found), to call directx functions.
> >
> >
>
> Really? Other than the capture-driver-preview-to-videoport model, it is
> difficult for me to come up with scenarios in which driver access to
> DirectX makes sense. User interface is supposed to be a user-mode
concept.
>
> >Your idea on have the user thread wait for a signal sounds interesting
just
> >concerned about what will happen if the driver tries to use a surface
before
> >the thread gets it ready.
> >
> >
>
> I’m committing heresy here, but in practical terms, this is never a
> problem. Locking a surface is, for the most part, purely decorative.
> Surfaces in device memory never move, and every graphics controller
> today is able to accept DMA data at arbitrary times (although this
> wasn’t the case 5 years ago).
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

8

Tom wrote:

I received the other computer module and just like you said it has no
videoport. I will still try the module as I was also hitting some PCI DMA
issues to see if the intel chips do better then the VIA chips.

What I thought to do with the driver was something like this. (May only
need 2 buffers instead of three.)

  1. DMA to buffer 1. Get pointer to buffer 2. Flip buffer 3 to display.
  2. Start dma to buffer 2 and flip buffer 1 to the display get pointer to
    buffer 3.
  3. Dma to buffer 3, Flip buffer 2 to display, get pointer to buffer 1
    go back to step 1.

So you are saying the pointers to the overlays will stay constant and all I
need to do is flip the buffer to the display at the correct time. Great!

Theoretically, they are allowed to change outside of Lock/Unlock. In
the real world, they never do.

Both the i815 and the Twister are UMA devices – the frame buffers are
part of system memory. That puts a limit on your performance. Plus, it
means screen refresh comes out of your system memory bandwidth; if
you’re running high refresh rates, that can hurt.

–

9

Currently the embedded hardware is running on Windows 98 and the Live Video
preview stuff (VXD) runs fine. I can even lockup the main program and the
video just keeps running. That is why I was surprised that testing showed
the poor performance (on the same hardware with more memory) of XP and WDM
of the live video under load. I am assuming the issue is the WDM stuff and
that making my own ‘direct’ driver will have performance like Win98 did.

Do you have any suggestions of why the performance issue with XP verses
Win98?

Thanks
Tom

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> Tom wrote:
>
> >I received the other computer module and just like you said it has no
> >videoport. I will still try the module as I was also hitting some PCI
DMA
> >issues to see if the intel chips do better then the VIA chips.
> >
> >What I thought to do with the driver was something like this. (May only
> >need 2 buffers instead of three.)
> >1. DMA to buffer 1. Get pointer to buffer 2. Flip buffer 3 to display.
> >2. Start dma to buffer 2 and flip buffer 1 to the display get pointer to
> >buffer 3.
> >3. Dma to buffer 3, Flip buffer 2 to display, get pointer to buffer 1
> >go back to step 1.
> >
> > So you are saying the pointers to the overlays will stay constant and
all I
> >need to do is flip the buffer to the display at the correct time. Great!
> >
> >
>
> Theoretically, they are allowed to change outside of Lock/Unlock. In
> the real world, they never do.
>
> Both the i815 and the Twister are UMA devices – the frame buffers are
> part of system memory. That puts a limit on your performance. Plus, it
> means screen refresh comes out of your system memory bandwidth; if
> you’re running high refresh rates, that can hurt.
>
> –
> - Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>