WDM streaming driver and user mode interaction

I have a WDM streaming driver(Video) solution and I want that to interact
with a user mode component( a Service Exe loaded at logon time in my case).

What would be the best way to go about this ?
Basically, the service sends some data eveyr now and then to the streaming
minidriver. Should I use IOCTL's and send data excluseively ? or shall I use
FileMapping or some shared objects ?

1>I know there are no direct IOCTL's going into the streaming minidriver as
the class driver handles everything. But can I overload the class driver's
IRP_MJ_DEVICE_CONTROL with mine ?

2>Should I use Property Sets and Plug ins ? Remember that the service will
need to send data every now and then( and I am thinking of using Events to
communicate between driver and the service where driver initiates an event
and the event when evoked, either does an IOCTL or some other way to
communicate data to the streaming minidriver)

so the calling would be something like a service -> Plugin -> Minidriver ?

3>any other method that anybody can suggest ?

Thanks.

You don't really have to write a plugin to talk to a KS minidriver.
Create an instance of KS proxy for your driver, QI it for IKsPropertySet and
set/get properties on your set.
Property sets is functionaly similar to an IOCTL.

-- Max.


"Amit" <> wrote in message
news:BEA97F9C-159C-485A-A619-...
>I have a WDM streaming driver(Video) solution and I want that to interact
> with a user mode component( a Service Exe loaded at logon time in my
> case).
>
> What would be the best way to go about this ?
> Basically, the service sends some data eveyr now and then to the streaming
> minidriver. Should I use IOCTL's and send data excluseively ? or shall I
> use
> FileMapping or some shared objects ?
>
> 1>I know there are no direct IOCTL's going into the streaming minidriver
> as
> the class driver handles everything. But can I overload the class driver's
> IRP_MJ_DEVICE_CONTROL with mine ?
>
> 2>Should I use Property Sets and Plug ins ? Remember that the service will
> need to send data every now and then( and I am thinking of using Events to
> communicate between driver and the service where driver initiates an event
> and the event when evoked, either does an IOCTL or some other way to
> communicate data to the streaming minidriver)
>
> so the calling would be something like a service -> Plugin -> Minidriver ?
>
> 3>any other method that anybody can suggest ?
>
> Thanks.

You mean to say, that the service would just do a query Interface on the
KSproxy ?
Is there any documentation on this ?

Is it possible to send buffer pointers into the streaming minidriver via
this method and the driver does the appropriate action based on the type of
ioctl ?

and also share events with the driver ? Meaning, the service creates an
event and the driver invokes the event when data is needed.

"Max Paklin" wrote:

> You don't really have to write a plugin to talk to a KS minidriver.
> Create an instance of KS proxy for your driver, QI it for IKsPropertySet and
> set/get properties on your set.
> Property sets is functionaly similar to an IOCTL.
>
> -- Max.
>
>
> "Amit" <> wrote in message
> news:BEA97F9C-159C-485A-A619-...
> >I have a WDM streaming driver(Video) solution and I want that to interact
> > with a user mode component( a Service Exe loaded at logon time in my
> > case).
> >
> > What would be the best way to go about this ?
> > Basically, the service sends some data eveyr now and then to the streaming
> > minidriver. Should I use IOCTL's and send data excluseively ? or shall I
> > use
> > FileMapping or some shared objects ?
> >
> > 1>I know there are no direct IOCTL's going into the streaming minidriver
> > as
> > the class driver handles everything. But can I overload the class driver's
> > IRP_MJ_DEVICE_CONTROL with mine ?
> >
> > 2>Should I use Property Sets and Plug ins ? Remember that the service will
> > need to send data every now and then( and I am thinking of using Events to
> > communicate between driver and the service where driver initiates an event
> > and the event when evoked, either does an IOCTL or some other way to
> > communicate data to the streaming minidriver)
> >
> > so the calling would be something like a service -> Plugin -> Minidriver ?
> >
> > 3>any other method that anybody can suggest ?
> >
> > Thanks.
>
>
>

Look up Amcap sample in old Platform SDK (or newer DX SDK). It shows how to
create an instance of ksproxy for your driver.
Then get IKsPropertySet interface from it and do you property sets and gets.

Given the fact that it is very similar to IOCTL all rules and techniques
designed for IOCTLs apply to this case as well. Yes, you can share events
through it altough this method is considered not to be the best by many.
Read up an article about it on OSR.com.
And yes, you can share buffers by passing them as a part of some structure
associated with a property, but that technique is error prone and greately
discouraged.

If I were you what I would do is the following. QI ksproxy instance for
IKsObject instead of IKsPropertySet and get the file handle from IKsObject.
You can use that file handle to call DeviceIoControl. IIRC the file handle
is opened with overlapped flag so you can do asynchronous I/O. In the driver
simply pend received SRBs and complete them as soon as you have your data
available. In your service associate an event with an asynchronous I/O and
wait on it from a thread.

-- Max.



"Amit" <> wrote in message
news:435D14EA-D15C-40D2-8F09-...
> You mean to say, that the service would just do a query Interface on the
> KSproxy ?
> Is there any documentation on this ?
>
> Is it possible to send buffer pointers into the streaming minidriver via
> this method and the driver does the appropriate action based on the type
> of
> ioctl ?
>
> and also share events with the driver ? Meaning, the service creates an
> event and the driver invokes the event when data is needed.
>
> "Max Paklin" wrote:
>
>> You don't really have to write a plugin to talk to a KS minidriver.
>> Create an instance of KS proxy for your driver, QI it for IKsPropertySet
>> and
>> set/get properties on your set.
>> Property sets is functionaly similar to an IOCTL.
>>
>> -- Max.
>>
>>
>> "Amit" <> wrote in message
>> news:BEA97F9C-159C-485A-A619-...
>> >I have a WDM streaming driver(Video) solution and I want that to
>> >interact
>> > with a user mode component( a Service Exe loaded at logon time in my
>> > case).
>> >
>> > What would be the best way to go about this ?
>> > Basically, the service sends some data eveyr now and then to the
>> > streaming
>> > minidriver. Should I use IOCTL's and send data excluseively ? or shall
>> > I
>> > use
>> > FileMapping or some shared objects ?
>> >
>> > 1>I know there are no direct IOCTL's going into the streaming
>> > minidriver
>> > as
>> > the class driver handles everything. But can I overload the class
>> > driver's
>> > IRP_MJ_DEVICE_CONTROL with mine ?
>> >
>> > 2>Should I use Property Sets and Plug ins ? Remember that the service
>> > will
>> > need to send data every now and then( and I am thinking of using Events
>> > to
>> > communicate between driver and the service where driver initiates an
>> > event
>> > and the event when evoked, either does an IOCTL or some other way to
>> > communicate data to the streaming minidriver)
>> >
>> > so the calling would be something like a service -> Plugin ->
>> > Minidriver ?
>> >
>> > 3>any other method that anybody can suggest ?
>> >
>> > Thanks.
>>
>>
>>

"Max Paklin" wrote:

> Look up Amcap sample in old Platform SDK (or newer DX SDK). It shows how to
> create an instance of ksproxy for your driver.
> Then get IKsPropertySet interface from it and do you property sets and gets.

Oh, so you mean how a regular DShow app would access it ussing PropertyBags
and Enumeration. So, that should be pretty starightforward. I thought, you
are talking about something different.

>
> Given the fact that it is very similar to IOCTL all rules and techniques
> designed for IOCTLs apply to this case as well. Yes, you can share events
> through it altough this method is considered not to be the best by many.
> Read up an article about it on OSR.com.
> And yes, you can share buffers by passing them as a part of some structure
> associated with a property, but that technique is error prone and greately
> discouraged.
Why is it error-prone ? I thought that would be the best way of doing it.
Basically, the service would ne a DsHow client and that would then access the
driver the way Dshow apps do it..

> If I were you what I would do is the following. QI ksproxy instance for
> IKsObject instead of IKsPropertySet and get the file handle from IKsObject.
> You can use that file handle to call DeviceIoControl. IIRC the file handle
> is opened with overlapped flag so you can do asynchronous I/O. In the driver
> simply pend received SRBs and complete them as soon as you have your data
> available. In your service associate an event with an asynchronous I/O and
> wait on it from a thread.

So, this way you can still do IOCTL directly ? So which function is going to
be called in the minidriver ? Do you need an exclusive DeviceIocontrol
routine ? but how will I expose that since there is dispatch routine. does
this method bypass KS.sys or stream.sys ? or is the call coming via a SRB ?

and pend what SRB's ? the ones for performing some videocapture operation ?
I havent used this before. I will have a detailed look at all this.

If you have a good link on some more documentation, please post it.

Thanks a bunch.
>
> -- Max.
>
>
>
> "Amit" <> wrote in message
> news:435D14EA-D15C-40D2-8F09-...
> > You mean to say, that the service would just do a query Interface on the
> > KSproxy ?
> > Is there any documentation on this ?
> >
> > Is it possible to send buffer pointers into the streaming minidriver via
> > this method and the driver does the appropriate action based on the type
> > of
> > ioctl ?
> >
> > and also share events with the driver ? Meaning, the service creates an
> > event and the driver invokes the event when data is needed.
> >
> > "Max Paklin" wrote:
> >
> >> You don't really have to write a plugin to talk to a KS minidriver.
> >> Create an instance of KS proxy for your driver, QI it for IKsPropertySet
> >> and
> >> set/get properties on your set.
> >> Property sets is functionaly similar to an IOCTL.
> >>
> >> -- Max.
> >>
> >>
> >> "Amit" <> wrote in message
> >> news:BEA97F9C-159C-485A-A619-...
> >> >I have a WDM streaming driver(Video) solution and I want that to
> >> >interact
> >> > with a user mode component( a Service Exe loaded at logon time in my
> >> > case).
> >> >
> >> > What would be the best way to go about this ?
> >> > Basically, the service sends some data eveyr now and then to the
> >> > streaming
> >> > minidriver. Should I use IOCTL's and send data excluseively ? or shall
> >> > I
> >> > use
> >> > FileMapping or some shared objects ?
> >> >
> >> > 1>I know there are no direct IOCTL's going into the streaming
> >> > minidriver
> >> > as
> >> > the class driver handles everything. But can I overload the class
> >> > driver's
> >> > IRP_MJ_DEVICE_CONTROL with mine ?
> >> >
> >> > 2>Should I use Property Sets and Plug ins ? Remember that the service
> >> > will
> >> > need to send data every now and then( and I am thinking of using Events
> >> > to
> >> > communicate between driver and the service where driver initiates an
> >> > event
> >> > and the event when evoked, either does an IOCTL or some other way to
> >> > communicate data to the streaming minidriver)
> >> >
> >> > so the calling would be something like a service -> Plugin ->
> >> > Minidriver ?
> >> >
> >> > 3>any other method that anybody can suggest ?
> >> >
> >> > Thanks.
> >>
> >>
> >>
>
>
>

This is an example of the code that imlements property-get call.

KSIDENTIFIER ksIdentifier;
ksIdentifier.Set = gGet;
ksIdentifier.Id = dwPropId;
ksIdentifier.Flags = KSPROPERTY_TYPE_GET;

dwResult = DeviceIoControl(
hKsObject,
IOCTL_KS_PROPERTY,
&ksIdentifier,
sizeof( ksIdentifier ),
btOutBuffer,
sizeof( btOutBuffer ),
&dwReturned,
&Overlapped );

In your driver what you get is SRB_GET_DEVICE_PROPERTY.
This is true of course, only if you define property set for "gGet" with
property item dwPropId.
You don't have to hook or hack anything. Use mechanisms provided by the
model. It is more than enough to cover all your needs as far as IOCTL are
concerned.
There is enough info in the DDK on how to define your custom property set.
Also usbintel sample in the DDK demonstrates how to do it.

-- Max.



"Amit" <> wrote in message
news:39BCC214-588A-4350-899C-...
>
>
> "Max Paklin" wrote:
>
>> Look up Amcap sample in old Platform SDK (or newer DX SDK). It shows how
>> to
>> create an instance of ksproxy for your driver.
>> Then get IKsPropertySet interface from it and do you property sets and
>> gets.
>
> Oh, so you mean how a regular DShow app would access it ussing
> PropertyBags
> and Enumeration. So, that should be pretty starightforward. I thought, you
> are talking about something different.
>
>>
>> Given the fact that it is very similar to IOCTL all rules and techniques
>> designed for IOCTLs apply to this case as well. Yes, you can share events
>> through it altough this method is considered not to be the best by many.
>> Read up an article about it on OSR.com.
>> And yes, you can share buffers by passing them as a part of some
>> structure
>> associated with a property, but that technique is error prone and
>> greately
>> discouraged.
> Why is it error-prone ? I thought that would be the best way of doing it.
> Basically, the service would ne a DsHow client and that would then access
> the
> driver the way Dshow apps do it..
>
>> If I were you what I would do is the following. QI ksproxy instance for
>> IKsObject instead of IKsPropertySet and get the file handle from
>> IKsObject.
>> You can use that file handle to call DeviceIoControl. IIRC the file
>> handle
>> is opened with overlapped flag so you can do asynchronous I/O. In the
>> driver
>> simply pend received SRBs and complete them as soon as you have your data
>> available. In your service associate an event with an asynchronous I/O
>> and
>> wait on it from a thread.
>
> So, this way you can still do IOCTL directly ? So which function is going
> to
> be called in the minidriver ? Do you need an exclusive DeviceIocontrol
> routine ? but how will I expose that since there is dispatch routine. does
> this method bypass KS.sys or stream.sys ? or is the call coming via a SRB
> ?
>
> and pend what SRB's ? the ones for performing some videocapture operation
> ?
> I havent used this before. I will have a detailed look at all this.
>
> If you have a good link on some more documentation, please post it.
>
> Thanks a bunch.
>>
>> -- Max.
>>
>>
>>
>> "Amit" <> wrote in message
>> news:435D14EA-D15C-40D2-8F09-...
>> > You mean to say, that the service would just do a query Interface on
>> > the
>> > KSproxy ?
>> > Is there any documentation on this ?
>> >
>> > Is it possible to send buffer pointers into the streaming minidriver
>> > via
>> > this method and the driver does the appropriate action based on the
>> > type
>> > of
>> > ioctl ?
>> >
>> > and also share events with the driver ? Meaning, the service creates an
>> > event and the driver invokes the event when data is needed.
>> >
>> > "Max Paklin" wrote:
>> >
>> >> You don't really have to write a plugin to talk to a KS minidriver.
>> >> Create an instance of KS proxy for your driver, QI it for
>> >> IKsPropertySet
>> >> and
>> >> set/get properties on your set.
>> >> Property sets is functionaly similar to an IOCTL.
>> >>
>> >> -- Max.
>> >>
>> >>
>> >> "Amit" <> wrote in message
>> >> news:BEA97F9C-159C-485A-A619-...
>> >> >I have a WDM streaming driver(Video) solution and I want that to
>> >> >interact
>> >> > with a user mode component( a Service Exe loaded at logon time in my
>> >> > case).
>> >> >
>> >> > What would be the best way to go about this ?
>> >> > Basically, the service sends some data eveyr now and then to the
>> >> > streaming
>> >> > minidriver. Should I use IOCTL's and send data excluseively ? or
>> >> > shall
>> >> > I
>> >> > use
>> >> > FileMapping or some shared objects ?
>> >> >
>> >> > 1>I know there are no direct IOCTL's going into the streaming
>> >> > minidriver
>> >> > as
>> >> > the class driver handles everything. But can I overload the class
>> >> > driver's
>> >> > IRP_MJ_DEVICE_CONTROL with mine ?
>> >> >
>> >> > 2>Should I use Property Sets and Plug ins ? Remember that the
>> >> > service
>> >> > will
>> >> > need to send data every now and then( and I am thinking of using
>> >> > Events
>> >> > to
>> >> > communicate between driver and the service where driver initiates an
>> >> > event
>> >> > and the event when evoked, either does an IOCTL or some other way to
>> >> > communicate data to the streaming minidriver)
>> >> >
>> >> > so the calling would be something like a service -> Plugin ->
>> >> > Minidriver ?
>> >> >
>> >> > 3>any other method that anybody can suggest ?
>> >> >
>> >> > Thanks.
>> >>
>> >>
>> >>
>>
>>
>>

Oh ok. Then I have this part working actually. All that was needed was
replacing the IKspropertySet interface with IKSObject and then using
KsSynchronousDeviceControl instead of Get(IkspropertySet)

However, I have one more question. The GetHandler/SetHandler member of the
KSPROPERTY_ITEM. Why isnt that being called even inspite of specifying a
proper function ?

I know the DDK says KS1.0 and Avstream. so KS1.0 refers to stream class and
port class drivers, isnt it ?
so, this should be supported.

All the while during my debugging, I had added functions to the
GetHandlder/SetHandler and they werent getting called and instead as you had
pointed out SRB_GET_DEVICE_PROPERTY function was being called.

So, how do I get GetHandler/SetHandler part going ? do I need to do anything
different? Because I have my 'test' custom property set working via
SRB_GET_DEVICE_PROPERTY...but why isnt GetHandler getting called ?

Thanks.
"Max Paklin" wrote:

> This is an example of the code that imlements property-get call.
>
> KSIDENTIFIER ksIdentifier;
> ksIdentifier.Set = gGet;
> ksIdentifier.Id = dwPropId;
> ksIdentifier.Flags = KSPROPERTY_TYPE_GET;
>
> dwResult = DeviceIoControl(
> hKsObject,
> IOCTL_KS_PROPERTY,
> &ksIdentifier,
> sizeof( ksIdentifier ),
> btOutBuffer,
> sizeof( btOutBuffer ),
> &dwReturned,
> &Overlapped );
>
> In your driver what you get is SRB_GET_DEVICE_PROPERTY.
> This is true of course, only if you define property set for "gGet" with
> property item dwPropId.
> You don't have to hook or hack anything. Use mechanisms provided by the
> model. It is more than enough to cover all your needs as far as IOCTL are
> concerned.
> There is enough info in the DDK on how to define your custom property set.
> Also usbintel sample in the DDK demonstrates how to do it.
>
> -- Max.

>
>
> "Amit" <> wrote in message
> news:39BCC214-588A-4350-899C-...
> >
> >
> > "Max Paklin" wrote:
> >
> >> Look up Amcap sample in old Platform SDK (or newer DX SDK). It shows how
> >> to
> >> create an instance of ksproxy for your driver.
> >> Then get IKsPropertySet interface from it and do you property sets and
> >> gets.
> >
> > Oh, so you mean how a regular DShow app would access it ussing
> > PropertyBags
> > and Enumeration. So, that should be pretty starightforward. I thought, you
> > are talking about something different.
> >
> >>
> >> Given the fact that it is very similar to IOCTL all rules and techniques
> >> designed for IOCTLs apply to this case as well. Yes, you can share events
> >> through it altough this method is considered not to be the best by many.
> >> Read up an article about it on OSR.com.
> >> And yes, you can share buffers by passing them as a part of some
> >> structure
> >> associated with a property, but that technique is error prone and
> >> greately
> >> discouraged.
> > Why is it error-prone ? I thought that would be the best way of doing it.
> > Basically, the service would ne a DsHow client and that would then access
> > the
> > driver the way Dshow apps do it..
> >
> >> If I were you what I would do is the following. QI ksproxy instance for
> >> IKsObject instead of IKsPropertySet and get the file handle from
> >> IKsObject.
> >> You can use that file handle to call DeviceIoControl. IIRC the file
> >> handle
> >> is opened with overlapped flag so you can do asynchronous I/O. In the
> >> driver
> >> simply pend received SRBs and complete them as soon as you have your data
> >> available. In your service associate an event with an asynchronous I/O
> >> and
> >> wait on it from a thread.
> >
> > So, this way you can still do IOCTL directly ? So which function is going
> > to
> > be called in the minidriver ? Do you need an exclusive DeviceIocontrol
> > routine ? but how will I expose that since there is dispatch routine. does
> > this method bypass KS.sys or stream.sys ? or is the call coming via a SRB
> > ?
> >
> > and pend what SRB's ? the ones for performing some videocapture operation
> > ?
> > I havent used this before. I will have a detailed look at all this.
> >
> > If you have a good link on some more documentation, please post it.
> >
> > Thanks a bunch.
> >>
> >> -- Max.
> >>
> >>
> >>
> >> "Amit" <> wrote in message
> >> news:435D14EA-D15C-40D2-8F09-...
> >> > You mean to say, that the service would just do a query Interface on
> >> > the
> >> > KSproxy ?
> >> > Is there any documentation on this ?
> >> >
> >> > Is it possible to send buffer pointers into the streaming minidriver
> >> > via
> >> > this method and the driver does the appropriate action based on the
> >> > type
> >> > of
> >> > ioctl ?
> >> >
> >> > and also share events with the driver ? Meaning, the service creates an
> >> > event and the driver invokes the event when data is needed.
> >> >
> >> > "Max Paklin" wrote:
> >> >
> >> >> You don't really have to write a plugin to talk to a KS minidriver.
> >> >> Create an instance of KS proxy for your driver, QI it for
> >> >> IKsPropertySet
> >> >> and
> >> >> set/get properties on your set.
> >> >> Property sets is functionaly similar to an IOCTL.
> >> >>
> >> >> -- Max.
> >> >>
> >> >>
> >> >> "Amit" <> wrote in message
> >> >> news:BEA97F9C-159C-485A-A619-...
> >> >> >I have a WDM streaming driver(Video) solution and I want that to
> >> >> >interact
> >> >> > with a user mode component( a Service Exe loaded at logon time in my
> >> >> > case).
> >> >> >
> >> >> > What would be the best way to go about this ?
> >> >> > Basically, the service sends some data eveyr now and then to the
> >> >> > streaming
> >> >> > minidriver. Should I use IOCTL's and send data excluseively ? or
> >> >> > shall
> >> >> > I
> >> >> > use
> >> >> > FileMapping or some shared objects ?
> >> >> >
> >> >> > 1>I know there are no direct IOCTL's going into the streaming
> >> >> > minidriver
> >> >> > as
> >> >> > the class driver handles everything. But can I overload the class
> >> >> > driver's
> >> >> > IRP_MJ_DEVICE_CONTROL with mine ?
> >> >> >
> >> >> > 2>Should I use Property Sets and Plug ins ? Remember that the
> >> >> > service
> >> >> > will
> >> >> > need to send data every now and then( and I am thinking of using
> >> >> > Events
> >> >> > to
> >> >> > communicate between driver and the service where driver initiates an
> >> >> > event
> >> >> > and the event when evoked, either does an IOCTL or some other way to
> >> >> > communicate data to the streaming minidriver)
> >> >> >
> >> >> > so the calling would be something like a service -> Plugin ->
> >> >> > Minidriver ?
> >> >> >
> >> >> > 3>any other method that anybody can suggest ?
> >> >> >
> >> >> > Thanks.
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

> Oh ok. Then I have this part working actually. All that was needed was
> replacing the IKspropertySet interface with IKSObject and then using
> KsSynchronousDeviceControl instead of Get(IkspropertySet)

Unless you want to do something really special (get detailed report about
minimal/maximal values of the property) using KsSynchronousDeviceControl and
IKsPropertySet makes no difference.
I suggested DeviceIoControl so that you could make it async.


> However, I have one more question. The GetHandler/SetHandler member of the
> KSPROPERTY_ITEM. Why isnt that being called even inspite of specifying a
> proper function ?
>
> I know the DDK says KS1.0 and Avstream. so KS1.0 refers to stream class
> and
> port class drivers, isnt it ?
> so, this should be supported.

IIRC this is by design.
KS 1.0 is not the same as Stream Class. Stream Class is based on KS 1.0, but
KS 1.0 is very low level streaming model with a lot of details and
relatively little abstraction. KS 2.0 (which is AVStream) added a lot of
abstraction hiding almost all gory details of KS 1.0.
Stream Class is overly simplified thing built on top of KS 1.0.
As far as I can remember Stream Class never supported Get/SetHandlers for
KSPROPERTY_ITEM.


-- Max.

"Max Paklin" wrote:

> > Oh ok. Then I have this part working actually. All that was needed was
> > replacing the IKspropertySet interface with IKSObject and then using
> > KsSynchronousDeviceControl instead of Get(IkspropertySet)
>
> Unless you want to do something really special (get detailed report about
> minimal/maximal values of the property) using KsSynchronousDeviceControl and
> IKsPropertySet makes no difference.
> I suggested DeviceIoControl so that you could make it async.

If I want my service to determine the max and min values of buffers, etc do
I need to use the KsSynchronousDeviceControl then. However, does it need any
difference in the driver ?

>
> > However, I have one more question. The GetHandler/SetHandler member of the
> > KSPROPERTY_ITEM. Why isnt that being called even inspite of specifying a
> > proper function ?
> >
> > I know the DDK says KS1.0 and Avstream. so KS1.0 refers to stream class
> > and
> > port class drivers, isnt it ?
> > so, this should be supported.
>
> IIRC this is by design.
> KS 1.0 is not the same as Stream Class. Stream Class is based on KS 1.0, but
> KS 1.0 is very low level streaming model with a lot of details and
> relatively little abstraction. KS 2.0 (which is AVStream) added a lot of
> abstraction hiding almost all gory details of KS 1.0.
> Stream Class is overly simplified thing built on top of KS 1.0.
> As far as I can remember Stream Class never supported Get/SetHandlers for
> KSPROPERTY_ITEM.
Interesting. so this is not suppored to work on a stream class minidriver.
anyway, we are planning to move to avstream sometime soon. We didnt envisage
this situation of using a service earlier and thats why he decoided to stick
to stream class until everything works and then move to avstream. So, now if
I want to support a property page for this custom propery, what would be the
solution ? using a plugin ? or something else ?

Thanks.

>
> -- Max.
>
>
>

> If I want my service to determine the max and min values of buffers, etc
> do
> I need to use the KsSynchronousDeviceControl then. However, does it need
> any
> difference in the driver ?

Yes, use KsSynchronousDeviceControl for that.
Driver doesn't care as request for property ranges doesn't get to it anyway.
The class driver handles all of that.


> to stream class until everything works and then move to avstream. So, now
> if
> I want to support a property page for this custom propery, what would be
> the
> solution ? using a plugin ? or something else ?

Yes, plugins is the way to go.

-- Max.