Re: [gdm-list] Pairing bluetooth input devices before logging in?

[Bastien Nocera <hadess hadess net>]

On Thu, 2007-08-09 at 19:20 +0200, Mourad De Clerck wrote:
> Hi Bastien,
> 
> On 09/08/07 18:07, Bastien Nocera wrote:
> > On Wed, 2007-08-08 at 11:13 -0400, William Jon McCann wrote:
> >> On 8/7/07, Mourad De Clerck <mourad aquazul com> wrote:
> >>> In light of the gdm rework that has been going on, I was wondering if
> >>> and how the new gdm is going to handle bluetooth input devices.
> >>>
> >> That is a good point.  And may be yet another reason to make our GDM
> >> greeters more session-like.
> > 
> > I guess the problem is mostly for desktop PCs with builtin Bluetooth, or
> > Bluetooth "proxy dongles" specific to the hardware used.
> > 
> <snip>
> 
> Well, I'm assuming that the distro's init scripts will always set the 
> dongles in HCI mode, and not leave them in HID mode. The only thing 
> hid2hci can reliably do, is go from hid -> hci. Querying the mode 
> doesn't work, and going hci -> hid often doesn't work either (Logitech).

I personally don't think it should be on by default, but that's
something to discuss on bluez-devel rather than here.

> > If you're thinking about a different use case/different hardware, let me
> > know, but be aware that el-cheapo Taiwanese Bluetooth adapter and an
> > unrelated Bluetooth keyboard will not work out of the box, and will
> > never do (they don't know about each other, and there's no other way
> > than pairing them).
> 
> That's pretty much the use case I've been seeing. To illustrate, these 
> are the problems I've had with a Logitech diNovo keyboard:
> 
> - once the logitech dongle was in HCI mode, it would not go back to HID 
> mode on reboot -> result is that I couldn't use the keyboard in 
> BIOS/GRUB, and when dual-booting in windows the bluetooth stack there 
> would not be able to "activate" the dongle (I'd have cut power 
> completely so dongle is in HID mode first). This problem can't really be 
> solved by bluez or gdm at all, since it's just caused by a lack of 
> specs, and a silly windows stack.

With the specs, it would "just work" as intended originally. That's for
both the Apple and Logitech cases.

> - These days, I just use an el-cheapo bluetooth dongle (the logitech one 
> died), so no hid2hci issues anymore. However, if I dual-boot, and pair 
> the keyboard in windows (or MacOSX , haven't tried yet), then we lost 
> the pairing in Linux and on reboot I have to plug in a USB keyboard to 
> login and pair.

Not much that we can do here, although devices using the new Bluetooth
spec should have simpler "bring them together" pairing, which might help
solving the problem.

> - Whenever I use my keyboard with other computers (laptop, 770, 
> whatever), the same thing happens of course: as soon as I boot I have to 
> go looking for an USB keyboard.
> 
> > In this use case, it would be nice to be able to type a password using a
> > virtual keyboard, if the mouse is wired/working for example.
> 
> I'd like to suggest something slightly simpler even: just show all 
> wireless (discoverable) HID devices somewhere in the GDM login screen, 
> and when you click on one it generates and displays a random pin to 
> initiate the pairing. Type it in and you're set.

This probably needs to be worked on as part of the work on the
bluetooth-wizard in bluez-gnome. A simple program would be started at
the same time as GDM (there were plans to allow that, for
gnome-power-manager, no?), then:
- check if there's no input device
- if there is no keyboard, allow entry via a virtual keyboard, make sure
GNOME launches a virtual keyboard too, user goes through pairing
"normally" (you probably want the bluetooth-applet to launch the pairing
process automatically)
- if there is no mouse, same thing, minus the virtual keyboard
- if there's no input device at all, try to connect to a nearby mouse
and/or keyboard (although I'm not sure how it would discover the PIN
codes required for it, unless we cached it at the bluez level, to
discuss on bluez-devel as well)

> If you've got no working input device (wired or wireless) at all, it 
> automatically attempts to pair the discoverable mice first.
> 
> (I don't believe any state needs to be carried over between GDM and the 
> user session, since it's all kept in the bluez stack, right?)

Yeah, the keyboard is connected to a particular adapter, not a user.
Although that would probably break badly for multi-seat setups.

> How does that sound?

Sounds good.

-- 
Bastien Nocera <hadess hadess net>