* [Bluez-users] hid keyboard events get lost
@ 2007-05-25 15:16 Konrad Kieling
2007-05-28 12:19 ` Konrad Kieling
0 siblings, 1 reply; 5+ messages in thread
From: Konrad Kieling @ 2007-05-25 15:16 UTC (permalink / raw)
To: bluez-users
[-- Attachment #1.1: Type: text/plain, Size: 8900 bytes --]
hi,
i have some problems with getting the ``Freedom Universal Keyboard'' to
work. after authentication the keyboard is automatically trying to
connect to my computer. however, the connections never work. heres is
the output of ``hcidump -V'' (using bluez-utils-3.10.1 and kernel
2.6.16.13):
> HCI Event: Connect Request (0x04) plen 10
bdaddr 00:0B:0D:85:30:0B class 0x002540 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:0B:0D:85:30:0B role 0x01
Role: Slave
.
.
.
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0040
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 42 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 1 clen 4
MTU 128
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 1 clen 4
MTU 128
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 42 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 42 reason 0x16
Reason: Connection Terminated by Local Host
it seems to have problems in negotiating the mtu size. so i tried and
commented out the lines in hidd which set the preferred mtu size,
opts.imtu = HIDP_DEFAULT_MTU;
opts.omtu = HIDP_DEFAULT_MTU;
with this version of hidd the connection works perfectly, and even
keystrokes are transferred, as can be seen in the hcidump:
.
.
.
> ACL data: handle 43 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 17 scid 0x0040
< ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 48
< ACL data: handle 43 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> ACL data: handle 43 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
> ACL data: handle 43 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 19 scid 0x0041
< ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 48
< ACL data: handle 43 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 43 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> ACL data: handle 43 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 43 flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Set protocol: Boot protocol
< ACL data: handle 43 flags 0x02 dlen 7
L2CAP(d): cid 0x0041 len 3 [psm 19]
HIDP: Data: Output report
> ACL data: handle 43 flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Handshake: Successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 43 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 43 mode 0x02 interval 128
Mode: Sniff
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 43 mode 0x00 interval 0
Mode: Active
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
> ACL data: handle 43 flags 0x02 dlen 13
L2CAP(d): cid 0x0041 len 9 [psm 19]
HIDP: Data: Input report
hcidump -X also shows, that the packets indeed contain keycodes.
the device is correctly registered in /proc/bus/input/devices and in
/sys/class/input/input4. however, the events never arrive in
/dev/input/event4. the debugging messages of the hidp kernel module
suggest, that they dont even arrive at this module:
May 25 15:57:38 ed007 kernel: Bluetooth: HIDP (Human Interface
Emulation) ver 1.1
May 25 16:06:13 ed007 hidd[6345]: Bluetooth HID daemon
May 25 16:06:24 ed007 hcid[5321]: link_key_request
(sba=00:03:7A:F0:73:B5, dba=00:0B:0D:85:30:0B)
May 25 16:06:24 ed007 hidd[6345]: New HID device 00:0B:0D:85:30:0B
(Bluetooth Kbd)
May 25 16:06:24 ed007 kernel: hidp_add_connection:
May 25 16:06:24 ed007 kernel: __hidp_get_session:
May 25 16:06:24 ed007 kernel: hidp_add_connection: ctrl mtu 0 intr
mtu 0
May 25 16:06:24 ed007 kernel: input: Bluetooth HID Boot Protocol
Device as /class/input/input4
May 25 16:06:24 ed007 kernel: __hidp_send_ctrl_message: session
d972f640 data 00000000 size 0
May 25 16:06:24 ed007 kernel: hidp_input_event: input d4a1e800 type 17
code 0 value 0
May 25 16:06:24 ed007 kernel: hidp_session: session d972f640
May 25 16:06:24 ed007 kernel: hidp_process_transmit: session d972f640
May 25 16:06:24 ed007 kernel: hidp_send_frame: sock db45bb40 data
e4fab800 len 1
May 25 16:06:24 ed007 kernel: hidp_send_frame: sock db45b840 data
eca4ba00 len 3
May 25 16:06:24 ed007 kernel: hidp_process_transmit: session d972f640
does anyone have a clue why the events get lost on their way? or
something on this mtu problem?
thanks,
konrad
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Bluez-users] hid keyboard events get lost
2007-05-25 15:16 [Bluez-users] hid keyboard events get lost Konrad Kieling
@ 2007-05-28 12:19 ` Konrad Kieling
2007-05-28 13:55 ` Marcel Holtmann
0 siblings, 1 reply; 5+ messages in thread
From: Konrad Kieling @ 2007-05-28 12:19 UTC (permalink / raw)
To: BlueZ users
[-- Attachment #1.1: Type: text/plain, Size: 10489 bytes --]
hello again,
just to let you know: the ``Freedom Universal Keyboard'' is working
perfectly now, after applying some minor tweaks to the kernel:
1. something to avoid the long negotiation for the mtu size, i commented
out the following lines in l2cap_build_conf_req
(net/bluetooth/l2cap.c):
// if (pi->imtu != L2CAP_DEFAULT_MTU)
// l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
yes i know, this might not be the way to go, but bt still works with
my mobile and the headset. maybe someone has an idea for a cleaner
solution?
2. unfortunately the data coming from the keyboard is missing the first
byte telling us about keyboard input. in hidp_input_report
(net/bluetooth/hidp/core.c) insert the following
lines after variable declaration:
if ( ( session->input->id.vendor == 0x045e ) &&
( session->input->id.product == 0x0403 ) )
{
for ( i = 7; i >= 0; i -- ) skb->data[i + 1] = skb->data[i];
skb->data[0] = 0x01;
}
again, is there a way to cope with this problem in a more generic
way?
ciao,
konrad
Konrad Kieling wrote:
> hi,
> i have some problems with getting the ``Freedom Universal Keyboard'' to
> work. after authentication the keyboard is automatically trying to
> connect to my computer. however, the connections never work. heres is
> the output of ``hcidump -V'' (using bluez-utils-3.10.1 and kernel
> 2.6.16.13):
> > HCI Event: Connect Request (0x04) plen 10
> bdaddr 00:0B:0D:85:30:0B class 0x002540 type ACL
> < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> bdaddr 00:0B:0D:85:30:0B role 0x01
> Role: Slave
> .
> .
> .
> > ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 17 scid 0x0040
> < ACL data: handle 42 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
> Connection successful
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 48
> < ACL data: handle 42 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
> Success
> < ACL data: handle 42 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 48
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 1 clen 4
> MTU 128
> < ACL data: handle 42 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 48
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 18
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 1 clen 4
> MTU 128
> < ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 42 packets 1
> > ACL data: handle 42 flags 0x02 dlen 12
> L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> < HCI Command: Disconnect (0x01|0x0006) plen 3
> handle 42 reason 0x13
> Reason: Remote User Terminated Connection
> > HCI Event: Command Status (0x0f) plen 4
> Disconnect (0x01|0x0006) status 0x00 ncmd 1
> > HCI Event: Disconn Complete (0x05) plen 4
> status 0x00 handle 42 reason 0x16
> Reason: Connection Terminated by Local Host
>
>
> it seems to have problems in negotiating the mtu size. so i tried and
> commented out the lines in hidd which set the preferred mtu size,
> opts.imtu = HIDP_DEFAULT_MTU;
> opts.omtu = HIDP_DEFAULT_MTU;
>
> with this version of hidd the connection works perfectly, and even
> keystrokes are transferred, as can be seen in the hcidump:
> .
> .
> .
> > ACL data: handle 43 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 17 scid 0x0040
> < ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
> Connection successful
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 48
> < ACL data: handle 43 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
> Success
> < ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
> MTU 0
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > ACL data: handle 43 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
> Success
> > ACL data: handle 43 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 19 scid 0x0041
> < ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 status 0
> Connection successful
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
> MTU 48
> < ACL data: handle 43 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
> Success
> < ACL data: handle 43 flags 0x02 dlen 16
> L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
> MTU 0
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > ACL data: handle 43 flags 0x02 dlen 14
> L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
> Success
> < ACL data: handle 43 flags 0x02 dlen 5
> L2CAP(d): cid 0x0040 len 1 [psm 17]
> HIDP: Set protocol: Boot protocol
> < ACL data: handle 43 flags 0x02 dlen 7
> L2CAP(d): cid 0x0041 len 3 [psm 19]
> HIDP: Data: Output report
> > ACL data: handle 43 flags 0x02 dlen 5
> L2CAP(d): cid 0x0040 len 1 [psm 17]
> HIDP: Handshake: Successful
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 43 packets 1
> > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 43 mode 0x02 interval 128
> Mode: Sniff
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > HCI Event: Mode Change (0x14) plen 6
> status 0x00 handle 43 mode 0x00 interval 0
> Mode: Active
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
> > ACL data: handle 43 flags 0x02 dlen 13
> L2CAP(d): cid 0x0041 len 9 [psm 19]
> HIDP: Data: Input report
>
>
> hcidump -X also shows, that the packets indeed contain keycodes.
> the device is correctly registered in /proc/bus/input/devices and in
> /sys/class/input/input4. however, the events never arrive in
> /dev/input/event4. the debugging messages of the hidp kernel module
> suggest, that they dont even arrive at this module:
> May 25 15:57:38 ed007 kernel: Bluetooth: HIDP (Human Interface
> Emulation) ver 1.1
> May 25 16:06:13 ed007 hidd[6345]: Bluetooth HID daemon
> May 25 16:06:24 ed007 hcid[5321]: link_key_request
> (sba=00:03:7A:F0:73:B5, dba=00:0B:0D:85:30:0B)
> May 25 16:06:24 ed007 hidd[6345]: New HID device 00:0B:0D:85:30:0B
> (Bluetooth Kbd)
> May 25 16:06:24 ed007 kernel: hidp_add_connection:
> May 25 16:06:24 ed007 kernel: __hidp_get_session:
> May 25 16:06:24 ed007 kernel: hidp_add_connection: ctrl mtu 0 intr
> mtu 0
> May 25 16:06:24 ed007 kernel: input: Bluetooth HID Boot Protocol
> Device as /class/input/input4
> May 25 16:06:24 ed007 kernel: __hidp_send_ctrl_message: session
> d972f640 data 00000000 size 0
> May 25 16:06:24 ed007 kernel: hidp_input_event: input d4a1e800 type 17
> code 0 value 0
> May 25 16:06:24 ed007 kernel: hidp_session: session d972f640
> May 25 16:06:24 ed007 kernel: hidp_process_transmit: session d972f640
> May 25 16:06:24 ed007 kernel: hidp_send_frame: sock db45bb40 data
> e4fab800 len 1
> May 25 16:06:24 ed007 kernel: hidp_send_frame: sock db45b840 data
> eca4ba00 len 3
> May 25 16:06:24 ed007 kernel: hidp_process_transmit: session d972f640
>
>
> does anyone have a clue why the events get lost on their way? or
> something on this mtu problem?
>
> thanks,
> konrad
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Bluez-users] hid keyboard events get lost
2007-05-28 12:19 ` Konrad Kieling
@ 2007-05-28 13:55 ` Marcel Holtmann
2007-05-28 20:50 ` Konrad Kieling
0 siblings, 1 reply; 5+ messages in thread
From: Marcel Holtmann @ 2007-05-28 13:55 UTC (permalink / raw)
To: BlueZ users
Hi Konrad,
> just to let you know: the ``Freedom Universal Keyboard'' is working
> perfectly now, after applying some minor tweaks to the kernel:
>
> 1. something to avoid the long negotiation for the mtu size, i commented
> out the following lines in l2cap_build_conf_req
> (net/bluetooth/l2cap.c):
>
> // if (pi->imtu != L2CAP_DEFAULT_MTU)
> // l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
>
> yes i know, this might not be the way to go, but bt still works with
> my mobile and the headset. maybe someone has an idea for a cleaner
> solution?
>
> 2. unfortunately the data coming from the keyboard is missing the first
> byte telling us about keyboard input. in hidp_input_report
> (net/bluetooth/hidp/core.c) insert the following
> lines after variable declaration:
>
> if ( ( session->input->id.vendor == 0x045e ) &&
> ( session->input->id.product == 0x0403 ) )
> {
> for ( i = 7; i >= 0; i -- ) skb->data[i + 1] = skb->data[i];
> skb->data[0] = 0x01;
> }
>
> again, is there a way to cope with this problem in a more generic
> way?
I need one of these keyboard to actually find the correct to fix this.
While it might be likely that we need a HID quirk, I am not happy with
any weird changes in L2CAP without understanding the reasons for it.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Bluez-users] hid keyboard events get lost
2007-05-28 13:55 ` Marcel Holtmann
@ 2007-05-28 20:50 ` Konrad Kieling
2007-05-29 4:02 ` Marcel Holtmann
0 siblings, 1 reply; 5+ messages in thread
From: Konrad Kieling @ 2007-05-28 20:50 UTC (permalink / raw)
To: BlueZ users
[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]
dear marcel,
yes, i totally agree not to screw things up for a non-standard device.
however, to understand things better, could you explain to me why l2cap
sends more config requests to change the mtu although it already agreed
on the one suggested by the keyboard (hcidump is in one of my recent
postings), or do i misinterpret what's going on?
all the best,
konrad
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bluez-users] hid keyboard events get lost
2007-05-28 20:50 ` Konrad Kieling
@ 2007-05-29 4:02 ` Marcel Holtmann
0 siblings, 0 replies; 5+ messages in thread
From: Marcel Holtmann @ 2007-05-29 4:02 UTC (permalink / raw)
To: BlueZ users
Hi Konrad,
> yes, i totally agree not to screw things up for a non-standard device.
> however, to understand things better, could you explain to me why l2cap
> sends more config requests to change the mtu although it already agreed
> on the one suggested by the keyboard (hcidump is in one of my recent
> postings), or do i misinterpret what's going on?
I removed the L2CAP MTU settings from the input service. So this one
should now work for you perfectly fine. However your kernel should some
weird behavior with a MTU size of 0. That is strange. Can you test a
2.6.22-rc3 kernel, because that contains a fix for the MTU config
setting.
It also contains the full HID report support. This means that the
missing report id in front of the report should be handled correctly. If
not than we need a quirk for that. My understanding is that even if this
is valid according to the HID specification, it is not valid for
Bluetooth based HID devices.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-05-29 4:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-25 15:16 [Bluez-users] hid keyboard events get lost Konrad Kieling
2007-05-28 12:19 ` Konrad Kieling
2007-05-28 13:55 ` Marcel Holtmann
2007-05-28 20:50 ` Konrad Kieling
2007-05-29 4:02 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox