RE: Recommendations for programming HID in FreeBSD 9
if (id != 0) copyin(ugd-ugd_data,id, 1); error = uhid_set_report(sc, ugd-ugd_report_type, id, NULL, ugd-ugd_data, imin(ugd-ugd_maxlen, size)); Hans is right. That code should do the trick. Last year I've fixed uhid driver to handle multiple report IDs. Even user-level tools are able to do it now. id != 0 should be correct condition. According to HID spec, if device has at least one non-zero report ID, report ID should be included into any transfer. So now uhid driver assumes that report ID should be in the first byte of request, if it found some non-zero ID in descriptor. Thanks to all for your help, I have it working, and am very happy to be up to date in BSD. For the record, one of my HID had different report IDs AND different report sizes, so I had to add my hack to send the size for it to work correctly. The bonus with that is that my touchscreen, which has badly ported HID code from the original USB firmware, and does not correctly report its report sizes, can also work with uhid. Thanks again Sam ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
RE: Recommendations for programming HID in FreeBSD 9
[original post moved to end for brevity - or should I just delete it when replying?] From: Hans Petter Selasky [mailto:hsela...@c2i.net] See: man usbhid Else use LibUSB to access the device. --HPS Thank you for replying I should point out that the usbhid.cpp compile below is my file - I didn't know there was a 'real' usbhid. Usbhid looks great, but it is probably a little higher level than I need. I should mention that the devices I am talking with are a known quantity - I wrote the firmware on some of them, and have extensive datasheets on the rest. I just need to get a usage page, or VID and PID so I can tell which one is which, i.e. who's at uhid0 and who's at uhid3. I had been researching libusb for a while, but their webpage says it is not recommended for HID devices and to use HIDAPI, which does not seem to be on BSD. I saw your version, and it looks great! I wish I had that a few years ago when you helped me with getting an isochronous device working on BSD 7.0. However, due to time constraints, I'd rather not write a HID front end using that if I don't need to. I see uhid is still around - is there any reason not to just use that? I already have cross-platform HID code that used to work with uhid - I suspect my problem might just be that the headers I need have moved or changed. I will grep... According to the uhid man page, these should all still exist somewhere: usbhid.cpp:35: error: 'usb_ctl_report_desc' does not name a type usbhid.cpp:157: error: 'usb_ctl_report' was not declared in this scope usbhid.cpp:174: error: 'USB_SET_REPORT' was not declared in this scope usbhid.cpp:331: error: 'USB_GET_REPORT_DESC' was not declared in this Or is uhid being obsoleted? Thanks Sam On Thursday 31 May 2012 18:30:56 Engineering wrote: Hi all, I hope this is the right place to ask this I am in process of migrating an embedded system from BSD 7.0 to 9.0, as we need upgraded video card drivers which will not compile on the old system. To confuse matters a bit, I believe it was 7.0 with some of HPS updated USB stack worked in. The system has 4 HID devices attached, and I need to read data and set feature reports to talk to them. I had been using read() and ioctl() - with the evolution of BSD, is there a different recommended way to do this? I also need open() and to be able to get the usage page, to tell one device from another. If I recall, at the time the uhid driver had problems with devices that had feature reports of varying sizes - I see I hacked it a bit to allow the application to specify the size of the report. Is this still the case? I of course will be looking into this myself, but initial compile gives me the following errors - does this ring a bell to anyone? Thanks, Sam Compiling usbhid.cpp... usbhid.cpp:35: error: 'usb_ctl_report_desc' does not name a type ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
RE: Recommendations for programming HID in FreeBSD 9
From: Hans Petter Selasky [mailto:hsela...@c2i.net]
uhid is not going to get obsoleted, though using libraries from
user-space is sometimes more convenient.
Thanks HPS (and Xiaofan)
I definitely agree with that, but I've got legacy code...
Last question - I've updated my code to convert the old 'usb_ctl_report' and
such to the new generic descriptors at runtime, and I've got two HIDs up and
running.
As I read uhid.c, it seems to assume only one feature report ID and size. I
have devices that have multiple feature report sizes. And one device which
I'm pretty sure has bad device descriptors, so the size is wrong.
In the BSD7, I added the following fakery to uhid.c:
case USB_SET_REPORTZ: // report id and size are in first two bytes
re = (struct usb_ctl_report *)addr;
id = re-ucr_data[0];
size = re-ucr_data[1];
err = usbd_set_report(sc-sc_iface, re-ucr_report, id,
re-ucr_data[2],size);
if (err)
{
return (EIO);
}
break;
Do you think it would make sense to do this again with the BSD9 uhid.c?
If so, is there a way to recompile the kernel so it only updates the uhid
part? Pardon my ignorance on that.
Sam
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
RE: Recommendations for programming HID in FreeBSD 9
-Original Message- From: Hans Petter Selasky [mailto:hsela...@c2i.net] I think mav @ did some work in that area? Are you sure you cannot use: ... if (id != 0) copyin(ugd-ugd_data, id, 1); error = uhid_set_report(sc, ugd-ugd_report_type, id, NULL, ugd-ugd_data, imin(ugd-ugd_maxlen, size)); break; That's definitely cleaner, using the ugd fields to denote a special case. I'm not sure about the (id != 0) - I'll need to check my specific devices, but something like: if(ugd-ugd_config_index) // abusing variables to set a flag, use passed in id and size in lang_id and actlen error = uhid_set_report(sc, ugd-ugd_report_type, ugd-ugd_lang_id, NULL, ugd-ugd_data, ugd-ugd_actlen); else error = uhid_set_report(sc, ugd-ugd_report_type, id, NULL, ugd-ugd_data, size); Would suit my needs well, as long as I remember to zero out ugd_config_index on a normal one! I suppose I need to rebuild the kernel. Thanks for your time and help! Sam ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Recommendations for programming HID in FreeBSD 9
Hi all, I hope this is the right place to ask this I am in process of migrating an embedded system from BSD 7.0 to 9.0, as we need upgraded video card drivers which will not compile on the old system. To confuse matters a bit, I believe it was 7.0 with some of HPS updated USB stack worked in. The system has 4 HID devices attached, and I need to read data and set feature reports to talk to them. I had been using read() and ioctl() - with the evolution of BSD, is there a different recommended way to do this? I also need open() and to be able to get the usage page, to tell one device from another. If I recall, at the time the uhid driver had problems with devices that had feature reports of varying sizes - I see I hacked it a bit to allow the application to specify the size of the report. Is this still the case? I of course will be looking into this myself, but initial compile gives me the following errors - does this ring a bell to anyone? Thanks, Sam Compiling usbhid.cpp... usbhid.cpp:35: error: 'usb_ctl_report_desc' does not name a type usbhid.cpp: In function 'int hid_set_feature(int, unsigned char*, int)': usbhid.cpp:157: error: 'usb_ctl_report' was not declared in this scope usbhid.cpp:157: error: expected `;' before 'ucr' usbhid.cpp:161: error: 'ucr' was not declared in this scope usbhid.cpp:169: error: invalid application of 'sizeof' to incomplete type 'usb_ctl_report' usbhid.cpp:174: error: 'USB_SET_REPORT' was not declared in this scope usbhid.cpp: In function 'void usbhid_populate_list()': usbhid.cpp:331: error: 'USB_GET_REPORT_DESC' was not declared in this scope usbhid.cpp:331: error: 'struct hid_t' has no member named 'ucrd' usbhid.cpp:334: error: 'struct hid_t' has no member named 'ucrd' usbhid.cpp:336: error: 'struct hid_t' has no member named 'ucrd' usbhid.cpp:337: error: 'struct hid_t' has no member named 'ucrd' *** Error code 1 ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
ugen write hangs on BSD 7.2
Hello all
I am having trouble communicating with a custom HID device using FreeBSD
7.2.
I was trying to use uhid, but it looks like it doesn't do interrupt out
transfers.
Open and read work fine, but write() errors with EIO
The device is a simple PIC based IO board. When sent 64 bytes, it responds
with 64 bytes. Oddly enough, my Windows version using ReadFile and WriteFile
works perfectly.
I'm looking into upgrading to BSD 8.0, but we have a lot of legacy code for
USB that won't compile under BSD8, so I'd rather avoid it. I wrote a small
test program - under BSD 8.0, it no longer hangs, but it still doesn't
write, so I'm not sure 8.0 is the answer. Although it looks like the naming
changed for 8. For instance, my device would be ugen0, and the first
endpoint would be ugen0.1. On 8.0, ugen0-ugen4 are always there, and
plugging the device in gets me ugen2.1 - not sure where the interrupt
endpoint went!
Here's a quick look at the test code, and output with hw.usb.debug on
void errp(void); // printfs errors in nice format
unsigned char io_buf[65]; //Allocate a memory buffer equal to our
endpoint size + 1 NOT ON STACK!!
int main(int argc,char *argv[])
{
int bw;
int i;
int err;
int device;
char devname[64];
if (argc != 2)
{
printf(Specify device\n);
exit(1);
}
sprintf(devname,/dev/%s,argv[1]);
device = open(devname,O_RDWR);//|O_NONBLOCK|O_NDELAY );
printf(Open dev %s: %d\n,devname,device);
for(i=0;i5;i++)
{
bw = write(device,io_buf,64);
printf(write %d bytes to %d returned %d\n,64,device,bw);
if (bw == (-1)) errp();
bw = read(device,io_buf,64);
printf(read %d bytes\n,bw);
if (bw == (-1)) errp();
}
close(device);
exit(0);
}
#./iotest ugen0.1
May 26 15:40:10 kernel: usbd_open_pipe: iface=0xc54dc960 address=0x1
flags=0x0
May 26 15:40:10 kernel: usbd_setup_pipe: dev=0xc5335a80 iface=0xc54dc960
ep=0xc54dc9cc pipe=0xe7b9b958
May 26 15:40:10 kernel: usbd_open_pipe_intr: address=0x81 flags=0x4 len=64
May 26 15:40:10 kernel: usbd_open_pipe: iface=0xc54dc960 address=0x81
flags=0x1
May 26 15:40:10 kernel: usbd_setup_pipe: dev=0xc5335a80 iface=0xc54dc960
ep=0xc54dc9c0 pipe=0xe7b9b930
May 26 15:40:10 kernel: usbd_alloc_xfer() = 0xc529c600
May 26 15:40:10 kernel: usbd_transfer: xfer=0xc529c600, flags=4,
pipe=0xc57b9480, running=0
May 26 15:40:10 kernel: usbd_dump_queue: pipe=0xc57b9480
May 26 15:40:10 kernel: usb_insert_transfer: pipe=0xc57b9480 running=0
timeout=0
Open dev /dev/ugen0.1: 3
May 26 15:40:10 kernel: usbd_alloc_xfer() = 0xc528c000
May 26 15:40:10 kernel: usbd_intr_transfer: start transfer 64 bytes
May 26 15:40:10 kernel: usbd_transfer: xfer=0xc528c000, flags=0,
pipe=0xc57c2a00, running=0
May 26 15:40:10 kernel: usbd_dump_queue: pipe=0xc57c2a00
May 26 15:40:10 kernel: usb_insert_transfer: pipe=0xc57c2a00 running=0
timeout=0
Stalls here, until CTRL-C
May 26 15:40:22 kernel: usbd_intr_transfer: tsleep=-1
May 26 15:40:22 kernel: usbd_ar_pipe: pipe=0xc57c2a00
May 26 15:40:22 kernel: usbd_dump_queue: pipe=0xc57c2a00
May 26 15:40:22 kernel: xfer=0xc528c000
May 26 15:40:22 kernel: usbd_ar_pipe: pipe=0xc57c2a00 xfer=0xc528c000
(methods=0xc0c50924)
May 26 15:40:22 kernel: usb_schedsoftintr: polling=0
May 26 15:40:22 kernel: usb_transfer_complete: pipe=0xc57c2a00
xfer=0xc528c000 status=6 actlen=0
May 26 15:40:22 kernel: usb_transfer_complete: repeat=0 new head=0
May 26 15:40:22 kernel: usbd_free_xfer: 0xc528c000
May 26 15:40:22 kernel: usbd_ar_pipe: pipe=0xc57c2a00
May 26 15:40:22 kernel: usbd_dump_queue: pipe=0xc57c2a00
May 26 15:40:22 kernel: usbd_ar_pipe: pipe=0xc57b9480
May 26 15:40:22 kernel: usbd_dump_queue: pipe=0xc57b9480
May 26 15:40:22 kernel: xfer=0xc529c600
May 26 15:40:22 kernel: usbd_ar_pipe: pipe=0xc57b9480 xfer=0xc529c600
(methods=0xc0c50924)
May 26 15:40:22 kernel: usb_schedsoftintr: polling=0
May 26 15:40:22 kernel: usb_transfer_complete: pipe=0xc57b9480
xfer=0xc529c600 status=6 actlen=0
May 26 15:40:22 kernel: usb_transfer_complete: repeat=0 new head=0
May 26 15:40:29 kernel: usb_event_thread: woke up
May 26 15:40:29 kernel: usb_discover
May 26 15:40:29 kernel: usb_event_thread: woke up
May 26 15:40:29 kernel: usb_discover
May 26 15:40:29 kernel: usb_event_thread: woke up
Any ideas?
Sam
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
RE: uhid write EIO
Hi - quick correction - I had it working under 7.0, not 6.2, but I think I had a beta version of HPS' updated USB stack in there. Sam -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Engineering Sent: Saturday, May 22, 2010 11:54 AM To: freebsd-usb@FreeBSD.org Subject: uhid write EIO Hello all I am having trouble communicating with a custom HID device using FreeBSD 7.2. Open and read work fine, but write() errors with EIO My code works well with another HID that uses read and feature reports. Oddly enough, my Windows version using ReadFile and WriteFile works perfectly. The device is a simple PIC based IO board. Windows WriteFile uses the interrupt OUT endpoint - does uhid not do the same? I have also tried changing the descriptor so the device shows up as a ugen. In previous (6.2 and 7.0) versions of BSD, I was able to open, read, and write to communicate with the device, but write is failing as a ugen too. I can provide more information, but I thought I'd check if this is appropriate for this list, and if anyone has an idea before I post. Thanks Sam ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Isochronous transfer missing frames on USB4?
Hello all. I am having an odd problem getting a UVC webcam to work on FreeBSD Little background: This is for an arcade game - needs to be able to run for weeks unattended at a bar Running of Intel D945PLNM board, nVidia 9500GT series video card. Storage is compact flash, with a CF-IDE adapter Webcam is no-name Chinese, which is supposed to conform to UVC spec - no other documentation 'Driver' is modified ugen with Hans Petter's newest stack. Running high-speed isochronous transfers. We've been running for months with no problems, but now that production motherboards and cameras are coming in, something is cropping up. The webcam is locked at 160x120, 30fps At this rate, it always gives me 39 frames of data per video frame 37 frames of 1024, 1 frame of 968, 1 frame of 12 Minus the 12 bytes of header on each packet, that is 37*1012+956 = 38400 bytes, which is exactly correct The last 12 byte header contains no data, but contains the end of frame bit Cannot confirm, but it only seems to happen when webcam is plugged into the USB port directly underneath the etherNet jack. Timing issue? Priority? Any suggestions on where to look? Thanks, Sam I have _tons_ of logs and source, but I'll snip what seems relevant for now... Apr 28 17:09:04 kernel: FreeBSD 7.0-RELEASE #9: Wed Mar 18 08:04:55 CDT 2009 Apr 28 17:09:04 kernel: usb4: EHCI version 1.0 Apr 28 17:09:04 kernel: usb4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 Apr 28 17:09:04 kernel: usb0: 12Mbps Full Speed USB v1.0 Apr 28 17:09:04 kernel: uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usb0 Apr 28 17:09:04 kernel: uhub0: 2 ports with 2 removable, self powered Apr 28 17:09:04 kernel: usb1: 12Mbps Full Speed USB v1.0 Apr 28 17:09:04 kernel: uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usb1 Apr 28 17:09:04 kernel: uhub1: 2 ports with 2 removable, self powered Apr 28 17:09:04 kernel: usb2: 12Mbps Full Speed USB v1.0 Apr 28 17:09:04 kernel: uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usb2 Apr 28 17:09:04 kernel: uhub2: 2 ports with 2 removable, self powered Apr 28 17:09:04 kernel: usb3: 12Mbps Full Speed USB v1.0 Apr 28 17:09:04 kernel: uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usb3 Apr 28 17:09:04 kernel: uhub3: 2 ports with 2 removable, self powered Apr 28 17:09:04 kernel: usb4: 480Mbps High Speed USB v2.0 Apr 28 17:09:04 kernel: uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usb4 Apr 28 17:09:04 kernel: uhub4: 8 ports with 8 removable, self powered Apr 28 17:09:04 kernel: ugen0: Vimicro Corp. Sirius USB2.0 Camera, class 239/2, rev 2.00/1.00, addr 2 on usb4 Apr 28 17:09:04 kernel: make_dev uvc.1 // My debug messages follow Apr 28 17:09:19 kernel: set config 0 Apr 28 17:09:19 kernel: make_dev uvc.1 Apr 28 17:09:19 kernel: set config 1 Apr 28 17:09:19 kernel: make_dev uvc.1 Apr 28 17:09:19 kernel: make_dev uvc.2 Apr 28 17:09:19 kernel: ugen_get_cdesc -1 Apr 28 17:09:19 kernel: usbd_find_idesc 0 0 Apr 28 17:09:19 kernel: UVC Start read uvc returned 0 Apr 28 17:09:19 kernel: High speed 64 frames Apr 28 17:09:19 kernel: ugen_open_pipe_read: isoc open done // Megabytes of this stuff... Shows the raw byte count of each of the 64 frames coming back on iso_read_callback Apr 28 17:09:19 kernel: 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 968 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 Apr 28 17:09:19 kernel: 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 Apr 28 17:09:19 kernel: 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 Apr 28 17:09:19 kernel: 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 0 Apr 28 17:09:19 kernel: 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 968 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 37 frames of 1024, 1 frame of 968, 1 frame of 12 Minus the 12 bytes of header on each packet, that is 37*1012+956 = 38400 bytes, which is exactly correct The last 12 byte header contains no data, but contains the end of frame bit After time - problems cropping up - a complete packet goes missing - easiest to see if the 968 or 12 goes, but it happens to the 1024s too When missing, the packet is completely gone - 0 bytes Apr 29 13:40:25 kernel: 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 968 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 Apr 29 13:40:25 kernel: 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 1024 0 0 0 0 0 0
RE: USB Video Class support
I have a driver based off ugen. Hans Petter helped me get started on it - it should be using his new stack It was built for a custom embedded application, so the functionality is limited to just what I needed to get it going. It works with 7 out of the 10 different Chinese cameras I have laying around :) I'm sure my coding style violates every FreeBSD standard, there is no documentation, and very few comments, but if someone wants it for a working framework to create a 'real' driver, they are welcome to it. Sam -Original Message- From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-...@freebsd.org] On Behalf Of Nicolas Sent: Sunday, March 29, 2009 5:09 AM To: freebsd-usb@freebsd.org; freebsd-multime...@freebsd.org Subject: USB Video Class support Hi, Someone knows if a person works on usb video class driver ? Thanks in advance, Nicolas. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Webcam ugen iso transfer problems
Hello
I am having much trouble trying to read isochronous data from a UVC webcam.
I understand that a full driver is being worked on right now, but I'd love
to be able to get my 'mini-driver' which only does one frame rate working in
the meantime.
I have updated the USB stack with Hans Petter Selasky's work, and am now
able to get data. The problem is, much of the YUV data seems to be missing.
I have just run tests through all of the Alt Interfaces, and have some
results.
I am just setting the cam to 160x120 uncompressed, and trying to get the
stream
In each case, I try to set the buffer to wMaxPacketSize * 400 (ugen seems to
collect 50 * 8 packets)
I notice at the faster interfaces, the ugen Frame Size no longer matches
wMaxPacketSize.
This should give me 12 byte stream headers, and lots of YUV data. I read the
results as a 2 channel raw file in Photoshop. I discarded the 2nd channel
(UV) for clarity, so the 12 bytes headers become 6 bytes, which you can see
in the png files.
the basic test code loop is
dev-isopipe = open(pipename,O_RDONLY);
(set the buffer size, timeout, short XFER)
FILE *f;
f = fopen(/usr/src/sys/dev/usb/test.raw,wb);
int i;
int bytes;
for(i = 0;i210;i++)
{
bytes = read(dev-isopipe,uvcbuf,UVCBUFSIZE); // 42240
if (bytes 0)
{
fwrite(uvcbuf,bytes,1,f);
zinfo(read %d bytes\n,bytes);
}
}
fclose(f);
Basic setup info...
VS_FRAME_UNCOMPRESSED
length 50
type 24
subtype 05
frame_index 5
capabilities 0
width 160
height 120
minbitrate 38400
maxbitrate 1152000
max_video_frame_buffer_size 38400
default_frame_interval 33
frame_interval_type 6
frame_interval[0] 33
USB_DO_REQUEST SEND...length = 34
USB_DO_REQUEST RECV...length = 34
UVC Stream probe
bmHint 01
bFormatIndex 1
bFrameIndex 5
dwFrameInterval 33
wKeyFrameRate 1
wPFrameRate 1
wCompQuality 1
wCompWindowSize 0
wDelay 34055
dwMaxVideoFrameSize 42240
dwMaxPayloadTransferSize 1600
dwClockFrequency 1852381070
bmFramingInfo B2
bPreferedVersion 175
bMinVersion 250
bMaxVersion 180
Alt Interface 1:
Setting altinterface to 1:1
Getting altinterface for 1
00 00 00 00 01 00 00 00 01 00 00 00
Getting interface description
bLength 09
bDescriptorType 04
bInterfaceNumber 01
bAlternateSetting 01
bNumEndpoints 01
bInterfaceClass 0E
bInterfaceSubClass 02
bInterfaceProtocol 00
iInterface 00
Getting endpoint description
bLength 07
bDescriptorType 05
bEndpointAddress 81
bmAttributes 05
wMaxPacketSize 0080 (128)
bInterfaceSubClass 01
Opening isopipe /dev/ugen0.1...
returned 5
Setting buffer size 51200
Setting short xfer...
Setting timeout to 1
ugen Frame size 128
ugen Buffer size 51200
dev-MaxPacketSize = 128
dev-endpoint = 81
result:
www.athyriogames.com/ai1.png
Alt Interface 2:
Setting altinterface to 1:2
Getting altinterface for 1
00 00 00 00 01 00 00 00 02 00 00 00
Getting interface description
bLength 09
bDescriptorType 04
bInterfaceNumber 01
bAlternateSetting 02
bNumEndpoints 01
bInterfaceClass 0E
bInterfaceSubClass 02
bInterfaceProtocol 00
iInterface 00
Getting endpoint description
bLength 07
bDescriptorType 05
bEndpointAddress 81
bmAttributes 05
wMaxPacketSize 0100 (256)
bInterfaceSubClass 01
Opening isopipe /dev/ugen0.1...
returned 5
Setting buffer size 102400
Setting short xfer...
Setting timeout to 1
ugen Frame size 256
ugen Buffer size 102400
dev-MaxPacketSize = 256
dev-endpoint = 81
result:
www.athyriogames.com/ai2.png
Alt Interface 3:
Setting altinterface to 1:3
Getting altinterface for 1
00 00 00 00 01 00 00 00 03 00 00 00
Getting interface description
bLength 09
bDescriptorType 04
bInterfaceNumber 01
bAlternateSetting 03
bNumEndpoints 01
bInterfaceClass 0E
bInterfaceSubClass 02
bInterfaceProtocol 00
iInterface 00
Getting endpoint description
bLength 07
bDescriptorType 05
bEndpointAddress 81
bmAttributes 05
wMaxPacketSize 0320 (800)
bInterfaceSubClass 01
Opening isopipe /dev/ugen0.1...
returned 5
Setting short xfer...
Setting timeout to 1
ugen Frame size 800
ugen Buffer size 65536
dev-MaxPacketSize = 800
dev-endpoint = 81
result:
www.athyriogames.com/ai3.png
Alt Interface 4:
Setting altinterface to 1:4
Getting altinterface for 1
00 00 00 00 01 00 00 00 04 00 00 00
Getting interface description
bLength 09
bDescriptorType 04
bInterfaceNumber 01
bAlternateSetting 04
bNumEndpoints 01
bInterfaceClass 0E
bInterfaceSubClass 02
bInterfaceProtocol 00
iInterface 00
Getting endpoint description
bLength 07
bDescriptorType 05
bEndpointAddress 81
bmAttributes 05
wMaxPacketSize 0B20 (2848)
bInterfaceSubClass 01
Opening isopipe /dev/ugen0.1...
returned 5
Setting buffer size 1139200
Setting short xfer...
Setting timeout to 1
ugen Frame size 1600
ugen Buffer size 262144
dev-MaxPacketSize = 2848
dev-endpoint = 81
result:
www.athyriogames.com/ai4.png
Alt Interface 3:
Setting altinterface to 1:5
Getting altinterface for 1
00 00 00 00 01 00 00 00 05 00 00 00
Getting interface description
Intro and question about High speed Isochronous
Hi all, this is Sam Zehr. I am an embedded systems programmer working on porting an app to FreeBSD. I'm afraid I'm no expert in BSD, or any *nix stuff, but I'm plugging along. My project requires high-speed isochronous transfer. At first, I thought, no problem. I got it working in Windows with a generic USB driver, so BSD should be easy! I started using ugen and got most of the code ported. Then I found out ehci does not support isochronous! Looking through archives, and googling, I see that work is being done to fix this (and it would appear that this is the right list, as I see the same names as some of the websites I've been to) Basically, I'm trying to implement a limited subset of UVC. I'm open to doing this whichever way will work. So, my questions are: Is there a fix coming for ehci so iso will work? Is there a new USB stack coming with high-speed iso? Will it work with ugen? If not ugen, how do I get at it? Is anyone working on a UVC driver? I don't need all the features, just to get at the stream data. I apologize if the answers are common knowledge, but I couldn't find anything definative in my googling. Thanks Sam ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
