On Wed, 3 Feb 2021 11:41:17 +0000 Edd Barrett <e...@theunixzoo.co.uk> wrote:
> On Wed, Feb 03, 2021 at 11:17:01AM +0000, Stuart Henderson wrote: > > btw the problem was seen with umb, it's not just ugen. > > From mglocker@'s explanation, I understood that it is the ugen driver > trying to attach to some part of the device that in turn hoses umb for > the same device? > > Maybe I misunderstood. That's right. ugen(4) tries to attach to another umb(4) interface, then fails, and labels the whole umb(4) device dying. I don't know if all umb(4) devices show this behaviour (I don't have such a device). But the other thing I was thinking about is whether we should make umb(4) attach to this other interface as well to prevent ugen(4) to take control. > > At some point you just have to say "this device is broken crap, send > > it back or ebay it and buy an alternative". This is much easier for > > some classes of device where there are many alternatives (like > > audio interfaces) than mobile broadband where it's still very > > difficult to find something suitable with the correct physical > > interface. > > Yes, I'm starting to lean in this direction too. > > The only other solution would be to have some kind of quirks system, > but I don't think that'd be perfect either: I bet some (different) > devices share vendor and device IDs... Well. I think there are a lot of USB device with all kind of non-compliant USB configurations. That's why I personally think spending too much efforts here, trying to make the right thing, isn't worth it. You will fix something, and then break something else IMO. I would rather focus on getting as much devices possible supported without breaking others. Just as we did now :-)
