Re: usb4bsd patch review [was Re: ...]
On Wednesday 20 August 2008, Alfred Perlstein wrote: [[ Reply to Hans at end of this ]] [[ Reply to Kris inline ]] Hi, I've CC'ed multimedia. We have the following diff to mixer.c. Can anyone tell if it will have any negative consequences: --- sys/dev/sound/pcm/mixer.c August 2008 +++ sys.new/dev/sound/pcm/mixer.c August 2008 @@ -589,7 +589,7 @@ KASSERT(m-type == MIXER_TYPE_SECONDARY, (%s(): illegal mixer type=%d, __func__, m-type)); - snd_mtxlock(m-lock); + /* mixer uninit can sleep --hps */ MIXER_UNINIT(m); @@ -704,14 +704,24 @@ return EBUSY; } + /* destroy dev can sleep --hps */ + + snd_mtxunlock(m-lock); + pdev-si_drv1 = NULL; destroy_dev(pdev); + snd_mtxlock(m-lock); + for (i = 0; i SOUND_MIXER_NRDEVICES; i++) mixer_set(m, i, 0); mixer_setrecsrc(m, SOUND_MASK_MIC); + snd_mtxunlock(m-lock); + + /* mixer uninit can sleep --hps */ + MIXER_UNINIT(m); snd_mtxfree(m-lock); @@ -1280,3 +1290,16 @@ return (EINVAL); } P.S. There were a number of questions you didn't answer, can I assume those will follow later? Could you please repeat the questions you did not get an answer to? I've repeated some of them already. e.g. in this mail you still didn't answer the is it safe to drop the locks question which was asked twice. Rather than me repeating them yet again, I'd suggest you go back and take another close read over my emails and your responses, and reply to the questions that are still not resolved. Hans, let's just leave sound the way it is. I will remove that part of the patch. It might be better to leave a bad locking in that generates a warning rather than obscure the locking issue by removing the warning without fully understanding the issues. USB audio is the only sound device I know about that is regularly plugged in and out, which is causing this code path to be executed, unless you load unload a sound module, which I think is very rarely done. The lock in question has never before been exposed to the underlying layers, so the funtions that are called should not have any knowledge about it and consequently not depend on it either. Alfred: Just make sure that everything builds. We can fix up these issues afterwards. If USB sound support is broken it is not that critical. ---HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review [was Re: ...]
Hi, OK. Based on this review thread I think we have agreed that: * The ARM changes were already imported separately by warner Great. * the sound changes will not go in since they're unrelated to USB and there are some unresolved questions there. It sounds like there are real bugs identified and possibly also fixed there, so I continue to encourage you or Hans to follow up with the sound developers so the problems can be resolved separately. Fine. * the newbus change is not needed (but warner liked Hans's helper function so maybe that should be committed separately) Fine. * the ndis module is not complete and will not go in yet, and the question about the above #ifdef will be resolved in the meantime Fine. * hans is going to work on adding back the individual drivers instead of bundling them Fine. * you and hans will work on the manpages post-commit with help from the doc guys Fine. Questions remaining: * Why is the PAGE_SHIFT change necessary? According to what Warner stated in a recent e-mail, the page PAGE_SHIFT re-definition by the NDIS is redundant and can be removed. * The $FreeBSD$ expansion in files that were copied - will this confuse SVN or the CVS exporter? In CVS we had to make sure not to import expanded tags. Easiest solution is to just unexpand them. Alfred, you have to answer this. * How much of the userland support is incomplete or in flux, and what functionality is missing for users of the usb2 code until it is finished? The USB userland library is nearly complete. All it lacks is proper documentation: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/libusb20 The USB config utility is also starting to become finished. It will be renamed to usbconfig. Currently it is called usbview : svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbview --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review [was Re: ...]
Hans Petter Selasky wrote: * How much of the userland support is incomplete or in flux, and what functionality is missing for users of the usb2 code until it is finished? The USB userland library is nearly complete. All it lacks is proper documentation: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/libusb20 The USB config utility is also starting to become finished. It will be renamed to usbconfig. Currently it is called usbview : svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbview So...what functionality is missing for users of the usb2 code until it is finished? Stated even more clearly, what things will users of the USB2 code not be able to do until the above userland code is imported? Seriously, I'm trying to understand this! Kris ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review [was Re: ...]
On Thursday 21 August 2008, Kris Kennaway wrote: Hans Petter Selasky wrote: * How much of the userland support is incomplete or in flux, and what functionality is missing for users of the usb2 code until it is finished? The USB userland library is nearly complete. All it lacks is proper documentation: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/libusb20 The USB config utility is also starting to become finished. It will be renamed to usbconfig. Currently it is called usbview : svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbview So...what functionality is missing for users of the usb2 code until it is finished? Stated even more clearly, what things will users of the USB2 code not be able to do until the above userland code is imported? Seriously, I'm trying to understand this! Hi, There are some USB drivers which run in userland that will not work until this library is complete. These are currently not part of the FreeBSD distribution. You find them in /usr/ports : grep libusb /usr/ports/INDEX The kernel USB drivers provided under /sys/dev/usb2 do not directly depend on any userland utilities, but rather indirectly through the TTY, KBD, NET ... One exception is the USB mouse driver which depends on moused, and currently have some warnings because moused tries to load the old ums module, which fails. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review [was Re: ...]
Hans Petter Selasky wrote: On Thursday 21 August 2008, Kris Kennaway wrote: Hans Petter Selasky wrote: * How much of the userland support is incomplete or in flux, and what functionality is missing for users of the usb2 code until it is finished? The USB userland library is nearly complete. All it lacks is proper documentation: svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/libusb20 The USB config utility is also starting to become finished. It will be renamed to usbconfig. Currently it is called usbview : svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/usbview So...what functionality is missing for users of the usb2 code until it is finished? Stated even more clearly, what things will users of the USB2 code not be able to do until the above userland code is imported? Seriously, I'm trying to understand this! Hi, There are some USB drivers which run in userland that will not work until this library is complete. These are currently not part of the FreeBSD distribution. You find them in /usr/ports : grep libusb /usr/ports/INDEX The kernel USB drivers provided under /sys/dev/usb2 do not directly depend on any userland utilities, but rather indirectly through the TTY, KBD, NET ... One exception is the USB mouse driver which depends on moused, and currently have some warnings because moused tries to load the old ums module, which fails. OK, now we're approaching half way. The moused thing should be documented somewhere with a workaround (or fix). If the new ums2 module is present before moused is started will it still try to load the old one? Is there another workaround? What about the second thing: usbconfig? Kris ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Video class
BTW; There was/is also a NetBSD GSoC project: http://netbsd-soc.sourceforge.net/projects/uvc/ cheers, Pedro. __ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb4bsd patch review
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : Hans Petter Selasky wrote: : On Thursday 21 August 2008, Kris Kennaway wrote: : Hans Petter Selasky wrote: : On Thursday 21 August 2008, Kris Kennaway wrote: : Hans Petter Selasky wrote: : * How much of the userland support is incomplete or in flux, and what : functionality is missing for users of the usb2 code until it is : finished? : The USB userland library is nearly complete. All it lacks is proper : documentation: : : svn --username anonsvn --password anonsvn \ :checkout svn://svn.turbocat.net/i4b/trunk/libusb20 : : The USB config utility is also starting to become finished. It will be : renamed to usbconfig. Currently it is called usbview : : : svn --username anonsvn --password anonsvn \ :checkout svn://svn.turbocat.net/i4b/trunk/usbview : So...what functionality is missing for users of the usb2 code until it : is finished? : : Stated even more clearly, what things will users of the USB2 code not be : able to do until the above userland code is imported? : : Seriously, I'm trying to understand this! : Hi, : : There are some USB drivers which run in userland that will not work until : this library is complete. These are currently not part of the FreeBSD : distribution. You find them in /usr/ports : : : grep libusb /usr/ports/INDEX : : The kernel USB drivers provided under /sys/dev/usb2 do not directly : depend on any userland utilities, but rather indirectly through the TTY, : KBD, NET ... : : One exception is the USB mouse driver which depends on moused, and : currently have some warnings because moused tries to load the old ums : module, which fails. : OK, now we're approaching half way. The moused thing should be : documented somewhere with a workaround (or fix). If the new ums2 module : is present before moused is started will it still try to load the old : one? Is there another workaround? : : Hi, : : What happens is this: : : 1. devd reports ums0 like before. : 2. moused is started : 3. moused tries to kldload ums : 4. The ums module depens on the usb module which is also tried loaded. : 5. Loading the usb module fails. : 6. moused finally tries to open /dev/ums0 and the mouse works like before. : : ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), class 0/0, rev : 1.10/3.00, addr 3 on usbus3 : ums0: 3 buttons and [XYZ] coordinates : Symlink: ums0 - usb3.3.0.16 : : module_register: module pci/uhci already exists! : Module pci/uhci failed to register: 17 : module_register: module cardbus/uhci already exists! : Module cardbus/uhci failed to register: 17 : module_register: module pci/ohci already exists! : Module pci/ohci failed to register: 17 : module_register: module cardbus/ohci already exists! : Module cardbus/ohci failed to register: 17 : module_register: module pci/ehci already exists! : Module pci/ehci failed to register: 17 : module_register: module cardbus/ehci already exists! : Module cardbus/ehci failed to register: 17 : KLD ums.ko: depends on usb - not available : : OK, so just cosmetic. It kind of sounds like moused is doing the wrong : thing, but this can hopefully be fixed later. : : What about the second thing: usbconfig? : : The USB stack will work fine without usbconfig. Its purpose is mostly to : view the currently attached USB devices, where the USB devices are located : and to select a non-default USB configuration. One thing which might be : missed is to change owner and permission of a USB device, which means you : must be either UID=root or GID=OPERATOR to be able to use USB devices that : create devices under /dev/ . : : OK great, this isn't critical either. I think all of the issues I : raised are agreed upon now! : : Unfortunately since Alfred is going away for 3 weeks it looks like that : is now going to put this on hold for a bit. It's probably a good thing : that the initial import was delayed actually, since he is going to need : to be available for the inevitable followup work after it gets imported, : and leaving 3 days after the planned import would have really hurt that : process. : : Unless someone else comes forward to take over from Alfred, here's what : I recommend as a plan: : : * post the revised diff with the minor changes/bits left out that we : have agreed upon. Users can continue to test this commit candidate : while Alfred is away. : : * When Alfred gets back and has a block of free time, he will proceed : with the import and handle followup commits to fix issues that are : identified. : : * If the commit candidate diff changes in the meantime due to bug : fixes etc, then you should keep the mailing list updated regularly with : a pointer to the latest version of the commit candidate diff. Other new : stuff like the forthcoming userland changes should stay out of this : first diff for now so we don't invalidate things
Re: trying out the new usb stuff ...
On Thursday 21 August 2008, Chuck Robey wrote:
I'm not sure how to change my config to try out the new usb2 code. I saw
where you mentioned the new config lines, but I'm not sure what to do with
the devices I have in my kernel now (I don't use the modules for usb). I
mean, things like usb, ohci, ehci, etc., do you keep them in or change them
(and what's the complete list of required changes, not only the additions?)
Hi Chuck,
1. Remove all the USB modules from the kernel config.
2. Add this to your /boot/loader.conf after installing the patches and
building a new kernel.
usb2_core_load=YES
usb2_controller_load=YES
usb2_input_load=YES
Lastly, are there any changes contemplated in the usb hid code? I'm not
sure if it's my own ineptness, or bugs in the usbhid code, but there are
parts of that libhibhid code that I've never been able to get to work (I
needed to write my own), so I'm really interested if the usbhid stuff is
going to change or not.
Yes, there are some new IOCTLs which might solve some of your problems.
/* Generic HID device */
#define USB_GET_REPORT_DESC _IOR ('U', 21, struct usb2_gen_descriptor)
#define USB_SET_IMMED _IOW ('U', 22, int)
#define USB_GET_REPORT _IOWR('U', 23, struct usb2_gen_descriptor)
#define USB_SET_REPORT _IOW ('U', 24, struct usb2_gen_descriptor)
#define USB_GET_REPORT_ID _IOR ('U', 25, int)
struct usb2_gen_descriptor {
void *ugd_data;
uint16_t ugd_lang_id;
uint16_t ugd_maxlen;
uint16_t ugd_actlen;
uint16_t ugd_offset;
uint8_t ugd_config_index;
uint8_t ugd_string_index;
uint8_t ugd_iface_index;
uint8_t ugd_altif_index;
uint8_t ugd_endpt_index;
uint8_t ugd_report_type;
uint8_t reserved[8];
};
For UHID you only need to initialise ugd_data, ugd_maxlen and
ugd_report_type .
--HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
