Designing video miniport driver using USB

NTDEV
1

Hello, everyone.

I’m developing sub display adapter using USB.

Because I’m quite a newbie in Windows device driver development, I don’t know every aspect of windows driver architecture.

After some study of video device driver, I noticed my video miniport driver should communicate with kernel via video port driver.
But, most of samples or explanations about this subject, only explain the case video apapter attached to PCI bus.

After I called VideoPortInitialize() in DriverEntry(), FindAdapter() function in my miniport driver is called, and AdapterInterfaceType in VIDEO_PORT_CONFIG_INFO is set to PNPBus.

But from this point, I don’t know what I should do. There is no proper argument on VideoPortGetBusData() for PNPBus.

What should I do for properly configure bus information to communicate between miniport driver and video port driver?

2

On Sat, Feb 24, 2007 at 07:59:27AM -0500, xxxxx@legend.co.kr wrote:

I’m developing sub display adapter using USB.

Interesting idea. What are actually transmitting? The typical video pixel
stream is WAY more than a USB can handle. Is is a CCIR656 stream, or are
you trying to send the individual commands?

Because I’m quite a newbie in Windows device driver development,
I don’t know every aspect of windows driver architecture.

Well, except for file system drivers, you could not have chosen a more
complicated starting point.

After some study of video device driver, I noticed my video miniport
driver should communicate with kernel via video port driver.

Yes; in fact, it is REQUIRED to do so.

But, most of samples or explanations about this subject, only explain the
case video apapter attached to PCI bus.

After I called VideoPortInitialize() in DriverEntry(), FindAdapter()
function in my miniport driver is called, and AdapterInterfaceType in
VIDEO_PORT_CONFIG_INFO is set to PNPBus.

But from this point, I don’t know what I should do. There is no proper
argument on VideoPortGetBusData() for PNPBus.

Right. You won’t be calling VideoPortGetBusData. Instead, you’ll call
into USBD like any normal USB driver, to fetch your device’s descriptors,
select your configuration, select your interface and alternate setting, and
populate your interface and endpoint structures.

The more interesting question is, how are you going to find out where to
send your URBs? For that, you need the device object of the next lower
driver in the stack. Ordinarily, you’d get that from the call to
IoAttachDeviceToDeviceStack, or from the DEVICE_OBJECT, but you don’t
have access to those. I assume someone here will now how to get this
information for a video miniport.

What should I do for properly configure bus information to communicate
between miniport driver and video port driver?

Well, this part won’t involve the video port very much.

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

3

At first, I should explain my HW/SW situation.

To make display adapter working on USB bus, I choose to use PCI graphic
controller chip & PCI-to-USB bridge chip supplied by PLX Technology
(http://www.plxtech.com).

Because I could acquire video display device driver source from graphic
chip vendor, and PCI-to-USB bridging API from PLX(they call it RemotePCI),
I tried to rebuild existing device driver to work on USB bus.

RemotePCI API is based on WDM, and to initialize it properly, I needed both
of functional device object & physical device object.

In most of situation which follows WDM, this can be worked because I can
create device object in AddDevice routine, but in video miniport driver,
things were quite different.

Device creation & other stuffs are hide in generic video port driver, and I
couldn’t find a way to get FDO/PDO in my video miniport driver.

So, I have two ideas for solving this problem.

  1. make independent USB class device driver, let it detected by PnP, and
    create device object & attach to device stack in AddDevice() routine, and
    then load another Display class device driver & do driver-to-driver
    communication.

  2. make some kind of bus driver which can cooperate with video
    port/miniport driver.

But, in case 1), I don’t know how to make compatible between miniport<-

port & display<->port communication with my USB class driver.

And, in case 2), even I can’t figure out this is possible or not.

Well, as Tim mentioned, if there is a way to get FDO/PDO in miniport
driver, it may be easiest solution to me.

Better idea, or how to approach this subject?

  • Choe, Hyun-ho

-----??? ?޽???-----
??? ???: xxxxx@lists.osr.com [mailto:bounce-279192-
xxxxx@lists.osr.com] ??(??) ??? ??? ??? ???: xxxxx@probo.com
??? ??¥: 2007?? 2?? 26?? ??? ??? 7:06
?޴? ???: Windows System Software Devs Interest List
???: Tim Roberts
???: Re: [ntdev] Designing video miniport driver using USB

On Sat, Feb 24, 2007 at 07:59:27AM -0500, xxxxx@legend.co.kr wrote:

I’m developing sub display adapter using USB.

Interesting idea. What are actually transmitting? The typical video pixel
stream is WAY more than a USB can handle. Is is a CCIR656 stream, or are
you trying to send the individual commands?

Because I’m quite a newbie in Windows device driver development, I
don’t know every aspect of windows driver architecture.

Well, except for file system drivers, you could not have chosen a more
complicated starting point.

After some study of video device driver, I noticed my video miniport
driver should communicate with kernel via video port driver.

Yes; in fact, it is REQUIRED to do so.

But, most of samples or explanations about this subject, only explain
the case video apapter attached to PCI bus.

After I called VideoPortInitialize() in DriverEntry(), FindAdapter()
function in my miniport driver is called, and AdapterInterfaceType in
VIDEO_PORT_CONFIG_INFO is set to PNPBus.

But from this point, I don’t know what I should do. There is no proper
argument on VideoPortGetBusData() for PNPBus.

Right. You won’t be calling VideoPortGetBusData. Instead, you’ll call
into USBD like any normal USB driver, to fetch your device’s descriptors,
select your configuration, select your interface and alternate setting, and
populate your interface and endpoint structures.

The more interesting question is, how are you going to find out where to
send your URBs? For that, you need the device object of the next lower
driver in the stack. Ordinarily, you’d get that from the call to
IoAttachDeviceToDeviceStack, or from the DEVICE_OBJECT, but you don’t have
access to those. I assume someone here will now how to get this
information for a video miniport.

What should I do for properly configure bus information to communicate
between miniport driver and video port driver?

Well, this part won’t involve the video port very much.

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, 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

4

Hyun-ho Choe,

You will be pleased to hear you are not alone developing USB video products. Unfortunately I cannot offer much help with your PCI-to-USB bridge because here at DisplayLink we use a custom ASIC with USB on one side and VGA on the other.

Instead of 1 graphics driver talking directly to the USB hardware, we use a software graphics driver to collect the drawing operations from GDI, and a service to collect the drawing operations from the graphics driver, compress them, and squirt them through a simple USB driver to our graphics chip.
http://www.displaylink.com/news/news090107b.htm

As far as I am aware everyone else in this arena is doing something similar to you with PCI graphics chips, including ASUS with their external PCI Express graphics expansion dock demoed at CES last month.

The graphics drivers examples in the DDK build 3790.1830 are quite helpful. For Vista and WDK build 6000 everything changes again, so I suggest targeting XP first until you get it working.

Good luck!

Tim Green
Development Engineer
DisplayLink (UK) Limited
Registered in England No. 04811048

Mount Pleasant House, Mount Pleasant,
Cambridge, CB3 0RN, United Kingdom
W: http://www.displaylink.com/

DisplayLink Corp.
A US incorporated company.
480 S. California Avenue Ste 304, Palo Alto, CA 94306, USA.

5

Choe, Hyun-ho wrote:

At first, I should explain my HW/SW situation.

To make display adapter working on USB bus, I choose to use PCI graphic
controller chip & PCI-to-USB bridge chip supplied by PLX Technology
(http://www.plxtech.com).

Because I could acquire video display device driver source from graphic
chip vendor, and PCI-to-USB bridging API from PLX(they call it RemotePCI),
I tried to rebuild existing device driver to work on USB bus.

It isn’t going to be that easy. Remember that both the display driver
and GDI are going to believe they can write directly to the frame buffer
mapped in from PCI memory. You won’t have a frame buffer. If the
display driver is written strictly to the rules, using the macros
everywhere it writes to the device, you may be able to do some macro
magic to redirect the writes as USB requests, but you can’t do that to
GDI. You’ll have to rewrite the driver as a driver-managed surface, not
a GDI-managed surface. That’s not trivial.

In most of situation which follows WDM, this can be worked because I can
create device object in AddDevice routine, but in video miniport driver,
things were quite different.

Device creation & other stuffs are hide in generic video port driver, and I
couldn’t find a way to get FDO/PDO in my video miniport driver.

There must be a way, but I haven’t tried it. A session of tracing
through videoprt.sys should reveal an answer.

  1. make independent USB class device driver, let it detected by PnP, and
    create device object & attach to device stack in AddDevice() routine, and
    then load another Display class device driver & do driver-to-driver
    communication.

That wouldn’t be too bad, but it does seem like an unnecessary extra
step, and you’ll still have to modify the display driver. Which
graphics chip did you choose, if I may ask?

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

6

hi,
That sounds interesting.
You can customize the display driver so as to blit the content on to
your buffer instead of the actual frame buffer.

thanks.

Tim Roberts wrote:

Choe, Hyun-ho wrote:

> At first, I should explain my HW/SW situation.
>
> To make display adapter working on USB bus, I choose to use PCI graphic
> controller chip & PCI-to-USB bridge chip supplied by PLX Technology
> (http://www.plxtech.com).
>
> Because I could acquire video display device driver source from graphic
> chip vendor, and PCI-to-USB bridging API from PLX(they call it RemotePCI),
> I tried to rebuild existing device driver to work on USB bus.
>
>

It isn’t going to be that easy. Remember that both the display driver
and GDI are going to believe they can write directly to the frame buffer
mapped in from PCI memory. You won’t have a frame buffer. If the
display driver is written strictly to the rules, using the macros
everywhere it writes to the device, you may be able to do some macro
magic to redirect the writes as USB requests, but you can’t do that to
GDI. You’ll have to rewrite the driver as a driver-managed surface, not
a GDI-managed surface. That’s not trivial.

> In most of situation which follows WDM, this can be worked because I can
> create device object in AddDevice routine, but in video miniport driver,
> things were quite different.
>
> Device creation & other stuffs are hide in generic video port driver, and I
> couldn’t find a way to get FDO/PDO in my video miniport driver.
>
>

There must be a way, but I haven’t tried it. A session of tracing
through videoprt.sys should reveal an answer.

> 1) make independent USB class device driver, let it detected by PnP, and
> create device object & attach to device stack in AddDevice() routine, and
> then load another Display class device driver & do driver-to-driver
> communication.
>
>

That wouldn’t be too bad, but it does seem like an unnecessary extra
step, and you’ll still have to modify the display driver. Which
graphics chip did you choose, if I may ask?

–
Anshul Makkar
Sr. Associate Engineer
Globallogic
The leader in Outsourced Product Development
B-34/1, Sector 59
Noida, UP 201301
Phone : +91-120-4342258
Fax: 91-120-2585721
www.globallogic.com
Disclaimer :http://www.globallogic.com/email_disclaimer.txt

7

After some struggle with DDK sample & document, I implemented device lower
filter driver for video port driver.

By lower filter driver, I can see IRP communication, and driver is
successfully installed and called FindAdapter, Initialize routine.

But after GetChildDescriptor is called, StartIO routine is called several
times with IOCTL_VIDEO_GET_CHILD_STATE, which I didn’t implement.

And when I run display control panel, Windows says "The currently selected
graphics driver cannot be used. It was written for

a previous version of Windows, and is no longer compatible with this
version of Windows. The system has been started using the default VGA
driver"

and no more VRP request happens.

In this point, I’m stuck, and don’t know what I should do.

Is there anyone who can explain this situation?

Thanks in advance.

  • Choe, Hyun-ho

P.S.> BTW, I gave USB enum ID to my video miniport driver, which I intended
to make my USB graphic adapter PnP-able.

But, I’m not sure video port driver support removing device
properly. Video port driver supports unplugging?

-----??? ?޽???-----
??? ???: xxxxx@lists.osr.com [mailto:bounce-279273-
xxxxx@lists.osr.com] ??(??) ??? ??? ??? ???: Tim Roberts
??? ??¥: 2007?? 2?? 27?? ȭ??? ??? 3:08
?޴? ???: Windows System Software Devs Interest List
???: Re: [ntdev] Designing video miniport driver using USB

Choe, Hyun-ho wrote:

At first, I should explain my HW/SW situation.

To make display adapter working on USB bus, I choose to use PCI
graphic controller chip & PCI-to-USB bridge chip supplied by PLX
Technology (http://www.plxtech.com).

Because I could acquire video display device driver source from
graphic chip vendor, and PCI-to-USB bridging API from PLX(they call it
RemotePCI), I tried to rebuild existing device driver to work on USB bus.

It isn’t going to be that easy. Remember that both the display driver and
GDI are going to believe they can write directly to the frame buffer mapped
in from PCI memory. You won’t have a frame buffer. If the display driver
is written strictly to the rules, using the macros everywhere it writes to
the device, you may be able to do some macro magic to redirect the writes
as USB requests, but you can’t do that to GDI. You’ll have to rewrite the
driver as a driver-managed surface, not a GDI-managed surface. That’s not
trivial.

In most of situation which follows WDM, this can be worked because I
can create device object in AddDevice routine, but in video miniport
driver, things were quite different.

Device creation & other stuffs are hide in generic video port driver,
and I couldn’t find a way to get FDO/PDO in my video miniport driver.

There must be a way, but I haven’t tried it. A session of tracing through
videoprt.sys should reveal an answer.

  1. make independent USB class device driver, let it detected by PnP,
    and create device object & attach to device stack in AddDevice()
    routine, and then load another Display class device driver & do
    driver-to-driver communication.

That wouldn’t be too bad, but it does seem like an unnecessary extra step,
and you’ll still have to modify the display driver. Which graphics chip
did you choose, if I may ask?

–
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