Skip to contentSkip to conversation

dinovo multimedia keys

Bluez-users Oli Ellis 2 participants 4 messages Mar 23, 2004 Bluetooth drivers

lore
Share & tools
lore

Oli Ellis

author
#0 lore raw

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

maintainer
#1 lore raw

Hi Oli,

Quoted 5 lines

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.

Quoted 12 lines

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?

Quoted 7 lines

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.

Quoted 2 lines

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

author
#2 lore raw

Re: the dinovo wrong consumer usage

Possibly cracked it?

Quoted 10 lines
Quoted 10 lines

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?

Quoted 5 lines

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

maintainer
#3 lore raw

Hi Oli,

Quoted 13 lines

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

Quoted 6 lines

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