Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Tue, Jan 15, 2008 at 11:06:21AM +0100, Matthias Schmidt wrote:
* Francois Tigeot wrote:
I recently upgraded a machine from Dragonfly 1.10.1 to a recent
1.11.0-DEVELOPMENT (as of today).
An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
unrecognized. Pluging and unpluging the USB cord doesn't result in any
kernel message visible in dmesg.
According to the sources we have an entry for your model:
{{ USB_DEVICE(0x04b8, 0x010b) }, 0 }, /* Perfection 1240U/1240Photo */
I'm currently preparing a mass update of USB quirks and it seems like
the vendor ID of Epson has changed. The new entry from FreeBSD device
ID list looks like this:
{{ USB_DEVICE(0x03f8, 0x010b) }, 0 }, /* Epson Perfection 1240U / */
Note the difference between 0x04b8 and 0x03f8. To check that I'm not
wrong, you could change the ID in the uscanner source, recompile the
module, reload it and check again if the scanner is detected:
I tried it and it didn't change anything: no kernel messages either.
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original - nothing
- patched - nothing
Uscanner in kernel:
- original - some kernel messages appear at startup
# dmesg | grep uscanner
uscanner0: EPSON Perfection1240, class 255/255, rev 1.00/1.04, addr 2
on uhub0
uscanner0: at uhub0 port 2 (addr 2) disconnected
uscanner0: detached
- patched - some messages about ugen0
ugen0: at uhub0 port 2 (addr 2) disconnected
ugen0: detached
There's definitely something fishy going there.
--
Francois Tigeot
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original - nothing - patched - nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. That sucks. We should do that, or at least operate on the previously detected devices. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original - nothing - patched - nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. That sucks. We should do that, or at least operate on the previously detected devices. I think USB devices are different than PCI/cardbus devices; Unrecognized devices are taken by ugen. Best Regards, sephe -- Live Free or Die
Re: cvsup
On Wed, Jan 16, 2008 at 02:35:48AM +, Vincent Stemen wrote: I am not clear how to access it. Try something like the attached script. Joerg update.sh Description: Bourne shell script
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
Sepherosa Ziehau wrote: On Jan 16, 2008 8:14 PM, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original - nothing - patched - nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. That sucks. We should do that, or at least operate on the previously detected devices. I think USB devices are different than PCI/cardbus devices; Unrecognized devices are taken by ugen. Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
USB stack (was: USB scanner unrecognized ...)
Simon 'corecode' Schubert wrote: Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? There is a lot of things that suck in USB stack all BSD's are using at the moment. This particular one is one of smallest ones I worry about ;). There is a light though. There is a new USB stack known as HPS or usb4bsd under development in FreeBSD. This particular problem is already resolved there as well. Also two biggest problems with current stack - sucking isochronous transfer support and sucking ugen. See these for details: http://www.turbocat.net/~hselasky/usb4bsd/ http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb Volunteers to port needed ;P. -- Hasso
Re: USB stack
Hasso Tepper wrote: Simon 'corecode' Schubert wrote: Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? There is a lot of things that suck in USB stack all BSD's are using at the moment. This particular one is one of smallest ones I worry about ;). There is a light though. There is a new USB stack known as HPS or usb4bsd under development in FreeBSD. This particular problem is already resolved there as well. Also two biggest problems with current stack - sucking isochronous transfer support and sucking ugen. See these for details: http://www.turbocat.net/~hselasky/usb4bsd/ http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/usb/src/sys/dev/usb Volunteers to port needed ;P. Here is a just-discovered oddity to also look for - though I haven't tested it on a 'real' *BSD yet. OS X 10.3.9 PowerBook 17 G4 - USB external kbd. -- If directly attached to the PowerBook, kbd works when coming out of 'sleep'. -- If kbd is attached via an unpowered USB hub, it is ignored when coming out of 'sleep', and has to be unplugged/replugged (either kbd-to-hub or the hub-to-PowerBook. This apparently relates to powering-down USB when sleeping, but I cannot fathom why there should be the difference exhibited once it awakens. Anyone able to test for that on DFLY? Bill
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Wed, Jan 16, 2008 at 12:45:49PM +0200, Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original - nothing - patched - nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. Ok. I'm not sure I did that with standalone modules. Uscanner in kernel: - original - some kernel messages appear at startup # dmesg | grep uscanner uscanner0: EPSON Perfection1240, class 255/255, rev 1.00/1.04, addr 2 on uhub0 uscanner0: at uhub0 port 2 (addr 2) disconnected uscanner0: detached It's a disconnect message only. - patched - some messages about ugen0 ugen0: at uhub0 port 2 (addr 2) disconnected ugen0: detached It's a disconnect message again only. And it shows that there is no need for patch. Show me the full dmesg with verbose booting, please. I have put a dmesg dump here (uscanner in kernel) : http://www.wolfpond.org/dmesg-dfly-1.11-verbose.txt I have disconnected and reconnected the scanner just after dumping this file. There were only this additional messages: uscanner0: at uhub0 port 2 (addr 2) disconnected uscanner: ops removed uscanner0: detached -- Francois Tigeot
Re: USB stack (was: USB scanner unrecognized ...)
On Wed, 16 Jan 2008 16:20:42 +0200, Hasso Tepper wrote: Simon 'corecode' Schubert wrote: Then devices should be probed and if there is a better match than ugen and if the ugen device is not open, it should be detached from ugen and attached to the new driver. Do you think this would be possible? There is a lot of things that suck in USB stack all BSD's are using at the moment. This particular one is one of smallest ones I worry about ;). There is a light though. There is a new USB stack known as HPS or usb4bsd under development in FreeBSD. This particular problem is already resolved there as well. Also two biggest problems with current stack - sucking isochronous transfer support and sucking ugen. See these for details: http://www.turbocat.net/~hselasky/usb4bsd/ http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/ usb/src/sys/dev/usb Volunteers to port needed ;P. See here: http://lists.freebsd.org/pipermail/freebsd-current/2008-January/081682.html Cheers, Mezz
