[BRLTTY] brltty 3.7.2 USB claiming fails

[mlang]

Jason White <jasonw at ariel.its.unimelb.edu.au> writes:

> On Sat, Feb 04, 2006 at 03:20:35PM +0100, Mario Lang wrote:
>
>> usb 1-7: usbfs: interface 0 claimed by belkin while 'brltty' sets config #1
> Perhaps the braille display is using a USB->serial chip internally. The vendor
> ids used on some braille displays (e.g., 0x0403), correspond to those of USB
> to serial chips, as a quick WEb search shows.

Jason: Yes, we know this.  Previously, we used to make these devices
(HandyTech and Papenmeier USB connectors) work by letting the kernel
do the USB->Serial converter initialisation, and specifying the
appropriate /dev/ttyUSBn device as braille-device for BRLTTY.  However,
this has the disadvantage that the user needs to know the correct USB serial
port in advance, which is unreliable, since the order could suddenly change
if the user has other USB->serial adapters.  Additionally, this
doesnt make autodetection particularily easy, which is sad, since
USB allows for neat autodetection based on Device IDs.  When we redid USB
in BRLTTY 3.5, we actually implemented the necessary code to control
these USB->serial adapters from userspace drectly, without the
need for a kernel module to be loaded. This means that now, BRLTTY
can simply search for the appropriate USB device on the USB bus,
and open it directly, without requiring the user to know the
actual USB->serial adapter device name.  So the -d parameter for these
displays changed from something like "serial:/dev/ttyUSB0" to "usb:".

There is a IOCTL for USB userspace programming in Linux which forces
the kernel to deregister a USB kernel driver module which feels
responsible for a particular USB device such that a userspace driver
can later claim it.  This once used to work, but fails now.

I.e., this problem will also apply to Papenmeier EL40s users which run
distro-kernels (which do have most/all USB drivers built as modules).
-- 
CYa,
  Mario