Closed smadasam closed 1 year ago
Thanks, @smadasam! I'll get on with this asap. Meanwhile, let's take it to internal email for convenience of comms, and I'll go ahead and close this. I'll return here and update this thread when I'm done.
Thanks! -Steve
UPDATE: The request changes are now live in the docs.
Thanks! -Steve
[Enter feedback here] We need to describe the Pnp namespace as obsolete or depreciated. It was [debatable whether it should ever have] existed. [That] was corrected in TH1 (10.0.10240.0). Device information kind was introduced at the base Windows.Devices.Enumeration namespace, which eliminates the need for the pnp namespace to exist.
Here is a diagram of the PnP object model as expressed by DevQuery or the Windows.Devices.Enumeration API
https://microsoft.sharepoint.com/:u:/r/teams/osg_core_sigma/dplat/Shared%20Documents/Teams/DnD/Planning/Nickel/Device%20Object%20Model.vsdx?d=wffd4600cc92d413690a523240f77b3b5&csf=1&web=1&e=csG4Yb
Windows.Devices.Enumeration defaults to returning device interfaces if no kind is specified. Most selectors and the enums, query device interfaces. This makes sense since most device stacks consume interfaces instances and their currency. The deeper PnP object model is available by passing the device information kind.
Association Endpoints (AEPs) generally "hit the wire" to discover devices, so it can be expensive in terms of power and time, and impact QoS depending on how your PC implemented their radios. Association objects should always be discovered with a watcher as many protocols don't have a concept of "enumeration complete," so the protocol stack emulates that with a long query timeout.
If you need to use a protocol-style device, they are normally discovered as AEPs first. Typically, these devices are discovered, and then paired. After they are paired, typically the protocol stack creates PnP state with devnodes, interfaces, etc., so the default interface watcher won't enumerate them until they are paired. Some devices can't be paired and are simply accessed as AEPs in their device stacks, eg. some BTLE devices and profiles.
What the objects are for: DeviceInterface: describes what the device can do, eg. camera, mic, accelerometer. Device stacks generally operate on device interfaces, or even more generically, devices are accessed by the interface with CreateFile, and IOCTL. Device, represents a device node as discovered by a bus, etc. PCI, USB, in the PnP tree. PnP loads drivers onto device nodes. DeviceContainer, is intended to describe what the user might precieve as a "device," eg. printer, mouse, laptop, and is a collection of device nodes that reside in that chassis. DevicePanel, DeviceInterfaceClass, defines well known devices classes and the programming contact for that interface, eg. a webcam interface class has a well known programming contract, so device interfaces of that class are used via that contract AssociationEndpoint: represents a device that is discoverable by the PC, but not typically by PnP busses like USB, but by device protocols like Bluetooth, or a network printer over various protocols like IPP. AssociationEndpointContainer, is intended to describe what the user might precieve as a "device," eg. printer, XBOX, that might make itself discoverable as one or more endpoint over one or more protocols AssociationEndpointService, describes what the device endpoint can do, eg. print, media server, headset, etc. an endpoint typically has to be paired to access the services, but not always
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.