Jiri Kosina wrote: > On Tue, 8 Jan 2008, Jonas Delrue wrote: > >> This fixes the problem. > > Thanks for the information, I will queue up the patch in my tree.
At this chance: > --- a/drivers/hid/hid-input-quirks.c > +++ b/drivers/hid/hid-input-quirks.c > @@ -296,6 +296,7 @@ static int quirk_btc_8193(struct hid_usage *usage, struct > input_dev *input, > #define VENDOR_ID_MICROSOFT 0x045e > #define DEVICE_ID_MS4K 0x00db > #define DEVICE_ID_MS6K 0x00f9 > +#define DEVICE_IS_MS_PRESENTER_MOUSE 0x0701 > #define DEVICE_ID_MS_PRESENTER_8K 0x0713 Maybe we should call the device id differently to express that they are in fact addressing the same hardware via different interfaces. I mean, something like #define DEVICE_IS_MS_PRESENTER_8K_BT 0x0701 #define DEVICE_IS_MS_PRESENTER_8K_USB 0x0713 > >> Another question, wouldn't it be better to assign the buttons to virtual >> buttons instead of real buttons? It's hard using the buttons for >> multimedia this way. > > Well, I don't have the hardware, so I don't know what exactly the button > layout looks like and what is the intended purpose of them. The mapping, > as it is in current tree, has been done according to information Jan sent > me (and you seem to have it dropped from CC, re-added). Jan? So that you can customize them via xmodmap? Yeah, that sounds more reasonable than my hard-wiring. Which -mm patches do I need to apply the new quirks handling on top of 2.6.23 or .24? I would like to test that stuff as well then. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux
