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