none
Drivers behavior on Connected Standby RRS feed

  • Question

  • Hi,

    I' m trying to understand the sensors behavior on CS.

    In order to do so I used 2 sensors. The first is USB sensor and the second is software only sensor (HID miniport driver that emulates an accelerometer sensor).

    I wanted to see what will be the behavior in CS entrance.

    There is a difference in the behavior of the 2 sensors:

    The UMDF sensorDDI unsubscribeForEvents() is called in the USB stack but isn't called in the SW only stack. I can't understand how the framework distinguishes between the 2 stacks…

    What is the expected behavior?

     

    The second issue that I would like to understand is if the HID miniport driver should Exit from D0 in CS entry? As I was told it should, but I didn't see it happen.

    I tried to add WdfDeviceAssignS0IdleSettings to the SW only miniport driver but I got STATUS_INVALID_DEVICE_REQUEST which means that the calling driver is not the device's power policy owner. So who is the power policy owner in that stack? I can't see another function driver in my stack… According to what I understand the miniport driver and the HIDCLASS driver are the same driver? Did I miss something?

    Thanks a lot,

    C.S

    Sunday, February 3, 2013 8:42 PM

Answers

  • Are you writing a driver for a sensor?  Is it a HID sensor, or do you have direct access to hardware?  If it is the latter, use the Geolocaton driver sample:  http://msdn.microsoft.com/en-us/library/windows/hardware/hh768273(v=vs.85).aspx

    The Geolocation driver sample shows how to do power management using power managed queues and StopIdle/ResumeIdle.  The HID sensor driver sample is built for the HID stack, where hidclass.sys is the power policy owner.

    As a note, only the system auto-rotation and Windows Store apps will automatically unsubscribe. Make sure you are not running any desktop apps.'


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 1:18 AM

All replies

  • Are you writing a driver for a sensor?  Is it a HID sensor, or do you have direct access to hardware?  If it is the latter, use the Geolocaton driver sample:  http://msdn.microsoft.com/en-us/library/windows/hardware/hh768273(v=vs.85).aspx

    The Geolocation driver sample shows how to do power management using power managed queues and StopIdle/ResumeIdle.  The HID sensor driver sample is built for the HID stack, where hidclass.sys is the power policy owner.

    As a note, only the system auto-rotation and Windows Store apps will automatically unsubscribe. Make sure you are not running any desktop apps.'


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 1:18 AM
  • Hi Janet,

    Thanks for your answer.

    I'm writing a HID sensor.

    I already saw that samples, but I didn't understand if the driver should be idle in CS or not.(Should it Exit from D0 or not?)

    As I undersatnd the hidclass.sys + HID miniport driver together are the function driver. Is it right? Does it mean that the miniport is the power owner too?

    Thanks ,

    C.S

    Monday, February 4, 2013 7:16 AM
  • there are two parts to the hid stack.

    1) the parent. this is the miniport + hidclass.  hidclass is the power policy owner. for a usb connected device, the hw ID for this device starts with "USB\"

    2) a raw PDO for each top level collection enumerated in the hid descriptor.  hidclass is the power policy owner for this stack as well. the HW ID for this device starts with "HID\".  Your driver is loading on this stack.

    the easiest way to see this is to open device manager and view devices by connection and you will see the parent and the raw PDO(s).


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 7:18 AM
  • Thanks for your clear answer.

    I still can't understand what is relation between the miniport and the hidclass.sys. Are they the same device? Do they created by the same createDevice()?

    If the hidclass.sys is the only power owner(and the miniport isn't) I understand that I don't have any way to control the power policy of the HID stack. Is it write?

    If so, I try to understand if my miniport driver will exit from D0 in CS entry or not.

    Thanks a lot,

    C.S

    • Proposed as answer by R__K Tuesday, April 16, 2013 11:20 PM
    Monday, February 4, 2013 7:33 AM
  • And another question,

    The second part of the stack contains the UMDF driver(SensorHIDDriverSample.dll) but it doesn't contain the hidclass, So how can it be the power owner of that part?

    Thanks, C.S

    Monday, February 4, 2013 7:39 AM
  • hidclass and the miniport share the same device object (same model as NDIS+NDIS miniport, storport+storport miniport, etc) for the parent device, it is a port+miniport model.  while they share the same device object, hidclass contains all of the io processing and power logic. the miniport just does what the port driver tells it to do (ie it is simpler). since you are writing a hid to sensor mapper driver, you are loaded on the raw PDO, not the parent. as such, you are not a miniport driver.  as janet stated, as a hid to sensor mapper driver, you will not change power states on a CS changes (entry or exit)

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 7:44 AM
  • hidclass controls the function of the PDO you are attached to.  it is a raw PDO which means it can run without a driver installed or attached to it, in other words it functions as both a PDO and FDO rolled into one device, the raw pdo.  since it takes on the actions of an fdo, that includes owning power policy.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 7:46 AM
  • Hi,

    Thanks for your patient answer, I'm realy new with the HID area, and I didn't anderstand it correctly yet.

    I wrote 2 drivers. one is KMDF mimiport driver (based on the HIDUSBFX2 sample driver )  and one is UMDF driver(based on the Sensors HID sample driver).

    If my first driver isn't the miniport driver so who is the miniport driver? (I am not using USB, I'm software only device).

    I can't undersatnd what is the sensor mapper driver , and I didn't find any documenataion about it.

    I understood that I don't allowed to change the power policy in CS enterance, but I still didn't understand what is the hidclass policy in that case (will it exit from D0 or not).

    Thanks a lot, C.S


    • Edited by tulush Monday, February 4, 2013 8:51 AM
    Monday, February 4, 2013 8:26 AM
  • KMDF / UMDF hid "miniports", and it is in quotes because it is not quite  miniport do not share a device object with hidclass.  there is a bit of a quirk in these stacks, there is a true hid miniport, mshidkmdf and mshidumdf, that share the device object with hidclass and then send down requests as irps. so in the wdf hid miniport case, it is really a full fledged wdf driver as a lower filter.

    the sensor mapper driver is the driver you are currently working on. it takes hid and maps it to something else, sensors in this case

    hidclass power policy is not to change power state on CS state changes


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, February 4, 2013 6:04 PM
  • Thanks a lot!!!

    Your explanations really helped me.

    C.S

    Monday, February 4, 2013 6:44 PM