Hello everybody,
I would like to request a feature to make it possible from command line
tool and dbus gtk gui to set a property just similar as the trusted
device property to directly reconnect a device at start-up of the
bluetoothd daemon.
Use-case: I have a lot of systems with successful connected bluetooth
keyboards. The boot-up of these systems are around 5 seconds with full
GUI. But the devices is not usable yet, because when you press a key it
first start connection... this takes almost the same time as the
complete boot-up and it forces an extra key press of the user every time
they start the system. Maybe some org.bluez.Input interface thing?
Would somebody be willing to place this on there to-do list, it has no
hurry bot somewhere in the next 6 months would be nice.
Thanks in advance,
Jelle de Jong
Iain Hibbert schreef:
> On Sat, 4 Jul 2009, Luiz Augusto von Dentz wrote:
>
>>> IIUC that's just how bluetooth input devices work: they do connect to
>>> the host - not the other way round. So it is really a problem that
>>> cannot be solved on bluez' side.
>> Yep, most hid devices will just refuse the connection if the 'virtual
>> cable plug' was already stabilised, in general this is also a bad idea
>> for any connection attempt during the startup as we have no guarantee
>> that the connection will complete.
>
> see HIDNormallyConnectable attribute in the HID spec (7.11.13)
>
> I certainly find with my Apple bluetooth keyboard and mouse that the host
> OS (not using BlueZ btw) can connect to them at boot without my
> intervention.
>
> iain
Thanks you for providing this information it helps to see that apple
does provide this behavior for usability to its users. Would a developer
be willing to investigate this feature and place this on his/her to do list?
Thanks in advance,
Jelle
On Sat, 4 Jul 2009, Luiz Augusto von Dentz wrote:
> > IIUC that's just how bluetooth input devices work: they do connect to
> > the host - not the other way round. So it is really a problem that
> > cannot be solved on bluez' side.
>
> Yep, most hid devices will just refuse the connection if the 'virtual
> cable plug' was already stabilised, in general this is also a bad idea
> for any connection attempt during the startup as we have no guarantee
> that the connection will complete.
see HIDNormallyConnectable attribute in the HID spec (7.11.13)
I certainly find with my Apple bluetooth keyboard and mouse that the host
OS (not using BlueZ btw) can connect to them at boot without my
intervention.
iain
Hi,
On Sat, Jul 4, 2009 at 8:57 AM, Stefan Seyfried<[email protected]> wrote:
> On Sat, 04 Jul 2009 13:15:52 +0200
> Jelle de Jong <[email protected]> wrote:
>
>> Use-case: I have a lot of systems with successful connected bluetooth
>> keyboards. The boot-up of these systems are around 5 seconds with full
>> GUI. But the devices is not usable yet, because when you press a key
>> it first start connection... this takes almost the same time as the
>> complete boot-up and it forces an extra key press of the user every
>> time they start the system. Maybe some org.bluez.Input interface
>> thing?
>
> IIUC that's just how bluetooth input devices work: they do connect to
> the host - not the other way round. So it is really a problem that
> cannot be solved on bluez' side.
Yep, most hid devices will just refuse the connection if the 'virtual
cable plug' was already stabilised, in general this is also a bad idea
for any connection attempt during the startup as we have no guarantee
that the connection will complete.
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
On Sat, 04 Jul 2009 13:15:52 +0200
Jelle de Jong <[email protected]> wrote:
> Use-case: I have a lot of systems with successful connected bluetooth
> keyboards. The boot-up of these systems are around 5 seconds with full
> GUI. But the devices is not usable yet, because when you press a key
> it first start connection... this takes almost the same time as the
> complete boot-up and it forces an extra key press of the user every
> time they start the system. Maybe some org.bluez.Input interface
> thing?
IIUC that's just how bluetooth input devices work: they do connect to
the host - not the other way round. So it is really a problem that
cannot be solved on bluez' side.
--
Stefan Seyfried
R&D Preload Department | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)