Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Sep 2015 10:07:21 -0700
From:      Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
To:        Dirk Engling <erdgeist@erdgeist.org>
Cc:        "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>
Subject:   Re: Apple Magic Mouse
Message-ID:  <CAFPOs6pYoPGNfWheDyG2vNu46oLyN%2BSgh2rPYrew=iYmeFFuZA@mail.gmail.com>
In-Reply-To: <55F60ED8.8080203@erdgeist.org>
References:  <1437909200.57929.3.camel@yandex.com> <alpine.NEB.2.11.1508092034290.5638@galant.ogmig.net> <55F4362A.4050203@erdgeist.org> <CAFPOs6p%2BEZDctPodY6DBbnhfZQFz%2Bo0uKSRvvqQBcM1QL3ACXw@mail.gmail.com> <55F60ED8.8080203@erdgeist.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 13, 2015 at 5:03 PM, Dirk Engling <erdgeist@erdgeist.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6pYoPGNfWheDyG2vNu46oLyN%2BSgh2rPYrew=iYmeFFuZA>