So I'am curious as to why one would need to specify D3D_DRIVER_TYPE_UNKNOWN when using a non null adapter with D3D11CreateDevice().
If anyone knows why this is it would make my day since I find it very illogical to pass a hardware adapter, then not specify a hardware driver.
My guess is that when you use a specific adapter, it uses the D3D_DRIVER_TYPE of the adapter, which is D3D_DRIVER_TYPE_HARDWARE for an adapter obtained from EnumAdapters and D3D_DRIVER_TYPE_SOFTWARE for an adapter created by CreateSoftwareAdapter.
It's also illogical to pass a hardware adapter but specify a software driver.
Although the documentation doesn't state this explicitly, it can be inferred that the call will determine the driver type from the adapter; in other words the adapter constrains the driver type.
Yea, the "unknown" refers to the fact that D3D itself does not have to know the driver type, as you provide the driver entrypoint.
The pointer could actually refer to a hardware driver (though I assume the entry point needs to be in user mode in this case).
Using the Windows DDK (Driver Development Kit), it is possible to create your own D3D driver. A full-featured graphics driver isn't - to put it mildly - easy to develop whether the functionality is implemented in software or hardware, though.
It's worth adding that this is absolutely consistent with other usages of "unknown" in D3D; in context "unknown" doesn't mean "I don't know it", it means "I don't specify it, the runtime or driver gets this information from elsewhere".
For example, in D3D9 when creating a windowed mode you would specify D3DFMT_UNKNOWN for the backbuffer format, meaning that it actually comes from the format of the current display mode.
It could probably be argued that use of the word "unknown" for this is confusing, but done is done. So whenever you see "unknown" it's the API design's way of telling you that this is something that you don't specify because the information comes from elsewhere and may be constrained by the state of that elsewhere.
