On Wed, 28 Apr 2004, Oliver Neukum wrote:
> We are, at least nominally, in a stable kernel series.
> If you do this a seamless kernel upgrade is no longer possible.
> Is there a technical reason to do this right now?
Not really. It was mostly because I read the Debian people are getting
ready to
Resend, since the first didn't appear to make it to the list. Sorry if you
get it twice.
Attached is a patch that removes the vicam firmware from the kernel
source and moves it out to userspace to be loaded by the hotplug system.
It works for me. More testing would be ideal, but I think it's read
Hi,
This patch cleans up the vicam_decode_color function by removing
unused/useless variables and combining the two "x" loops inside the
y loop into one. It also reduces the number of times that the "x"
loop occurs from 512 to 320 which should provide a decent speed
increase. It also fixes a bug
On Sun, Nov 24, 2002 at 03:28:45AM +0100, Oliver Neukum wrote:
Yours is the reply I was looking forward to. :)
>
> > It works for me.
>
> Looking good.
Glad I was able to do it right this time.
> > [snip]
>
> Nope, that's wrong. What do you do propose to let the read on proc
> do if you run
.49.c2002-11-22 20:10:37.0 -0800
+++ drivers/usb/media/vicam.c 2002-11-23 08:12:35.0 -0800
@@ -1,7 +1,7 @@
/*
* USB ViCam WebCam driver
* Copyright (c) 2002 Joe Burks ([EMAIL PROTECTED]),
- * John Tyner (fill in email address)
+ * Joh
Hi,
Included in this patch:
- 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.
- Change the behaviour of send_control_msg to return 0 o
Hi,
This patch fixes some things that have failed to go in as part of other
patches that have been rejected. Namely, this adds the forgotten up call
in the read function, removes the usb_put_dev (since there is no
usb_get_dev), and also moves the allocation and freeing of the image and
frame buffer
> Please don't remove the proc interface. This is a V4L issue. It's in
> there because this is a V4L driver.
I saw that you were going to raise the issue on that list. I said the patch
can wait. Regardless, though, I think that the driverfs is where this kind
of thing is supposed to be going.
A
> Why take out the usb_put_dev() call?
It seemed to be keeping the driver from being inserted, remove, and
re-inserted. I didn't figure out why... just that this was the cause.
John
---
This sf.net emial is sponsored by: Influence the future
> 1. Who can write these settings? How do you control that?
I set permissions to rw-r--r--. Don't these files get owned by root when
created?
> 2. The module count handling is wrong.
>These methods don't sleep. Either they are racy or safe with or without
>manipulating the usage count.
I
Hi,
The attached patch removes vicam.c's proc interface and replaces it with a
driverfs file called shutter_speed through which the shutter speed can be
changed for each device.
This patch also removes the usb_put_dev call from the disconnect routine
as well as adding the up call for the busy mut
> You no longer check buf against NULL, can a misbehaved program cause a
> problematic seg fault in the kernel?
I put the onus of checking buf != NULL and count != 0 on copy_to_user.
> I'm betting that semaphore needs to be upped before returning :)
Yes, it does. I'll leave that to you.
-
> The following patch removes the old framebuf_size and framebuf_read_start
> values from the cam structure and simplifes the read function. It also
> moves the needs dummy read check into the read_frame function. cp and dd
> should both still work.
This is in addition to the previous patch. It sh
The following patch removes the old framebuf_size and framebuf_read_start
values from the cam structure and simplifes the read function. It also
moves the needs dummy read check into the read_frame function. cp and dd
should both still work.
Patch is against 2.5.43, but I believe should apply clea
> require a stand alone vicam-specific executable to change the shutter
> speed. I didn't think that was a reasonable expectation.
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
> Yes, but Joe's was there first, based on the original driver, that's why
> I accepted his patch.
I understand that. My code is even based partially on it and wouldn't exist
without the reverse engineering/color decoding information that I found at
his site.
> Could you point out the problems in
Sorry to resurrect this thread, but...
> On Mon, 14 Oct 2002, Joe Burks wrote:
>
> 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
On Mon, 14 Oct 2002, Joe Burks wrote:
> 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 tha
On Mon, 14 Oct 2002, Greg KH wrote:
> Hi all,
>
> I just got a message from John Tyner asking why I just merged a vicam
> driver from Joe Burks. Rather than repeat myself a few times to
> everyone involved, I thought I would just post here, publicly to help
> straighten things o
I believe that this driver has been sufficiently beaten into submission that
it can now be considered for being added to the tree.
Patch is against 2.5.41.
I have a 2.4 version as well that is essentially the same as this version
with the necessary backport changes if we want to add it to the 2.4
> Sorry, my humor got the better of me. You should add a few comment
> regarding the locking through v4l open. YOur relienance on it makes
> it very subtle and impossible to understand without comments.
> The code itself is very well.
Absolutely. Once there are no more problems with the code, I'l
> To be frank, your disconnection handling is the most outrageous abuse
> of semaphores I've seen in months. But it is correct :-)
Well, I'd like it to be correct in the "it's actually decent code"
department as well. The "in months" part makes me feel a little bit better,
though, as it implies s
Let's try this one. Patch is against 2.5.41.
The device is no longer unregistered in the disconnect but in the
vicam_free_memory function. This introduced a race with the open call, which
I believe I've taken care of. I also implemented the mechanism that I talked
about in my previous email for d
On Wed, 9 Oct 2002, Oliver Neukum wrote:
> Hi,
>
> you make me feel like a villain from a bad movie, but ...
Ha, ha, ha. Hopefully, you won't give up before I get it right. :)
> > release {
> > get disconnect mutex
> > decrement users
>
> Don't do this. Release does not map to close.
>
On Wed, 9 Oct 2002, David Brownell wrote:
>
> Or better yet, use the primitives and
> call wait_for_completion() ... if your event model allows.
I think it would allow, but the problem seems to be that the disconnect
routine cannot wait indefinitely for a wake up call from the release
function.
Hi,
I'm removing Greg and the linux-kernel list from To/CC of this thread. I
think Greg gets it from the usb-devel list, and I don't want to take up
more bandwidth on the linux-kernel list with this single usb issue. :)
Now, on to the fun stuff.
> + if ( waitqueue_active( &vicam_v4l_priv->n
This is a resend of the patch I sent earlier. I worked on the one earlier
while away from home and was unable to test it. This one has been fixed,
tested, and should be correct. Sorry for the confusion.
Patch is against 2.5.41.
Thanks,
John
vicam-2.5.41.patch.gz
Description: GNU Zip compresse
On Mon, 7 Oct 2002, Oliver Neukum wrote:
> Well, here we go again, there are other issues as well.
> There's a race between open() and disconnect(). The best way to deal
[snip]
I believe this addresses (and hopefully corrects) this issues raised about
the race between disconnect and the device b
28 matches
Mail list logo
