IRP_MJ_PNP and display driver

Hi all,

I’m new in Windows driver development.
I’m investigating if it’s possible to add hot unplug capability to a
cardbus video card (VTBook).

In ddk PnP Driver Design Guidelines documentation I read
“Some drivers are insulated from the details of the PnP and power
management by system-supplied port or class drivers.”

Display drivers are among these: if I ask the PnP manager to “safely
remove VTBook”, it answers that “The device cannot be stopped right now.
Try later”. It’s because, I guess, there is no driver that handles the
IRP_MJ_PNP IRPs.

If the video port driver does not service IRP_MJ_PNP requests is there a
way to handle them in the miniport?
Or could I write a second driver (a PnP-driver) that receives IRP_MJ_PNP
IRPs sent to my card? Could such a driver, when receiving a
IRP_MN_REMOVE_DEVICE, make the system go back to the state it was
in before plugging in the VTBook (unload the video driver, remove VTBook
from hw devices list, …), as it happens for other pnp devices?

Thanks

Giovanni

I’ve got no experience with hotplugging graphics (AGP cards tend to short
the VCC to GND when unplugged, which is not a good thing), so this may be of
no help whatsoever…

Have you had a look at HwVidSetPowerState and HwVidGetPowerState. These
function pointers into the miniport driver for the video device, and they
are called from the VideoPort driver, which is the principal manager of the
Video devices in the system.

I think you’ll find that somewhere in the miniport driver (I assume you have
source code for this driver) there is a data structure with a
VidSetPowerState function pointer in it, that is set to some function in
your miniport. This function should be called when you’re trying to power
down the hardware.

If your VidSetPowerState does not return a success from for instance a
“power off” call, then it will of course result in the device refusing to
unplug itself.

However, it is also possible that the VideoPort driver itself is “failing”
the call in the first place.

But hopefully this will give you a hint of what’s going on (or the lack of
it).

-----Original Message-----
From: Giovanni Longoni [mailto:xxxxx@villagetronic.com]
Sent: Monday, April 05, 2004 10:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP_MJ_PNP and display driver

Hi all,

I’m new in Windows driver development.
I’m investigating if it’s possible to add hot unplug capability to a
cardbus video card (VTBook).

In ddk PnP Driver Design Guidelines documentation I read
“Some drivers are insulated from the details of the PnP and power
management by system-supplied port or class drivers.”

Display drivers are among these: if I ask the PnP manager to “safely
remove VTBook”, it answers that “The device cannot be stopped
right now.
Try later”. It’s because, I guess, there is no driver that handles the
IRP_MJ_PNP IRPs.

If the video port driver does not service IRP_MJ_PNP requests
is there a
way to handle them in the miniport?
Or could I write a second driver (a PnP-driver) that receives
IRP_MJ_PNP
IRPs sent to my card? Could such a driver, when receiving a
IRP_MN_REMOVE_DEVICE, make the system go back to the state it was
in before plugging in the VTBook (unload the video driver,
remove VTBook
from hw devices list, …), as it happens for other pnp devices?

Thanks

Giovanni


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> If the video port driver does not service IRP_MJ_PNP requests is there a

way to handle them in the miniport?

No.

in before plugging in the VTBook (unload the video driver, remove VTBook
from hw devices list, …), as it happens for other pnp devices?

I’m not sure that Windows supports hot-plug video at all.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

The heretic will speak… prepare for flames.

Why should the OS need to know whether or not you have an actual card there
? There’s probably a way to pretend the card’s always there, whether or not
that’s true - it’s called “lying to the OS”. Then you handle all the
plug/unplug stuff inside your own code, and isolate the OS from that
decision.

Don’t ask me for details, it’s been many years I last worked with that kind
of thing, but I’m sure an enterprising mind will find a way.

Alberto.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Monday, April 05, 2004 6:01 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MJ_PNP and display driver

I’ve got no experience with hotplugging graphics (AGP cards tend to short
the VCC to GND when unplugged, which is not a good thing), so this may be of
no help whatsoever…

Have you had a look at HwVidSetPowerState and HwVidGetPowerState. These
function pointers into the miniport driver for the video device, and they
are called from the VideoPort driver, which is the principal manager of the
Video devices in the system.

I think you’ll find that somewhere in the miniport driver (I assume you have
source code for this driver) there is a data structure with a
VidSetPowerState function pointer in it, that is set to some function in
your miniport. This function should be called when you’re trying to power
down the hardware.

If your VidSetPowerState does not return a success from for instance a
“power off” call, then it will of course result in the device refusing to
unplug itself.

However, it is also possible that the VideoPort driver itself is “failing”
the call in the first place.

But hopefully this will give you a hint of what’s going on (or the lack of
it).

-----Original Message-----
From: Giovanni Longoni [mailto:xxxxx@villagetronic.com]
Sent: Monday, April 05, 2004 10:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] IRP_MJ_PNP and display driver

Hi all,

I’m new in Windows driver development.
I’m investigating if it’s possible to add hot unplug capability to a
cardbus video card (VTBook).

In ddk PnP Driver Design Guidelines documentation I read
“Some drivers are insulated from the details of the PnP and power
management by system-supplied port or class drivers.”

Display drivers are among these: if I ask the PnP manager to “safely
remove VTBook”, it answers that “The device cannot be stopped
right now.
Try later”. It’s because, I guess, there is no driver that handles the
IRP_MJ_PNP IRPs.

If the video port driver does not service IRP_MJ_PNP requests
is there a
way to handle them in the miniport?
Or could I write a second driver (a PnP-driver) that receives
IRP_MJ_PNP
IRPs sent to my card? Could such a driver, when receiving a
IRP_MN_REMOVE_DEVICE, make the system go back to the state it was
in before plugging in the VTBook (unload the video driver,
remove VTBook
from hw devices list, …), as it happens for other pnp devices?

Thanks

Giovanni


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

> -----Original Message-----

From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Monday, April 05, 2004 10:21 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] IRP_MJ_PNP and display driver

The heretic will speak… prepare for flames.

Why should the OS need to know whether or not you have an
actual card there ? There’s probably a way to pretend the
card’s always there, whether or not that’s true - it’s called
“lying to the OS”. Then you handle all the plug/unplug stuff
inside your own code, and isolate the OS from that decision.

Don’t ask me for details, it’s been many years I last worked
with that kind of thing, but I’m sure an enterprising mind
will find a way.

That actually works, and is not a violation of anything. Unless there are
strong requirements to provide this sort of virtual video device though, it
is not worth the effort. Also the system does not handle a transition to no
video device gracefully :slight_smile:

=====================
Mark Roddy

I think you really mean video MINIPORT driver instead of Display Driver?
Display Drivers (rendering driver) do not follow KMD model, there’s no
DriverEntry and no IRP_MJ_XXX routines, therefore, display driver does not
handle IRP_MJ_PNP at all.

If the video port driver does not service IRP_MJ_PNP requests
is there a way to handle them in the miniport?

No, unless you patch the MajorFunction table.
Videoprt.sys handles all IRP_MJ_PNP requests for the video miniport driver.

Or could I write a second driver (a PnP-driver) that receives
IRP_MJ_PNP
IRPs sent to my card? Could such a driver, when receiving a
IRP_MN_REMOVE_DEVICE, make the system go back to the state it was
in before plugging in the VTBook (unload the video driver,
remove VTBook
from hw devices list, …), as it happens for other pnp devices?

My experience is that the video miniport stack never receive a
IRP_MN_REMOVE_DEVICE since the videoprt.sys seemingly always fails a
IRP_MN_QUERY_REMOVE_DEVICE.

good luck,

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com