Chris Cheney wrote:
>
> I decided to try writing a usb camera driver and was wondering if someone could
> give me a few pointers. So far I have it registering the device. I will need
> to add procfs, v4l, and usb functions, does anyone have suggestions on examples
> to read? I have read over t
I decided to try writing a usb camera driver and was wondering if someone could
give me a few pointers. So far I have it registering the device. I will need
to add procfs, v4l, and usb functions, does anyone have suggestions on examples
to read? I have read over the programming guide dated 2000
Matthew Dharm wrote:
>> * mount -r -n /dev/sda1 /mnt/cf
>> START_STOP - start
>
>
> Here is where we need to change the behavior. Right here we need to fail
> the command with the right sense data -- at least, that seems to work
> correctly for other devices. Th
Followups on [EMAIL PROTECTED] please ...
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Hi...
Looking at the Linux USB code (2.4.3) and I wonder why I dont have to acquire
any locks to access the usb_device structs.
When the device is disconnected in usb_disconnect() the usb_device struct is
freed, but no one prevents code that already has a pointer to it to access
it. And usb_h
On Tue, Apr 10, 2001, Sancho Dauskardt <[EMAIL PROTECTED]> wrote:
> I had major performance problems reading the SSFDC mapping table: that
> involed to usb_stor_bulk_msg() for each of the 4096 blocks and took around
> 17 sek (and only around 6 sek same device under Win98 ).. I guessed that
> th
I call this the "turn time" problem.. I've known about it for a while, and
it's much bigger than just this.
I've been waiting for URB queuing to be done and stable (and for more time
and broadband internet service) before I look at this -- but I consider it
a future enhancement, which is less imp
On Tue, Apr 10, 2001 at 09:13:05PM +0200, Sancho Dauskardt wrote:
>
> > > What happens when swapping different size CompactFlash cards ?
> >
> >It appears that, if a TEST_UNIT_READY fails with the right sense data to
> >indicate a media-change, the disk is re-validated. But don't quote me on
> >
I had major performance problems reading the SSFDC mapping table: that
involed to usb_stor_bulk_msg() for each of the 4096 blocks and took around
17 sek (and only around 6 sek same device under Win98 ).. I guessed that
this could possibly be a schedluing issue, and tried following:
master_XXX
> > What happens when swapping different size CompactFlash cards ?
>
>It appears that, if a TEST_UNIT_READY fails with the right sense data to
>indicate a media-change, the disk is re-validated. But don't quote me on
>that...
Sounds good, but in a mount,umount,mount sequence only one TEST_UNIT_
On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
>
> I did notice a very thin line at the bottom of the frame and at the right.
> I'll do some more
> adjust with the h v offsets. But its absolutely acceptable.
>
>
> #if 0
> #endif
>
> I noticed that there is an if statement that was not
On Tue, Apr 10, 2001 at 04:57:51PM +0200, Sancho Dauskardt wrote:
> So any ideas of how we can force the BLKRRPART ioctl() or sd_init_onedisk()
> with each mount ?
>
> What happens when swapping different size CompactFlash cards ?
It appears that, if a TEST_UNIT_READY fails with the right sense
In case folks here are unaware, RedHat has been hacking
the hotplug srpm releases here for their rawhide releases
(and I assume their upcoming RH 7.1 release) doing such things
as removing the rc scripts from hotplug. On my linuxppc (running
Linux 2.4.4pre1, glibc 2.2.3 and the rawhide srpms),
I noticed that there is an if statement that was not in the older version.
The if statement contains if 0 to initialize int char[].
Opppsss The if statement was in the older version and not in the
newer version.
My mistake.Maybe I'll add the if statement to the new version and
see if
Heheh I noticed...
Jörg Heckenbach <[EMAIL PROTECTED]> on 04/10/2001 10:37:20 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: Dwaine Garden/ISD/WCBO)
Subject: Re: [linux-usb-devel] New Device added to USBVISION code
> Maybe we can delete the green lin
I did notice a very thin line at the bottom of the frame and at the right.
I'll do some more
adjust with the h v offsets. But its absolutely acceptable.
#if 0
static const unsigned char init[] = {
0x00, 0x00,/* 00 - ID byte */
0x01, 0x00,/* 01 - reserved
>
>Re-reading the mapping:
>
>That's a problem. I'm not familiar enough with the way SCSI works to know
>how to tell it that the media changed. And if it knows that the media
>changed, will it get the capacity again? If no-one knows the answer to
>this off-hand, I'll read the source and find o
> Maybe we can delete the green line by increasing the h-offset in
> usbvision_set_output.
Sorry. usbvision_set_input of course.
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-deve
Hi Dwaine,
the picture looks good. I'll take the values from your site.
[EMAIL PROTECTED] wrote:
>
> I have better input values for NTSC video. Also, I have identified a problem
> in the saa7111-new that seems to result in no colour.
Give me some time to check my last changes in saa7111-new
> > What "proper alignment"? None is mentioned in any
> > part of the linux/Documentation/DMA-mapping.txt ...
>
> Yes - in fact there are no requirements at all mentioned there wrt. to
> the address to be mapped by pci_map_single(). ...
Or for other use with pci DMA; pci_map_single is only one
> > > I solved a problem with the pci_alloc_consistent function for my
> > > architecture. Now the pci_alloc_consistent function allocates uncachable
> > > memory (from a region starting from b700 address as you can see from
> > > the following debug messages pci_alloc_consistent: ).
> > >
>
Hi,
Why are you doing that? You should get kernel 2.2.19 or 2.4.3.
Everything is there. That cvs package has changes which have been
requested to be added to the next 2.4 kernel but haven't been used yet.
regards,
I have better input values for NTSC video. Also, I have identified a problem
in the saa7111-new that seems to result in no colour.
If I use the old version of saa7111-new I do get colour, but with a green line
on the left hand side of the video output.
Did you just want to grab the new NTSC
On Mon, 9 Apr 2001, David Brownell wrote:
Hi David,
> What "proper alignment"? None is mentioned in any
> part of the linux/Documentation/DMA-mapping.txt ...
Yes - in fact there are no requirements at all mentioned there wrt. to
the address to be mapped by pci_map_single(). Accordingly, someth
>>* when should the mapping table be rebuilt ?
>>START_STOP time & ALLOW_MEDIUM_REMOVAL time aren't quite suitable...
>>Or ist there just an easy mount option which forces READ_CAPACITY to
>> always be called ?
>
>Dunno... This is probably related to the "mount/umount/mount" problem in
>
>They are deprecated anyway since they don't use the same
>voltage as newer ones (ie all the new smartmedia readers
>since at least 1 year or more can not use them)
Um, sorry to object, but:
Dev-ID:
E8,EC -> 1MB-3.3V
6E -> 1MB 3.3V or 5V
EA -> 2MB-3.3V
64 -> 2MB-5V
E5 ->
[EMAIL PROTECTED] wrote:
>
> > I solved a problem with the pci_alloc_consistent function for my
> > architecture. Now the pci_alloc_consistent function allocates uncachable
> > memory (from a region starting from b700 address as you can see from
> > the following debug messages pci_alloc_con
27 matches
Mail list logo
