Date: Mon, 14 Sep 2015 13:22:11 -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: <CAFPOs6ozJashriYAs%2BMHBz%2BYrC4ZTELJ31gkuTObP7Y__KaVdQ@mail.gmail.com> In-Reply-To: <55F72204.5060007@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> <CAFPOs6pYoPGNfWheDyG2vNu46oLyN%2BSgh2rPYrew=iYmeFFuZA@mail.gmail.com> <55F72204.5060007@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFPOs6ozJashriYAs%2BMHBz%2BYrC4ZTELJ31gkuTObP7Y__KaVdQ>