On Mon, Jan 23, 2012 at 8:03 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > And it's not relevant to the discussion. Any chance you could send me > the details about your devices for me to add them to the database? :) > Not yet ;-) (but they're not relevant to this patch, because this patch isn't intended to cover them) > We already know when we have a keyboard, we already know when we have a > non-SSP device. Why can't we use RequestPincode in the UI? We already > generate the random PIN for devices. > See Marcel's mails for why he doesn't want this done in the UI. >From my point of view, because then we have give different UIs which are all different. Implementing this in bluetoothd means GNOME, KDE, Maemo/Moblin/MeeGo/Tizen, Android, Chrome OS, etc. can all share a single behavior. >> > From what I can see, the whole operation can be implemented from >> > user-space without a problem. >> > >> > Care to explain what benefits this has for user-space? >> > >> >> Marcel asked me to implement this in bluetoothd, so everyone can >> benefit equally rather than four different bluetooth agents all >> handling auto-pairing slightly differently. > > In which case it needs not to regress from the existing solutions. We > have a database of devices with their specific pairing information, we > also have ways to show the PIN in special ways depending on the remote > device: > I don't disagree - the "database of devices" is only relevant to the other patch set I submitted for comments though, not this one. You'll note that this keyboard PIN generation patch is deliberately after any plugins, so that they (including the autopair plugin in the previous patch) can handle the fixed PIN cases. Scott -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
