Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 24 Aug 2005 23:55:23 -0700
the ddk sample you are referring to blows away the previous values and
hardcodes the new values. let's say you want to keep the existing values
and just put your driver at the front of the list. That can't be done using
an INF.
a power policy owner is the driver in the stack that translates S (system)
irps into D (device) irps and decides when/if to arm the device for wait
wake.
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.
"Martin Smith" <smith_removeme_mb_at_ufl_ignorethis_edu> wrote in message
news:%23ZUN3PTqFHA.1328@xxxxxxxxxxxxxxxxxxxxxxx
>I almost forgot... found this at
>http://www.microsoft.com/whdc/archive/PnP-XPDDK.mspx
>
> ClasFilt Sample INF File
> %winddk%\src\setup\infs\clasfilt\ ClasFilt.inf is a sample INF file that
> demonstrates the installation of a class filter driver that will be
> applied as an upper or lower filter to all devices of a specific device
> setup class. INF files based on ClasFilt.inf can be installed either
> manually or programmatically. Users can install INF files based on
> ClasFilt.inf manually by right-clicking on the designated INF file and
> selecting "Install" from the pop-up menu. A device installation program
> can install the class filter driver programmatically by calling the
> InstallHinfSection API, which reads the indicated INF file and installs
> the driver listed in the indicated DefaultInstall section.
>
>
>
> It appears that installing a class filter with an inf is indeed possible,
> no?
>
> Thanks!
>
>
>
>
>
> "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:un7QQW6pFHA.2952@xxxxxxxxxxxxxxxxxxxxxxx
>
>> an INF cannot install a class filter. there is inf syntax to specify
>> position in a multi sz.
>>
>> the mouclass class driver pends read irps and maintains a circular ring
>> buffer of incoming input packets or pended reads awaiting input packets.
>> it acts as the power policy owner for the stack. all the port driver has
>> to do is report input data via the service callback set in the IOCTL in
>> the title and handle pnp/power/wmi irps. mouclass's job is make the port
>> driver's life easy. kbdclass does the same thing for keyboards. the src
>> for both (which are almost identical) are in the ddk.
>>
>> 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.
>>
>>
>> "Martin Smith" <smith_removeme_mb_at_ufl_ignorethis_edu> wrote in message
>> news:edl7lu5pFHA.1096@xxxxxxxxxxxxxxxxxxxxxxx
>>> Hi there --
>>>
>>> After some fiddling, I got this to work. I could have sworn I tried this
>>> before, but I apparently had the driver loaded just above mouclass. The
>>> syntax for the UpperFilters' REG_SZ_MULTI must have thrown me. It's all
>>> about the order of the list there. I was filtering the entire class of
>>> mouse devices, in order to avoid the trouble of finding the correct ID,
>>> and the UpperFilters' entry in the registry for the Mouse class of
>>> devices was in the wrong order. Moufiltr first, then Mouclass -- though
>>> I'm sure I tried this before. Not sure what changed. I was using the MS
>>> BT stack. I'm still not entirely sure about what Pointer class and
>>> Pointer port drivers do, and why this filter goes below Mouclass as
>>> opposed to "above pointer class" or something else; From my own
>>> conceptual standpoint, the Pointer/Mouse/Hid Class/Port/Filter tree is a
>>> bit confusing!
>>>
>>> Currently working on getting better versed in INF syntax to install the
>>> filter =). Please excuse my novice stacking error =)
>>>
>>> Thanks for the reply. It's good to learn the mechanics behind this!
>>>
>>> Thanks again!
>>>
>>> "Doron Holan [MS]" <doronh@xxxxxxxxxxxxxxxxxxxx> wrote in message
>>> news:uDcUBoypFHA.3244@xxxxxxxxxxxxxxxxxxxxxxx
>>>> are you sure you are below mouclass? you should see this IOCTl as soon
>>>> as you have returned from AddDevice(). are you sure you installed on
>>>> the mouse itself (or are you installing as a class upper filter)? a
>>>> bluetooth mouse is just a HID device, just a like a usb device. it
>>>> uses the HID stack and the mouse HID mapper (mouhid) to report mouse
>>>> data, so what works for usb, works for bluetooth (this is assuming you
>>>> are using the MSFT provided stack).
>>>>
>>>> after you create and attach your device in AddDevice, break into the
>>>> debugger and run
>>>>
>>>> !devstack <your devobj pointer value>
>>>>
>>>> and reply with the results
>>>>
>>>> thx
>>>> 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.
>>>>
>>>>
>>>> "Martin Smith" <smith_removeme_mb_at_ufl_ignorethis_edu> wrote in
>>>> message news:eYYZ$3spFHA.3568@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> Howdy there --
>>>>>
>>>>> This is my first post here, although I have been occaisonally lurking.
>>>>> I'm
>>>>> working on writing an filter driver to be placed right below
>>>>> MouClass.sys.
>>>>> I've started off with the DDK MouFiltr.sys example, but I think I've
>>>>> come up
>>>>> against a wall somewhere --
>>>>>
>>>>> When trying to hook into the ISR/callback function so that my filter
>>>>> driver
>>>>> can be notified (the ddk example does this),
>>>>> IOCTL_INTERNAL_MOUSE_CONNECT is
>>>>> never seen by my driver. At first I assumed I was simply placing the
>>>>> driver
>>>>> in the wrong stack position, but now I suspect this problem is due my
>>>>> mouse
>>>>> being a bluetooth device.
>>>>>
>>>>> In the notes for the DDK example, it mentions that hooking into the
>>>>> callback
>>>>> isr to process "input" data before the MouClass.sys driver sees it is
>>>>> only
>>>>> possible with the i8042prt stack. Is there an equivalent IOCTL that
>>>>> the
>>>>> bluetooth (xpsp2) stack uses to hook this -- or does the bluetooth
>>>>> stack
>>>>> just fill in IRPs with the "input" data from the (bluetooth?) driver
>>>>> stacked
>>>>> below MouFiltr?
>>>>>
>>>>> Thanks for any responses!
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
.
- References:
- IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: Martin Smith
- Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: Doron Holan [MS]
- Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: Martin Smith
- Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: Doron Holan [MS]
- Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- From: Martin Smith
- IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- Prev by Date: Re: Cache
- Next by Date: Safe DataTypes
- Previous by thread: Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- Next by thread: Re: IOCTL_INTERNAL_MOUSE_CONNECT Equivalent for the Bluetooth Stack
- Index(es):
Relevant Pages
|
