Re: Usb2 and hal issue

On Fri, 2008-11-14 at 20:17 +0100, Hans Petter Selasky wrote:
> Hi Kane!
> 
> Your patch will solve the CPU problem, but will otherwise not fix FreeBSD USB 
> support under HAL.
> 
> 1) Hal should use "devd" to get attach/detach events.
> 2) Hal should use libusb20/libusb to access USB functions and to enumerate USB 
> devices.
> 
> --HPS

Thanks,

Yes, after further investigation I found out that it just fixes the CPU
utilization issue, but the USB support remains broken. I don't use its
USB support all that much, so I didn't even realize this until recently.
I guess our old USB code presented /dev/usb0, /dev/usb1, ..., /dev/usbN
for N+1 USB controllers. These aren't here anymore so maybe the above
suggestion to use libusb now for FreeBSD (which currently gets disabled
when configure realizes we're FreeBSD) is the best approach.

I managed to get the libusb20 library working with libfprint and the
associated pam_fprint and fprint_demo software. It is working really
well for me so far.

> 
> On Friday 14 November 2008, Coleman Kane wrote:
> > On Thu, 2008-11-06 at 01:38 +0100, Diego Depaoli wrote:
> > > Hi all,
> > > I don't know how provide further details, but on my system there is
> > > something of wrong between new usb2 drivers and hald.
> > > Top shows hald's cpu load at 100% while with old drivers it's 2-4%.
> > > I tried rebuilding hald, loading/unloading each usb2_* device but
> > > nothing changed, so I suspect the problem is located in usb2_core.
> >
> > I figured out the problem, and I have a solution. As the other person
> > mentioned, the device name has changed from "/dev/usb" into "/dev/usb
> > " (the space is important). However, the hald daemon doesn't use libusb
> > on FreeBSD. Here's a patch which tells hald to look at the new device,
> > apply it to the root of your ports collection.
> >
> > Additionally, I think it is a bug that hald busy-loops trying (and
> > failing) to open "/dev/usb". Ideally, I think that hald should put a
> > sleep in there of some sort, to give up CPU to something else.
> 

-- 
Coleman Kane