From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 00:03:48 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 2DA039CA761 for ; Mon, 14 Sep 2015 00:03:48 +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 823B010F6 for ; Mon, 14 Sep 2015 00:03:46 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 34437 invoked from network); 14 Sep 2015 00:03:37 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 14 Sep 2015 00:03:37 -0000 Subject: Re: Apple Magic Mouse To: Maksim Yevmenkin References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55F60ED8.8080203@erdgeist.org> Date: Mon, 14 Sep 2015 02:03:36 +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: multipart/mixed; boundary="------------060602030404060108060001" 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, 14 Sep 2015 00:03:48 -0000 This is a multi-part message in MIME format. --------------060602030404060108060001 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 12.09.15 19:53, Maksim Yevmenkin wrote: > i think it should be possible to teach bthidd to make another sdp > request to pull device id sdp record (if available). if apple mouse > answers it then it should very easy to identify it and enable all the > features. Apples magic mouse indeed answers the SDP request for its Device ID Service Record. Find attached a first patch that adds a vendor, product and version member in the bthid_session object that is filled after both connections for the session were attached. This is done in a new function session_get_devid that issues and handles the SDP requests. There's also a new hid_initialise function, that gets a chance to take a look at those new members and initialise devices based on those information. Caveats: Only the first DevIDService record is parsed without regard for the PrimaryRecord flag. This is not necessarily correct for devices that expose multiple services. For most HID it still should be good enough and checking for multiple records and writing code to handle devices with no PrimaryRecord is way too complex for what we want to achieve. The libsdp actually issues a blocking write and, worse: a blocking read on the bluetooth connection, potentially blocking the whole bthidd until the read times out. However, since this happens after both channels were successfully established, chances are pretty good that the device will not die just when we send the request. Depending on lingual preferences, you might want to rename initialise to initialize. Comments on the patch are appreciated. I will now go on and blatantly rip off Iain Hibberts code from the NetBSD driver to make use of what the mouse sends me. Regards, erdgeist --------------060602030404060108060001 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="bthidd.sdp.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bthidd.sdp.patch" ZGlmZiAtdXIgYnRoaWRkL01ha2VmaWxlIC91c3Ivc3JjL3Vzci5zYmluL2JsdWV0b290aC9i dGhpZGQvTWFrZWZpbGUKLS0tIGJ0aGlkZC9NYWtlZmlsZQkyMDE1LTA4LTEyIDE2OjIxOjM2 LjAwMDAwMDAwMCArMDIwMAorKysgL3Vzci9zcmMvdXNyLnNiaW4vYmx1ZXRvb3RoL2J0aGlk ZC9NYWtlZmlsZQkyMDE1LTA5LTE0IDAxOjIzOjU4Ljc0NTg0MjMxNyArMDIwMApAQCAtMTEs NyArMTEsNyBAQAogREVCVUdfRkxBR1M9CS1nCiAKIERQQUREPSAgICAgICAgICAke0xJQkJM VUVUT09USH0gJHtMSUJVU0JISUR9Ci1MREFERD0JCS1sYmx1ZXRvb3RoIC1sdXNiaGlkCitM REFERD0JCS1sYmx1ZXRvb3RoIC1sdXNiaGlkIC1sc2RwCiAKIE5PX1dNSVNTSU5HX1ZBUklB QkxFX0RFQ0xBUkFUSU9OUz0KIApkaWZmIC11ciBidGhpZGQvYnRoaWRkLmggL3Vzci9zcmMv dXNyLnNiaW4vYmx1ZXRvb3RoL2J0aGlkZC9idGhpZGQuaAotLS0gYnRoaWRkL2J0aGlkZC5o CTIwMTUtMDgtMTIgMTY6MjE6MzYuMDAwMDAwMDAwICswMjAwCisrKyAvdXNyL3NyYy91c3Iu c2Jpbi9ibHVldG9vdGgvYnRoaWRkL2J0aGlkZC5oCTIwMTUtMDktMTQgMDE6MjA6NDkuODYz ODgwODg3ICswMjAwCkBAIC02MSw2ICs2MSw5IEBACiAJaW50MzJfdAkJCQkgaW50cjsJLyog aW50ZXJydXB0IGNoYW5uZWwgKi8KIAlpbnQzMl90CQkJCSB2a2JkOwkvKiB2aXJ1YWwga2V5 Ym9hcmQgKi8KIAliZGFkZHJfdAkJCSBiZGFkZHI7LyogcmVtb3RlIGJkYWRkciAqLworCXVp bnQxNl90CQkJIHZlbmRvcjsvKiByZW1vdGUgdmVuZG9yIGlkICovCisJdWludDE2X3QJCQkg cHJvZHVjdDsvKnJlbW90ZSBwcm9kdWN0IGlkICovCisJdWludDE2X3QJCQkgdmVyc2lvbjsv KnJlbW90ZSB2ZXJzaW9uIGlkICovCiAJdWludDE2X3QJCQkgc3RhdGU7CS8qIHNlc3Npb24g c3RhdGUgKi8KICNkZWZpbmUgQ0xPU0VECTAKICNkZWZpbmUJVzRDVFJMCTEKQEAgLTg0LDgg Kzg3LDEwIEBACiBidGhpZF9zZXNzaW9uX3AJc2Vzc2lvbl9vcGVuICAgICAoYnRoaWRfc2Vy dmVyX3Agc3J2LCBoaWRfZGV2aWNlX3AgY29uc3QgZCk7CiBidGhpZF9zZXNzaW9uX3AJc2Vz c2lvbl9ieV9iZGFkZHIoYnRoaWRfc2VydmVyX3Agc3J2LCBiZGFkZHJfcCBiZGFkZHIpOwog YnRoaWRfc2Vzc2lvbl9wCXNlc3Npb25fYnlfZmQgICAgKGJ0aGlkX3NlcnZlcl9wIHNydiwg aW50MzJfdCBmZCk7Cit2b2lkIAkJc2Vzc2lvbl9nZXRfZGV2aWQoYnRoaWRfc2Vzc2lvbl9w IHMpOwogdm9pZAkJc2Vzc2lvbl9jbG9zZSAgICAoYnRoaWRfc2Vzc2lvbl9wIHMpOwogCit2 b2lkCQloaWRfaW5pdGlhbGlzZQkgKGJ0aGlkX3Nlc3Npb25fcCBzKTsKIGludDMyX3QJCWhp ZF9jb250cm9sICAgICAgKGJ0aGlkX3Nlc3Npb25fcCBzLCB1aW50OF90ICpkYXRhLCBpbnQz Ml90IGxlbik7CiBpbnQzMl90CQloaWRfaW50ZXJydXB0ICAgIChidGhpZF9zZXNzaW9uX3Ag cywgdWludDhfdCAqZGF0YSwgaW50MzJfdCBsZW4pOwogCmRpZmYgLXVyIGJ0aGlkZC9oaWQu YyAvdXNyL3NyYy91c3Iuc2Jpbi9ibHVldG9vdGgvYnRoaWRkL2hpZC5jCi0tLSBidGhpZGQv aGlkLmMJMjAxNS0wOC0xMiAxNjoyMTozNi4wMDAwMDAwMDAgKzAyMDAKKysrIC91c3Ivc3Jj L3Vzci5zYmluL2JsdWV0b290aC9idGhpZGQvaGlkLmMJMjAxNS0wOS0xNCAwMTo0Mzo0OC42 NDQ3NTQ2NzggKzAyMDAKQEAgLTQ5LDYgKzQ5LDE5IEBACiAjaW5jbHVkZSAia2JkLmgiCiAK IC8qCisgKiBQcm9iZSBmb3IgcGVyLWRldmljZSBpbml0aWFsaXNhdGlvbgorICovCit2b2lk CitoaWRfaW5pdGlhbGlzZShidGhpZF9zZXNzaW9uX3AgcykKK3sKKwkvKiBNYWdpYyByZXBv cnQgdG8gZW5hYmxlIHRyYWNrcGFkIG9uIEFwcGxlJ3MgTWFnaWMgTW91c2UKKwlzdGF0aWMg dWludDhfdCByZXBbXSA9IHsgMHg1MywgMHhkNywgMHgwMSB9OworCWlmKHMtPnZlbmRvciAg PT0gMHg1YWMgJiYgcy0+cHJvZHVjdCA9PSAweDMwZCApCisJCXdyaXRlKHMtPmN0cmwsIHJl cCwgMyApOworCSovCit9CisKKy8qCiAgKiBQcm9jZXNzIGRhdGEgZnJvbSBjb250cm9sIGNo YW5uZWwKICAqLwogCmRpZmYgLXVyIGJ0aGlkZC9zZXJ2ZXIuYyAvdXNyL3NyYy91c3Iuc2Jp bi9ibHVldG9vdGgvYnRoaWRkL3NlcnZlci5jCi0tLSBidGhpZGQvc2VydmVyLmMJMjAxNS0w OC0xMiAxNjoyMTozNi4wMDAwMDAwMDAgKzAyMDAKKysrIC91c3Ivc3JjL3Vzci5zYmluL2Js dWV0b290aC9idGhpZGQvc2VydmVyLmMJMjAxNS0wOS0xNCAwMTo0NDoxMi44NDM3NjUwNDkg KzAyMDAKQEAgLTI4Niw2ICsyODYsMTIgQEAKIAkJCXNydi0+bWF4ZmQgPSBzLT52a2JkOwog CX0KIAorCS8qIEdldCBWZW5kb3JJRCBhbmQgUHJvZHVjdElEIGFmdGVyIGJvdGggY2hhbm5l bHMgYXJlIGVzdGFibGlzaGVkICovCisJaWYgKHMtPnN0YXRlID09IE9QRU4pIHsKKwkJc2Vz c2lvbl9nZXRfZGV2aWQocyk7CisJCWhpZF9pbml0aWFsaXNlKHMpOworCX0KKwogCXJldHVy biAoMCk7CiB9CiAKZGlmZiAtdXIgYnRoaWRkL3Nlc3Npb24uYyAvdXNyL3NyYy91c3Iuc2Jp bi9ibHVldG9vdGgvYnRoaWRkL3Nlc3Npb24uYwotLS0gYnRoaWRkL3Nlc3Npb24uYwkyMDE1 LTA4LTEyIDE2OjIxOjM2LjAwMDAwMDAwMCArMDIwMAorKysgL3Vzci9zcmMvdXNyLnNiaW4v Ymx1ZXRvb3RoL2J0aGlkZC9zZXNzaW9uLmMJMjAxNS0wOS0xNCAwMTo1MDoxOS44NjI3MjY0 MTggKzAyMDAKQEAgLTM2LDYgKzM2LDcgQEAKICNpbmNsdWRlIDxibHVldG9vdGguaD4KICNp bmNsdWRlIDxlcnJuby5oPgogI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8c2RwLmg+ CiAjaW5jbHVkZSA8c3RkaW8uaD4KICNpbmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxz dHJpbmcuaD4KQEAgLTYxLDcgKzYyLDcgQEAKIAlpZiAoKHMgPSAoYnRoaWRfc2Vzc2lvbl9w KSBtYWxsb2Moc2l6ZW9mKCpzKSkpID09IE5VTEwpCiAJCXJldHVybiAoTlVMTCk7CiAKLQlz LT5zcnYgPSBzcnY7ICAKKwlzLT5zcnYgPSBzcnY7CiAJbWVtY3B5KCZzLT5iZGFkZHIsICZk LT5iZGFkZHIsIHNpemVvZihzLT5iZGFkZHIpKTsKIAlzLT5jdHJsID0gLTE7CiAJcy0+aW50 ciA9IC0xOwpAQCAtODAsNiArODEsNyBAQAogCQlzLT52a2JkID0gLTE7CiAKIAlzLT5zdGF0 ZSA9IENMT1NFRDsKKwlzLT52ZW5kb3IgPSBzLT5wcm9kdWN0ID0gcy0+dmVyc2lvbiA9IDA7 CiAKIAlzLT5rZXlzMSA9IGJpdF9hbGxvYyhrYmRfbWF4a2V5KCkpOwogCWlmIChzLT5rZXlz MSA9PSBOVUxMKSB7CkBAIC0xMzgsNiArMTQwLDg5IEBACiB9CiAKIC8qCisgKiBHZXQgRGV2 aWNlIElEIFNlcnZpY2UgUmVjb3JkIGZvciBzZXNzaW9uCisKKyAgIEhhcmQgY29kZWQgYXR0 aWJ1dGUgSURzIHRha2VuIGZyb20gdGhlCisgICBERVZJQ0UgSURFTlRJRklDQVRJT04gUFJP RklMRSBTUEVDSUZJQ0FUSU9OIFYxMyBwLjEyCisgKi8KKworI2RlZmluZSBTRFBfREVWSUNF X0lEX1NFUlZJQ0VfQVRUUl9WRU5ET1JJRCAgMHgwMjAxCisjZGVmaW5lIFNEUF9ERVZJQ0Vf SURfU0VSVklDRV9BVFRSX1BST0RVQ1RJRCAweDAyMDIKKyNkZWZpbmUgU0RQX0RFVklDRV9J RF9TRVJWSUNFX0FUVFJfVkVSU0lPTiAgIDB4MDIwMworI2RlZmluZSBTRFBfREVWSUNFX0lE X1JBTkdFIFNEUF9BVFRSX1JBTkdFKCBcCisgU0RQX0RFVklDRV9JRF9TRVJWSUNFX0FUVFJf VkVORE9SSUQsIFNEUF9ERVZJQ0VfSURfU0VSVklDRV9BVFRSX1ZFUlNJT04gKQorCit2b2lk CitzZXNzaW9uX2dldF9kZXZpZChidGhpZF9zZXNzaW9uX3AgcykKK3sKKwlzZHBfYXR0cl90 IHZhbFszXTsKKwl1aW50OF90IGJ1ZlsxNl07CisJdWludDE2X3QgZGV2aWRfc2VydnJlY191 dWlkID0gU0RQX1NFUlZJQ0VfQ0xBU1NfUE5QX0lORk9STUFUSU9OOworCXVpbnQzMl90IGRl dmlkX3NlcnZyZWNfYXR0cl9yYW5nZSA9IFNEUF9ERVZJQ0VfSURfUkFOR0U7CisJdWludDMy X3QgdHlwZTsKKwl2b2lkICp4czsKKwl1aW50OF90ICp2OworCWludCBpOworCisJYXNzZXJ0 KHMgIT0gTlVMTCk7CisJYXNzZXJ0KHMtPnN0YXRlID09IE9QRU4pOworCisJeHMgPSBzZHBf b3BlbihOR19IQ0lfQkRBRERSX0FOWSwgJnMtPmJkYWRkcik7CisJaWYgKCF4cykKKwkJcmV0 dXJuOworCisJLyogSW5pdGlhbGlzZSByZXR1cm4gYXJyYXkgKi8KKwlmb3IgKGk9MDsgaTwz OyArK2kpIHsKKwkJdmFsW2ldLmZsYWdzID0gU0RQX0FUVFJfSU5WQUxJRDsKKwkJdmFsW2ld LmF0dHIgID0gMDsKKwkJdmFsW2ldLnZhbHVlID0gYnVmICsgaSo0OworCQl2YWxbaV0udmxl biAgPSA0OyAvKiBNYXggc2l6ZSBzaG91bGQgYmUgMyAqLworCX0KKworCS8qIEdldHRpbmcg b25seSB0aGUgZmlyc3Qgc2V0IG9mIGF0dHJpYnV0ZXMsIGFzc3VtaW5nIHRoZQorCSAgIHBy aW1hcnkgcmVjb3JkIHRvIGNvbWUgZmlyc3QuIFRPRE8uICovCisJaWYgKHNkcF9zZWFyY2go eHMsIDEsICZkZXZpZF9zZXJ2cmVjX3V1aWQsCisJCQkgICAxLCAmZGV2aWRfc2VydnJlY19h dHRyX3JhbmdlLAorCQkJICAgMywgdmFsKSAhPSAwICkgeworCQlzZHBfY2xvc2UoeHMpOwor CQlyZXR1cm47CisJfQorCisKKwkvKiBJZiBzZWFyY2ggaXMgc3VjY2Vzc2Z1bCwgc2NhbiB0 aHJvdWdoIHJldHVybiB2YWxzICovCisJZm9yIChpPTA7IGk8MzsgKytpKSB7CisJCWlmICh2 YWxbaV0uZmxhZ3MgPT0gU0RQX0FUVFJfSU5WQUxJRCApCisJCQljb250aW51ZTsKKworCQkv KiBFeHBlY3RpbmcgdGFnICsgdWludDE2X3Qgb24gYWxsIDMgYXR0cmlidXRlcyAqLworCQlp ZiAodmFsW2ldLnZsZW4gIT0gMykKKwkJCWNvbnRpbnVlOworCisJCS8qIE1ha2Ugc3VyZSwg d2UncmUgcmVhZGluZyBhIHVpbnQxNl90ICovCisJCXYgPSB2YWxbaV0udmFsdWU7CisJCVNE UF9HRVQ4KHR5cGUsIHYpOworCQlpZiAodHlwZSAhPSBTRFBfREFUQV9VSU5UMTYgKQorCQkJ Y29udGludWU7CisKKwkJc3dpdGNoICh2YWxbaV0uYXR0cikgeworCQkJY2FzZSBTRFBfREVW SUNFX0lEX1NFUlZJQ0VfQVRUUl9WRU5ET1JJRDoKKwkJCQlTRFBfR0VUMTYocy0+dmVuZG9y LCB2KTsKKwkJCQlicmVhazsKKwkJCWNhc2UgU0RQX0RFVklDRV9JRF9TRVJWSUNFX0FUVFJf UFJPRFVDVElEOgorCQkJCVNEUF9HRVQxNihzLT5wcm9kdWN0LCB2KTsKKwkJCQlicmVhazsK KwkJCWNhc2UgU0RQX0RFVklDRV9JRF9TRVJWSUNFX0FUVFJfVkVSU0lPTjoKKwkJCQlTRFBf R0VUMTYocy0+dmVyc2lvbiwgdik7CisJCQkJYnJlYWs7CisJCQlkZWZhdWx0OgorCQkJCWJy ZWFrOworCQl9CisJfQorCisJc2RwX2Nsb3NlKHhzKTsKK30KKworLyoKICAqIENsb3NlIHNl c3Npb24KICAqLwogCg== --------------060602030404060108060001-- From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 17:07:23 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 D8873A030ED for ; Mon, 14 Sep 2015 17:07:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 714821D11 for ; Mon, 14 Sep 2015 17:07:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by wicgb1 with SMTP id gb1so150635812wic.1 for ; Mon, 14 Sep 2015 10:07:22 -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=ZmiYfJK4Dx0Xv/U0davZzqxSebYhnM4cz0UKpoXxiTo=; b=pZsTXp3eWFa225syzGju+WWkbuof9YyiiirI0ApcXYrBCu2dTVjWJzw4NlRYUiU0Io +pIKTNS82spprumdL1kcNxp8MOZD998GAUBb5ilbiboa40Ee8TNpHrcAcsYDsDUZTtlb QlVyV1LAoSc+C4b/wzgnE3Hpd5D3QxNW15wszrnMC/Z35E0QhtsyJvW3CHEuEY+p4TF9 qUYZOZghJ6NFjSHtdDfrS+BrpqduNbdnnIjWugVC+BfRGSHMucrHNVVG4Wju1ukmgw7x B+MN5tf0C6zxmdmEitv4gMPugvBKSWv3Ga9uu1n0IdrXO61iKVn2iexERiRoJmSkBJn3 BuiA== MIME-Version: 1.0 X-Received: by 10.180.102.226 with SMTP id fr2mr29229090wib.3.1442250441983; Mon, 14 Sep 2015 10:07:21 -0700 (PDT) Received: by 10.28.146.132 with HTTP; Mon, 14 Sep 2015 10:07:21 -0700 (PDT) In-Reply-To: <55F60ED8.8080203@erdgeist.org> References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> Date: Mon, 14 Sep 2015 10:07:21 -0700 Message-ID: Subject: Re: Apple Magic Mouse 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, 14 Sep 2015 17:07:24 -0000 On Sun, Sep 13, 2015 at 5:03 PM, Dirk Engling wrote: > On 12.09.15 19:53, Maksim Yevmenkin wrote: > >> i think it should be possible to teach bthidd to make another sdp >> request to pull device id sdp record (if available). if apple mouse >> answers it then it should very easy to identify it and enable all the >> features. > > Apples magic mouse indeed answers the SDP request for its Device ID > Service Record. ok > Find attached a first patch that adds a vendor, product and version > member in the bthid_session object that is filled after both connections > for the session were attached. > > This is done in a new function session_get_devid that issues and handles > the SDP requests. > > There's also a new hid_initialise function, that gets a chance to take a > look at those new members and initialise devices based on those information. > > Caveats: > > Only the first DevIDService record is parsed without regard for the > PrimaryRecord flag. This is not necessarily correct for devices that > expose multiple services. For most HID it still should be good enough > and checking for multiple records and writing code to handle devices > with no PrimaryRecord is way too complex for what we want to achieve. > > The libsdp actually issues a blocking write and, worse: a blocking read > on the bluetooth connection, potentially blocking the whole bthidd until > the read times out. However, since this happens after both channels were > successfully established, chances are pretty good that the device will > not die just when we send the request. > > Depending on lingual preferences, you might want to rename initialise to > initialize. > > Comments on the patch are appreciated. this looks good. i only have one comment: why does it have to be in bthidd ? we already query hid descriptor from the device (in bthidcontrol) as part of initial device setup. why can't we query device id at the same too? and simply stick it into the bthidd.conf and be done with it? the nice thing about it is that if device specific code does not work (for whatever reason), one can simply turn it off by removing device id lines from the bthidd.conf. does it make sense to you? thanks max From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 17:09:30 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 06AA8A031C6 for ; Mon, 14 Sep 2015 17:09:30 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (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 B81911D79 for ; Mon, 14 Sep 2015 17:09:29 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 9633BFB87E; Mon, 14 Sep 2015 19:09:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 9CvaGqFy522T; Mon, 14 Sep 2015 19:09:23 +0200 (CEST) X-Originating-IP: 31.68.69.76 Received: from galant.ogmig.net (unknown [31.68.69.76]) (Authenticated sender: plunky@ogmig.net) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 34194FB882; Mon, 14 Sep 2015 19:09:22 +0200 (CEST) Received: by galant.ogmig.net (Postfix, from userid 1000) id 6EFD726026A; Mon, 14 Sep 2015 18:09:23 +0100 (BST) Date: Mon, 14 Sep 2015 18:09:23 +0100 (BST) From: Iain Hibbert To: Dirk Engling cc: "freebsd-bluetooth@freebsd.org" Subject: Re: Apple Magic Mouse In-Reply-To: <55F60ED8.8080203@erdgeist.org> Message-ID: References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@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: Mon, 14 Sep 2015 17:09:30 -0000 On Mon, 14 Sep 2015, Dirk Engling wrote: > On 12.09.15 19:53, Maksim Yevmenkin wrote: > > > i think it should be possible to teach bthidd to make another sdp > > request to pull device id sdp record (if available). if apple mouse > > answers it then it should very easy to identify it and enable all the > > features. > > Apples magic mouse indeed answers the SDP request for its Device ID > Service Record. > > Find attached a first patch that adds a vendor, product and version > member in the bthid_session object that is filled after both connections > for the session were attached. > > This is done in a new function session_get_devid that issues and handles > the SDP requests. > > There's also a new hid_initialise function, that gets a chance to take a > look at those new members and initialise devices based on those information. My advice is, to put that code in bthidcontrol, which already queries the device, and add product-id and vendor-id fields to the bthidd.conf file. that then solves your issue about the libsdp blocking read/write calls, since it knows the information before it starts. iain From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 17:18:18 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 37B2EA036AF for ; Mon, 14 Sep 2015 17:18:18 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (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 ED3B7150B for ; Mon, 14 Sep 2015 17:18:17 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from mfilter33-d.gandi.net (mfilter33-d.gandi.net [217.70.178.164]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 72C7FC5A46; Mon, 14 Sep 2015 19:18:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter33-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter33-d.gandi.net (mfilter33-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 3b__YsGH-BZf; Mon, 14 Sep 2015 19:18:05 +0200 (CEST) X-Originating-IP: 31.68.69.76 Received: from galant.ogmig.net (unknown [31.68.69.76]) (Authenticated sender: plunky@ogmig.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 31E3DC5A3C; Mon, 14 Sep 2015 19:18:04 +0200 (CEST) Received: by galant.ogmig.net (Postfix, from userid 1000) id 3E77726026A; Mon, 14 Sep 2015 18:18:05 +0100 (BST) Date: Mon, 14 Sep 2015 18:18:05 +0100 (BST) From: Iain Hibbert To: Dirk Engling , freebsd-bluetooth@freebsd.org Subject: Re: Apple Magic Mouse In-Reply-To: <55F4362A.4050203@erdgeist.org> Message-ID: References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@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: Mon, 14 Sep 2015 17:18:18 -0000 On Sat, 12 Sep 2015, Dirk Engling wrote: > Problem is, that the bthidd code does not handle reports not announced > in hid descriptors at all. So I would need to either manually inject the > report id in hid_device->desc and add handler code, handle magic mouse > in a completely different code path, or write my own driver. another option is to (in bthidcontrol) emit a fake descriptor which does contain information about reports you wish to handle.. iain From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 18:59:43 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 673CCA04AC2 for ; Mon, 14 Sep 2015 18:59:43 +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 B0AD41DA7 for ; Mon, 14 Sep 2015 18:59:41 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 76209 invoked from network); 14 Sep 2015 18:59:38 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 14 Sep 2015 18:59:38 -0000 Subject: Re: Apple Magic Mouse To: Iain Hibbert , freebsd-bluetooth@freebsd.org References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> From: Dirk Engling Message-ID: <55F71919.1080606@erdgeist.org> Date: Mon, 14 Sep 2015 20:59:37 +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: 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, 14 Sep 2015 18:59:43 -0000 On 14.09.15 19:18, Iain Hibbert wrote: > another option is to (in bthidcontrol) emit a fake descriptor which does > contain information about reports you wish to handle.. That does not help me with the magic numbers in the init report which needs to be sent on every attach. erdgeist From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 19:37:44 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 C943DA03F7F for ; Mon, 14 Sep 2015 19:37:44 +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 369C41935 for ; Mon, 14 Sep 2015 19:37:43 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 88202 invoked from network); 14 Sep 2015 19:37:41 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 14 Sep 2015 19:37:41 -0000 Subject: Re: Apple Magic Mouse To: Maksim Yevmenkin References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55F72204.5060007@erdgeist.org> Date: Mon, 14 Sep 2015 21:37:40 +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, 14 Sep 2015 19:37:44 -0000 On 14.09.15 19:07, Maksim Yevmenkin wrote: > this looks good. i only have one comment: why does it have to be in > bthidd ? we already query hid descriptor from the device (in > bthidcontrol) as part of initial device setup. why can't we query > device id at the same too? and simply stick it into the bthidd.conf > and be done with it? the nice thing about it is that if device > specific code does not work (for whatever reason), one can simply turn > it off by removing device id lines from the bthidd.conf. > > does it make sense to you? Oh, I saw it the other way around: I never understood the stony road to achieving something as simple as connecting a bluetooth mouse, in the first place and I did not want to further complicate things. It took _me_ a while to understand all the steps and quirks necessary to get a bluetooth device running and adding fields to a file that needs to be dumped and re-parsed later was something I could not imagine to be good practice. Maybe I just missed the crucial glue script that helps an average user to properly configure all the required daemons and start all the necessary tools, but neither is the handbook particularly useful [1] (seriously, an introduction into the basics of bluetooth when all you should need is inquiry, select a device and provide a PIN!?) nor does "man bluetooth" guide the novice user. In the end I needed to resort to [2] and manually copy&paste instructions. I just noticed, this is a little off-topic, but I think that you get the point that something is odd, if I am able to dwell into the depths of a hid driver but fail to get all the basic info. And before you ask: Yes, I volunteer to write an interactive/scriptable bluetooth framework configure script, if it is not yet there. ;) Back to the topic at hand: I do not know what kind of init magic other devices might require, but maybe bthidcontrol can offer to dump certain control commands that bthidd would execute when it attaches to the device. Iain suggested to also fake the hid descriptor, this way we would not even need to store vendor/product. However, I am not sure about the unofficial report ids apple uses for magic mouse and magic trackpad, and would not blindly handle them the way they are handled by the magic mouse driver. Still now I need to touch parser and generator and its documentation. Well, then. What do you think? erdgeist [1] https://www.freebsd.org/doc/handbook/network-bluetooth.html [2] http://astralblue.livejournal.com/357664.html From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 19:42: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 CCE19A042A9 for ; Mon, 14 Sep 2015 19:42:16 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (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 8BB881E45 for ; Mon, 14 Sep 2015 19:42:16 +0000 (UTC) (envelope-from plunky@ogmig.net) Received: from mfilter37-d.gandi.net (mfilter37-d.gandi.net [217.70.178.168]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 00886A80B0; Mon, 14 Sep 2015 21:42:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter37-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter37-d.gandi.net (mfilter37-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 170N2I9OM7m5; Mon, 14 Sep 2015 21:42:12 +0200 (CEST) X-Originating-IP: 31.68.69.76 Received: from galant.ogmig.net (unknown [31.68.69.76]) (Authenticated sender: plunky@ogmig.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id A1E6EA80B4; Mon, 14 Sep 2015 21:42:11 +0200 (CEST) Received: by galant.ogmig.net (Postfix, from userid 1000) id 1B6A126026A; Mon, 14 Sep 2015 20:42:13 +0100 (BST) Date: Mon, 14 Sep 2015 20:42:13 +0100 (BST) From: Iain Hibbert To: Dirk Engling , freebsd-bluetooth@freebsd.org Subject: Re: Apple Magic Mouse In-Reply-To: <55F71919.1080606@erdgeist.org> Message-ID: References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F71919.1080606@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: Mon, 14 Sep 2015 19:42:16 -0000 On Mon, 14 Sep 2015, Dirk Engling wrote: > On 14.09.15 19:18, Iain Hibbert wrote: > > > another option is to (in bthidcontrol) emit a fake descriptor which does > > contain information about reports you wish to handle.. > > That does not help me with the magic numbers in the init report which > needs to be sent on every attach. You can list a feature report in the descriptor, and send the init command (which is a feature report) when it appears in the descriptor. but perhaps it gets too convoluted and I don't remember why I didn't go down the fake descriptor route in the end but it could be all of that :) in any case, you have to know the DeviceID first anyway to decide if this device is special iain From owner-freebsd-bluetooth@freebsd.org Mon Sep 14 20:22:13 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 93EBAA035B9 for ; Mon, 14 Sep 2015 20:22:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 2DCE41EAB for ; Mon, 14 Sep 2015 20:22:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by wicge5 with SMTP id ge5so564578wic.0 for ; Mon, 14 Sep 2015 13:22:11 -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=2Lx/USkONpFebJJJSq/thW7PxZUWvBJ7B7tjm81tGXI=; b=oqcbSDzmdMP4mKhV5ueSLAse1HMuYfGaapautb8JIkTlBkW/HzIsb50K9N6z2DRuCm KIHEnH7QkJbhppbmcpWdojBqW4iA1L8znkD8m+eZJrWGEUZho9FeiCZupkJbMaLGMH86 sDTQUJHwbItXXuunIL9Kuv8hAJlclkVSP2kDGlH2XFJyuMpvAPagC/0bFunq3+ir9QTa Dda86XsIRv9zDS7x5Kz2V0YBqbpFnQF6ps6k/JIZhi1/Ih7/mDvUaFEsRUXDJBAYxaGF AdRRTpqgHkywXqb6Gl/jmT/MRGHmPKE72B7d4lGto8jdal9EI4FCjGlL9FAEhEEEb1bA +kLg== MIME-Version: 1.0 X-Received: by 10.194.184.136 with SMTP id eu8mr2308285wjc.151.1442262131694; Mon, 14 Sep 2015 13:22:11 -0700 (PDT) Received: by 10.28.146.132 with HTTP; Mon, 14 Sep 2015 13:22:11 -0700 (PDT) In-Reply-To: <55F72204.5060007@erdgeist.org> References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F72204.5060007@erdgeist.org> Date: Mon, 14 Sep 2015 13:22:11 -0700 Message-ID: Subject: Re: Apple Magic Mouse 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, 14 Sep 2015 20:22:13 -0000 >> this looks good. i only have one comment: why does it have to be in >> bthidd ? we already query hid descriptor from the device (in >> bthidcontrol) as part of initial device setup. why can't we query >> device id at the same too? and simply stick it into the bthidd.conf >> and be done with it? the nice thing about it is that if device >> specific code does not work (for whatever reason), one can simply turn >> it off by removing device id lines from the bthidd.conf. >> >> does it make sense to you? > > Oh, I saw it the other way around: I never understood the stony road to > achieving something as simple as connecting a bluetooth mouse, in the > first place and I did not want to further complicate things. well, bluetooth is simply a transport here. basically, the idea was to replace usb transfer with bluetooth. in sounds simple in theory, but in practice its not quite simple. devil is in the details. > It took _me_ a while to understand all the steps and quirks necessary to > get a bluetooth device running and adding fields to a file that needs to > be dumped and re-parsed later was something I could not imagine to be > good practice. i'm sorry you had trouble. documentation certainly could be better. let me put it this way: hid descriptor has to be obtained and parsed every time. on the other hands, hid descriptor does not usually change, so, the idea was to simply fetch hid descriptor once and cache it. the way i see it, bthidd has absolutely no reason to run sdp query every single time device is connected to re-fetch it. additional bonus here is that one can tweak various bits to work around bug in devices. for example, i've seen bluetooth mouse that incorrectly reports its psm for control and interrupt channels. the fix was to simply change device reported values in bthidd.conf and it worked. another example is when the actual hid descriptor is "broken", i've seen devices like that too. device vendor/id pair is another piece of information that usually does not change. again, there is no reason for bthidd to re-fetch it every single time device is connected. so, to me, it makes total sense to just stick it in the bthidd.conf and have it ready. > Maybe I just missed the crucial glue script that helps an average user > to properly configure all the required daemons and start all the > necessary tools, but neither is the handbook particularly useful [1] > (seriously, an introduction into the basics of bluetooth when all you > should need is inquiry, select a device and provide a PIN!?) nor does > "man bluetooth" guide the novice user. In the end I needed to resort to > [2] and manually copy&paste instructions. again, i'm sorry you had so much trouble. documentation could be better no question about it. the whole pin idea is really tricky. i've provided very basic hcsecd to respond to PIN/key request. the tricky part is that PIN has to entered. this required some sort of user notification and input. in general one can not assume that hcsecd will run in graphical environment, and, its rather tricky to get user's attention and input from a background daemon process. and then there is another class of devices (such as bluetooth keyboards), that do not have any notification at all, i.e. its tricky for user to know when to type PIN. so, yeah, i admit, hcsecd is kinda head-in-a-sand approach, but it can be made to work. > Back to the topic at hand: I do not know what kind of init magic other > devices might require, but maybe bthidcontrol can offer to dump certain > control commands that bthidd would execute when it attaches to the i'm not sure i follow. all Iain and i suggesting is that bthidcontrol simply query device / vendor id and put it in the config. i might be wrong, but i would imagine that combination of device / vendor id and hid descriptor would give bthidd enough information to go on. i'm not quite sure what other magic you refer to. this would be somewhat similar to usb, where one must query device descriptor (where vendor / device id pair id), interface descriptor(s) etc. just for the sake of it, i re-checked bluetooth hid spec. the sdp record exchange seems to only happening at bluetooth hid service setup time. both device and host initiated reconnects do not have sdp exchange. bthidcontrol is supposed to be used during "bluetooth hid service setup time". > device. Iain suggested to also fake the hid descriptor, this way we > would not even need to store vendor/product. However, I am not sure > about the unofficial report ids apple uses for magic mouse and magic > trackpad, and would not blindly handle them the way they are handled by > the magic mouse driver. true. this however depends on who is doing fake descriptor injection. if bthidcontrol does (i.e. not user) then bthidcontrol needs to know device / vendor id pair. thanks, max From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 03:21:39 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 D915DA0287C for ; Tue, 15 Sep 2015 03:21:39 +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 56E641365 for ; Tue, 15 Sep 2015 03:21:38 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 17248 invoked from network); 15 Sep 2015 03:21:30 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 15 Sep 2015 03:21:30 -0000 Subject: Re: Apple Magic Mouse To: Iain Hibbert References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling Message-ID: <55F78EB8.8060408@erdgeist.org> Date: Tue, 15 Sep 2015 05:21:28 +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: multipart/mixed; boundary="------------070604080301050005060400" 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, 15 Sep 2015 03:21:39 -0000 This is a multi-part message in MIME format. --------------070604080301050005060400 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 14.09.15 19:09, Iain Hibbert wrote: > My advice is, to put that code in bthidcontrol, which already queries the > device, and add product-id and vendor-id fields to the bthidd.conf file. Thanks for the advice, find attach an implementation. The only problem I found is that the bthidd.conf format is not backward compatible, the three additional parameters will fail on old versions of bthidcontrol and bthidd. Also contained in the patch is successful probing for my Magic Mouse and extraction of basic mouse features when track pad events are sent by the mouse. Next up: translation of finger tracking to z-scroll events. Looking forward to your reviews. erdgeist --------------070604080301050005060400 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="bluetooth.magic.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bluetooth.magic.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-15 04:31:18.791591870 +0200 @@ -86,6 +86,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-15 05:09:01.009438308 +0200 @@ -49,6 +49,30 @@ #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_STRENGHT_REPORT_ID 0x47 +#define SURFACE_REPORT_ID 0x61 + +/* + * Probe for per-device initialisation + */ +void +hid_initialise(bthid_session_p s) +{ + hid_device_p hid_device = get_hid_device(&s->bdaddr); + assert(hid_device != NULL); + + /* Magic report to enable trackpad on Apple's Magic Mouse */ + static uint8_t rep[] = { 0x53, 0xd7, 0x01 }; + if (hid_device->vendor_id == 0x5ac && hid_device->product_id == 0x30d) + write(s->ctrl, rep, 3 ); +} + +/* * Process data from control channel */ @@ -370,6 +394,41 @@ 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 (report_id == MOUSE_REPORT_ID && + hid_device->vendor_id == 0x5ac && + hid_device->product_id == 0x30d && + len > 5 && len <= 6 + 8*15 && ( (len - 6) % 8) == 0 ) { + + /* The basics. When touches are detected, no normal mouse + reports are sent. Collect clicks and dx/dy */ + int16_t delta; + ++data, --len; /* Chomp report_id */ + + if (data[2] & 1) + mouse_butt |= 0x4, mevents++; + if (data[2] & 2) + mouse_butt |= 0x1, mevents++; + + delta = data[0] + ((data[2] & 0x0C) << 6); + if (delta) /* add and sign extend */ + mouse_x += ((int16_t)(delta << 6)) >> 6, mevents++; + + delta = data[1] + ((data[2] & 0x30) << 4); + if (delta) /* add and sign extend */ + mouse_y += ((int16_t)(delta << 6)) >> 6, mevents++; + + data += 5, len -= 5; /* Chomp fixed header */ + + /* The harder part: accumulate touch events */ + /* TODO */ + } + + + /* * XXX FIXME Feed keyboard events into kernel. * The code below works, bit host also needs to track * and handle repeat. @@ -403,7 +462,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); } --------------070604080301050005060400-- From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 03:59:44 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 A6361A0406C for ; Tue, 15 Sep 2015 03:59:44 +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 EBDAF137F for ; Tue, 15 Sep 2015 03:59:43 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 26720 invoked from network); 15 Sep 2015 03:59:41 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 15 Sep 2015 03:59:41 -0000 Subject: Re: Apple Magic Mouse To: Maksim Yevmenkin References: <1437909200.57929.3.camel@yandex.com> <55F4362A.4050203@erdgeist.org> <55F60ED8.8080203@erdgeist.org> <55F72204.5060007@erdgeist.org> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55F797AB.5000501@erdgeist.org> Date: Tue, 15 Sep 2015 05:59:39 +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: Tue, 15 Sep 2015 03:59:44 -0000 On 14.09.15 22:22, Maksim Yevmenkin wrote: > again, i'm sorry you had so much trouble. documentation could be > better no question about it. the whole pin idea is really tricky. i've > provided very basic hcsecd to respond to PIN/key request. the tricky > part is that PIN has to entered. this required some sort of user > notification and input. in general one can not assume that hcsecd will > run in graphical environment, and, its rather tricky to get user's > attention and input from a background daemon process. and then there > is another class of devices (such as bluetooth keyboards), that do not > have any notification at all, i.e. its tricky for user to know when to > type PIN. > > so, yeah, i admit, hcsecd is kinda head-in-a-sand approach, but it can > be made to work. Maybe my email came across much harsher than it was meant. Please do not excuse yourself. After understanding how the fragments work together I think it is nicely engineered. The important take-away should be that I actually WANT to write a script that automatizes the bluetooth setup for the novice user. For reference: I know shell pretty well and am the author sysutils/ezjail, a convenient front end for jail environments. Maybe this should move to another thread, but as I see it, the tool should provide at least an interactive command bluetooth-config pair-new-device [-n node] [-a address|host] * check for presence of ng_ubt.ko, or [offer to] load it * check for all the rcvars enabled for services bluetooth, hcsecd and bthidd or [offer to] enable them using sysrc * If no node is passed as param, use "hccontrol read_node_list" to get the list of hci nodes and if multiple nodes exist, let the user chose * Ask the user to put device in pair mode * If no host is passed as param, use "hccontrol -n NODE inquiry" to scan for nearby devices. Use "bthidcontrol -a HOST query" to get all info and present the most useful entries, i.e. name, type, vendor, is-already-known, etc. Let the user select one host. * If no entry is found in /etc/bluetooth/hosts, ask the user for a human readable name and create an entry there. * If "bthidcontrol -a HOST known" does not indicate the node is known, append the "bthidcontrol -a HOST query" to /etc/bluetooth/bthidd.conf * Ask the user to put device in pair mode again (probably pairing time out) * Ask user if device presents a PIN. If yes, let user enter the PIN and dump an entry in /etc/bluetooth/hcsecd.conf, then restart hcsecd * If not, generate a PIN and (re)write entry in hcsecd.conf, present it to the user, restart hcsecd and ask the user to put device in pairing mode again * restart bthidd * If device is a keyboard, offer a text entry test field and if it does not succeed, leave some clues for debugging (i.e. if the node responds to pings, maybe switch keyboard on/off, etc) * Same if device is a mouse, i.e. hexdump /dev/sysmouse. * If device offers DUN profiles, ask the user if an entry in /etc/ppp/ppp.conf should be created * If OPUSH or SPP is offered, refer to the respective man pages to give some clues how to continue For most users, wrapping this up in a script would make the difference between setting up their mouse or giving up in the process. > just for the sake of it, i re-checked bluetooth hid spec. the sdp > record exchange seems to only happening at bluetooth hid service setup > time. both device and host initiated reconnects do not have sdp > exchange. bthidcontrol is supposed to be used during "bluetooth hid > service setup time". In my tests I could retrieve device identification service records at any time. Best, erdgeist From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 22:17: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 31E079C2E7C for ; Tue, 15 Sep 2015 22:17:28 +0000 (UTC) (envelope-from owner-moderators@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2689D129A for ; Tue, 15 Sep 2015 22:17:28 +0000 (UTC) (envelope-from owner-moderators@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: Your message to moderators awaits moderator approval From: moderators-owner@freebsd.org To: freebsd-bluetooth@freebsd.org Message-ID: Date: Tue, 15 Sep 2015 22:17:27 +0000 Precedence: bulk X-BeenThere: moderators@freebsd.org X-Mailman-Version: 2.1.20 X-List-Administrivia: yes Errors-To: owner-moderators@freebsd.org Sender: owner-moderators@freebsd.org X-BeenThere: freebsd-bluetooth@freebsd.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:17:28 -0000 Your mail to 'moderators' with the subject ENC: Dinheiro que você me pediu Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://lists.freebsd.org/mailman/confirm/moderators/04da1fd4bfb97a4626cb971b57f1e38b4133bbfd PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 22:17:23 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 8D09B9C2E12 for ; Tue, 15 Sep 2015 22:17:23 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 810D51296 for ; Tue, 15 Sep 2015 22:17:23 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: Your message to freebsd-current awaits moderator approval From: freebsd-current-owner@freebsd.org To: freebsd-bluetooth@freebsd.org Message-ID: Date: Tue, 15 Sep 2015 22:17:22 +0000 Precedence: bulk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 X-List-Administrivia: yes Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-BeenThere: freebsd-bluetooth@freebsd.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:17:23 -0000 Your mail to 'freebsd-current' with the subject ENC: Dinheiro que você me pediu Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://lists.freebsd.org/mailman/confirm/freebsd-current/d87082f1ce66f886a7e4e79cc771d4adb70ad231 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 22:17:18 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 104769C2D8A for ; Tue, 15 Sep 2015 22:17:18 +0000 (UTC) (envelope-from owner-freebsd-ia64@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E8F2E128B for ; Tue, 15 Sep 2015 22:17:17 +0000 (UTC) (envelope-from owner-freebsd-ia64@freebsd.org) Subject: The results of your email commands From: freebsd-ia64-owner@freebsd.org To: freebsd-bluetooth@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2036696997279694710==" Message-ID: Date: Tue, 15 Sep 2015 22:17:17 +0000 Precedence: bulk X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.20 X-List-Administrivia: yes Errors-To: owner-freebsd-ia64@freebsd.org Sender: owner-freebsd-ia64@freebsd.org X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-bluetooth@freebsd.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:17:18 -0000 --===============2036696997279694710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Results: Ignoring non-text/plain MIME parts freebsd-bluetooth@freebsd.org is not a member of the freebsd-ia64 mailing list - Done. --===============2036696997279694710== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: freebsd-ia64-unsubscribe@mailman.ysv.freebsd.org Delivered-To: freebsd-ia64-unsubscribe@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 11AE99C2D43 for ; Tue, 15 Sep 2015 22:17:17 +0000 (UTC) (envelope-from www-data@foxtubo.com.br) Received: from foxtubo.com.br (169.57.135.18-static.reverse.softlayer.com [169.57.135.18]) by mx1.freebsd.org (Postfix) with ESMTP id CE938126C for ; Tue, 15 Sep 2015 22:17:16 +0000 (UTC) (envelope-from www-data@foxtubo.com.br) Received: by foxtubo.com.br (Postfix, from userid 33) id 4F86911DAC5; Tue, 15 Sep 2015 17:16:45 -0500 (CDT) To: freebsd-ia64-unsubscribe@freebsd.org Subject: ENC: Dinheiro que você me pediu X-PHP-Originating-Script: 0:lu46vl422hxl2xj.php From: Maristela Bezerra Ramos De Oliveira 428677 freebsd-bluetooth X-Mailer: Microsoft Office Outlook, Build 17.551210 Message-Id: <20150915221645.4F86911DAC5@foxtubo.com.br> Date: Tue, 15 Sep 2015 17:16:45 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" --===============2036696997279694710==-- From owner-freebsd-bluetooth@freebsd.org Tue Sep 15 22:17:32 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 8D7CD9C2EF4 for ; Tue, 15 Sep 2015 22:17:32 +0000 (UTC) (envelope-from owner-moderators@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 805C712B0 for ; Tue, 15 Sep 2015 22:17:32 +0000 (UTC) (envelope-from owner-moderators@freebsd.org) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Subject: Your message to moderators awaits moderator approval From: moderators-owner@freebsd.org To: freebsd-bluetooth@freebsd.org Message-ID: Date: Tue, 15 Sep 2015 22:17:30 +0000 Precedence: bulk X-BeenThere: moderators@freebsd.org X-Mailman-Version: 2.1.20 X-List-Administrivia: yes Errors-To: owner-moderators@freebsd.org Sender: owner-moderators@freebsd.org X-BeenThere: freebsd-bluetooth@freebsd.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:17:32 -0000 Your mail to 'moderators' with the subject ENC: Dinheiro que você me pediu Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://lists.freebsd.org/mailman/confirm/moderators/2e36cbaf857c19737210b3a6e5b5f823f6573991 PLEASE NOTE! If you would like to post freely to the list, please subscribe first. If you post from multiple addresses, you can subscribe each address and go into the options page and select 'no mail' for all but one address. This will allow you to post without delay in the future. Sorry for the hassle, but certain immature people made this necessary. From owner-freebsd-bluetooth@freebsd.org Sat Sep 19 03:51:29 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 D934FA0376D for ; Sat, 19 Sep 2015 03:51:29 +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 2A0A918F2 for ; Sat, 19 Sep 2015 03:51:28 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: (qmail 43397 invoked from network); 19 Sep 2015 03:51:19 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with ESMTPS (DHE-RSA-AES128-SHA encrypted); 19 Sep 2015 03:51:19 -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> Cc: "freebsd-bluetooth@freebsd.org" From: Dirk Engling X-Enigmail-Draft-Status: N1110 Message-ID: <55FCDBB6.6090004@erdgeist.org> Date: Sat, 19 Sep 2015 05:51:18 +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: <55F78EB8.8060408@erdgeist.org> Content-Type: multipart/mixed; boundary="------------030507000703030402030603" 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, 19 Sep 2015 03:51:29 -0000 This is a multi-part message in MIME format. --------------030507000703030402030603 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 15.09.15 05:21, Dirk Engling wrote: > Also contained in the patch is successful probing for my Magic Mouse and > extraction of basic mouse features when track pad events are sent by the > mouse. Next up: translation of finger tracking to z-scroll events. With the attached patch I now do successfully operate my magic mouse on my FreeBSD, scroll wheel emulation and middle button works. I tried to keep everything apple mouse specific in one block. I would have loved to move it to its own function, but it needs access to many variables from hid_interrupt()'s scope. Moving all those variables to a state struct would work but blow up the patch. Either way is messy. In theory we now can cherry pick all the nice features from linux and netbsd drivers, e.g. acceleration, but for now my itches are scratched. Feedback is welcome. erdgeist --------------030507000703030402030603 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="bluetooth.magic.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bluetooth.magic.patch" diff -ru bthidd/bthid_config.h /usr/src/usr.sbin/bluetooth/bthidd/bthid_c= onfig.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= =2E046363156 +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 -ru bthidd/bthidd.conf.sample /usr/src/usr.sbin/bluetooth/bthidd/bth= idd.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:0= 8:15.624443300 +0200 @@ -2,6 +2,9 @@ =20 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 @@ =20 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 -ru 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.14657= 6846 +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); =20 +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= ); =20 diff -ru 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-18 08:18:02.87230420= 6 +0200 @@ -31,6 +31,7 @@ * $FreeBSD: releng/10.2/usr.sbin/bluetooth/bthidd/hid.c 281567 2015-04-= 15 22:07:51Z rakuco $ */ =20 +#include #include #include #include @@ -49,6 +50,48 @@ #include "kbd.h" =20 /* + * 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 x[MAGIC_MOUSE_MAX_BUTTONS]; + int y[MAGIC_MOUSE_MAX_BUTTONS]; + int button_state; +} apple_state; +#define MAGIC_MOUSE(D) (((D)->vendor_id =3D=3D 0x5ac) && ((D)->product_i= d =3D=3D 0x30d)) +#define SCROLL_WHEEL_SPEED 100 + +/* + * Probe for per-device initialisation + */ +void +hid_initialise(bthid_session_p s) +{ + hid_device_p hid_device =3D get_hid_device(&s->bdaddr); + assert(hid_device !=3D NULL); + + /* Magic report to enable trackpad on Apple's Magic Mouse */ + if (hid_device->vendor_id =3D=3D 0x5ac && + hid_device->product_id =3D=3D 0x30d) { + static uint8_t rep[] =3D { 0x53, 0xd7, 0x01 }; + s->ctx =3D malloc(sizeof(struct apple_state)); + if (!s->ctx) + return; + memset(s->ctx, 0, sizeof(struct apple_state)); + write(s->ctrl, rep, 3 ); + } +} + +/* * Process data from control channel */ =20 @@ -370,6 +413,88 @@ hid_end_parse(d); =20 /* + * 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 =3D (struct apple_state *)s->ctx; + int firm =3D 0, middle =3D 0; + int16_t v; + + if (report_id !=3D MOUSE_REPORT_ID || + len < 6 || len > 6 + 8*15 || ((len - 6) % 8)) + goto check_middle_button; + + /* The basics. When touches are detected, no normal mouse + reports are sent. Collect clicks and dx/dy */ + + ++data, --len; /* Chomp report_id */ + + if (data[2] & 1) + mouse_butt |=3D 0x1; + if (data[2] & 2) + mouse_butt |=3D 0x4; + + if ((v =3D data[0] + ((data[2] & 0x0C) << 6))) + mouse_x +=3D ((int16_t)(v << 6)) >> 6, mevents++; + if ((v =3D data[1] + ((data[2] & 0x30) << 4))) + mouse_y +=3D ((int16_t)(v << 6)) >> 6, mevents++; + + data +=3D 5, len -=3D 5; /* Chomp fixed header */ + + /* The hard part: accumulate touch events and emulate middle */ + while (len >=3D 8) { + int x, y, z, force, id; + + v =3D data[0] | ((data[1] & 0xf) << 8 ); + x =3D ((int16_t)(v << 4)) >> 4; + =09 + v =3D (data[1] >> 4) | (data[2]<<4); + y =3D -(((int16_t)(v << 4)) >> 4); + + force =3D data[5] & 0x3f; + id =3D 0xf & ((data[5] >> 6) | (data[6] << 2)); + + switch ((data[7] >> 4) & 0x7) { /* Phase */ + case 3: /* First touch */ + c->y[id] =3D y; + break; + case 4: /* Touch dragged */ + z =3D (y - c->y[id]) / SCROLL_WHEEL_SPEED; + mouse_z +=3D z; + if (mouse_z) + mevents++; + c->y[id] +=3D z * SCROLL_WHEEL_SPEED; + break; + default: + break; + } + /* Count firm touches vs. firm+middle touches */ + if (force >=3D 8 && ++firm && x > -350 && x < 350) + ++middle; + + data +=3D 8, len -=3D 8; + } + + /* 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 =3D=3D firm) + mouse_butt =3D 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 =3D=3D 0x2) + mouse_butt =3D 0x2; + + if (mouse_butt !=3D c->button_state) { + mevents++; + c->button_state =3D mouse_butt; + } + } + + /* * XXX FIXME Feed keyboard events into kernel. * The code below works, bit host also needs to track * and handle repeat. @@ -403,7 +528,6 @@ mi.u.data.y =3D mouse_y; mi.u.data.z =3D mouse_z; mi.u.data.buttons =3D 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 -ru 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.762445= 199 +0200 @@ -50,9 +50,13 @@ =20 hexdigit [0-9a-fA-F] hexbyte {hexdigit}{hexdigit}? +hexword {hexdigit}{hexdigit}?{hexdigit}?{hexdigit}? =20 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 @@ =20 bdaddrstring {hexbyte}:{hexbyte}:{hexbyte}:{hexbyte}:{hexbyte}:{hexbyt= e} hexbytestring 0x{hexbyte} +hexwordstring 0x{hexword} =20 %% =20 @@ -78,6 +83,9 @@ =20 {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 =3D=3D '\0'? T_HEXBYTE : T_ERROR); } =20 +{hexwordstring} { + char *ep; + + yylval.num =3D strtoul(yytext, &ep, 16); + + return (*ep =3D=3D '\0'? T_HEXWORD : T_ERROR); + } + . return (T_ERROR); =20 %% diff -ru 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.18345= 8248 +0200 @@ -86,8 +86,10 @@ =20 %token T_BDADDRSTRING %token T_HEXBYTE -%token T_DEVICE T_BDADDR T_CONTROL_PSM T_INTERRUPT_PSM T_RECONNECT_INITI= ATE -%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_PS= M +%token T_INTERRUPT_PSM T_RECONNECT_INITIATE T_BATTERY_POWER +%token T_NORMALLY_CONNECTABLE T_HID_DESCRIPTOR %token T_TRUE T_FALSE T_ERROR =20 %% @@ -123,6 +125,9 @@ ; =20 option: bdaddr + | vendor_id + | product_id + | version | control_psm | interrupt_psm | reconnect_initiate @@ -138,6 +143,24 @@ } ; =20 +vendor_id: T_VENDOR_ID T_HEXWORD + { + hid_device->vendor_id =3D $2; + } + ; + +product_id: T_PRODUCT_ID T_HEXWORD + { + hid_device->product_id =3D $2; + } + ; + +version: T_VERSION T_HEXWORD + { + hid_device->version =3D $2; + } + ; + control_psm: T_CONTROL_PSM T_HEXBYTE { hid_device->control_psm =3D $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 -ru 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.66445= 9031 +0200 @@ -286,6 +286,10 @@ srv->maxfd =3D s->vkbd; } =20 + /* Pass device for probing after both channels are established */ + if (s->state =3D=3D OPEN) + hid_initialise(s); + return (0); } =20 diff -ru 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.1853= 83406 +0200 @@ -65,6 +65,7 @@ memcpy(&s->bdaddr, &d->bdaddr, sizeof(s->bdaddr)); s->ctrl =3D -1; s->intr =3D -1; + s->ctx =3D NULL; =20 if (d->keyboard) { /* Open /dev/vkbdctl */ @@ -175,6 +176,7 @@ s->srv->maxfd --; } =20 + free(s->ctx); free(s->keys1); free(s->keys2); =20 diff -ru 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.41= 3719623 +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); =20 +/* + * 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 =3D SDP_SERVICE_CLASS_HUMAN_INTERFACE_DEVICE; +static uint16_t service_devid =3D SDP_SERVICE_CLASS_PNP_INFORMATION; +static uint32_t attrs_devid =3D SDP_DEVICE_ID_RANGE; =20 static uint32_t attrs[] =3D { SDP_ATTR_RANGE( SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST, @@ -84,27 +97,34 @@ return (((e) =3D=3D 0)? 0 : -1); \ } =20 +static void +hid_init_return_values() { + int i; + for (i =3D 0; i < nvalues; i ++) { + values[i].flags =3D SDP_ATTR_INVALID; + values[i].attr =3D 0; + values[i].vlen =3D sizeof(buffer[i]); + values[i].value =3D buffer[i]; + } +} + static int32_t hid_sdp_query(bdaddr_t const *local, struct hid_device *hd, int32_t *err= or) { void *ss =3D NULL; - uint8_t *hid_descriptor =3D NULL; + uint8_t *hid_descriptor =3D NULL, *v; int32_t i, control_psm =3D -1, interrupt_psm =3D -1, reconnect_initiate =3D -1, normally_connectable =3D 0, battery_power =3D 0, - hid_descriptor_length =3D -1; + hid_descriptor_length =3D -1, type; + int16_t vendor_id, product_id, version; =20 if (local =3D=3D NULL) local =3D NG_HCI_BDADDR_ANY; if (hd =3D=3D NULL) hid_sdp_query_exit(EINVAL); =20 - for (i =3D 0; i < nvalues; i ++) { - values[i].flags =3D SDP_ATTR_INVALID; - values[i].attr =3D 0; - values[i].vlen =3D sizeof(buffer[i]); - values[i].value =3D buffer[i]; - } + hid_init_return_values(); =20 if ((ss =3D sdp_open(local, &hd->bdaddr)) =3D=3D NULL) hid_sdp_query_exit(ENOMEM); @@ -113,9 +133,6 @@ if (sdp_search(ss, 1, &service, nattrs, attrs, nvalues, values) !=3D 0)= hid_sdp_query_exit(sdp_error(ss)); =20 - sdp_close(ss); - ss =3D NULL; - for (i =3D 0; i < nvalues; i ++) { if (values[i].flags !=3D SDP_ATTR_OK) continue; @@ -150,11 +167,51 @@ } } =20 + hid_init_return_values(); + + if (sdp_search(ss, 1, &service_devid, 1, &attrs_devid, nvalues, values)= !=3D 0) + hid_sdp_query_exit(sdp_error(ss)); + + sdp_close(ss); + ss =3D NULL; + + /* If search is successful, scan through return vals */ + for (i =3D 0; i < 3; i ++ ) { + if (values[i].flags =3D=3D SDP_ATTR_INVALID ) + continue; + + /* Expecting tag + uint16_t on all 3 attributes */ + if (values[i].vlen !=3D 3) + continue; + + /* Make sure, we're reading a uint16_t */ + v =3D values[i].value; + SDP_GET8(type, v); + if (type !=3D 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 =3D=3D -1 || interrupt_psm =3D=3D -1 || reconnect_initiate =3D=3D -1 || hid_descriptor =3D=3D NULL || hid_descriptor_length =3D=3D -1) hid_sdp_query_exit(ENOATTR); - + hd->vendor_id =3D vendor_id; + hd->product_id =3D product_id; + hd->version =3D version; hd->control_psm =3D control_psm; hd->interrupt_psm =3D interrupt_psm; hd->reconnect_initiate =3D reconnect_initiate? 1 : 0; --------------030507000703030402030603--