[BRLTTY] mantis q40

[Florian Beijers]

Hello Dave,

For some reason, your message didn't make it to me, but I saw it from
the list digest.

> I believe you mentioned that this braille device can connect to multiple hosts.
> This implies that it may use multiple channels, and that might be the problem.
> In other words, brltty mightn't be able to figure out which channel to use.
> Please post the output of sdp browse on the deivce's Bluetooth address.
That may very well be the case. The device can connect to up to five
bluetooth devices at once and, unlike the Vario Ultra for example,
these channels aren't numbered on the user-facing side, so there's not
really a way to see what bt channel a device is taking up and what the
q40 is using to determine what device to use for what channel. Output
of sdptool browse with the q40 set to the channel of the kali machine
is below, quite a lot is happening there:


kali at kali:~$ sdptool browse AC:64:CF:A2:A1:FD
Browsing AC:64:CF:A2:A1:FD ...
Service RecHandle: 0x10000
Service Class ID List:
  "PnP Information" (0x1200)
Profile Descriptor List:
  "PnP Information" (0x1200)
    Version: 0x0103

Browsing AC:64:CF:A2:A1:FD ...
Service Search failed: Invalid argument
Service Name: Generic Access Profile
Service Provider: BlueZ
Service RecHandle: 0x10001
Service Class ID List:
  "Generic Access" (0x1800)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 31
  "ATT" (0x0007)
    uint16: 0x0001
    uint16: 0x0005

Service Name: Generic Attribute Profile
Service Provider: BlueZ
Service RecHandle: 0x10002
Service Class ID List:
  "Generic Attribute" (0x1801)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 31
  "ATT" (0x0007)
    uint16: 0x0006
    uint16: 0x000f

Service Name: AVRCP CT
Service RecHandle: 0x10003
Service Class ID List:
  "AV Remote" (0x110e)
  "AV Remote Controller" (0x110f)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x0103
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0106

Service Name: AVRCP TG
Service RecHandle: 0x10004
Service Class ID List:
  "AV Remote Target" (0x110c)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x0103
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0105

Service Name: Audio Source
Service RecHandle: 0x10005
Service Class ID List:
  "Audio Source" (0x110a)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 25
  "AVDTP" (0x0019)
    uint16: 0x0103
Profile Descriptor List:
  "Advanced Audio" (0x110d)
    Version: 0x0103

Service Name: Headset Voice gateway
Service RecHandle: 0x10006
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 12
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0102

Service Name: Hands-Free Voice gateway
Service RecHandle: 0x10007
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 13
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0107

Service Name: APH Mantis Q40
Service Description: Humanware
Service Provider: Humanware
Service RecHandle: 0x10008
Service Class ID List:
  "Human Interface Device" (0x1124)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 17
  "HIDP" (0x0011)
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Human Interface Device" (0x1124)
    Version: 0x0100

Browsing AC:64:CF:A2:A1:FD ...
Service Search failed: Invalid argument
kali at kali:~$

> What, exactly, do you mean by "connecting", here? It's possible that this could
indeed cause brltty to "think" that the device is in use by something else.

I have tried both hitting enter on the device in
gnome-control-center's bluetooth panel, which made the q40 output that
a connection has been established. I have also tried deleting the
device from the GUI and , in a bluetoothctl shell, ran pair, followed
by connect, which gave the same result.
Doing either procedure makes the qwerty-style keyboard, which the
device has built in, work, but braille is abscent.

Hope that helps,
Florian

2021-02-10 17:14 GMT+01:00, Florian Beijers <florianbeijers at gmail.com>:
> Just realized I only sent this to Mario before, my bad.
> I have done some more experimenting, and quite simply, the unit just
> won't sit up and take notice where brltty is concerned. Connection
> goes off without a hitch, the HID keyboard part works, but error 111:
> connection refused from RFCOMM is all the logs show.
> I've tried connecting through the GUI as well as bluetoothctl,
> manually trusting the device first, re-paring it several times without
> result.
> So I guess this is when I have to conclude there's a bug :) I just
> looked at the github repo but I don't see the issues tab being there.
> What is the procedure for submitting a bug report?
>
> Thanks,
> Florian
>
> 2021-02-09 20:59 GMT+01:00, Florian Beijers <florianbeijers at gmail.com>:
>> Ok, I ran a few more tests but still am not really getting anywhere.
>>
>> I tailed the journalctl to see what wold happen if I were to cycle to and
>> away from the box I'm trying to connect, that did nothing whatsoever.
>> Then, I hopped back into bluetoothctl and saw that it was connecting and
>> disconnecting repeatedly every few seconds.
>> I deleted the device, re-paired it and explicitly gave the connect
>> command,
>> that made it stop flickering.
>> Tailing the journalctl again I now see L2CAP: connection timed out, as
>> well
>> as "software caused connection abort" errors in the logs. Does that help
>> with diagnosing what's happening?
>>
>>
>>
>> Op di 9 feb. 2021 om 19:57 schreef Florian Beijers
>> <florianbeijers at gmail.com
>>>:
>>
>>> Hi,
>>>
>>> Ok, so the mantis q40 is a hybrid device of a keyboard and a braille
>>> display. I have paired it through the GUI and I can confirm that the
>>> keyboard part of it works fine. So I would say it is paired correctly.
>>> The way this device works is that you can connect to several devices at
>>> once, with a little menu that cycles in between devices.
>>> I currently am not near the device but when I was logging, I didn't have
>>> the device's channel selected, which lead to the "connection refused"
>>> log.
>>> My theory, which I haven't been able to validate yet, is that "resource
>>> busy" comes up when either one of the other channels is in use, or when
>>> I'm
>>> actually connected to the device, in which case the driver or the device
>>> internals are doing something weird. I'll report back when I have all
>>> the
>>> permutations logged.
>>>
>>> Florian
>>>
>>> Op di 9 feb. 2021 om 19:45 schreef Mario Lang <mlang at blind.guru>:
>>>
>>>> Florian Beijers <florianbeijers at gmail.com> writes:
>>>>
>>>> > I see a whole lot of RFCOMM errors, either connection refused or
>>>> resource busy.
>>>> > What would that indicate?
>>>>
>>>> My first question would be: Are you sure you have correctly paired the
>>>> device?  Does bluetoothctl report it as paired?
>>>>
>>>> --
>>>> CYa,
>>>>   ⡍⠁⠗⠊⠕
>>>>
>>>
>>
>