Re: Potential problem with reading data from usb devices with ugen(4)

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello.  In looking further at the ugen(4) driver, it looks like there
has been some effort to get things like select/poll(2) working with ugen(4)
connected devices, as well as having read calls return after a specific
timeout interval.  Under 5.2, at least, and I think -current as well, I
don't think that machinery is working quite right.  Here are the things I
notice as I look at the code.  Keep in mind that I'm not an expert with the
way usb works, so there may be huge gaps in my understanding in terms of
what's actually broken.

1.  If a process wants to write to a device on one end point and then be
notified via select/poll that another endpoint of the same  device is ready
for reading, I don't see anything in the ugen(4) driver that polls the
device to see if it has something to say.  Normally, with most other
devices, this is what interupts do, but it's not clear to me that usb
connected devices can assert interrupts or, if they can, that our usb
subsystem can take those bus transactions and translate them into calls to
the ugen(4) interrupt  handler.  In other words, I see the handler, but I
don't understand the mechanism by which it gets called.  Further, I don't
see how the ugen(4) driver can read data from a device and then notify the
user level process that the data is ready for reading.  (If the process is
sleeping in the read call, then, yes, I understand that.)  However, it
looks like there's no way to have an interrupt initiate a device read
process which then notifies the user process that there's data to read.
(Again, there's some code that looks like it tries to do this, but I think
it assumes the user process is sleeping in the read(2) call.)

2.  What I want is to be able to write to a usb device, then do a
select/poll on the read descriptor and, when there's data to get, be
notified.  That's not currently working.   (The linux drivers apparently do
this,so I don't think it's outside the scope of reasonable ness.)
	I've tried some test patches which get me closer to this, but once the
device stops producing data to read, it's hard to get the driver to poll
the device to see if it has data.  

	So, I guess, what I'm thinking about is how to get a ugen(4) that can
poll a usb device for data that's not being prodded by a user level process
sitting in the read(2) call.

Thoughts?

-Brian