Date: Wed, 18 Mar 2015 11:48:34 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Waitman Gobble <gobble.wa@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, Iain Hibbert <plunky@ogmig.net> Subject: Re: register HID with SDP error Message-ID: <CAFPOs6o7jrULqF%2BVSbZ0ckFx3MqAbO-eHyL5FfToTL4xMxSBLQ@mail.gmail.com> In-Reply-To: <CAFuo_fxGgWYp5x=xWbFogj8F8ZMULFQw_HOWZiJ42=vDO7tXnQ@mail.gmail.com> References: <CAFuo_fy9xRU2T3GUPY8116yZCUd8sL9pBQ9ixXnMwO56niJFog@mail.gmail.com> <CAFuo_fzdmB79qdoH8P5EcO_ZZoa=_id6h=eqFBXvP_a%2B3WMkLw@mail.gmail.com> <CAFuo_fzB3A5L3vivH7Z80OEoBtVEHftEYE4LUkhnrkguzL5GDA@mail.gmail.com> <CAFuo_fzrk%2BWLXivZrnTsGQD%2BS7mq%2BUSXB7Mn6%2BJT=y64JakGSw@mail.gmail.com> <CAFPOs6q3iVcNthF=S--UgTm=5wA0HM6coqB7AcmCKb=55OWdTQ@mail.gmail.com> <CAFuo_fxgBVKxmzbJs%2B-XDz%2Bu4tb2_i3eYXSa-oiOoU%2BQD6ApwQ@mail.gmail.com> <CAFPOs6r_D7bcGCMP_bP%2BQtZgKt7Oj5jRJ2v872RODekn%2B6xv1Q@mail.gmail.com> <CAFuo_fwPuaD4bYwfZou0RBswZsTmdtVZA1B2GqUdo3ZJJiWRQg@mail.gmail.com> <0AD7A2F7-37BE-4F6A-9FD6-F6C81B2CAF36@gmail.com> <CAFuo_fye5RWNtjsutHa%2BbXL0AYHYRpJxW-b=48o0iMwX227wdA@mail.gmail.com> <alpine.NEB.2.11.1503170658130.4414@galant.ogmig.net> <CAFuo_fx47uRC-eKD_KtsSsrMCQZauyHyCOgRxGbtp_WEZ49o_Q@mail.gmail.com> <CAFPOs6rYXOFPk5_nqXivToUvGRjXDMS=XL60RyKbMQm7nP8wFg@mail.gmail.com> <CAFuo_fw5-YtH_sj3Ft52hpfXEP8QCkweptJzT0eUSos9DoBZ%2BA@mail.gmail.com> <CAFuo_fzSMNvwewpkKxcLr9aHyTcwaVgcreLtexSo=FNzNhC6og@mail.gmail.com> <CAFPOs6rJ_SaKjmXrbr%2Bpa9BoVL2HtjkzoyBo015BFK1QB9ZVsQ@mail.gmail.com> <CAFuo_fxGgWYp5x=xWbFogj8F8ZMULFQw_HOWZiJ42=vDO7tXnQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[...] > I'm working on the hid code. It opens the l2cap control and interrupt > sockets then waits for client connect. When the client connects it > sends the key codes. > > very simply, > > struct sockaddr_l2cap l2addr, cli_addr; > > controlsock = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BLUETOOTH_PROTO_L2CAP); > bind(controlsock, (struct sockaddr *) &l2addr, sizeof(l2addr)); > > intrsock = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BLUETOOTH_PROTO_L2CAP); > bind(intrsock, (struct sockaddr *) &l2addr, sizeof(l2addr)); > > > clilen = sizeof(cli_addr); > newsockfd = accept(controlsock, (struct sockaddr *) &cli_addr, > &clilen); //blocks until client connect ok... are you also accepting connection on interrupt channel? please recall, i've mentioned that buetooth hid is modeled after usb hid. there are two channels: control and interrupt. > then loop while reading chars from FIFO: > > evkeyb->btcode = 0xA1; > evkeyb->rep_id = REPORTID_KEYBD; > evkeyb->key[0] = retkey(sfifo[i]); //translate to key code > send ( newsockfd, evkeyb,sizeof(struct hidrep_keyb_t),MSG_NOSIGNAL ); hmm.... i don't think its quite correct. all the hid reports should be sent on the interrupt channel (just like usb hid device uses interrupt transfer endpoint to send its reports back to host). if i'm reading your code correctly, newsockfd is an accepted connection on the control socket. i presume you have constructed correct hid report sequence to send too (as per hid descriptor you have given out to remote host via sdp). [...] > # ./hid_sppd > control socket created > interrupt socket created > waiting for connect > waiting for fifo.. press Control-C to exit. > sent data 38 "key 0" > sent data 29 "key 1" > sent data 30 "key 2" > sent data 31 "key 3" > sent data 32 "key 4" > ... > > ...and it's reading the fifo buffer and sending the keys through the > clientfd, but nothing useful is happening on client.. So I think I'm > either doing this wrong, or my SDP record is still incorrect. well, if remote host has connected then, presumably, it has found everything that it needed from sdp. so, i would guess that your sdp records are probably correct. i suspect that you need to sort out your hid reports format and send them via interrupt channel, not control. you also might want to take a look at USBHID(3), specifically hid_set_data(). you can use bthidd(8) code as an example of what host *might* be doing and how host *might* expect data. in fact, you can probably use bthidd(8) to test your virtual hid device. one thing to keep in mind is the initial "handshake" setup. when hid device is "unknown" to host, host must initiate connection to the device first. later, host must respect value of reconnect_initiate attribute, and, if its set, host must wait for hid device to re-connect. this way, say, keyboard may put itself to sleep, and, wake up and reconnect when user presses a button. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6o7jrULqF%2BVSbZ0ckFx3MqAbO-eHyL5FfToTL4xMxSBLQ>