Replying to myself:
Apologies that copying using the Cntrl-R option (read file) in pine made
such a mess of the formatting. This was really a mess when I got a copy
back again. Sorry, each header _was_ on a separate line :-/
Header: ff ff 00 ff 96 64 d0 37 5a 27 48 91 Header: ff ff
On Fri, 17 Apr 2009, Kyle Guinn wrote:
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
But I have never seen the 0x64 0xX0 bytes used to count the frames.
Could you tell me how to repeat that? It certainly would knock down the
validity of the above table wouldn't it?
I've m
On Fri, 17 Apr 2009, Kyle Guinn wrote:
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
ff ff 00 ff 96 64 d0 c1 5c c6 00 00
ff ff 00 ff 96 65
On Friday 17 April 2009 12:50:51 Theodore Kilgore wrote:
> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> > On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
> >> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> >>> I've been looking through the frame headers sent by the MR97310A (the
> >>> Aiptek PenCa
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the com
On Thursday 16 April 2009 13:22:11 Theodore Kilgore wrote:
> On Thu, 16 Apr 2009, Kyle Guinn wrote:
> > On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
> >> Hello Theodore
> >>
> >> kilg...@banach.math.auburn.edu wrote:
> >>> Also, after the byte indicator for the compression algorithm the
On Thu, 16 Apr 2009, Kyle Guinn wrote:
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the compression algorithm there are
some more bytes, and these almost definitely contain information which
On Wednesday 04 March 2009 02:41:05 Thomas Kaiser wrote:
> Hello Theodore
>
> kilg...@banach.math.auburn.edu wrote:
> > Also, after the byte indicator for the compression algorithm there are
> > some more bytes, and these almost definitely contain information which
> > could be valuable while doing
On Thu, 5 Mar 2009, Kyle Guinn wrote:
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote:
Well, here is the code in the function. I don't see. So can you explain?
Perhaps I am dense.
{
struct sd *sd = (struct sd *) gspca_dev;
int i;
/* Search
On Thursday 05 March 2009 14:58:54 kilg...@banach.math.auburn.edu wrote:
> Well, here is the code in the function. I don't see. So can you explain?
> Perhaps I am dense.
>
> {
> struct sd *sd = (struct sd *) gspca_dev;
> int i;
>
> /* Search for the SOF marker (fixed part
kilg...@banach.math.auburn.edu wrote:
felling->feeling
spelling/writing error (I meant feeling)
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.aubur
On Thu, 5 Mar 2009, Thomas Kaiser wrote:
kilg...@banach.math.auburn.edu wrote:
That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or
it could be that only the digits 0 through 9 are actually used, and the
basis is then 100, or too many other variations to count. Also what i
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu
wrote:
On Wed, 4 Mar 2009, Kyle Guinn
On Thu, 5 Mar 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:3
kilg...@banach.math.auburn.edu wrote:
That of course is a guess. OTOH it could be on a scale of 0 to 0x80,
or it could be that only the digits 0 through 9 are actually used,
and the basis is then 100, or too many other variations to count.
Also what is considered a "normal" or an "average" valu
On Thu, 5 Mar 2009, Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
For the brightness, I guess, 0 means dark and 0xff completely bright
(sensor is in saturation)?
That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or it
could be that only the d
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
For the brightness, I guess, 0 means dark and 0xff completely bright
(sensor is in saturation)?
That of course is a guess. OTOH it could be on a scale of 0 to 0x80, or
it could be that only the digits 0 through 9 are actually used, and the
kilg...@banach.math.auburn.edu wrote:
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu
wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu
wrote:
cont
On Thu, 5 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
contents of file mr97310a.patch follow, for g
On Thu, 5 Mar 2009, Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Thomas Kaiser wrote:
As to the actual contents of the header, as you describe things,
0. Do you have any idea how to account for the discrepancy between
From usb snoop.
FF
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Thomas Kaiser wrote:
As to the actual contents of the header, as you describe things,
0. Do you have any idea how to account for the discrepancy between
From usb snoop.
FF FF 00 FF 96 64 xx 00 xx xx xx xx xx xx 00 00
Kyle Guinn wrote:
On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote:
Which also makes me wonder about the same change for the mr97310a, is that
cam already supported in a released kernel ?
If not we MUST make sure we get this change in before 2.6.29 final, if it
is I'm afraid we cannot
Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
-
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
On Wednesday 04 March 2009 22:34:13 kilg...@banach.math.auburn.edu wrote:
> On Wed, 4 Mar 2009, Kyle Guinn wrote:
> > On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
> >> contents of file mr97310a.patch follow, for gspca/mr97310a.c
> >> --
On Wed, 4 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
contents of file mr97310a.patch follow, for gspca/mr97310a.c
--- mr97310a.c.old 2009-02-23 23:59:07.0 -0600
+++ m
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
> contents of file mr97310a.patch follow, for gspca/mr97310a.c
>
> --- mr97310a.c.old2009-02-23 23:59:07.0 -0600
> +++ mr97310a.c.new2009-03-03 17:19:06.0
On Wednesday 04 March 2009 02:39:11 Hans de Goede wrote:
> Which also makes me wonder about the same change for the mr97310a, is that
> cam already supported in a released kernel ?
>
> If not we MUST make sure we get this change in before 2.6.29 final, if it
> is I'm afraid we cannot make these cha
On Wed, 4 Mar 2009, Thomas Kaiser wrote:
Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the compression algorithm there are
some more bytes, and these almost definitely contain information which
could be valuable while doing ima
On Wed, 4 Mar 2009, Hans de Goede wrote:
Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
Just a random thought, but maybe the pac207 driver can benefit from such a
change as well?
It could, but it is to late for that, the pac207 driver and co
Thomas Kaiser wrote:
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the compression algorithm there are
some more bytes, and these almost definitely contain information which
could be valuable while doing image processing on the output. If they
are alr
Hello Theodore
kilg...@banach.math.auburn.edu wrote:
Also, after the byte indicator for the compression algorithm there are
some more bytes, and these almost definitely contain information which
could be valuable while doing image processing on the output. If they
are already kept and passed o
Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
Just a random thought, but maybe the pac207 driver can benefit from such a
change as well?
It could, but it is to late for that, the pac207 driver and corresponding libv4l
functionality has been out
kilg...@banach.math.auburn.edu wrote:
Hans, Jean-Francois, and Kyle,
The proposed patches are not very long, so I will give each of them,
with my comments after each, to explain why I believe that these changes
are a good idea.
First, the patch to libv4lconvert is short and sweet:
content
On Tue, 3 Mar 2009, Kyle Guinn wrote:
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
Hans, Jean-Francois, and Kyle,
The proposed patches are not very long, so I will give each of them, with
my comments after each, to explain why I believe that these changes are a
goo
On Tuesday 03 March 2009 18:12:33 kilg...@banach.math.auburn.edu wrote:
> Hans, Jean-Francois, and Kyle,
>
> The proposed patches are not very long, so I will give each of them, with
> my comments after each, to explain why I believe that these changes are a
> good idea.
>
> First, the patch to lib
Hans, Jean-Francois, and Kyle,
The proposed patches are not very long, so I will give each of them, with
my comments after each, to explain why I believe that these changes are a
good idea.
First, the patch to libv4lconvert is short and sweet:
contents of file mr97310av4l.patch follow
--
38 matches
Mail list logo
