I have had a poke around utils2/hid/, specifically parser.c and
uinput.h. Correct me if I am wrong, but I am figuring that bthid
collects events from hcid and converts them into events that the kernel
input system can understand. (uinput.h repeats the kernel's input.h key
definitions.)
My question is, are the consumer keymaps in parser.c some sort of
immutable bluetooth standard or just what your personal keyboard is? For
example, you have the following for volumes:
case 0xe2: butt = KEY_MUTE; break;
case 0xe9: butt = KEY_VOLUMEUP; break;
case 0xea: butt = KEY_VOLUMEDOWN; break;
Whereas, my dinovo works with
case 0xe3: butt = KEY_MUTE; break;
case 0xea: butt = KEY_VOLUMEUP; break;
case 0xeb: butt = KEY_VOLUMEDOWN; break;
What sort of keyboard do you have?
Presumably for now it would not matter if the events reported to the
kernel input system did not match what was written on the button labels,
as most people use, for example, gnome acme, which maps arbitrary keys
to program executions. However, the names in kernel input.h must be
there for a reason. I think the long term plan is for things like X to
read /dev/eventX, where it might become important to get it right. Does
this mean that bthid should become configurable?
I am happy to help with this as best I can (patches, testing etc), but
my c/c++ is a little flaky...
Regards,
Oli Ellis
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Oli,
> It does not seem to be an error with the parser - I checked the USB HID
> usage tables, and they tally up with the parser code. However, the
> consumer buttons on the dinovo all seem to be out by one. For example:
>
> Key label keyboard reports (hex) Should be (hex)
> -------------------------------------------------------
> My Pictures 1b7 1b6
> My Music 1b8 1b7
> Volume+ ea e9
> Volume- eb ea
> Mute e3 e2
> &c
>
> Now the question is whether this is a problem in hardware (and if so how
> widespread it is), or the kernel bluetooth bit, or the parser. I can't see
> anything wrong with parser.c, and am inclined towards a bodge job by
> Logitech (and I was so pleased with my new keyboard...) However the
> DiNovo is widespread, so if it is a HID implementation error, any ideas on
> how it can be elegantly worked around?
acutally it can be the parser. Check how the report descriptors of the
Logitech diNovo and the Microsoft keyboard differs. I think our parser
is wrong and shifts a bit with the Logitech descriptor. All information
can be found here
http://www.holtmann.org/linux/bluetooth/hid.html
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Re: the dinovo wrong consumer usage
Possibly cracked it?
>>My question is, are the consumer keymaps in parser.c some sort of
>>immutable bluetooth standard or just what your personal keyboard is? For
>>example, you have the following for volumes:
>> case 0xe2: butt = KEY_MUTE; break;
>> case 0xe9: butt = KEY_VOLUMEUP; break;
>> case 0xea: butt = KEY_VOLUMEDOWN; break;
>>Whereas, my dinovo works with
>> case 0xe3: butt = KEY_MUTE; break;
>> case 0xea: butt = KEY_VOLUMEUP; break;
>> case 0xeb: butt = KEY_VOLUMEDOWN; break;
>>What sort of keyboard do you have?
>>
>Maybe there is a bit error somewhere in parser.c. Actually the consumer
>usages are defined in the USB HID standard and should be general for all
>Bluetooth keyboards.
>
>
It does not seem to be an error with the parser - I checked the USB HID
usage tables, and they tally up with the parser code. However, the
consumer buttons on the dinovo all seem to be out by one. For example:
Key label keyboard reports (hex) Should be (hex)
-------------------------------------------------------
My Pictures 1b7 1b6
My Music 1b8 1b7
Volume+ ea e9
Volume- eb ea
Mute e3 e2
&c
Now the question is whether this is a problem in hardware (and if so how
widespread it is), or the kernel bluetooth bit, or the parser. I can't see
anything wrong with parser.c, and am inclined towards a bodge job by
Logitech (and I was so pleased with my new keyboard...) However the
DiNovo is widespread, so if it is a HID implementation error, any ideas on
how it can be elegantly worked around?
Regards,
Oli
Hi Oli,
> I have had a poke around utils2/hid/, specifically parser.c and
> uinput.h. Correct me if I am wrong, but I am figuring that bthid
> collects events from hcid and converts them into events that the kernel
> input system can understand. (uinput.h repeats the kernel's input.h key
> definitions.)
the hcid has nothing to do with it. It reads the HID reports from the
L2CAP control and interrupts sockets.
> My question is, are the consumer keymaps in parser.c some sort of
> immutable bluetooth standard or just what your personal keyboard is? For
> example, you have the following for volumes:
> case 0xe2: butt = KEY_MUTE; break;
> case 0xe9: butt = KEY_VOLUMEUP; break;
> case 0xea: butt = KEY_VOLUMEDOWN; break;
> Whereas, my dinovo works with
> case 0xe3: butt = KEY_MUTE; break;
> case 0xea: butt = KEY_VOLUMEUP; break;
> case 0xeb: butt = KEY_VOLUMEDOWN; break;
> What sort of keyboard do you have?
>
> Presumably for now it would not matter if the events reported to the
> kernel input system did not match what was written on the button labels,
> as most people use, for example, gnome acme, which maps arbitrary keys
> to program executions. However, the names in kernel input.h must be
> there for a reason. I think the long term plan is for things like X to
> read /dev/eventX, where it might become important to get it right. Does
> this mean that bthid should become configurable?
Maybe there is a bit error somewhere in parser.c. Actually the consumer
usages are defined in the USB HID standard and should be general for all
Bluetooth keyboards.
> I am happy to help with this as best I can (patches, testing etc), but
> my c/c++ is a little flaky...
Go ahead and try. Every patch is welcome.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users