Greg, please apply
Included in this patch:
- (From John Tyner) Move allocation of memory out of send_control_msg. With
the allocation moved to open, control messages are less expensive since
they don't allocate and free memory every time.
- (From John Tyner) Change the behaviour of
At 10:35 AM 10/25/2002 +0200, Oliver Neukum wrote:
So in your read the easiest fix would be not to let proc pass you a pointer
to a device descriptor, but an offset into a table of pointers to device
descriptors which you can protect with a spinlock.
Probe and disconnect would have to update the
At 01:04 AM 10/25/2002 +0200, Oliver Neukum wrote:
So this is safe if, and only if, remove_proc_entry waits
for current readers to finish before it returns.
As far as I can tell, this is not the case.
So reading from the proc file while the camera is disconnected is
potentially deadly. I see no
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why would teaching applications your ioctl be harder than
teaching them your customs procfs or driverfs file?
From a coding point of view an ioctl on a file you do a lot of
ioctls on anyway is far simpler than deducing a path to another file,
At 10:34 AM 10/23/2002 +0200, Oliver Neukum wrote:
Why should shutter speed setting be different from, eg. frame size?
They should be settable by the same method.
Agreed. And in V4L2 they can be. Technically it could be set through a
vicam-specific ioctl, but if that were the only way to set
:
--- linux-2.5.44/drivers/usb/media/vicam.c Mon Oct 21 14:09:13 2002
+++ linux-2.5.44-vicam/drivers/usb/media/vicam.cTue Oct 22 02:25:05
2002
@@ -1,6 +1,7 @@
/*
* USB ViCam WebCam driver
- * Copyright (c) 2002 Joe Burks ([EMAIL PROTECTED])
+ * Copyright (c) 2002 Joe Burks [EMAIL PROTECTED
At 03:55 AM 10/22/2002 -0700, Joe Burks wrote:
from your patch file:
+ down_interruptible(cam-busy_lock);
[...]
+ if (*ppos = VICAM_MAX_FRAME_SIZE) {
+ *ppos = 0;
+ return 0;
}
I'm betting that semaphore needs to be upped before returning :)
Now if only I had upped it in my patch... Ignore
2002
@@ -1,6 +1,7 @@
/*
* USB ViCam WebCam driver
- * Copyright (c) 2002 Joe Burks ([EMAIL PROTECTED])
+ * Copyright (c) 2002 Joe Burks [EMAIL PROTECTED]
+ * Copyright (c) 2002 John Tyner [EMAIL PROTECTED]
*
* Supports 3COM HomeConnect PC Digital WebCam
*
@@ -39,9 +40,10 @@
#include linux
At 02:30 PM 10/22/2002 -0700, Greg KH wrote:
On Tue, Oct 22, 2002 at 12:49:06PM -0700, Joe Burks wrote:
static int
-vicam_write_proc(struct file *file, const char *buffer,
+vicam_write_proc(struct file *file, const char *buf,
unsigned long count, void *data)
Thanks
At 03:27 PM 10/22/2002 -0700, Greg KH wrote:
Do user programs actually try to write to these proc files? If no, then
yes, tradition should be broken here.
thanks,
greg k-h
Because of the very limited scope of V4L controls, it has been used to
allow users to adjust camera settings that
At 08:55 PM 10/22/2002 -0700, John Tyner wrote:
I saw some discussion as to whether we want to break V4L standard by
removing the proc interface, but the driverfs interface provides what was
required of the proc interface: shutter_speed to be settable for each
attached camera individually by a
At 10:06 PM 10/17/2002 -0700, you wrote:
The use of the dev_set_drvdata family of calls. I'm not sure why, but those
seem to keep the driver from being inserted, removed, and reinserted.
Replacing those with the use of private_data field in the usb_interface
struct seems to fix that (I removed
At 11:34 AM 10/21/2002 -0700, John Tyner wrote:
You're actually looking at a bug there. The proc interface for the shutter
(which you don't seem to like) should be setting needsDummyRead. As the
Well, that makes more sense. I'm not against what the proc interface is
trying to achieve so much
At 03:55 PM 10/21/2002 -0700, John Tyner wrote:
Is a MODULE_PARM too unreasonable? I agree that the proc interface
provides a simple way to change the shutter speed, but I still think that
it's a lot of code to do a small amount of work. Maybe a standalone app is
too much to ask, but [personally]
I'd hope for keeping just one version in the kernel, otherwise the
companies making distros are going to have a terrible time with
it... There are a couple important things my driver does that John's
doesn't, but there is one very important thing that John's driver did that
mine doesn't:
With the 3com homeconnect driver I've written I have a user reporting that he
is using 8 cameras simultaneously. Of course he is only grabbing one image
from each every few seconds. He has recently switched over to using camserv
(http://www.sourceforge.net/projects/cserv) which allows an
16 matches
Mail list logo
