Firefly example sends HID related
in [Device Drivers]
|
From: Angela Yan on 22 Aug 2005 06:30 Hi All, I have some queries here regarding the DDK's firefly example. In its vfeature.cpp, it sends IOCTL_HID_GET_COLLECTION_INFORMATION IOCTL_HID_GET_COLLECTION_DESCRIPTOR IOCTL_HID_SET_FEATURE to the Top most driver of the driver stack instead of the one just below the firefily filter. I just wonder why it wants to send the top most driver of the driver stack? Is it compulsory, or is it a norm to do so for these calls? Else, in what situation would a filter driver send these IRPs all the way up? Because some driver in the stack above the filter driver will handle these calls? And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID and usage ID. What are the vedor specific range for them? Why the firefly doesn't need to set the usage of the page ID and usage ID beforehand if the taillight is turning off? Last question, will HidClass block custom IOCTL call? Thanks in advance. Angela
From: Doron Holan [MS] on 22 Aug 2005 11:02 it sends them to the top of the stack because all i/o goes through the top of the stack. IIRC, it sends it to the devobj that it got from IoGetDeviceObjectPointer. you should follow the rules and do the same > And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID and > usage ID. What are the vedor specific range for them? > i don't understand the question about vendor ranges with usage pages. there are defined pages by the spec and those left up to the particular device manufacturer. > Why the firefly doesn't need to set the usage of the page ID and usage ID > beforehand if the taillight is turning off? probably b/c the the buffer contains the report ID already and if everything else is zero, it is turned off > Last question, will HidClass block custom IOCTL call? do you mean will hidclas block a custom IOCTL sent by a driver to the hid miniport? if so, yes, it will fail. the HID PDO will fail all IOCTLs it does not know about. d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. "Angela Yan" <yanyan9(a)hotmail.com> wrote in message news:uYBMBSwpFHA.3316(a)TK2MSFTNGP14.phx.gbl... > Hi All, > > I have some queries here regarding the DDK's firefly example. > > In its vfeature.cpp, it sends > > IOCTL_HID_GET_COLLECTION_INFORMATION > IOCTL_HID_GET_COLLECTION_DESCRIPTOR > IOCTL_HID_SET_FEATURE > > to the Top most driver of the driver stack instead of the one just below > the firefily filter. > > I just wonder why it wants to send the top most driver of the driver > stack? > > Is it compulsory, or is it a norm to do so for these calls? Else, in what > situation would a filter driver send these IRPs all the way up? Because > some driver in the stack above the filter driver will handle these calls? > > And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID and > usage ID. What are the vedor specific range for them? > > Why the firefly doesn't need to set the usage of the page ID and usage ID > beforehand if the taillight is turning off? > > Last question, will HidClass block custom IOCTL call? > > Thanks in advance. > > Angela > > >
From: Angela Yan on 23 Aug 2005 23:41 Hi, Thank you, Doron. You are very helpful. :) I still have some doubts on HidClass and its mini driver behavior. Forgive me if I ask silly questions. >> Last question, will HidClass block custom IOCTL call? > do you mean will hidclas block a custom IOCTL sent by a driver to the hid > miniport? if so, yes, it will fail. the HID PDO will fail all IOCTLs it > does not know about. This behavior of HidClass would make me have some silly thoughts. Eg. how can the Hid minidriver inform the upper filter, such as firefly, of an occurance of a user input event. Currently for mouse devices, firefly can access the user input event through MouFilter_ServiceCallback(). But what if it has a custom user input event that is not included in the PMOUSE_INPUT_DATA struct? Since HidClass blocks custom IOCTL call, firefly cannot send a custom IOCTL to the mini driver, mini driver just marks it pending and complete it upon receiving a user input event from bus driver. Or, is it possible for firefly to send an asynch IRP for IOCTL_HID_GET_FEATURE call then the mini driver just marks it pending and retun it upon receiving an event?? In this case, will HidClass have some timeout scheme for IOCTL_HID_GET_FEATURE call? Or, is there any other strategy can be used for this kind of situation? From Oney's book, I think probably an EDO (Control device object) from the Hid minidriver can accomplish that. But, is there any 'normal' way to do this? Thanks in advance. Regards, Angela "Doron Holan [MS]" <doronh(a)nospam.microsoft.com> wrote in message news:u7IlQqypFHA.3180(a)TK2MSFTNGP15.phx.gbl... > it sends them to the top of the stack because all i/o goes through the top > of the stack. IIRC, it sends it to the devobj that it got from > IoGetDeviceObjectPointer. you should follow the rules and do the same > >> And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID >> and usage ID. What are the vedor specific range for them? >> > i don't understand the question about vendor ranges with usage pages. > there are defined pages by the spec and those left up to the particular > device manufacturer. > >> Why the firefly doesn't need to set the usage of the page ID and usage ID >> beforehand if the taillight is turning off? > probably b/c the the buffer contains the report ID already and if > everything else is zero, it is turned off > >> Last question, will HidClass block custom IOCTL call? > do you mean will hidclas block a custom IOCTL sent by a driver to the hid > miniport? if so, yes, it will fail. the HID PDO will fail all IOCTLs it > does not know about. > > d > > -- > Please do not send e-mail directly to this alias. this alias is for > newsgroup purposes only. > This posting is provided "AS IS" with no warranties, and confers no > rights. >
From: Doron Holan [MS] on 25 Aug 2005 02:45 are you writing the HID miniport driver? a control devobj will not work with a HID miniport, HIDclass owns the dispatch table and the devobj and it does not support control devices. you talk to your hid miniport through HID reports or features. if you have custom functionality/settings in your hid miniport that you want to manipulate, report another top level collection (TLC) and talk to that 2nd TLC. IOCTL_HID_GET_FEATURE will not timeout, you must implement your own time out. how does spontaneous async data get from the device to the driver? hidclass continuously sends reads dwon the device and queues up the data returned to each TLC. the client can then open the TLC and read that data. mouhid continuously sends read reports to the HIDClass PDO for its TLC. d -- Please do not send e-mail directly to this alias. this alias is for newsgroup purposes only. This posting is provided "AS IS" with no warranties, and confers no rights. "Angela Yan" <yanyan9(a)hotmail.com> wrote in message news:ekSFt2FqFHA.3112(a)TK2MSFTNGP12.phx.gbl... > Hi, > > Thank you, Doron. You are very helpful. :) I still have some doubts on > HidClass > and its mini driver behavior. Forgive me if I ask silly questions. > >>> Last question, will HidClass block custom IOCTL call? >> do you mean will hidclas block a custom IOCTL sent by a driver to the hid >> miniport? if so, yes, it will fail. the HID PDO will fail all IOCTLs it >> does not know about. > > This behavior of HidClass would make me have some silly thoughts. Eg. how > can > the Hid minidriver inform the upper filter, such as firefly, of an > occurance of > a user input event. Currently for mouse devices, firefly can access the > user > input event through MouFilter_ServiceCallback(). But what if it has a > custom > user input event that is not included in the PMOUSE_INPUT_DATA struct? > > Since HidClass blocks custom IOCTL call, firefly cannot send a custom > IOCTL > to the mini driver, mini driver just marks it pending and complete it upon > receiving > a user input event from bus driver. > > Or, is it possible for firefly to send an asynch IRP for > IOCTL_HID_GET_FEATURE call > then the mini driver just marks it pending and retun it upon receiving an > event?? > In this case, will HidClass have some timeout scheme for > IOCTL_HID_GET_FEATURE call? > > Or, is there any other strategy can be used for this kind of situation? > From Oney's > book, I think probably an EDO (Control device object) from the Hid > minidriver can > accomplish that. But, is there any 'normal' way to do this? > > Thanks in advance. > > Regards, > Angela > > > > > > > "Doron Holan [MS]" <doronh(a)nospam.microsoft.com> wrote in message > news:u7IlQqypFHA.3180(a)TK2MSFTNGP15.phx.gbl... >> it sends them to the top of the stack because all i/o goes through the >> top of the stack. IIRC, it sends it to the devobj that it got from >> IoGetDeviceObjectPointer. you should follow the rules and do the same >> >>> And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID >>> and usage ID. What are the vedor specific range for them? >>> >> i don't understand the question about vendor ranges with usage pages. >> there are defined pages by the spec and those left up to the particular >> device manufacturer. >> >>> Why the firefly doesn't need to set the usage of the page ID and usage >>> ID beforehand if the taillight is turning off? >> probably b/c the the buffer contains the report ID already and if >> everything else is zero, it is turned off >> >>> Last question, will HidClass block custom IOCTL call? >> do you mean will hidclas block a custom IOCTL sent by a driver to the hid >> miniport? if so, yes, it will fail. the HID PDO will fail all IOCTLs it >> does not know about. >> >> d >> >> -- >> Please do not send e-mail directly to this alias. this alias is for >> newsgroup purposes only. >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >
From: Angela Yan on 28 Aug 2005 11:07 Thanks, Doron. You're very helpful. :) Angela "Doron Holan [MS]" <doronh(a)nospam.microsoft.com> wrote in message news:uQvoXCUqFHA.3136(a)TK2MSFTNGP11.phx.gbl... > are you writing the HID miniport driver? a control devobj will not work > with a HID miniport, HIDclass owns the dispatch table and the devobj and > it does not support control devices. you talk to your hid miniport > through HID reports or features. if you have custom > functionality/settings in your hid miniport that you want to manipulate, > report another top level collection (TLC) and talk to that 2nd TLC. > > IOCTL_HID_GET_FEATURE will not timeout, you must implement your own time > out. > > how does spontaneous async data get from the device to the driver? > hidclass continuously sends reads dwon the device and queues up the data > returned to each TLC. the client can then open the TLC and read that > data. mouhid continuously sends read reports to the HIDClass PDO for its > TLC. > > d > -- > Please do not send e-mail directly to this alias. this alias is for > newsgroup purposes only. > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > "Angela Yan" <yanyan9(a)hotmail.com> wrote in message > news:ekSFt2FqFHA.3112(a)TK2MSFTNGP12.phx.gbl... >> Hi, >> >> Thank you, Doron. You are very helpful. :) I still have some doubts on >> HidClass >> and its mini driver behavior. Forgive me if I ask silly questions. >> >>>> Last question, will HidClass block custom IOCTL call? >>> do you mean will hidclas block a custom IOCTL sent by a driver to the >>> hid miniport? if so, yes, it will fail. the HID PDO will fail all >>> IOCTLs it does not know about. >> >> This behavior of HidClass would make me have some silly thoughts. Eg. how >> can >> the Hid minidriver inform the upper filter, such as firefly, of an >> occurance of >> a user input event. Currently for mouse devices, firefly can access the >> user >> input event through MouFilter_ServiceCallback(). But what if it has a >> custom >> user input event that is not included in the PMOUSE_INPUT_DATA struct? >> >> Since HidClass blocks custom IOCTL call, firefly cannot send a custom >> IOCTL >> to the mini driver, mini driver just marks it pending and complete it >> upon receiving >> a user input event from bus driver. >> >> Or, is it possible for firefly to send an asynch IRP for >> IOCTL_HID_GET_FEATURE call >> then the mini driver just marks it pending and retun it upon receiving an >> event?? >> In this case, will HidClass have some timeout scheme for >> IOCTL_HID_GET_FEATURE call? >> >> Or, is there any other strategy can be used for this kind of situation? >> From Oney's >> book, I think probably an EDO (Control device object) from the Hid >> minidriver can >> accomplish that. But, is there any 'normal' way to do this? >> >> Thanks in advance. >> >> Regards, >> Angela >> >> >> >> >> >> >> "Doron Holan [MS]" <doronh(a)nospam.microsoft.com> wrote in message >> news:u7IlQqypFHA.3180(a)TK2MSFTNGP15.phx.gbl... >>> it sends them to the top of the stack because all i/o goes through the >>> top of the stack. IIRC, it sends it to the devobj that it got from >>> IoGetDeviceObjectPointer. you should follow the rules and do the same >>> >>>> And, the TAILLIGHT_PAGE and TAILLIGHT_FEATURE are custom usage page ID >>>> and usage ID. What are the vedor specific range for them? >>>> >>> i don't understand the question about vendor ranges with usage pages. >>> there are defined pages by the spec and those left up to the particular >>> device manufacturer. >>> >>>> Why the firefly doesn't need to set the usage of the page ID and usage >>>> ID beforehand if the taillight is turning off? >>> probably b/c the the buffer contains the report ID already and if >>> everything else is zero, it is turned off >>> >>>> Last question, will HidClass block custom IOCTL call? >>> do you mean will hidclas block a custom IOCTL sent by a driver to the >>> hid miniport? if so, yes, it will fail. the HID PDO will fail all >>> IOCTLs it does not know about. >>> >>> d >>> >>> -- >>> Please do not send e-mail directly to this alias. this alias is for >>> newsgroup purposes only. >>> This posting is provided "AS IS" with no warranties, and confers no >>> rights. >>> >> > >
|
Pages: 1 Prev: WinXP x64 STREAM.SYS 0x3b Crash Next: MmAllocateContiguousMemory in WDM drivers |