From owner-freebsd-bluetooth@freebsd.org Sun Sep 20 17:39:51 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B057A058E4 for ; Sun, 20 Sep 2015 17:39:51 +0000 (UTC) (envelope-from starikarp@yandex.com) Received: from forward16p.cmail.yandex.net (forward16p.cmail.yandex.net [IPv6:2a02:6b8:0:1465::bf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B25DA1CE9 for ; Sun, 20 Sep 2015 17:39:50 +0000 (UTC) (envelope-from starikarp@yandex.com) Received: from smtp18.mail.yandex.net (smtp18.mail.yandex.net [IPv6:2a02:6b8:0:1402::119]) by forward16p.cmail.yandex.net (Yandex) with ESMTP id F0A3821E8C; Sun, 20 Sep 2015 20:39:21 +0300 (MSK) Received: from smtp18.mail.yandex.net (localhost [127.0.0.1]) by smtp18.mail.yandex.net (Yandex) with ESMTP id 58C9B18A0097; Sun, 20 Sep 2015 20:39:21 +0300 (MSK) Received: by smtp18.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id zyc11ZQKgc-dJl8mIs1; Sun, 20 Sep 2015 20:39:20 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1442770760; bh=0d/j//Z8qyo6gsxo4gBnYJq2JS84lXDjGyoIPg96nKI=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:X-Mailer:Mime-Version:Content-Transfer-Encoding; b=N2yGKK3bAP9dEHck7pgOLJ9bzTPbhQfrLHGHWD2OfSGgFwxmQyjANZKFKBvZa7TpB CFNwMEaWbc3WqJrgqwBe3l3X7KGmK55+iVCIZcxT9M2YdhAZVrE01bodNt9NTDy/ft GxS6XdXF0nqEXRv7H3lZz1xaudFblF6doiAwHWq8= Authentication-Results: smtp18.mail.yandex.net; dkim=pass header.i=@yandex.com X-Yandex-ForeignMX: DE Message-ID: <1442770757.1551.6.camel@yandex.com> Subject: Re: Apple Magic Mouse From: Stari Karp To: Dirk Engling , Maksim Yevmenkin Cc: "freebsd-bluetooth@freebsd.org" Date: Sun, 20 Sep 2015 13:39:17 -0400 In-Reply-To: <55F797AB.5000501@erdgeist.org> References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F72204.5060007@erdgeist.org> <55F797AB.5000501@erdgeist.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 17:39:51 -0000 It works with a big help of Mr. Dirk Engling :). My system: FreeBSD 10.2-RELEASE #p3 (amd64) installed on iMac 11,1. Now I have emulation of middle click and scrolling works too. Thank you very much. -- ajtiM ----- http://www.redbubble.com/people/lumiwa From owner-freebsd-bluetooth@freebsd.org Sun Sep 20 19:28:16 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80B009D0B53 for ; Sun, 20 Sep 2015 19:28:16 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAF07125B for ; Sun, 20 Sep 2015 19:28:14 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 7568 invoked from network); 20 Sep 2015 19:28:06 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 20 Sep 2015 19:28:06 -0000 Subject: Re: Apple Magic Mouse To: Iain Hibbert References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F78EB8.8060408@erdgeist.org> <55FCDBB6.6090004@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling Message-ID: <55FF08C5.1020509@erdgeist.org> Date: Sun, 20 Sep 2015 21:28:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FCDBB6.6090004@erdgeist.org> Content-Type: multipart/mixed; boundary="------------090404060809000603040204" X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 19:28:16 -0000 This is a multi-part message in MIME format. --------------090404060809000603040204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 19.09.15 05:51, Dirk Engling wrote: > Feedback is welcome. One last path, I fed the source through a KNF aware indent and formatted it according to style(9). Now I think I can release it to the maintainer and look into the bluetooth-config script discussed earlier. erdgeist --------------090404060809000603040204 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="bluetooth.magic-cleanup.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bluetooth.magic-cleanup.patch" diff -rwu bthidcontrol/sdp.c /usr/src/usr.sbin/bluetooth/bthidcontrol/sdp.c --- bthidcontrol/sdp.c 2015-08-12 16:21:37.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidcontrol/sdp.c 2015-09-15 04:14:53.413719623 +0200 @@ -46,7 +46,20 @@ static int32_t hid_sdp_parse_hid_descriptor (sdp_attr_p a); static int32_t hid_sdp_parse_boolean (sdp_attr_p a); +/* + * Hard coded attibute IDs taken from the + * DEVICE IDENTIFICATION PROFILE SPECIFICATION V13 p.12 + */ + +#define SDP_DEVICE_ID_SERVICE_ATTR_VENDORID 0x0201 +#define SDP_DEVICE_ID_SERVICE_ATTR_PRODUCTID 0x0202 +#define SDP_DEVICE_ID_SERVICE_ATTR_VERSION 0x0203 +#define SDP_DEVICE_ID_RANGE SDP_ATTR_RANGE( \ + SDP_DEVICE_ID_SERVICE_ATTR_VENDORID, SDP_DEVICE_ID_SERVICE_ATTR_VERSION ) + static uint16_t service = SDP_SERVICE_CLASS_HUMAN_INTERFACE_DEVICE; +static uint16_t service_devid = SDP_SERVICE_CLASS_PNP_INFORMATION; +static uint32_t attrs_devid = SDP_DEVICE_ID_RANGE; static uint32_t attrs[] = { SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, @@ -84,27 +97,34 @@ return (((e) == 0)? 0 : -1); \ } +static void +hid_init_return_values() { + int i; + for (i = 0; i < nvalues; i ++) { + values[i].flags = SDP_ATTR_INVALID; + values[i].attr = 0; + values[i].vlen = sizeof(buffer[i]); + values[i].value = buffer[i]; + } +} + static int32_t hid_sdp_query(bdaddr_t const *local, struct hid_device *hd, int32_t *error) { void *ss = NULL; - uint8_t *hid_descriptor = NULL; + uint8_t *hid_descriptor = NULL, *v; int32_t i, control_psm = -1, interrupt_psm = -1, reconnect_initiate = -1, normally_connectable = 0, battery_power = 0, - hid_descriptor_length = -1; + hid_descriptor_length = -1, type; + int16_t vendor_id, product_id, version; if (local == NULL) local = NG_HCI_BDADDR_ANY; if (hd == NULL) hid_sdp_query_exit(EINVAL); - for (i = 0; i < nvalues; i ++) { - values[i].flags = SDP_ATTR_INVALID; - values[i].attr = 0; - values[i].vlen = sizeof(buffer[i]); - values[i].value = buffer[i]; - } + hid_init_return_values(); if ((ss = sdp_open(local, &hd->bdaddr)) == NULL) hid_sdp_query_exit(ENOMEM); @@ -113,9 +133,6 @@ if (sdp_search(ss, 1, &service, nattrs, attrs, nvalues, values) != 0) hid_sdp_query_exit(sdp_error(ss)); - sdp_close(ss); - ss = NULL; - for (i = 0; i < nvalues; i ++) { if (values[i].flags != SDP_ATTR_OK) continue; @@ -150,11 +167,51 @@ } } + hid_init_return_values(); + + if (sdp_search(ss, 1, &service_devid, 1, &attrs_devid, nvalues, values) != 0) + hid_sdp_query_exit(sdp_error(ss)); + + sdp_close(ss); + ss = NULL; + + /* If search is successful, scan through return vals */ + for (i = 0; i < 3; i ++ ) { + if (values[i].flags == SDP_ATTR_INVALID ) + continue; + + /* Expecting tag + uint16_t on all 3 attributes */ + if (values[i].vlen != 3) + continue; + + /* Make sure, we're reading a uint16_t */ + v = values[i].value; + SDP_GET8(type, v); + if (type != SDP_DATA_UINT16 ) + continue; + + switch (values[i].attr) { + case SDP_DEVICE_ID_SERVICE_ATTR_VENDORID: + SDP_GET16(vendor_id, v); + break; + case SDP_DEVICE_ID_SERVICE_ATTR_PRODUCTID: + SDP_GET16(product_id, v); + break; + case SDP_DEVICE_ID_SERVICE_ATTR_VERSION: + SDP_GET16(version, v); + break; + default: + break; + } + } + if (control_psm == -1 || interrupt_psm == -1 || reconnect_initiate == -1 || hid_descriptor == NULL || hid_descriptor_length == -1) hid_sdp_query_exit(ENOATTR); - + hd->vendor_id = vendor_id; + hd->product_id = product_id; + hd->version = version; hd->control_psm = control_psm; hd->interrupt_psm = interrupt_psm; hd->reconnect_initiate = reconnect_initiate? 1 : 0; diff -rwu bthidd/bthid_config.h /usr/src/usr.sbin/bluetooth/bthidd/bthid_config.h --- bthidd/bthid_config.h 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/bthid_config.h 2015-09-15 02:47:06.046363156 +0200 @@ -42,6 +42,9 @@ bdaddr_t bdaddr; /* HID device BDADDR */ uint16_t control_psm; /* control PSM */ uint16_t interrupt_psm; /* interrupt PSM */ + uint16_t vendor_id; /* primary vendor id */ + uint16_t product_id; + uint16_t version; unsigned new_device : 1; unsigned reconnect_initiate : 1; unsigned battery_power : 1; diff -rwu bthidd/bthidd.conf.sample /usr/src/usr.sbin/bluetooth/bthidd/bthidd.conf.sample --- bthidd/bthidd.conf.sample 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/bthidd.conf.sample 2015-09-15 05:08:15.624443300 +0200 @@ -2,6 +2,9 @@ device { bdaddr 00:50:f2:e5:68:84; + vendor_id 0x0000; + product_id 0x0000; + version 0x0000; control_psm 0x11; interrupt_psm 0x13; reconnect_initiate true; @@ -24,6 +27,9 @@ device { bdaddr 00:50:f2:e3:fb:e1; + vendor_id 0x0000; + product_id 0x0000; + version 0x0000; control_psm 0x11; interrupt_psm 0x13; reconnect_initiate true; diff -rwu bthidd/bthidd.h /usr/src/usr.sbin/bluetooth/bthidd/bthidd.h --- bthidd/bthidd.h 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/bthidd.h 2015-09-17 00:09:09.146576846 +0200 @@ -60,6 +60,7 @@ int32_t ctrl; /* control channel */ int32_t intr; /* interrupt channel */ int32_t vkbd; /* virual keyboard */ + void *ctx; /* product specific dev state */ bdaddr_t bdaddr;/* remote bdaddr */ uint16_t state; /* session state */ #define CLOSED 0 @@ -86,6 +87,7 @@ bthid_session_p session_by_fd (bthid_server_p srv, int32_t fd); void session_close (bthid_session_p s); +void hid_initialise (bthid_session_p s); int32_t hid_control (bthid_session_p s, uint8_t *data, int32_t len); int32_t hid_interrupt (bthid_session_p s, uint8_t *data, int32_t len); diff -rwu bthidd/hid.c /usr/src/usr.sbin/bluetooth/bthidd/hid.c --- bthidd/hid.c 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/hid.c 2015-09-20 21:17:46.670461896 +0200 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include #include @@ -49,6 +50,45 @@ #include "kbd.h" /* + * Inoffical and unannounced report ids for Apple Mice and trackpad + */ +#define TRACKPAD_REPORT_ID 0x28 +#define MOUSE_REPORT_ID 0x29 +#define BATT_STAT_REPORT_ID 0x30 +#define BATT_STRENGTH_REPORT_ID 0x47 +#define SURFACE_REPORT_ID 0x61 + +/* + * Magic mouse specific device state + */ +#define MAGIC_MOUSE_MAX_BUTTONS 16 +struct apple_state { + int y [MAGIC_MOUSE_MAX_BUTTONS]; + int button_state; +}; + +#define MAGIC_MOUSE(D) (((D)->vendor_id == 0x5ac) && ((D)->product_id == 0x30d)) +#define SCROLL_WHEEL_SPEED 100 + +/* + * Probe for per-device initialisation + */ +void +hid_initialise(bthid_session_p s) +{ + hid_device_p hid_device = get_hid_device(&s->bdaddr); + + if (hid_device && MAGIC_MOUSE(hid_device)) { + /* Magic report to enable trackpad on Apple's Magic Mouse */ + static uint8_t rep[] = {0x53, 0xd7, 0x01}; + + if ((s->ctx = calloc(sizeof(struct apple_state), 1)) == NULL) + return; + write(s->ctrl, rep, 3); + } +} + +/* * Process data from control channel */ @@ -370,6 +410,90 @@ hid_end_parse(d); /* + * Apple adheres to no standards and sends reports it does + * not introduce in its hid descriptor for its magic mouse. + * Handle those reports here. + */ + if (MAGIC_MOUSE(hid_device) && s->ctx) { + struct apple_state *c = (struct apple_state *)s->ctx; + int firm = 0, middle = 0; + int16_t v; + + ++data, --len; /* Chomp report_id */ + + if (report_id != MOUSE_REPORT_ID || + len < 5 || len > 5 + 8 * 15 || len % 8 != 5) + goto check_middle_button; + + /* + * The basics. When touches are detected, no normal mouse + * reports are sent. Collect clicks and dx/dy + */ + if (data[2] & 1) + mouse_butt |= 0x1; + if (data[2] & 2) + mouse_butt |= 0x4; + + if ((v = data[0] + ((data[2] & 0x0C) << 6))) + mouse_x += ((int16_t)(v << 6)) >> 6, mevents++; + if ((v = data[1] + ((data[2] & 0x30) << 4))) + mouse_y += ((int16_t)(v << 6)) >> 6, mevents++; + + /* + * The hard part: accumulate touch events and emulate middle + */ + for (data += 5, len -= 5; len >= 8; data += 8, len -= 8) { + int x, y, z, force, id; + + v = data[0] | ((data[1] & 0xf) << 8); + x = ((int16_t)(v << 4)) >> 4; + + v = (data[1] >> 4) | (data[2] << 4); + y = -(((int16_t)(v << 4)) >> 4); + + force = data[5] & 0x3f; + id = 0xf & ((data[5] >> 6) | (data[6] << 2)); + z = (y - c->y[id]) / SCROLL_WHEEL_SPEED; + + switch ((data[7] >> 4) & 0x7) { /* Phase */ + case 3: /* First touch */ + c->y[id] = y; + break; + case 4: /* Touch dragged */ + if (z) { + mouse_z += z; + c->y[id] += z * SCROLL_WHEEL_SPEED; + mevents++; + } + break; + default: + break; + } + /* Count firm touches vs. firm+middle touches */ + if (force >= 8 && ++firm && x > -350 && x < 350) + ++middle; + } + + /* + * If a new click is registered by mouse and there are firm + * touches which are all in center, make it a middle click + */ + if (mouse_butt && !c->button_state && firm && middle == firm) + mouse_butt = 0x2; + + /* + * If we're still clicking and have converted the click + * to a middle click, keep it middle clicking + */ +check_middle_button: + if (mouse_butt && c->button_state == 0x2) + mouse_butt = 0x2; + + if (mouse_butt != c->button_state) + c->button_state = mouse_butt, mevents++; + } + + /* * XXX FIXME Feed keyboard events into kernel. * The code below works, bit host also needs to track * and handle repeat. @@ -403,7 +527,6 @@ mi.u.data.y = mouse_y; mi.u.data.z = mouse_z; mi.u.data.buttons = mouse_butt; - if (ioctl(s->srv->cons, CONS_MOUSECTL, &mi) < 0) syslog(LOG_ERR, "Could not process mouse events from " \ "%s. %s (%d)", bt_ntoa(&s->bdaddr, NULL), diff -rwu bthidd/lexer.l /usr/src/usr.sbin/bluetooth/bthidd/lexer.l --- bthidd/lexer.l 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/lexer.l 2015-09-15 05:05:49.762445199 +0200 @@ -50,9 +50,13 @@ hexdigit [0-9a-fA-F] hexbyte {hexdigit}{hexdigit}? +hexword {hexdigit}{hexdigit}?{hexdigit}?{hexdigit}? device_word device bdaddr_word bdaddr +vendor_id_word vendor_id +product_id_word product_id +version_word version control_psm_word control_psm interrupt_psm_word interrupt_psm reconnect_initiate_word reconnect_initiate @@ -64,6 +68,7 @@ bdaddrstring {hexbyte}:{hexbyte}:{hexbyte}:{hexbyte}:{hexbyte}:{hexbyte} hexbytestring 0x{hexbyte} +hexwordstring 0x{hexword} %% @@ -78,6 +83,9 @@ {device_word} return (T_DEVICE); {bdaddr_word} return (T_BDADDR); +{vendor_id_word} return (T_VENDOR_ID); +{product_id_word} return (T_PRODUCT_ID); +{version_word} return (T_VERSION); {control_psm_word} return (T_CONTROL_PSM); {interrupt_psm_word} return (T_INTERRUPT_PSM); {reconnect_initiate_word} return (T_RECONNECT_INITIATE); @@ -100,6 +108,14 @@ return (*ep == '\0'? T_HEXBYTE : T_ERROR); } +{hexwordstring} { + char *ep; + + yylval.num = strtoul(yytext, &ep, 16); + + return (*ep == '\0'? T_HEXWORD : T_ERROR); + } + . return (T_ERROR); %% diff -rwu bthidd/parser.y /usr/src/usr.sbin/bluetooth/bthidd/parser.y --- bthidd/parser.y 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/parser.y 2015-09-15 05:03:43.183458248 +0200 @@ -86,8 +86,10 @@ %token T_BDADDRSTRING %token T_HEXBYTE -%token T_DEVICE T_BDADDR T_CONTROL_PSM T_INTERRUPT_PSM T_RECONNECT_INITIATE -%token T_BATTERY_POWER T_NORMALLY_CONNECTABLE T_HID_DESCRIPTOR +%token T_HEXWORD +%token T_DEVICE T_BDADDR T_VENDOR_ID T_PRODUCT_ID T_VERSION T_CONTROL_PSM +%token T_INTERRUPT_PSM T_RECONNECT_INITIATE T_BATTERY_POWER +%token T_NORMALLY_CONNECTABLE T_HID_DESCRIPTOR %token T_TRUE T_FALSE T_ERROR %% @@ -123,6 +125,9 @@ ; option: bdaddr + | vendor_id + | product_id + | version | control_psm | interrupt_psm | reconnect_initiate @@ -138,6 +143,24 @@ } ; +vendor_id: T_VENDOR_ID T_HEXWORD + { + hid_device->vendor_id = $2; + } + ; + +product_id: T_PRODUCT_ID T_HEXWORD + { + hid_device->product_id = $2; + } + ; + +version: T_VERSION T_HEXWORD + { + hid_device->version = $2; + } + ; + control_psm: T_CONTROL_PSM T_HEXBYTE { hid_device->control_psm = $2; @@ -306,6 +329,9 @@ fprintf(f, "device {\n" \ " bdaddr %s;\n" \ +" vendor_id 0x%04x;\n" \ +" product_id 0x%04x;\n" \ +" version 0x%04x;\n" \ " control_psm 0x%x;\n" \ " interrupt_psm 0x%x;\n" \ " reconnect_initiate %s;\n" \ @@ -313,6 +339,7 @@ " normally_connectable %s;\n" \ " hid_descriptor {", bt_ntoa(&d->bdaddr, NULL), + d->vendor_id, d->product_id, d->version, d->control_psm, d->interrupt_psm, d->reconnect_initiate? "true" : "false", d->battery_power? "true" : "false", diff -rwu bthidd/server.c /usr/src/usr.sbin/bluetooth/bthidd/server.c --- bthidd/server.c 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/server.c 2015-09-15 05:15:15.664459031 +0200 @@ -286,6 +286,10 @@ srv->maxfd = s->vkbd; } + /* Pass device for probing after both channels are established */ + if (s->state == OPEN) + hid_initialise(s); + return (0); } diff -rwu bthidd/session.c /usr/src/usr.sbin/bluetooth/bthidd/session.c --- bthidd/session.c 2015-08-12 16:21:36.000000000 +0200 +++ /usr/src/usr.sbin/bluetooth/bthidd/session.c 2015-09-17 00:08:19.185383406 +0200 @@ -65,6 +65,7 @@ memcpy(&s->bdaddr, &d->bdaddr, sizeof(s->bdaddr)); s->ctrl = -1; s->intr = -1; + s->ctx = NULL; if (d->keyboard) { /* Open /dev/vkbdctl */ @@ -175,6 +176,7 @@ s->srv->maxfd --; } + free(s->ctx); free(s->keys1); free(s->keys2); --------------090404060809000603040204-- From owner-freebsd-bluetooth@freebsd.org Sun Sep 20 23:30:28 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70416A0613C for ; Sun, 20 Sep 2015 23:30:28 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB52213B6 for ; Sun, 20 Sep 2015 23:30:26 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 73752 invoked from network); 20 Sep 2015 23:30:23 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 20 Sep 2015 23:30:23 -0000 To: freebsd-bluetooth@freebsd.org From: Dirk Engling Subject: service bluetooth start ubt0 fails every other time X-Enigmail-Draft-Status: N1110 Message-ID: <55FF418D.10806@erdgeist.org> Date: Mon, 21 Sep 2015 01:30:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2015 23:30:28 -0000 When initially calling service bluetooth start ubt0, I usually get an error: /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 When tracking the error down, I can link it to the command ngctl mkpeer ubt0: hci hook drv ngctl: send msg: File exists So I assume, when attaching my usb host controller, the usb framework has already launched the bluetooth start ubt0? Is that correct? What happens then is that bluetooth_shutdown_stack $dev is called, actually shutting down the device. This is exactly the opposite of the expected effect. Maybe the rc script should check if the stack is already set up and exit with a more verbose error and then not shut down the interface? erdgeist From owner-freebsd-bluetooth@freebsd.org Mon Sep 21 00:40:28 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB12BA061CB for ; Mon, 21 Sep 2015 00:40:28 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F156E1D3E for ; Mon, 21 Sep 2015 00:40:27 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 91727 invoked from network); 21 Sep 2015 00:40:23 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 21 Sep 2015 00:40:23 -0000 Subject: Re: service bluetooth start ubt0 fails every other time To: freebsd-bluetooth@freebsd.org References: <55FF418D.10806@erdgeist.org> From: Dirk Engling Message-ID: <55FF51F7.8030404@erdgeist.org> Date: Mon, 21 Sep 2015 02:40:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FF418D.10806@erdgeist.org> Content-Type: multipart/mixed; boundary="------------030805040205080708010907" X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 00:40:28 -0000 This is a multi-part message in MIME format. --------------030805040205080708010907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 21.09.15 01:30, Dirk Engling wrote: > Maybe the rc script should check if the stack is already set up and exit > with a more verbose error and then not shut down the interface? I think the attached patch does what is needed. Looking forward to your comments. erdgeist --------------030805040205080708010907 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="rc.d-bluetooth.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rc.d-bluetooth.patch" --- /etc/rc.d/bluetooth 2015-08-12 16:21:53.000000000 +0200 +++ bluetooth 2015-09-21 02:29:52.113993498 +0200 @@ -95,6 +95,10 @@ hook=$1 shift + # Check if stack is already set up for device + ngctl status ${dev}hci: 2> /dev/null > /dev/null && + err 0 "Stack already set up for ${dev}" && return 0 + # Setup HCI ngctl mkpeer ${dev}: hci ${hook} drv \ > /dev/null 2>&1 || return 1 --------------030805040205080708010907-- From owner-freebsd-bluetooth@freebsd.org Mon Sep 21 00:58:01 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0776A0695A for ; Mon, 21 Sep 2015 00:58:01 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D8E51342 for ; Mon, 21 Sep 2015 00:58:01 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by wicfx3 with SMTP id fx3so125008324wic.1 for ; Sun, 20 Sep 2015 17:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v9xdLgcEa8MEq21N/VPlJDqwCTS6UPr4kwbpvrQpS+U=; b=iDklbNM348BbxPZ6IHTwhHVtt8giTOU0d582X9MqxwaDJMHUruJPk+Bh260ctC/tps Vs7nnFI7+4LXGfcb0AYdBK/V6cw/fRHxK6jePmBweBwi6+0wJUjtNMaMLTyOMHP5r2mK WgKoowh4e7K1/erCd2dlfLS9KJPbQVfwkkjE5qUbTf/3w9SXTaRY9jZHAu2ajN6/No5Q ziN+/BvEJ/AiZqOVvKUqBm4uN28AGrTKxgze/e2zG4DLozgAYm6E6z+aISaq93EHurMl bGbRfeDCAuSwVAfGaYRtp2o8ubDHLpWCQyozL5bdZFOpAjPDxqwyzRetd9J7rV7jJ2SY VUgA== MIME-Version: 1.0 X-Received: by 10.194.82.167 with SMTP id j7mr20187648wjy.123.1442797078848; Sun, 20 Sep 2015 17:57:58 -0700 (PDT) Received: by 10.28.146.132 with HTTP; Sun, 20 Sep 2015 17:57:58 -0700 (PDT) In-Reply-To: <55FF51F7.8030404@erdgeist.org> References: <55FF418D.10806@erdgeist.org> <55FF51F7.8030404@erdgeist.org> Date: Sun, 20 Sep 2015 17:57:58 -0700 Message-ID: Subject: Re: service bluetooth start ubt0 fails every other time From: Maksim Yevmenkin To: Dirk Engling Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 00:58:01 -0000 /etc/rc.d/bluetooth start/stop is executed from devd (on device arrival / departure). there is no real need to execute bluetooth start/stop by hand. i would implement this as part of /etc/rc.d/bluetooth status command (just like other rc.d services), i.e. # /etc/rc.bluetooth status ubt0 should print status, i.e. running/non-running. very similar to daemon process status thanks, max On Sun, Sep 20, 2015 at 5:40 PM, Dirk Engling wrote: > On 21.09.15 01:30, Dirk Engling wrote: > >> Maybe the rc script should check if the stack is already set up and exit >> with a more verbose error and then not shut down the interface? > > I think the attached patch does what is needed. Looking forward to your > comments. > > erdgeist > > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@freebsd.org" From owner-freebsd-bluetooth@freebsd.org Mon Sep 21 00:59:28 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECFAEA069D4 for ; Mon, 21 Sep 2015 00:59:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 860B61364 for ; Mon, 21 Sep 2015 00:59:28 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by wiclk2 with SMTP id lk2so91111958wic.1 for ; Sun, 20 Sep 2015 17:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05CUdzamXKras58e4hKN7URDomOOrsJnA1ofpVevZs8=; b=pkHIkIyrpXTYyALmZ/KIF6tyoNd4ErVmnTAqoYTsospD2BhwFNh6WzeXDcdFCflRgc XWIPr6GwpmuvzGeTVpXud6l1bR1WBFwkmGvmTcTLq0XeHLHIrSpATWR0jReCHUYTGRIB 91XG6p5DyJCfYp3C86xz0B4fIZOa2f8qrevrAJY6cfauIL5JB1aMRQSvQCUX+a7H5Pvv zx9JPd+KseHht7L62NxSRoBHimM1wQK5CHHt5qWRUbZlMJCLx9+GfmtwemFrpj0pBO3i wpf7vfDf9YUtKFvwg8NMSVAjKH8ZQRiqkp3tlYbyiTzTQjmvmwycHI5UENmjOq1iikCt Z4Zg== MIME-Version: 1.0 X-Received: by 10.180.39.175 with SMTP id q15mr11047961wik.73.1442797166881; Sun, 20 Sep 2015 17:59:26 -0700 (PDT) Received: by 10.28.146.132 with HTTP; Sun, 20 Sep 2015 17:59:26 -0700 (PDT) In-Reply-To: <55FF08C5.1020509@erdgeist.org> References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F78EB8.8060408@erdgeist.org> <55FCDBB6.6090004@erdgeist.org> <55FF08C5.1020509@erdgeist.org> Date: Sun, 20 Sep 2015 17:59:26 -0700 Message-ID: Subject: Re: Apple Magic Mouse From: Maksim Yevmenkin To: Dirk Engling Cc: Iain Hibbert , "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 00:59:29 -0000 i will review this tomorrow. also, can you please put this into phabricator (https://reviews.freebsd.org/) so other interested parties can join review? thanks!! max On Sun, Sep 20, 2015 at 12:28 PM, Dirk Engling wrote: > On 19.09.15 05:51, Dirk Engling wrote: > >> Feedback is welcome. > > One last path, I fed the source through a KNF aware indent and formatted > it according to style(9). > > Now I think I can release it to the maintainer and look into the > bluetooth-config script discussed earlier. > > erdgeist > > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@freebsd.org" From owner-freebsd-bluetooth@freebsd.org Mon Sep 21 01:32:33 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93332A05B07 for ; Mon, 21 Sep 2015 01:32:33 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D63F1117F for ; Mon, 21 Sep 2015 01:32:32 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 5819 invoked from network); 21 Sep 2015 01:32:30 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 21 Sep 2015 01:32:30 -0000 Subject: Re: Apple Magic Mouse To: Maksim Yevmenkin References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F78EB8.8060408@erdgeist.org> <55FCDBB6.6090004@erdgeist.org> <55FF08C5.1020509@erdgeist.org> Cc: Iain Hibbert , "freebsd-bluetooth@freebsd.org" From: Dirk Engling Message-ID: <55FF5E2D.4000705@erdgeist.org> Date: Mon, 21 Sep 2015 03:32:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 01:32:33 -0000 On 21.09.15 02:59, Maksim Yevmenkin wrote: > i will review this tomorrow. also, can you please put this into > phabricator (https://reviews.freebsd.org/) so other interested parties > can join review? I'm new to the phabricator, so please be gentle ;) I added a differential https://reviews.freebsd.org/D3702 and added Maksim as reviewer. Anything I have missed? erdgeist From owner-freebsd-bluetooth@freebsd.org Mon Sep 21 01:45:02 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F19A0611C for ; Mon, 21 Sep 2015 01:45:02 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1DF1647 for ; Mon, 21 Sep 2015 01:45:01 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 8685 invoked from network); 21 Sep 2015 01:44:58 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 21 Sep 2015 01:44:58 -0000 Subject: Re: service bluetooth start ubt0 fails every other time To: Maksim Yevmenkin References: <55FF418D.10806@erdgeist.org> <55FF51F7.8030404@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55FF6119.8050902@erdgeist.org> Date: Mon, 21 Sep 2015 03:44:57 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 01:45:02 -0000 On 21.09.15 02:57, Maksim Yevmenkin wrote: > /etc/rc.d/bluetooth start/stop is executed from devd (on device > arrival / departure). there is no real need to execute bluetooth > start/stop by hand. i would implement this as part of > /etc/rc.d/bluetooth status command (just like other rc.d services), I see. I was following up on several howtos I found about getting bluetooth devices running, so I found this "And although bluetooth dongles will run the fore-mentioned command automatically when inserted into a USB slot, your built-in bluetooth controller is never inserted into anything so I’m not entirely sure how the service is started if it is not started manually." at http://modal.us/blog/2013/09/16/bluetooth-freebsd-9-1-macbook/. I wondered if it was smarter to just play along, since the howto is out there and others will also stumble here. Also the "service bluetooth start" command does not really adhere to the rc-systems standards (it works without rcvar, and as I noticed, start does as stop, when the stack is already up.) Also nowhere is communicated that this script is supposed to be internal to devd. Is the blog's author correct that builtin controllers are not reliably started when the system boots? When my system starts up with the builtin host controllers, I at least get a Warning: attempt to domain_add(graph) after domainfinalize() but ngctl status ubt0hci: reports that it actually was started. Thanks, erdgeist From owner-freebsd-bluetooth@freebsd.org Tue Sep 22 20:03:55 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A687A9CE516 for ; Tue, 22 Sep 2015 20:03:55 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65EEA1D85 for ; Tue, 22 Sep 2015 20:03:55 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id ADCC441C067; Tue, 22 Sep 2015 22:03:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fAUJ1VA8cjgC; Tue, 22 Sep 2015 22:03:51 +0200 (CEST) X-Originating-IP: 31.68.69.24 Received: from galant.ogmig.net (unknown [31.68.69.24]) (Authenticated sender: plunky@ogmig.net) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 3991C41C06A; Tue, 22 Sep 2015 22:03:49 +0200 (CEST) Received: by galant.ogmig.net (Postfix, from userid 1000) id A5C0226026A; Tue, 22 Sep 2015 21:03:59 +0100 (BST) Date: Tue, 22 Sep 2015 21:03:59 +0100 (BST) From: Iain Hibbert To: Dirk Engling cc: "freebsd-bluetooth@freebsd.org" Subject: Re: Apple Magic Mouse In-Reply-To: <55FF08C5.1020509@erdgeist.org> Message-ID: References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F78EB8.8060408@erdgeist.org> <55FCDBB6.6090004@erdgeist.org> <55FF08C5.1020509@erdgeist.org> User-Agent: Alpine 2.11 (NEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:03:55 -0000 On Sun, 20 Sep 2015, Dirk Engling wrote: > > Feedback is welcome. +/* + * Hard coded attibute IDs taken from the + * DEVICE IDENTIFICATION PROFILE SPECIFICATION V13 p.12 + */ + +#define SDP_DEVICE_ID_SERVICE_ATTR_VENDORID 0x0201 +#define SDP_DEVICE_ID_SERVICE_ATTR_PRODUCTID 0x0202 +#define SDP_DEVICE_ID_SERVICE_ATTR_VERSION 0x0203 +#define SDP_DEVICE_ID_RANGE SDP_ATTR_RANGE( \ + SDP_DEVICE_ID_SERVICE_ATTR_VENDORID, SDP_DEVICE_ID_SERVICE_ATTR_VERSION ) in the rest of SDP code, these are styled SDP_ATTR_* is there a reason to be different? /* + * Inoffical and unannounced report ids for Apple Mice and trackpad + */ it is not required to credit the source of the information used to write the handler for this device, but it is good practice to do so :) iain From owner-freebsd-bluetooth@freebsd.org Tue Sep 22 20:38:59 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91A11A029BF for ; Tue, 22 Sep 2015 20:38:59 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF24F18E5 for ; Tue, 22 Sep 2015 20:38:58 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 81323 invoked from network); 22 Sep 2015 20:38:49 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 22 Sep 2015 20:38:49 -0000 Subject: Re: Apple Magic Mouse To: Iain Hibbert References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F78EB8.8060408@erdgeist.org> <55FCDBB6.6090004@erdgeist.org> <55FF08C5.1020509@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <5601BC58.9060200@erdgeist.org> Date: Tue, 22 Sep 2015 22:38:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:38:59 -0000 On 22.09.15 22:03, Iain Hibbert wrote: > in the rest of SDP code, these are styled SDP_ATTR_* is there a reason to > be different? No, when I first wrote that code for bthidd, there was no other SDP related code to steal from, so I never noticed there were naming conventions. Going to fix that in phabricator. > it is not required to credit the source of the information used to write > the handler for this device, but it is good practice to do so :) Frankly, I never thought about how code from now on gets it's proper attribution. Apple's proprietary report format now is only implicitly documented in code and I normally hate putting arbitrary integer offsets in code. But on the other hand I have the feeling that already there is too much non-generic code that does not even adhere to HID in a generic HID driver and this is without a magic track pad handler. That left me wondering if all of this should move to another object or maybe even out of the generic bthid driver. So I wonder how much documentation or reference to documentation is adequate. Also, how does one properly link to linux or netbsd driver source? erdgeist From owner-freebsd-bluetooth@freebsd.org Sat Sep 26 23:29:36 2015 Return-Path: Delivered-To: freebsd-bluetooth@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 015E79D07BB for ; Sat, 26 Sep 2015 23:29:36 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.115.13.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C193869 for ; Sat, 26 Sep 2015 23:29:34 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 46314 invoked from network); 26 Sep 2015 23:29:24 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 26 Sep 2015 23:29:24 -0000 To: "freebsd-bluetooth@freebsd.org" From: Dirk Engling Subject: first shot at user friendly bluetooth-config script X-Enigmail-Draft-Status: N1110 Message-ID: <56072A53.4010005@erdgeist.org> Date: Sun, 27 Sep 2015 01:29:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------000805080601020205030608" X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2015 23:29:36 -0000 This is a multi-part message in MIME format. --------------000805080601020205030608 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Find attached a script that tries to tie together essential parts of the bluetooth sub-system in a human friendly manner. Currently I implemented all the steps necessary to get a hid running, and helping out the user along the way. Next up I want to implement setting up everything necessary to get connected using the DUN profile, if available. Still some questions remain about pairing: besides grepping debug.log's output, is there a reliable way to get pairing status? Looking into /var/db/hcsecd.keys may give me positive results, but info like whether a PIN_Code_Negative_Reply has been sent to the device because of a wrong pin code would be helpful. It would also be helpful to know if the device never sent a PIN_Code_Request in the first place. And how do you use hcsecd to actively start pairing? The script's style may still be a little concise, but is extensively documented, I will factor out code blocks into functions later. I am also trying to make it more usable from a script by adding a quiet mode that is not interactive and tries to automatically resolve everything by the info passed on command line. Now I wonder, where the code will be heading. Is it likely to go into the bluetooth framework or should I start writing a port? Do you have suggestions where the user might be provided additional info on how to continue, especially if stuff breaks? Regards, erdgeist --------------000805080601020205030608 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="bluetooth-config" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bluetooth-config" IyEvYmluL3NoCgojIGRlZmluZSBvdXIgYmFpbCBvdXQgc2hvcnRjdXQKZXhlcnIgKCkgeyBl Y2hvIC1lICJFcnJvcjogJCoiID4mMiA7IGV4aXQgMTsgfQoKIyBBc3N1bWluZyB3ZSBhcmUg Y2FsbGVkIHRvIGRvIHRoZSBwYWlyLW5ldy1kZXZpY2Ugc3ViY29tbWFuZCBmaXJzdAoKbWFp bigpIHsKdW5zZXQgbm9kZSBkZXZpY2Ugc3RhcnRlZCBiZGFkZHJlc3NlcyByZXRyeQoKWyAk KCBpZCAtdSApIC1lcSAwIF0gfHwgZXhlcnIgIiQwIG5lZWRzIHRvIG1vZGlmeSBmaWxlcyB0 aGF0IGJlbG9uZyB0byByb290LiBSZS1ydW4gYXMgcm9vdC4iCgojIEdldCBjb21tYW5kIGxp bmUgb3B0aW9ucwp3aGlsZSBnZXRvcHRzIDphOm46IGFyZzsgZG8KICBjYXNlICR7YXJnfSBp bgogICAgbikgbm9kZT0iJE9QVEFSRyI7OwogICAgYSkgZGV2aWNlPSIkT1BUQVJHIjs7CiAg ICA/KSBleGVyciAiU3ludGF4OiAkMCBbLW4gbm9kZV0gY21kIjs7CiAgZXNhYwpkb25lCgpr bm93bl9ub2Rlcz0kKC91c3Ivc2Jpbi9oY2NvbnRyb2wgcmVhZF9ub2RlX2xpc3QgMj4vZGV2 L251bGwgfCBcCiAgICAvdXNyL2Jpbi90YWlsIC1uICsyIHwgL3Vzci9iaW4vY3V0IC1kICcg JyAtZiAxKQoKIyBDaGVjayBpZiBuZXRncmFwaCBrbm93cyBhYm91dCBhbnkgSENJIG5vZGVz CmlmICEgWyAiJHtrbm93bl9ub2Rlc30iIF07IHRoZW4KICBuZ19ub2Rlcz0kKC91c3Ivc2Jp bi9uZ2N0bCBsaXN0IDI+L2Rldi9udWxsIHwgXAogICAgL3Vzci9iaW4vZ3JlcCAtbyAiTmFt ZTogLiogVHlwZTogdWJ0IiB8IC91c3IvYmluL2N1dCAtZCAnICcgLWYgMikKCiAgWyAiJHtu Z19ub2Rlc30iIF0gfHwgZXhlcnIgIk5vIGJsdWV0b290aCBob3N0IGNvbnRyb2xsZXJzIGZv dW5kLiIKCiAgdW5zZXQgZm91bmQKICBmb3IgbiBpbiAke25nX25vZGVzfTsgZG8KICAgIGlm IFsgIiR7bn0iID0gIiR7bm9kZSVoY2l9IiBdOyB0aGVuCiAgICAgICMgSWYgd2UgZm91bmQg dGhlIG5vZGUgYnV0IGl0J3Mgc3RhY2sgaXMgbm90IHNldCB1cCwgZG8gaXQgbm93CiAgICAg IC91c3Ivc2Jpbi9zZXJ2aWNlIGJsdWV0b290aCBzdGFydCAke25vZGUlaGNpfSB8fCBleGl0 IDEKICAgICAgZm91bmQ9IllFUyIKICAgIGZpCiAgZG9uZQoKICAjIElmIHdlIGhhdmUgYmx1 ZXRvb3RoIGNvbnRyb2xsZXIgbm9kZXMgd2l0aG91dCBhIHNldHVwIHN0YWNrLAogICMgYXNr IHRoZSB1c2VyIGlmIHdlIHNoYWxsIHN0YXJ0IGl0IHVwCiAgaWYgISBbICIke2ZvdW5kfSIg XTsgdGhlbgogICAgcHJpbnRmICJObyB1c2FibGUgYmx1ZXRvb3RoIGhvc3QgY29udHJvbGxl cnMgd2VyZSBmb3VuZC5cblRoZXNlIGhvc3QgY29udHJvbGxlcnMgZXhpc3QgaW4gdGhlIHN5 c3RlbTpcbiAgJXMiICIgJHtuZ19ub2Rlc30iCiAgICByZWFkIC1wICJDaG9vc2UgYSBob3N0 IGNvbnRyb2xsZXIgdG8gc2V0IHVwOiBbJHtuZ19ub2RlcyUlICp9XSIgbm9kZQogICAgOiAk e25vZGU6PSIke25nX25vZGVzJSUgKn0ifQogICAgL3Vzci9zYmluL3NlcnZpY2UgYmx1ZXRv b3RoIHN0YXJ0ICR7bm9kZX0gfHwgZXhpdCAxCiAgZmkKCiAgIyBSZS1yZWFkIGtub3duIG5v ZGVzCiAga25vd25fbm9kZXM9JCgvdXNyL3NiaW4vaGNjb250cm9sIHJlYWRfbm9kZV9saXN0 IDI+L2Rldi9udWxsIHwgXAogICAgL3Vzci9iaW4vdGFpbCAtbiArMiB8IC91c3IvYmluL2N1 dCAtZCAnICcgLWYgMSkKICAjIGNoZWNrIGlmIHdlIHN1Y2NlZWRlZCBpbiBicmluZ2luZyBp dCB1cAogIFsgIiR7a25vd25fbm9kZXN9IiBdIHx8IGV4ZXJyICJGYWlsZWQgdG8gc2V0dXAg Ymx1ZXRvb3RoIHN0YWNrIgpmaQoKIyBpZiBhIG5vZGUgd2FzIHJlcXVlc3RlZCBvbiBjb21t YW5kIGxpbmUsIGNoZWNrIGlmIGl0IGlzIHRoZXJlCmlmIFsgIiR7bm9kZX0iIF07IHRoZW4K ICB1bnNldCBmb3VuZAogIGZvciBuIGluICR7a25vd25fbm9kZXN9OyBkbwogICAgWyAiJHtu fSIgPSAiJHtub2RlfSIgXSAmJiBmb3VuZD0iWUVTIgogICAgWyAiJHtufSIgPSAiJHtub2Rl fWhjaSIgXSAmJiBub2RlPSIke25vZGV9aGNpIiAmJiBmb3VuZD0iWUVTIgogIGRvbmUKICBb ICIke2ZvdW5kfSIgXSB8fCBleGVyciAiTm9kZSAke25vZGV9IG5vdCBmb3VuZCIKZmkKClsg IiR7bm9kZX0iIF0gJiYgbm9kZT0iLW4gJHtub2RlfSIKCndoaWxlICEgWyAiJHtiZGFkZHJl c3Nlc30iIF07IGRvCiAgcmV0cnk9WCR7cmV0cnl9CiAgcHJpbnRmICJTY2FubmluZyBmb3Ig bmV3IGJsdWV0b290aCBkZXZpY2VzIChBdHRlbXB0ICVkIG9mIDUpIC4uLiAiICR7I3JldHJ5 fQogIGJkYWRkcmVzc2VzPSQoIC91c3Ivc2Jpbi9oY2NvbnRyb2wgLU4gJHtub2RlfSBpbnF1 aXJ5IDI+L2Rldi9udWxsIHwgXAogICAgL3Vzci9iaW4vZ3JlcCAtbyAiQkRfQUREUjogLioi IHwgL3Vzci9iaW4vY3V0IC1kICcgJyAtZiAyICkKCiAgIyBDb3VudCBlbnRyaWVzIGFuZCwg aWYgYSBkZXZpY2Ugd2FzIHJlcXVlc3RlZCBvbiBjb21tYW5kIGxpbmUsCiAgIyB0cnkgdG8g ZmluZCBpdAogIHVuc2V0IGZvdW5kIGNvdW50CiAgZm9yIGJkYWRkcmVzcyBpbiAke2JkYWRk cmVzc2VzfTsgZG8KICAgIGNvdW50PVgke2NvdW50fQogICAgaWYgWyAiJHtiZGFkZHJlc3N9 IiA9ICIke2RldmljZX0iIF07IHRoZW4KICAgICAgZm91bmQ9WUVTCiAgICAgIGJkYWRkcmVz c2VzPSIke2RldmljZX0iCiAgICAgIGNvdW50PVgKICAgICAgYnJlYWsKICAgIGZpCiAgZG9u ZQoKICAjIElmIGRldmljZSB3YXMgcmVxdWVzdGVkIG9uIGNvbW1hbmQgbGluZSBidXQgaXMg bm90IGZvdW5kLAogICMgb3Igbm8gZGV2aWNlcyBmb3VuZCBhdCBhbGwsIHJlc2NhbiB1bnRp bCByZXRyeSBpcyBleGhhdXN0ZWQKICBpZiAhIFsgIiR7Zm91bmR9IiAtbyAiJHtjb3VudH0i IC1hIC16ICIke2RldmljZX0iIF07IHRoZW4KICAgIHByaW50ZiAiZmFpbGVkLlxuIgogICAg aWYgWyAiJHsjcmV0cnl9IiAtZXEgNSBdOyB0aGVuCiAgICAgIFsgIiR7ZGV2aWNlfSIgXSAm JiBleGVyciAiRGV2aWNlICR7ZGV2aWNlfSBub3QgZm91bmQiCiAgICAgIGV4ZXJyICJObyBu ZXcgYmx1ZXRvb3RoIGRldmljZXMgZm91bmQiCiAgICBmaQogICAgdW5zZXQgYmRhZGRyZXNz ZXMKICAgIHNsZWVwIDIKICAgIGNvbnRpbnVlCiAgZmkKCiAgcHJpbnRmICJkb25lLlxuRm91 bmQgJWQgbmV3IGJsdWV0b290aCBkZXZpY2UocykgKHNjYW5uaW5nIGZvciBuYW1lcyk6XG4i ICR7I2NvdW50fQoKICAjIExvb3BpbmcgYWdhaW4gZm9yIHRoZSBmYXN0ZXIgZmVlZGJhY2sK ICB1bnNldCBjb3VudAogIGZvciBiZGFkZHJlc3MgaW4gJHtiZGFkZHJlc3Nlc307IGRvCiAg ICBjb3VudD1YJHtjb3VudH0KICAgIGJkbmFtZT0kKCAvdXNyL2Jpbi9idGhvc3QgLWIgIiR7 YmRhZGRyZXNzfSIgMj4vZGV2L251bGwgKQogICAgZnJpZW5kbHluYW1lPSQoIC91c3Ivc2Jp bi9oY2NvbnRyb2wgUmVtb3RlX05hbWVfUmVxdWVzdCAke2JkYWRkcmVzc30gMj4gL2Rldi9u dWxsIHwgXAogICAgICAvdXNyL2Jpbi9ncmVwIC1vICJOYW1lOiAuKiIgfCAvdXNyL2Jpbi9j dXQgLWQgJyAnIC1mIDItICkKCiAgICAjIHNkcGNvbnRyb2wgc2hvdWxkIGJlIGFibGUgdG8g cHVsbCB2ZW5kb3IgYW5kIHByb2R1Y3QgaWQgdmlhIHNkcAogICAgcHJpbnRmICJbJTJkXSAl c1x0XCIlc1wiICglcylcbiIgJHsjY291bnR9ICIke2JkYWRkcmVzc30iICIke2ZyaWVuZGx5 bmFtZX0iICIke2JkbmFtZX0iCgogICAgZXZhbCBiZGFkZHJlc3NfJHsjY291bnR9PVwke2Jk YWRkcmVzc30KICAgIGV2YWwgYmRuYW1lXyR7I2NvdW50fT1cJHtiZG5hbWV9CiAgICBldmFs IGZyaWVuZGx5bmFtZV8keyNjb3VudH09XCR7ZnJpZW5kbHluYW1lfQogIGRvbmUKCiAgIyBJ ZiBhIGRldmljZSB3YXMgcHJlLXNlbGVjdGVkLCBkb24ndCBxdWVyeSB0aGUgdXNlcgogIFsg IiR7ZGV2aWNlfSIgXSAmJiB0b3BhaXI9MSB8fCB1bnNldCB0b3BhaXIKCiAgIyBFdmVuIGlm IG9ubHkgb25lIGRldmljZSB3YXMgZm91bmQsIHVzZXIgbWF5IGNob3NlIDAgdG8gcmVzY2Fu CiAgd2hpbGUgISBbICIke3RvcGFpcn0iIF07IGRvCiAgICByZWFkIC1wICJTZWxlY3Qgd2hp Y2ggZGV2aWNlIHlvdSB3YW50IHRvIHBhaXIgd2l0aCBbMS0keyNjb3VudH0sIDAgdG8gcmVz Y2FuXTogIiB0b3BhaXIKICAgIGlmICEgWyAiJHt0b3BhaXJ9IiAtZ2UgMCAtYSAiJHt0b3Bh aXJ9IiAtbGUgIiR7I2NvdW50fSIgXSAyPi9kZXYvbnVsbCA7IHRoZW4KICAgICAgcHJpbnRm ICJWYWx1ZSBvdXQgb2YgcmFuZ2U6ICVzLlxuIiB7dG9wYWlyfQogICAgICB1bnNldCB0b3Bh aXIKICAgIGZpCiAgZG9uZQoKICBbICIke3RvcGFpcn0iIC1lcSAiMCIgXSAmJiB1bnNldCBi ZGFkZHJlc3NlcyByZXRyeQpkb25lCgpldmFsIGJkYWRkcmVzcz1cJHtiZGFkZHJlc3NfJHt0 b3BhaXJ9fQpldmFsIGJkbmFtZT1cJHtiZG5hbWVfJHt0b3BhaXJ9fQpldmFsIGZyaWVuZGx5 bmFtZT1cJHtmcmllbmRseW5hbWVfJHt0b3BhaXJ9fQoKIyBEbyB3ZSBuZWVkIHRvIGFkZCBh biBlbnRyeSB0byAvZXRjL2JsdWV0b290aC9ob3N0cz8KaWYgISBbICIke2JkbmFtZX0iIF07 IHRoZW4KICBwcmludGYgIlxuQWRkaW5nIGRldmljZSAke2JkYWRkcmVzc30gdG8gL2V0Yy9i bHVldG9vdGgvaG9zdHMuXG4iCgogIHdoaWxlICEgWyAiJHtiZG5hbWV9IiBdOyBkbwogICAg cmVhZCAtcCAiUGxlYXNlIGVudGVyIGZyaWVuZGx5IG5hbWUuIFske2ZyaWVuZGx5bmFtZX1d OiAiIFJFUExZCiAgICA6ICR7UkVQTFk6PSIke2ZyaWVuZGx5bmFtZX0ifQoKICAgIGlmIFsg IiR7UkVQTFl9IiBdOyB0aGVuCiAgICAgICMgUmVtb3ZlIHdoaXRlIHNwYWNlIGFuZCBub24t ZnJpZW5kbHkgY2hhcmFjdGVycwogICAgICBiZG5hbWU9JCggcHJpbnRmICIlcyIgIiR7UkVQ TFl9IiB8IHRyIC1jICdbOmFsbnVtOl0tLC4nIF8gKQogICAgICBbICIke1JFUExZfSIgIT0g IiR7YmRuYW1lfSIgXSAmJiBwcmludGYgIk5vdGljZTogVXNpbmcgc2FuaXRpemVkIG5hbWUg XCIlc1wiIGluIC9ldGMvYmx1ZXRvb3RoL2hvc3RzLlxuIiAiJHtiZG5hbWV9IgogICAgZmkK ICBkb25lCgogIHByaW50ZiAiJXNcdCVzXG4iICIke2JkYWRkcmVzc30iICIke2JkbmFtZX0i ID4+IC9ldGMvYmx1ZXRvb3RoL2hvc3RzCmZpCgojIElmIHNjYW5uaW5nIGZvciB0aGUgbmFt ZSBkaWQgbm90IHN1Y2NlZWQsIHJlc29ydCB0byBiZG5hbWUKOiAke2ZyaWVuZGx5bmFtZTo9 IiR7YmRuYW1lfSJ9CgojIG5vdyBvdmVyIHRvIGhjc2VjZAoKIyBTaW5jZSBoY3NlY2QgZG9l cyBub3QgYWxsb3cgcXVlcnlpbmcgZm9yIGtub3duIGRldmljZXMsIHdlIG5lZWQgdG8KIyBj aGVjayBmb3IgYmRhZGRyIGVudHJpZXMgbWFudWFsbHkuCiMKIyBBbHNvIHdlIGNhbiBub3Qg cmVhbGx5IG1vZGlmeSB0aGUgUElOIGluIGFuIGV4aXN0aW5nIGVudHJ5LiBTbyB3ZQojIG5l ZWQgdG8gcHJvbXB0IHRoZSB1c2VyIHRvIG1hbnVhbGx5IGRvIGl0IGFuZCByZXN0YXJ0IHRo aXMgc2NyaXB0CmlmICEgL3Vzci9zYmluL3NlcnZpY2UgaGNzZWNkIGVuYWJsZWQ7IHRoZW4K ICBwcmludGYgIlxuV2FybmluZzogaGNzZWNkIGlzIG5vdCBlbmFibGVkIG9uIHlvdXIgc3lz dGVtLlxuVGhpcyBkYWVtb24gbWFuYWdlcyBwYXJpbmcgcmVxdWVzdHMuXG4iCiAgcmVhZCAt cCAiRW5hYmxlIGhjc2VjZD8gW3llc106ICIgUkVQTFkKICBjYXNlICIke1JFUExZfSIgaW4g bm98bnxOT3xOfE5vfG5PKSA7OyAqKSAvdXNyL3NiaW4vc3lzcmMgaGNzZWNkX2VuYWJsZT0i WUVTIjs7IGVzYWMKZmkKc2VjZF9jb25maWc9JCggL3Vzci9zYmluL3N5c3JjIC1uIGhjc2Vj ZF9jb25maWcgKQpzZWNkX2VudHJpZXM9JCggL3Vzci9iaW4vZ3JlcCAtRW8gImJkYWRkcltb OnNwYWNlOl1dKygke2JkYWRkcmVzc318JHtiZG5hbWV9KSIgJHtzZWNkX2NvbmZpZ30gfCBh d2sgJ3sgcHJpbnQgJDI7IH0nICkKCmlmIFsgIiR7c2VjZF9lbnRyaWVzfSIgXTsgdGhlbgog IHByaW50ZiAiXG5XYXJuaW5nOiBBbiBlbnRyeSBmb3IgZGV2aWNlICVzIGlzIGFscmVhZHkg cHJlc2VudCBpbiAlcy5cbiIgJHtzZWNkX2VudHJpZXN9ICR7c2VjZF9jb25maWd9CiAgcHJp bnRmICJJZiB5b3Ugd2FudCB0byBtb2RpZml5IHBhaXJpbmcgaW5mb3JtYXRpb24sIGVkaXQg dGhpcyBmaWxlIGFuZCBydW4gdGhlIGNvbW1hbmRcbiAgc2VydmljZSBoY3NlY2QgcmVzdGFy dFxuIgogIHJlYWQgLXAgIkNvbnRpbnVlPyBbeWVzXTogIiBSRVBMWQogIGNhc2UgIiR7UkVQ TFl9IiBpbiBub3xufE5PfE58Tm98bk8pIGV4aXQ7OyBlc2FjCmVsc2UKICBwcmludGYgIlxu V3JpdGluZyBwYWlyaW5nIGluZm9ybWF0aW9uIGRlc2NyaXB0aW9uIGJsb2NrIHRvICVzLlxu IiAke3NlY2RfY29uZmlnfQogIHByaW50ZiAiKE5vdGljZTogVG8gZ2V0IFBJTiwgeW91IG1p Z2h0IHdhbnQgdG8gcHV0IGRldmljZSBpbiBwYWlyaW5nIG1vZGUsIGZpcnN0LilcbiIKICBy ZWFkIC1wICJFbnRlciBQSU4gW25vcGluXTogIiBwaW4KICBbICIke3Bpbn0iIF0gJiYgcGlu PVwiIiR7cGlufSJcIiB8fCBwaW49Im5vcGluIgoKICAjIFdyaXRlIG91dCBuZXcgaGNzZWNk IGNvbmZpZyBibG9jawogIHByaW50ZiAiXG5kZXZpY2Uge1xuXHRiZGFkZHJcdCVzO1xuXHRu YW1lXHRcIiVzXCI7XG5cdGtleVx0bm9rZXlcO1xuXHRwaW5cdCVzXDtcbn1cbiIgXAogICAg IiR7YmRhZGRyZXNzfSIgIiR7ZnJpZW5kbHluYW1lfSIgIiR7cGlufSIgPj4gJHtzZWNkX2Nv bmZpZ30KCiAgIyAuLi4gYW5kIG1ha2UgZGFlbW9uIHJlbG9hZCBjb25maWcsIFRPRE86IGhj c2VjZCBzaG91bGQgcHJvdmlkZSBhIHJlbG9hZCBob29rCiAgL3Vzci9zYmluL3NlcnZpY2Ug aGNzZWNkIHJlc3RhcnQKCiAgIyBUT0RPOiB3ZSBzaG91bGQgY2hlY2sgaWYgaGNzZWNkIHN1 Y2NlZWRlZCBwYWlyaW5nIGFuZCByZXZlcnQgdG8gYW4gb2xkIHZlcnNpb24KICAjIG9mIGhj c2VjZC5jb25mIHNvIHdlIGNhbiB1bmRvIGFkZGluZyB0aGUgYmxvY2sgYWJvdmUgYW5kIHJl dHJ5IHdpdGggYSBuZXcgUElOCiAgIyBhbHNvLCBpZiB0aGVyZSdzIGEgd2F5IHRvIGZvcmNl IGRldmljZXMgdG8gcmUtcGFpciwgdHJ5IHRoaXMKZmkKCiMgbm93IGNoZWNrIGZvciBzcGVj aWZpYyBzZXJ2aWNlcyB0byBiZSBwcm92aWRlZCBieSB0aGUgZGV2aWNlCiMgZmlyc3QgdXA6 IEhJRAoKaWYgL3Vzci9zYmluL3NkcGNvbnRyb2wgLWEgIiR7YmRhZGRyZXNzfSIgc2VhcmNo IEhJRCB8IFwKICAgL3Vzci9iaW4vZ3JlcCAtcSAiXlJlY29yZCBIYW5kbGU6ICI7IHRoZW4K CiAgcHJpbnRmICJcblRoaXMgZGV2aWNlIHByb3ZpZGVzIGh1bWFuIGludGVyZmFjZSBkZXZp Y2Ugc2VydmljZXMuXG4iCiAgcmVhZCAtcCAiRG8geW91IHdhbnQgdG8gc2V0IGl0IHVwPyBb eWVzXTogIiBSRVBMWQogIGNhc2UgIiR7UkVQTFl9IiBpbiBub3xufE5PfE58Tm98bk8pIDs7 CiAgKikKICAgIGlmICEgL3Vzci9zYmluL3NlcnZpY2UgYnRoaWRkIGVuYWJsZWQ7IHRoZW4K ICAgICAgcHJpbnRmICJcbldhcm5pbmc6IGJ0aGlkZCBpcyBub3QgZW5hYmxlZCBvbiB5b3Vy IHN5c3RlbS5cblRoaXMgZGFlbW9uIG1hbmFnZXMgYmx1ZXRvb3RoIEhJRCBkZXZpY2VzLlxu IgogICAgICByZWFkIC1wICJFbmFibGUgYnRoaWRkPyBbeWVzXTogIiBSRVBMWQogICAgICBj YXNlICIke1JFUExZfSIgaW4gbm98bnxOT3xOfE5vfG5PKSA7OyAqKSAvdXNyL3NiaW4vc3lz cmMgYnRoaWRkX2VuYWJsZT0iWUVTIjs7IGVzYWMKICAgIGZpCgogICAgIyBDaGVjayBpZiBi dGhpZGQgYWxyZWFkeSBrbm93cyBhYm91dCB0aGlzIGRldmljZQogICAgYnRoaWRkX2tub3du PSQoIC91c3Ivc2Jpbi9idGhpZGNvbnRyb2wgLWEgIiR7YmRhZGRyZXNzfSIga25vd24gKQog ICAgaWYgWyAiJHtidGhpZGRfa25vd259IiBdOyB0aGVuCiAgICAgIHByaW50ZiAiTm90aWNl OiBEZXZpY2UgJXMgYWxyZWFkeSBrbm93biB0byBidGhpZGQuXG4iICIke2JkYWRkcmVzc30i CiAgICBlbHNlCiAgICAgIGJ0aGlkZF9jb25maWc9JCggL3Vzci9zYmluL3N5c3JjIC1uIGJ0 aGlkZF9jb25maWcgKQogICAgICBwcmludGYgIldyaXRpbmcgSElEIGRlc2NyaXB0b3IgYmxv Y2sgdG8gJXMgLi4uICIgIiR7YnRoaWRkX2NvbmZpZ30iCiAgICAgIC91c3Ivc2Jpbi9idGhp ZGNvbnRyb2wgLWEgIiR7YmRhZGRyZXNzfSIgcXVlcnkgPj4gIiR7YnRoaWRkX2NvbmZpZ30i CgogICAgICAjIFJlLXJlYWQgY29uZmlnIHRvIHNlZSBpZiB3ZSBzdWNjZWVkZWQgYWRkaW5n IHRoZSBkZXZpY2UKICAgICAgYnRoaWRkX2tub3duPSQoIC91c3Ivc2Jpbi9idGhpZGNvbnRy b2wgLWEgIiR7YmRhZGRyZXNzfSIga25vd24gKQogICAgICBpZiAhIFsgIiR7YnRoaWRkX2tu b3dufSIgXTsgdGhlbgogICAgICAgIHByaW50ZiAiZmFpbGVkLlxuIgogICAgICBlbHNlCiAg ICAgICAgcHJpbnRmICJzdWNjZXNzLlxuSW4gb3JkZXIgdG8gcmUtcmVhZCBpdHMgY29uZmln LCBidGhpZGQgbXVzdCBiZSByZXN0YXJ0ZWQuXG4iCiAgICAgICAgcHJpbnRmICJXYXJuaW5n OiBJZiB5b3UncmUgdXNpbmcgYSBibHVldG9vdGgga2V5Ym9hcmQsIGNvbm5lY3Rpb24gbWF5 IGJlIGxvc3QuXG4iCiAgICAgICAgcHJpbnRmICJZb3UgbWF5IG1hbnVhbGx5IHJlc3RhcnQg aXQgbGF0ZXIgdXNpbmdcbiAgc2VydmljZSBidGhpZGQgcmVzdGFydFxuIgogICAgICAgIHJl YWQgLXAgIlJlc3RhcnQgYnRoaWRkIG5vdz8gW3llc106ICIgUkVQTFkKICAgICAgICBjYXNl ICIke1JFUExZfSIgaW4gbm98bnxOT3xOfE5vfG5PKSA7OyAqKSAvdXNyL3NiaW4vc2Vydmlj ZSBidGhpZGQgcmVzdGFydDs7IGVzYWMKICAgICAgZmkKICAgIGZpCiAgOzsKICBlc2FjCmZp Cgp9CgojIEFmdGVyIGZ1bmN0aW9uIGRlZmluaXRpb25zLCBtYWluKCkgY2FuIHVzZSB0aGVt Cm1haW4gIiRAIgoKZXhpdAoKIyBUT0RPCiMgKiBJZiBkZXZpY2UgaXMgYSBrZXlib2FyZCwg b2ZmZXIgYSB0ZXh0IGVudHJ5IHRlc3QgZmllbGQgYW5kIGlmIGl0IGRvZXMKIyAgIG5vdCBz dWNjZWVkLCBsZWF2ZSBzb21lIGNsdWVzIGZvciBkZWJ1Z2dpbmcgKGkuZS4gaWYgdGhlIG5v ZGUgcmVzcG9uZHMKIyAgIHRvIHBpbmdzLCBtYXliZSBzd2l0Y2gga2V5Ym9hcmQgb24vb2Zm LCBldGMpCiMgKiBTYW1lIGlmIGRldmljZSBpcyBhIG1vdXNlLCBpLmUuIGhleGR1bXAgL2Rl di9zeXNtb3VzZS4KIyAqIElmIGRldmljZSBvZmZlcnMgRFVOIHByb2ZpbGVzLCBhc2sgdGhl IHVzZXIgaWYgYW4gZW50cnkgaW4KIyAgIC9ldGMvcHBwL3BwcC5jb25mIHNob3VsZCBiZSBj cmVhdGVkCiMgKiBJZiBPUFVTSCBvciBTUFAgaXMgb2ZmZXJlZCwgcmVmZXIgdG8gdGhlIHJl c3BlY3RpdmUgbWFuIHBhZ2VzIHRvIGdpdmUKIyAgIHNvbWUgY2x1ZXMgaG93IHRvIGNvbnRp bnVlCgo= --------------000805080601020205030608--