Marcel,
I originally sent these observations at the end of april but
you were busy at that time and I guess it passed by without
you noticing.
0) Everything works fine in HID mode. All the buttons on the mouse
and keyboard work correctly at the input level as reported by evtest.
1) The patch to hid2hci.c that Trevor Joynson provided and which was
incorporated is not correct - and this is consistent with the reported
experience of other people with the di novo laser desktop combo.
- the 0x0b02 device is the usb hub itself and it is not the right thing
to attempt to switch to hci mode. Rather, you try to switch the HID
devices themselves. In the case of the mx-5000, the hid devices are
0xc70a (the mouse) and 0xc70e (the keyboard). I belive that the
di novo devices are 0xc70b and 0xc70c.
- Once switched, the hci device appears as 0xc709 - the same as in the
di novo receiver.
2) I did not need Trevor's hci_usb patch, which Marcel did not see a
need for either.
3) I applied the mh patches (now 2.6.16-mh3) to get HID report mode.
4) In HID report mode, the HWHEEL is mangled at some point. Instead of
reporting a usage of 0x10036, it reports 0xC0238, causing it to be
marked as an unknown button. I put a hack into hidp's hid.c to catch
this case and rewrite the usage. The rest of the characteristics seem
to be correct and the horizontal scrolling works correctly.
I don't know if the mouse is just reporting the wrong value or if the
usage is getting mangled somewhere in the stack.
5) The keyboard also sees modified usages, but this is definitely in the
hidp driver:
This step is in hidinput_configure_usage:
while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
usage->code = find_next_zero_bit(bit, max + 1, usage->code);
}
eg: It mangles KEY_UNDO (131) into KEY_SENDFILE (145) which doesn't
seem very useful.
It's not the end of the world if the desktop environment/application
supports configurable keybindings, but it's still not correct.
6) The keyboard has HID consumer reports that hidp doesn't know about.
So, I added entries for them in hidinput_configure_usage and now they
work fine.
7) Not a driver matter, but the keyboard features keys that generate no
bluetooth traffic, at least as far as hcidump is concerned. My
conclusion was that these buttons are only activated by firmware that
you download to the keyboard in windows - but I currently have the
basic firmware running on the keyboard (Gives me data/time/temp) and
none of these keys work in linux. Philip Lawatsch thinks that it's
not quite as simple as I describe - he says the firmware files are
too small to actually include code that would program the buttons
at a low level. These non-functional buttons also don't work in HID
proxy mode, in case you were wondering.
8) No idea how extra stuff like battery levels and tweaking the cruise
control buttons works. Tools like locomo don't work (and they don't
work with the mx900 either). Could such things still be done through
the HID endpoints in HCI mode or would they have to be done at the
bluetooth level? If it's at the bluetooth level, should we see an
explicit service of somesort listed?
I've attached the hidp patch that I'm using the fix the HWHEEL and the
extra keyboard events, but this is hardly directly applicable. If
nothing else, a proper quirks infrastructure is needed for the HWHEEL
handling.
Thanks,
--phil
Marcel Holtmann wrote:
>
> are you sure that we should replace 0xc70a - 0xc70e with 0x0b02? Is this
> the hub and it is accepting HID reports now?
Ah. The diff is the wrong way round. :-)
0x0b02 is the hub and it is not accepting HID reports, which is why
you can't switch the mx-5000/dinovo adapter with hid2hci today.
--phil
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Philip,
> >> 1) The patch to hid2hci.c that Trevor Joynson provided and which was
> >> incorporated is not correct - and this is consistent with the reported
> >> experience of other people with the di novo laser desktop combo.
> >
> > I have no idea what you are talking about. If you think that something
> > is wrong, please provide a patch to fix it.
>
> I have attached the patch against hid2hci.
are you sure that we should replace 0xc70a - 0xc70e with 0x0b02? Is this
the hub and it is accepting HID reports now?
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>> 4) In HID report mode, the HWHEEL is mangled at some point. Instead of
>> reporting a usage of 0x10036, it reports 0xC0238, causing it to be
>> marked as an unknown button. I put a hack into hidp's hid.c to catch
>> this case and rewrite the usage. The rest of the characteristics seem
>> to be correct and the horizontal scrolling works correctly.
>>
>> I don't know if the mouse is just reporting the wrong value or if the
>> usage is getting mangled somewhere in the stack.
>
> If you think the HID report descriptor is wrong, then I prefer to fix it
> instead of adding workarounds to kernel code. We did the same for the
> EPoX presenter. Please check if a modified HID report descriptor can
> solve your problem.
Heh. I looked at the USB HID code and they handle Consumer 0x238 by
mapping it to HWHEEL. So this is more common than just this mouse.
So, that's one argument in favour of resync'ing.
>> 5) The keyboard also sees modified usages, but this is definitely in the
>> hidp driver:
>>
>> This step is in hidinput_configure_usage:
>>
>> while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
>> usage->code = find_next_zero_bit(bit, max + 1, usage->code);
>> }
>>
>> eg: It mangles KEY_UNDO (131) into KEY_SENDFILE (145) which doesn't
>> seem very useful.
>>
>> It's not the end of the world if the desktop environment/application
>> supports configurable keybindings, but it's still not correct.
>
> Can't tell you the reason for it. Maybe it is a bug or maybe this has
> been done on purpose. Please check with the USB HID driver.
This sequence is the same in the usb hid driver. It's also worth
pointing out that it does useful stuff for other types of events, but
for these consumer keys, it does that mangling. Maybe resync'ing will
fix it by another change in some other part of the code.
>> 6) The keyboard has HID consumer reports that hidp doesn't know about.
>> So, I added entries for them in hidinput_configure_usage and now they
>> work fine.
>
> Please check with the USB HID driver from latest vanilla kernel. Maybe
> we need to sync these two drivers again.
Some of the new codes are now covered, but others are not. I guess I
should talk to the USB HID maintainer about that.
Thanks,
--phil
Marcel Holtmann wrote:
>>
>> 1) The patch to hid2hci.c that Trevor Joynson provided and which was
>> incorporated is not correct - and this is consistent with the reported
>> experience of other people with the di novo laser desktop combo.
>
> I have no idea what you are talking about. If you think that something
> is wrong, please provide a patch to fix it.
I have attached the patch against hid2hci.
I'll followup on the other items and get back to you when I've got
some information.
--phil
Hi Philip,
> I originally sent these observations at the end of april but
> you were busy at that time and I guess it passed by without
> you noticing.
looks like I missed that.
> 0) Everything works fine in HID mode. All the buttons on the mouse
> and keyboard work correctly at the input level as reported by evtest.
>
> 1) The patch to hid2hci.c that Trevor Joynson provided and which was
> incorporated is not correct - and this is consistent with the reported
> experience of other people with the di novo laser desktop combo.
I have no idea what you are talking about. If you think that something
is wrong, please provide a patch to fix it.
> 4) In HID report mode, the HWHEEL is mangled at some point. Instead of
> reporting a usage of 0x10036, it reports 0xC0238, causing it to be
> marked as an unknown button. I put a hack into hidp's hid.c to catch
> this case and rewrite the usage. The rest of the characteristics seem
> to be correct and the horizontal scrolling works correctly.
>
> I don't know if the mouse is just reporting the wrong value or if the
> usage is getting mangled somewhere in the stack.
If you think the HID report descriptor is wrong, then I prefer to fix it
instead of adding workarounds to kernel code. We did the same for the
EPoX presenter. Please check if a modified HID report descriptor can
solve your problem.
> 5) The keyboard also sees modified usages, but this is definitely in the
> hidp driver:
>
> This step is in hidinput_configure_usage:
>
> while (usage->code <= max && test_and_set_bit(usage->code, bit)) {
> usage->code = find_next_zero_bit(bit, max + 1, usage->code);
> }
>
> eg: It mangles KEY_UNDO (131) into KEY_SENDFILE (145) which doesn't
> seem very useful.
>
> It's not the end of the world if the desktop environment/application
> supports configurable keybindings, but it's still not correct.
Can't tell you the reason for it. Maybe it is a bug or maybe this has
been done on purpose. Please check with the USB HID driver.
> 6) The keyboard has HID consumer reports that hidp doesn't know about.
> So, I added entries for them in hidinput_configure_usage and now they
> work fine.
Please check with the USB HID driver from latest vanilla kernel. Maybe
we need to sync these two drivers again.
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel