On Thu, 12 Apr 2007, Jiri Kosina wrote:
On Thu, 12 Apr 2007, Paul Walmsley wrote:
Now, another implementation approach would be to get rid of the quirk
type names entirely, to use a path such as:
/usbhid/quirks_runtime/:
with the last component being a r/w configfs attribute containing the
On Thu, 12 Apr 2007, Paul Walmsley wrote:
> Now, another implementation approach would be to get rid of the quirk
> type names entirely, to use a path such as:
>
> /usbhid/quirks_runtime/:
>
> with the last component being a r/w configfs attribute containing the quirks
> value. Is that what y
On Thu, 12 Apr 2007, Jiri Kosina wrote:
On Wed, 11 Apr 2007, Paul Walmsley wrote:
You're talking about using another static struct hid_blacklist array in
place of the struct hid_quirk_types array, right?
no, in fact I was just thinking about extending the hid_blacklist[] with
additional fiel
On Wed, 11 Apr 2007, Paul Walmsley wrote:
> You're talking about using another static struct hid_blacklist array in
> place of the struct hid_quirk_types array, right?
Hi Paul,
no, in fact I was just thinking about extending the hid_blacklist[] with
additional field 'name', which will be use
On Wed, 11 Apr 2007, Jiri Kosina wrote:
On Wed, 11 Apr 2007, Jiri Kosina wrote:
- [7/7] I agree with using configfs. What is quite unfortunate is that
adding a new quirk requires now another place that it is necessary to
modify - forgetting to do it and keeping configfs values out-of-sync
Hello Jiri,
On Wed, 11 Apr 2007, Jiri Kosina wrote:
I have a few rather simple notes to your patches.
Thanks for the review - I've fixed all of the issues that you noted and
rebased the patches against hid.git - will post them shortly.
I made one other cosmetic change, 'equirks' is now 'dq
On Wed, 11 Apr 2007, Jiri Kosina wrote:
> - [7/7] I agree with using configfs. What is quite unfortunate is that
> adding a new quirk requires now another place that it is necessary to
> modify - forgetting to do it and keeping configfs values out-of-sync
> seems rather easy mistake to do
On Wed, 11 Apr 2007, Paul Walmsley wrote:
> Much of this code could probably be shared with the Bluetooth HID
> subsystem. I guess there's been some discussion about this recently.
> If this code seems more appropriate to drivers/hid/, I'd be happy to
> reshuffle it.
Hi Paul,
thanks a lot fo
Hello,
As requested, I respun the runtime USB HID quirks patches that I posted a
few weeks ago. My application for this code is to switch quirks at
runtime for a data acquisition device. This device has at least two
drivers written for it: one kernel module driver requiring
HID_QUIRK_IGNOR
