xxxxx@gmail.com wrote:
Your information helped me understand the following code on GitHub, which seems to work:
https://github.com/flowerinthenight/windows-camera-class-filter-driver/blob/master/ccfltr/ccfltr.c#L395
Maybe, but I’m suspicious of anyone who writes code like this:
InterlockedAnd(&pDeviceExtension->IsVideoInfoHeader2, 0);
InterlockedAnd(&pDeviceExtension->KsStateRun, 0);
InterlockedAnd(&pDeviceExtension->StreamerPid, 0);
That shows a misunderstanding on several levels. A DeviceExtension is
automatically zeroed on creation, and a write of a 32-bit value is
already atomic, so this would have had the same effect:
pDeviceExtension->IsVideoInfoHeader2 = 0;
pDeviceExtension->KsStateRun = 0;
pDeviceExtension->StreamerPid = 0;
Your comment, “you can’t really use the KMDF APIs to access the data”, made me notice that I can use the WdfRequestWdmGetIrp
function to get the raw IRP pointer in the completion routine, and use a code which is similar to the WDM example. So far, looks like it works.
Yep, that’s the right way to do it.
Â
Are the any other details that I need to be aware of?
I’m sure there are lots, but it depends on what you need to do. If you
need to know the format of the video stream as it was negotiated, that
turns out to be complicated. Are you able to assume a format?
Also, you mentioned WdfSynchronizationScopeNone in one of the threads:
https://www.osronline.com/showthread.cfm?link=212301
Can you please say whether and why it’s needed in my case?
It’s difficult to come up with general rules. You need to know what
parts of your shared state are vulnerable and need locking. If you
access a lot of shared data, then a sync scope can make that easier, but
it’s also easy to overdo it.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.