From owner-freebsd-hardware@FreeBSD.ORG Fri Nov 21 11:20:03 2003 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D01C16A4CE for ; Fri, 21 Nov 2003 11:20:03 -0800 (PST) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (does-d9b91939.pool.mediaWays.net [217.185.25.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57DFA43FDD for ; Fri, 21 Nov 2003 11:19:34 -0800 (PST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk (NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk [2002:3e50:3ceb:0:200:c0ff:fefc:19aa] (may be forged)) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id hAL0hU706755 verified NO) for ; Fri, 21 Nov 2003 01:43:34 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost)hAL0hDu01322; Fri, 21 Nov 2003 01:43:13 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Fri, 21 Nov 2003 01:43:13 +0100 (CET) Message-Id: <200311210043.hAL0hDu01322@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> X-Authentication-Warning: NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk: beer set sender to bounce@NOSPAM.dyndns.dk using -f References: <200311050441.hA54fhJ54978@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk> From: Barry Bouwsma To: FreeBSD Hardware Wizards Subject: Re: USB camera compatibility question X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2003 19:20:03 -0000 [Drop my (IPv6-only) address if replying; I'll catch the archives] I'm going to do a Bad Thing and follow up to myself, just because I tend to write way too much. And in case this would be useful for the archives or elsewhere... I blabbered mindlessly the following a few weeks back: > I'm wondering if anyone in the southern germany or adjacent border areas > has any experience with the digital camera on offer from the discounter > Aldi-Sued since 22.Okt, and FreeBSD. It's a `Traveller' or something > Does it, or should I be able to expect it to, function as a USB storage > device connected directly to a USB port under FreeBSD? Yes, with a fair amount of kernel hacking. > Or do I have to use some other device to access the memory cards and any > images thereupon? Yes, because so far the images snarfed with my hacks are okay for the first 4096 bytes, thereafter failing to match the perfect images I can download with the `mtools' utilities from a printer cum card slot. There seem to be chunks of NULs present regularly throughout the file. First of all, the device can be attached as a umass device -- I'm using some mid-Sept. source code plus the RELENG_4-USB patches based on recent -current code, fixing what breaks. The device is identified as follows: umass0: vendor 0x0784 product 0x1689, rev 0.01/0.01, addr 2, 8070i (ATAPI) over Bulk-Only The vendor ID is listed in the NetBSD usbdevs source as JENOPTIK. Make of that what you will. The product number is not present, no surprise. The SCSI ID for the camera is as follows: pass1 at umass-sim0 bus 0 target 0 lun 0 pass1: Removable Direct Access SCSI-0 device pass1: 650KB/s transfers A quirk entry is needed in umass.c in order for the device to be created as /dev/da*, without which one sees the following: Creating DISK da1 (da1:umass-sim0:0:0:0): got CAM status 0x4 (da1:umass-sim0:0:0:0): fatal error, failed to attach to device (da1:umass-sim0:0:0:0): lost device (da1:umass-sim0:0:0:0): removing device entry if (UGETW(dd->idVendor) == 0x0784) /* JENOPTIK */ { sc->quirks |= FORCE_SHORT_INQUIRY; } (Whether additional quirks are needed, perhaps to solve the 4096- byte corruption, well, I haven't experimented with that yet) Also, a quirk could be added to scsi_da.c because this device does not care for the SYNCHRONIZE_CACHE command. However, that looks to be more of a shortcoming in the ATAPI transformation, and rather than adding a line like {T_DIRECT, SIP_MEDIA_REMOVABLE, "CAMERA*", "5MP-9A3*", "1.00*"}, /*quirks*/ DA_Q_NO_SYNC_CACHE (The wildcard CAMERA* seems to be needed; the others probably can be made much more generic) instead, I thought I would see if I could get the atapi transformation to ignore sync_cache instead of returning an error and putting out those annoying messages all over my console. I don't suppose the CAM or xpt or whatever layer would know it's talking to an 8070i device and thus automagically apply the NO_SYNC_CACHE quirk... So, with that, I have a modest amount of joy. Save for the corrupted images, at least I can mount the card and get directory listings, and copy the corrupt files at several hundred kB/sec, much faster than the mtools access that gives proper images for those times I care about data integrity, taking minutes rather than seconds. Woohoo. Barry Bouwsma