question about bthidd client.c

[Maksim Yevmenkin]

On Wed, Apr 22, 2015 at 11:17 AM, Maksim Yevmenkin
<maksim.yevmenkin at gmail.com> wrote:
>>>> I notice that if bthidd is running, and bluetooth is not active, or
>>>> the configured host is out of range, the client_rescan() function
>>>> generates new vkbd devices every 20 seconds or so. I believe this will
>>>> eventually lock up the machine.
>>>>
>>>
>>> may be... usually devices will reconnect, i.e. reconnect_initiate
>>> would be 1. however, this is a known problem. for whatever reason
>>> "cloned" devices are not completely going away when closed. similar
>>> problem exists with other "cloned" devices. its not bthidd or
>>> bluetooth code specific.
>>
>> Thanks for the reply. Is there a better way to decide if a device is
>> 'connectable'? It looks like a chicken-and-egg kind of problem, since
>
> device tells host who is supposed to initiate reconnect (in sdp
> attribute). normally, devices will initiate reconnect. host should not
> be required to constantly "poll". there is no easy way to know if
> device is "connectable". inquiry may tell you if device is in range
> but only if device is in "discoverable" mode. most devices will only
> go into discoverable mode during pairing.
>
>> the connect routine uses the established vkbd device. I am thinking
>> that attempting to connect to the device on psm 1 is a way to verify
>> that the host is connectable in the first place, before creating a new
>> vkbd. Or, maybe the new vkbd can be destroyed on failure... but maybe
>> this would cause other problems.
>
> there should not be any problem. cloned device is created on open()
> and should be destroyed on close().

the simplest solution to this problem is to add a configuration
parameter that specifies vkbd unit number for each entry. this way,
the same device (i.e. keyboard) will always use the same vkbd. no more
endless cloning.

thanks,
max