hi!

Ok, so it's because in theory the firmware could be buggy and need
patching via the ath3kfw tool (which gosh I really should just import
into -head already) before it starts up.

can you clone https://github.com/erikarn/ath3k and try to load in what
it thinks the right patch set / config file is? See if it comes up ok?
Now that we have the hotplug work from warner and others I bet we
could import ath3k and just have it autorun via devd in a non-terrible
fashion.



-adrian

On Wed, 25 Mar 2020 at 23:09, Chris <bsd-li...@bsdforge.com> wrote:
>
> On Wed, 25 Mar 2020 19:05:40 -0700 (PDT) jason-fbsd-blueto...@shalott.net said
>
> > >> Hello.  I am trying to get an ath3k-based USB bluetooth adapter
> > >> working.  I previously had this adapter working under FreeBSD, several
> > >> years ago[.]  After loading the firmware, it is not detected by ng_ubt.
> >
> > > I tracked this down:
> > >
> > > https://svnweb.freebsd.org/base?view=revision&revision=249178
> > >
> > > Can someone explain why these devices were blacklisted from the ng_ubt
> > > driver?  It seems like the devices will fail to work if the firmware is
> > > not loaded to the device before ng_ubt is loaded into the kernel; but it
> > > seems like the failure mode is just that those devices don't work in
> > > that case.  So blacklisting them from the driver seems a lot worse...
> >
> > Pinging again on this.
> >
> > Any chance we can revert the above commit?
> >
> > After reverting the above commit on my box, I am able to fully use my
> > bluetooth adapter (pair HID devices, play audio through my headset with
> > virtual_oss, etc).  I don't want to have to maintain a custom kernel in
> > perpetuity to maintain that capability.
> >
> > Am I missing something about the current situation?  As far as I can tell,
> > with all of those devices blacklisted in the ng_ubt driver, there is no
> > way to use those devices on FreeBSD.  But if those devices are re-instated
> > in ng_ubt, the only downside is that they _might_ not work, because it's
> > left as an exercise to the user to make sure that the device firmware is
> > pushed to the device before ng_ubt is loaded into the kernel.  So my
> > understanding is: current situation, those devices are impossible to use;
> > reverting the above commit, those devices might be usable if the user
> > knows what they're doing.  Is that the wrong understanding?  And if it's
> > correct, is there any reason to not re-instate them?
> >
> >
> > If some other change is needed or wanted instead of just reverting the
> > above commit -- extra checks, warning log messages, etc -- I would be
> > happy to take a run at it if someone could describe what's needed.  I
> > don't know anything about Bluetooth and don't have any kernel-hacking
> > experience, but I am an experienced C programmer.
> It might be worth opening a pr (https://bugs.freebsd.org) for this. Doing
> so might give it higher visibility, and I *think* that's also the
> preferred direction. After all. As far as your concerned, this seems like
> a bug. No? :)
>
> --Chris
> >
> > Thanks.
> >
> >
> >  -Jason
> >
> > _______________________________________________
> > freebsd-bluetooth@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
> > To unsubscribe, send any mail to "freebsd-bluetooth-unsubscr...@freebsd.org"
>
>
_______________________________________________
freebsd-bluetooth@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscr...@freebsd.org"

Reply via email to