wacom and x11 and webcamd
i recently decided to check how well the wacom tablets are supported under FreeBSD-x11. This post is mostly a followup to http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010681.html and tries to give extra information on how to address common problems. In short, recent webcamd versions implement a linux module which makes the tablet available as /dev/input/event0 so you don't need any specific usb driver. In turn, xorg uses the wacom_drv.so module to access these events and convert them to a suitable format. I used the webcamd version from Hans' tree svn --username anonsvn --password anonsvn \ checkout svn://svn.turbocat.net/i4b/trunk/ports which is currently at version 3.2.0.1 , and the inputwacom patches at http://people.freebsd.org/~nox/tmp/inputwacom.patch The patch applies cleanly; at build time you should leave the usb support not selected (because uwacom does not compile and probably it is not necessary, either). I also left HAL disabled in building inputwacom, following a comment in the original post. Before running /usr/local/etc/rc.d/wacom onesetup remember to set wacom_porttype="usb" # lowercase, not uppercase) wacom_types="stylus eraser" in /etc/rc.conf and also replace "/dev/event0" with "/dev/input/event0" in /usr/local/etc/rc.d/wacom so that the correct entries are created in xorg.conf The proper sequence of actions is the following: - connect the tablet to the USB port (I tried a recent Bamboo touch and an old Wacom FT-0405 (Volito); both worked). The tablet identifies as a USB mouse and a uhid device. The mouse is possibly picked up by moused, so you should either kill moused on the tablet, or make sure that it is not recognised, or the events from the mouse will interfere with those from wacom_drv - start webcamd (either manually or automatically) . This creates /dev/input/event0 which is accessed by wacom_drv - start the X server. The tablet should be recognised and work in absolute coordinates. I found that by default the table is way too sensitive to pressure, so just approaching the tablet with the pen triggers a button pressure. You can set the threshold with the following user command (within X): xsetwacom --set stylus threshold 200 # range is 0..2047 I think you can also set the value from within xorg.conf Hope this helps... cheers luigi ___ 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: usb2 + scanner HP ScanJet 4300C
On Fri, Dec 12, 2008 at 09:27:27PM +0100, Oliver Fromme wrote: > Hi, > > I've got a HP ScanJet 4300C that seems to be a little bit > stubborn. > ... > Is there anything I can do, except for forgetting about > this scanner alltogether? one option is to put the device IDs in uscanner.c and see if it is recognised. But other than that, i wouldn't waste much time: for 50..80 euro you can get one of the Epson multifunction printer scanners (i have personally tried DX4400 to DX7050) which are well supported and extremely reliable. see http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html cheers luigi ___ 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: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: > On Saturday 05 July 2008, Luigi Rizzo wrote: > > On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: > > > On Friday 04 July 2008, Luigi Rizzo wrote: > > > > On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: > > > > > On Thursday 03 July 2008, Luigi Rizzo wrote: > > > > > > On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: > > > > > > > On Thu, 3 Jul 2008 16:07:19 +0200 > > > > > > > > > > > > > > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > > > > > > There was a discussion back in september about adding > > > > > > > > support for basic CDC tty devices in umodem.c. > > > > > > > > This lets you talk to a number of usb devices built around > > > > > > > > microcontrollers (e.g. Atmel), and puts us on par with > > > > > > > > Linux and Windows in terms of supporting these devices. > > > > > > > > > > > > > > > > Because this simply requires the small patch below to the > > > > > > > > probe/attach routine, so if there are no objections I plan to > > > > > > > > add this to the system (CURRENT then RELENG_7 and RELENG_6) in > > > > > > > > the next few days. > > > > > > > > > > What about flow control? Is flow control required for these devices? > > > > > > > > the ones I am talking about don't implement any form of flow control. > > > > I suppose they would otherwise match the previous check. > > > > > > > > luigi > > > > > > I mean, are you going to upload firmware through these interfaces? > > > > the OS only know about bytes. > > > > are firmware, software, data or random noise. > > if you want to know whether the sam7 uploader works, yes it does. > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > Yes, but you know that umodem can drop data, if the buffers overflow ? yes i know. and there is another million things that can go wrong. bye luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: may I commit this small umodem patch ?
On Sat, Jul 05, 2008 at 12:28:47AM +0200, Hans Petter Selasky wrote: > On Friday 04 July 2008, Luigi Rizzo wrote: > > On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: > > > On Thursday 03 July 2008, Luigi Rizzo wrote: > > > > On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: > > > > > On Thu, 3 Jul 2008 16:07:19 +0200 > > > > > > > > > > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > > > > There was a discussion back in september about adding > > > > > > support for basic CDC tty devices in umodem.c. > > > > > > This lets you talk to a number of usb devices built around > > > > > > microcontrollers (e.g. Atmel), and puts us on par with > > > > > > Linux and Windows in terms of supporting these devices. > > > > > > > > > > > > Because this simply requires the small patch below to the > > > > > > probe/attach routine, so if there are no objections I plan to add > > > > > > this to the system (CURRENT then RELENG_7 and RELENG_6) in the next > > > > > > few days. > > > > > > What about flow control? Is flow control required for these devices? > > > > the ones I am talking about don't implement any form of flow control. > > I suppose they would otherwise match the previous check. > > > > luigi > > I mean, are you going to upload firmware through these interfaces? the OS only know about bytes. are firmware, software, data or random noise. if you want to know whether the sam7 uploader works, yes it does. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: may I commit this small umodem patch ?
On Fri, Jul 04, 2008 at 11:33:15PM +0200, Hans Petter Selasky wrote: > On Thursday 03 July 2008, Luigi Rizzo wrote: > > On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: > > > On Thu, 3 Jul 2008 16:07:19 +0200 > > > > > > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > > There was a discussion back in september about adding > > > > support for basic CDC tty devices in umodem.c. > > > > This lets you talk to a number of usb devices built around > > > > microcontrollers (e.g. Atmel), and puts us on par with > > > > Linux and Windows in terms of supporting these devices. > > > > > > > > Because this simply requires the small patch below to the > > > > probe/attach routine, so if there are no objections I plan to add > > > > this to the system (CURRENT then RELENG_7 and RELENG_6) in the next > > > > few days. > > What about flow control? Is flow control required for these devices? the ones I am talking about don't implement any form of flow control. I suppose they would otherwise match the previous check. luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: may I commit this small umodem patch ?
On Thu, Jul 03, 2008 at 05:07:00PM +0200, Gary Jennejohn wrote: > On Thu, 3 Jul 2008 16:07:19 +0200 > Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > There was a discussion back in september about adding > > support for basic CDC tty devices in umodem.c. > > This lets you talk to a number of usb devices built around > > microcontrollers (e.g. Atmel), and puts us on par with > > Linux and Windows in terms of supporting these devices. > > > > Because this simply requires the small patch below to the > > probe/attach routine, so if there are no objections I plan to add > > this to the system (CURRENT then RELENG_7 and RELENG_6) in the next > > few days. > > > > > Index: umodem.c > > > === > > > RCS file: /home/ncvs/src/sys/dev/usb/umodem.c,v > > > retrieving revision 1.57 > > > diff -u -r1.57 umodem.c > > > --- umodem.c 31 Jan 2005 13:58:10 - 1.57 > > > +++ umodem.c 20 Aug 2006 17:05:34 - > > > @@ -256,6 +260,15 @@ > > > id->bInterfaceProtocol == UIPROTO_CDC_AT) > > > ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; > > > > > > +#if 1 > > > + if (ret == UMATCH_NONE && > > > + id->bInterfaceClass == UICLASS_CDC_DATA && > > > + id->bInterfaceSubClass == UISUBCLASS_DATA && > > > + id->bInterfaceProtocol == 0x00) > > > + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; > > > + return ret; > > > +#endif > > > + > > > if (ret == UMATCH_NONE) > > > return (ret); > > > > Is there any reason to keep the #if 1 ... #endif? And why not just > directly return UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO rather than > assigning it to ret first? in fact there are also missing braces that need to be added -- as is, the code after the #endif is completely disabled. thanks for the comment, but don't worry, the commit will be done the right way. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
may I commit this small umodem patch ?
There was a discussion back in september about adding support for basic CDC tty devices in umodem.c. This lets you talk to a number of usb devices built around microcontrollers (e.g. Atmel), and puts us on par with Linux and Windows in terms of supporting these devices. Because this simply requires the small patch below to the probe/attach routine, so if there are no objections I plan to add this to the system (CURRENT then RELENG_7 and RELENG_6) in the next few days. > Index: umodem.c > === > RCS file: /home/ncvs/src/sys/dev/usb/umodem.c,v > retrieving revision 1.57 > diff -u -r1.57 umodem.c > --- umodem.c 31 Jan 2005 13:58:10 - 1.57 > +++ umodem.c 20 Aug 2006 17:05:34 - > @@ -256,6 +260,15 @@ > id->bInterfaceProtocol == UIPROTO_CDC_AT) > ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; > > +#if 1 > + if (ret == UMATCH_NONE && > + id->bInterfaceClass == UICLASS_CDC_DATA && > + id->bInterfaceSubClass == UISUBCLASS_DATA && > + id->bInterfaceProtocol == 0x00) > + ret = UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO; > + return ret; > +#endif > + > if (ret == UMATCH_NONE) > return (ret); cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD support for the Epson CX5000/DX5000/DX5050 printer-scanner
There was already a thread on the topic as http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/107665 however, since i just bought a DX-5050 and have it fully working on FreeBSD (which is usually rare with USB devices), i thought it was good to summarise and detail all the steps needed to configure the device: http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html I hope you'll find the info useful. I am quite happy with the device so far, and it is extremely low cost. For the records - the CX5000 and DX5050 seem to be the same thing, one for the US market, the other one for the european market. The DX5000 is marginally slower (24ppm vs 26ppm), but no idea if it is because of faster CPU or faster mechanics. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP
The following reply was made to PR usb/107665; it has been noted by GNATS. From: Luigi Rizzo <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: usb/107665: [usb] [patch] uscanner support for epson stylus DX5050 MFP Date: Tue, 28 Aug 2007 08:33:11 -0700 just bought one of these devices (DX5050) and made it work on FreeBSD with a partly modified patch. If others want to try it, the full details (including SANE configuration) are at http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html (includes a kernel patch, currently at http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.20070828.diffs but the url might change as i work on it). It would be nice to know other stories. Have not tried the printer yet, but the scanner does work, and the cardreader works as well. For a 90 Euro device, not bad! cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux USB emulation layer now committed to my new USB stack for FreeBSD
On Fri, May 18, 2007 at 01:04:17PM +0200, Hans Petter Selasky wrote: > Hi, > > If you are interested, the files are: > > http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c > http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h > > It is almost finished now. > > And it is not very much code. > > Also I have a preliminary patch for Luigi's webcam driver! But it does not > compile yet. > > NOTE: Before you use a Linux USB endpoint you have to call: > > usb_setup_endpoint() with the buffer size you want. For isoc transfers the > buffer size is ignored. Just set a dummy value. > > Do you have time to fix the rest Luigi? not now, sorry. But seeing the patch that you attach, let me kindly comment once again (i have already told you multiple time) that this approach of ignoring compatibility with existing code (usb stack/api/emulation layer, linux device drivers) and not commenting code at all is really a showstopper for getting your code tested and/or accepted. E.g. see usb_compat_linux.c in the url above - basically the only comment is the copyright - way too little for anyone to understand what is done there. usb_compat_linux.h is just a copy of stuff in the existing linux usb emulation, _but_ without any comments at all (and there was a lot of them in the existing code). Undocumented code is almost useless for us, and nobody has the time to reverse engineer your code and document its architecture. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: FreeBSD webcam driver (and more)
On Mon, Feb 05, 2007 at 04:33:15PM -0800, Kevin Downey wrote: > On 1/30/07, Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > I think I reached a first interesting milestone in my project > > to build an emulation layer to compile linux device drivers on FreeBSD. > > > > I managed to build a FreeBSD port of the linux 'gspca' driver (which claims > > to support 228 different webcams) with basically no modifications to > > the original source. So it would be good if someone could give a try > > to this code, either on -current or -stable, keeping in mind that > > this is NOT PRODUCTION READY yet. > > > > More details on how the thing works are at > > > > http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html > > > > together of course with source code, and even binary modules > > for FreeBSD 6.2. > > Basically I would like to know how it builds/works on -current, > > have reports on cameras that work with it and those which don't > > and so on. The driver supports the Video4Linux API so it should > > be useful for a variety of applications. > > very cool. But how do you know if it works? what applications can be a good idea would be to read the 'Trying the drivers' section of the page above and do what it says there :) As for the list of application i cannot make one because i have no idea which ones apart from ekiga (which requires a patch on FreeBSD) and the pwcview mentioned in the page. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: FreeBSD webcam driver (and more)
someone (in Bcc) asked me the following question and i think the explaination is of general interest. Am cross-posting the usb list as maybe people there can confirm this or give more details. On Sat, Feb 03, 2007 at 01:00:31AM -0500, ... wrote: > On 2/2/07, Luigi Rizzo <[EMAIL PROTECTED]> wrote: > > > > On Sat, Feb 03, 2007 at 12:32:17AM +, Florent Thoumie wrote: > > > usb1: *** WARNING: opening low/full speed device, this does not work > > yet. > > > > this is a [annoying] problem with the freebsd drivers, not with gspca. > > > > try connect the camera directly to the ports on your usb > > controller instead of the external hub. > > > What is the technical problem that makes this happen and what is the order > of effort required to fix it. I have also come up against this and would > take a stab at it if it were within my reach. The message comes from ehci.c and is not very informative. >From what i read in the ehci.c source, there is no support at all for ISOChronous transfers in that driver. In fact, the above message is triggered in an early stage of the _open() routine, when you ask for a low or full speed ISOC transfer; if you go past it because you request a high speed isoc transfer, you hit another error later in the same routine because some functions are not implemented. I have absolutely no idea how much time would take to fix this, have never looked at the specs of the controllers. Now if you wonder why connecting directly to the main board (instead of going through a hub) works, i think the reason is the following (hope i am not spreading misinformation): >From what i have read, on the mainboard there are two controllers (ehci and uhci) connected in parallel, i.e. really sharing the wires, and there is some form of arbitration so that USB2 devices (which can do high speed requests) talk to ehci, whereas USB1 devices talk to uhci. If you have a USB2 hub in the middle, chances are that the hub does connects to ehci hiding the real nature of devices downstream. Maybe (not sure) that a workaround could be to put a USB1 hub in the middle. If you can find one, they should cost close to nothing these days. Unfortunately i cannot try it because i only have a USB2 hub here. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: FreeBSD webcam driver (and more)
On Sat, Feb 03, 2007 at 12:32:17AM +, Florent Thoumie wrote: > Hey Luigi, > > I have a Creative Webcam Instant: > > usb_spca5xx_init: gspca driver 01.00.12 registered > ldev_attach: sc at 0xc8ec1b00, l_u_d at 0xc8ec1b64 > --- allocate 272 bytes gives 0xc6e14800 > interface 0 has 8 altsettings (cur 0) > gspca_attach_bridge: USB SPCA5XX camera found.(ZC3XX) > spca5xx_probe: [spca5xx_probe:3976] Camera type JPEG > zc3xx_config: [zc3xx_config:515] Sensor ID:10 > zc3xx_config: [zc3xx_config:587] Find Sensor PAS106 > spca5xx_getcapability: [spca5xx_getcapability:1182] maxw 352 maxh 288 > minw 176 minh 144 > 279074705 [ 878] video_register_device: to be fixed but ok for now > ldev0: Creative Labs WebCam Instant, rev 1.10/1.00, addr 3 > > Trying to use camorama gives the following error: > > 279277285 [ 842] video_devdata: not complete but ok for now > gspca_set_isoc_ep: [gspca_set_isoc_ep:874] ISO EndPoint found 0x81 > AlternateSet 7 > usb1: *** WARNING: opening low/full speed device, this does not work yet. this is a [annoying] problem with the freebsd drivers, not with gspca. try connect the camera directly to the ports on your usb controller instead of the external hub. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Testers: FreeBSD webcam driver (and more)
On Wed, Jan 31, 2007 at 01:23:05PM +0100, Rene Ladan wrote: > Luigi Rizzo schreef: > > I think I reached a first interesting milestone in my project > > to build an emulation layer to compile linux device drivers on FreeBSD. > > > > I managed to build a FreeBSD port of the linux 'gspca' driver (which claims > > to support 228 different webcams) with basically no modifications to > > the original source. So it would be good if someone could give a try > > to this code, either on -current or -stable, keeping in mind that > > this is NOT PRODUCTION READY yet. > > > [...] > > together of course with source code, and even binary modules > > for FreeBSD 6.2. > > Basically I would like to know how it builds/works on -current, > > have reports on cameras that work with it and those which don't > > and so on. > [...] > > The binary modules also load on CURRENT i386 as of 2007/01/30, > dmesg shows > > > usb_spca5xx_init: gspca driver 01.00.12 registered > > but it doesn't recognize the Xbox360 webcam (vendor 0x45e, product 0x294) : > > > spcaDetectCamera called vend 0x45e prod 0x294 p 0xc7a8d334 > > spcaCameraDetect failed > > neither does it recognize the builtin USB 2.0 webcam of my Asus A6JE > laptop (Syntek, product 0xa311), at least no /dev/video* show up. ok thanks for the work anyways... i see there is a project on sourceforge for this one but probably not complete yet http://syntekdriver.sourceforge.net/index.php?mode=documentation while i haven't found anything on the web for the xbox thing. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Call for Testers: FreeBSD webcam driver (and more)
I think I reached a first interesting milestone in my project to build an emulation layer to compile linux device drivers on FreeBSD. I managed to build a FreeBSD port of the linux 'gspca' driver (which claims to support 228 different webcams) with basically no modifications to the original source. So it would be good if someone could give a try to this code, either on -current or -stable, keeping in mind that this is NOT PRODUCTION READY yet. More details on how the thing works are at http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html together of course with source code, and even binary modules for FreeBSD 6.2. Basically I would like to know how it builds/works on -current, have reports on cameras that work with it and those which don't and so on. The driver supports the Video4Linux API so it should be useful for a variety of applications. cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
new usb stack (was Re: FreeBSD Status Report Fourth Quarter 2006)
[i avoid the cross-post to hackers as my reply mostly affects -current and -usb. hope i don't miss anyone interested. I am also Bcc-ing a few people who might have something to say on the subject] On Tue, Jan 16, 2007 at 11:52:37PM +0100, Max Laier wrote: ... > FreeBSD Status Report thanks all for the long and interesting report, i see lot of stuff going on. I have a couple of usb-related comments: > New USB Stack > >URL: >http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects >/usb/src/sys/dev/usb >URL: http://www.turbocat.net/~hselasky/usb4bsd > >Contact: Hans Petter Sirevaag Selasky <[EMAIL PROTECTED]> > >During the last three months there has not been so much activity in >the USB project. Some regression issues have been reported and fixed. >Bernd Walter reports that he has got the new USB stack working on ARM >processors with some minor tweaks. Markus Brueffer reports that he is >working on the USB HID parser and support. A current issue with the >new USB stack is that the EHCI driver does not work on the Sparc64 >architecture. If someone has got a Sparc64 with FreeBSD 7-CURRENT on >and can lend the USB project the root password, a serial console and a >USB test device, for example a USB memory stick, that would be much >appreciated. Another unresolved issue is that the ural(4) USB device >driver does not always work. This is currently being worked on. > >If you want to test the new USB stack, check out the USB perforce tree >or download the SVN version of the USB driver from my USB homepage. At >the moment the tarballs are a little out of date. > >Ideas and comments with regard to the new USB API are welcome at >freebsd-usb@FreeBSD.org . I just happen to have spent some time on the USB stack trying to put together support for some webcams i have. Apart from the details on this specific work, which i started summarising at http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html there are a few things that i would like to say/ask: 1. Migration strategy to the new usb stack One of the reasons to move to the new usb stack that Hans mentions above, is the lack of high speed isochronous support in the 'old' usb stack (i.e. the one in HEAD and RELENG_6 and below) I am particularly concerned about because it has to do with camera support. One issue with the new stack, however, is the different kernel API which is not backward compatible, and, as i discussed with Hans at length, this could be a significant obstacle to its adoption as it basically cuts support for third party drivers. The obvious solution to this problem is building an emulation layer on top of the new stack to offer a backward compatible API to old style drivers. This would serve both as a tool to support re-building of old-style drivers, and as an indirect source of documentation for adapting drivers to the new style. Building this emulation layer poses some difficulties, but in a relatively long phone call with Hans tonight we probably came up with a reasonable plan to solve the locking issues that existed in his previous implementation of the compatibility layer (removed some time ago because of these locking issues, you can see some detail in perforce http://perforce.freebsd.org/changeView.cgi?CH=107765 ). I hope Hans will follow up with more details, but i am confident that this approach will provide us with a suitable upgrade path that does not cost us regressions. 2. Linux compatibility layer. The discussion, as well as my recent work on webcams and other work from Raaf on DVB drivers (see http://raaf.atspace.org/dvbusb/index.html; and Raaf is in Bcc so he may comment if he likes) raised another issue, namely a linux compatibility layer. The linux community has developed a relatively large set of drivers for USB devices, for many sort of devices which we do not support at the moment e.g. webcams, DVB receivers, even 802.11 cards. Because a lot of these driver are built by reverse-engineering, the code tends to be on the obfuscated side, and doing a 'clueful' rewrite is typically not a viable option unless one has plenty of time to dedicate to the task. What one ends up doing is, instead, is a mechanical conversion, #ifdef'ing out the glue module and device hooks that gets replaced with FreeBSD equivalents, and then trying to translate the linux kernel API into more-or-less equivalent FreeBSD code. As i said this is a mechanical conversion, and it would be a tremendous help to have a linux-compatibility layer (library + macros) to support this work at least partially. More than comments like "yeah it would be great" i am wondering if there is any work around already done on this area. Surely people who ported linux drivers to FreeBSD have some clue, and maybe
Re: any way to detect usb detached from a device driver ?
On Wed, Jan 10, 2007 at 11:34:54PM +0100, Hans Petter Selasky wrote:
> Hi Luigi,
>
> On Wednesday 10 January 2007 13:46, Luigi Rizzo wrote:
> > On Tue, Jan 09, 2007 at 09:37:21PM +0100, Hans Petter Selasky wrote:
> > > On Tuesday 09 January 2007 17:34, Luigi Rizzo wrote:
>
> [...]
>
> >
> > sorry but i cannot figure out how the above helps in the
> > detach case e.g. when a process is waiting for an ioctl
> > or read operation to complete - can you give more details ?
>
> "usb_cdev" is an abstraction layer for pluggable devices that wants to create
> a device under /dev, to read/write some data. It does not help unless you
> port your PWC driver over to using the "usb_cdev" system, instead of devfs
> directly.
>
> >
> > In my case, i did the following:
> >
> > USB_DETACH(pwc)
> > {
> > USB_DETACH_START(pwc, sc);
> > again:
> > if(sc->sc_videopipe != NULL) {
> > usbd_abort_pipe(sc->sc_videopipe);
> > usbd_close_pipe(sc->sc_videopipe);
> > sc->sc_videopipe = NULL;
> > }
> > sc->error_status = EPIPE;
> > if(sc->vopen) {
> > if(sc->state & PWC_ASLEEP)
> > wakeup(sc);
> > if(sc->state & PWC_POLL) {
> > sc->state &= ~PWC_POLL;
> > selwakeuppri(&sc->rsel,PZERO);
> > }
> > device_printf(sc->sc_dev, "Disconnected while webcam is in
> > use!\n"); usb_detach_wait(USBDEV(sc->sc_dev));
> > goto again;
> > }
> >
> > if(sc->sc_dev_t != NULL)
> > destroy_dev(sc->sc_dev_t);
> >
> > mtx_destroy(&sc->ptrlock);
> > pwc_free_buffers(sc,1);
> >
> > usbd_add_drv_event(USB_EVENT_DRIVER_DETACH,sc->udev,USBDEV(sc->sc_dev));
> > return 0;
> > }
> >
> > and at the end of the close routine
> >
> > ...
> > sc->vopen = 0;
> > usb_detach_wakeup(USBDEV(sc->sc_dev));
> > }
> >
> > so the USB_DETACH() will wake up any process blocked,
> > the sc->error_status = EPIPE; should force an error and
> > cause the process to call close().
> >
> > The down side is that you are still in the hands
> > of the process to let the detach complete. Ideally one
> > would just flag the descriptor as 'detach_pending'
> > and get rid of it at the end of the close(), while the
> > DETACH() could terminate without doing the free()
>
> What I do is to ensure that no thread is executing in any of the devfs
> callbacks. This might imply some waiting. Then I simply destroy the device
> using destroy_dev(). This way you don't have to wait for the userland process
> to call close(), which might not happen right away.
ok... so if i understand well, once all processes have exited
the callbacks you destroy, which means that afterwards they will
not be able to invoke the callbacks anymore (nor crash the machine)
even if they retain a handle ?
cheers
luigi
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: any way to detect usb detached from a device driver ?
On Tue, Jan 09, 2007 at 09:37:21PM +0100, Hans Petter Selasky wrote:
> On Tuesday 09 January 2007 17:34, Luigi Rizzo wrote:
> > [sorry for the repost, not sure it went through]
> >
> > On Tue, Jan 09, 2007 at 08:16:29AM -0800, Luigi Rizzo wrote:
> > I am modifying a kernel device driver for webcams
> > (see http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html)
> > packing together various projects around, and i was wondering
> > how to handle the situation of a device being
> > detached while in use.
>
> If you look at the my USB driver for FreeBSD,
> http://www.turbocat.net/~hselasky/usb4bsd , there has been created a new
> device system, usb_cdev, with that goal in mind that you should not have to
> worry about detaching devices, hence this is somewhat complicated:
>
> http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_cdev.c
>
> For example, have a look a the new URIO driver:
>
> http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/urio.c
sorry but i cannot figure out how the above helps in the
detach case e.g. when a process is waiting for an ioctl
or read operation to complete - can you give more details ?
In my case, i did the following:
USB_DETACH(pwc)
{
USB_DETACH_START(pwc, sc);
again:
if(sc->sc_videopipe != NULL) {
usbd_abort_pipe(sc->sc_videopipe);
usbd_close_pipe(sc->sc_videopipe);
sc->sc_videopipe = NULL;
}
sc->error_status = EPIPE;
if(sc->vopen) {
if(sc->state & PWC_ASLEEP)
wakeup(sc);
if(sc->state & PWC_POLL) {
sc->state &= ~PWC_POLL;
selwakeuppri(&sc->rsel,PZERO);
}
device_printf(sc->sc_dev, "Disconnected while webcam is in
use!\n");
usb_detach_wait(USBDEV(sc->sc_dev));
goto again;
}
if(sc->sc_dev_t != NULL)
destroy_dev(sc->sc_dev_t);
mtx_destroy(&sc->ptrlock);
pwc_free_buffers(sc,1);
usbd_add_drv_event(USB_EVENT_DRIVER_DETACH,sc->udev,USBDEV(sc->sc_dev));
return 0;
}
and at the end of the close routine
...
sc->vopen = 0;
usb_detach_wakeup(USBDEV(sc->sc_dev));
}
so the USB_DETACH() will wake up any process blocked,
the sc->error_status = EPIPE; should force an error and
cause the process to call close().
The down side is that you are still in the hands
of the process to let the detach complete. Ideally one
would just flag the descriptor as 'detach_pending'
and get rid of it at the end of the close(), while the
DETACH() could terminate without doing the free()
cheers
luigi
> >
> > Right now the code (from ports/multimedia/pwcbsd) detects
> > that the device is in use while the driver-specific USB_DETACH
> > routine is called, however then it goes on without doing
> > anything.
>
> Very bad!
>
> >
> > In another driver in the dree (urio.c) i see the driver
> > calls usb_detach_wait() to wait up to 60s for the
> > drivers to complete. However that function is not documented
> > and used a bit inconsistently in the rest of /sys/dev/usb
> >
>
> --HPS
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
any way to detect usb detached from a device driver ?
I am modifying a kernel device driver for webcams (see http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html) packing together various projects around, and i was wondering how to handle the situation of a device being detached while in use. Right now the code (from ports/multimedia/pwcbsd) detects that the device is in use while the driver-specific USB_DETACH routine is called, however then it goes on without doing anything. In another driver in the dree (urio.c) i see the driver calls usb_detach_wait() to wait up to 60s for the drivers to complete. However that function is not documented and used a bit inconsistently in the rest of /sys/dev/usb Any suggestions ? cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
any way to detect usb detached from a device driver ?
[sorry for the repost, not sure it went through] On Tue, Jan 09, 2007 at 08:16:29AM -0800, Luigi Rizzo wrote: I am modifying a kernel device driver for webcams (see http://info.iet.unipi.it/~luigi/FreeBSD/usb-cameras.html) packing together various projects around, and i was wondering how to handle the situation of a device being detached while in use. Right now the code (from ports/multimedia/pwcbsd) detects that the device is in use while the driver-specific USB_DETACH routine is called, however then it goes on without doing anything. In another driver in the dree (urio.c) i see the driver calls usb_detach_wait() to wait up to 60s for the drivers to complete. However that function is not documented and used a bit inconsistently in the rest of /sys/dev/usb Any suggestions ? cheers luigi ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[EMAIL PROTECTED]"
