I noticed a version of vicam.c a few revisions ago had all the /proc fs
writing removed because I was incorrectly using potentially tainted user
space pointers. Here's a patch which I think fixes the pointer issue and
restores the /proc fs interface to vicam. If this fix is still
problematic,
This is the same patch as before, without the checks for CONFIG_PROC_FS.
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 m
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 send_control
Looks good to me. Please include it.
I was working on patches to vicam as well, I guess I'm going to have to
figure out how to get your pre-release and submit a patch against it now
:) Any easy way to do this without bit keeper?
At 04:13 PM 10/31/2002 -0800, Greg KH wrote:
On Thu, Oct 31, 200
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 e
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 t
At 11:57 AM 10/23/2002 +0200, Oliver Neukum wrote:
> The risk being run here (root might change camuser's shutter speed on him /
> disconnect at just the wrong time) is less than the benefit (the shutter
> speed can be changed).
No, most emphatically not. Risking data corruption due to accessing
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,
open
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
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 s
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 could
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
18:15
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 +4
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
patch against 2.5.44:
--- 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) 20
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]
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 muc
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 the
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: asyn
On Friday 19 April 2002 09:57 am, Munaut Sylvain wrote:
> Hi
>
> My first question is : Are all usb webcam using about the same protocol
> ( i mean is there a lot of similarities between protocols or are they
> all completel different ? )
Never twice the same protocol it seems (okay, there may be
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 auto
21 matches
Mail list logo
