>> Actually, this happens and is happening!
I got OT. I just needed to vent!
Sorry for the spam.
For the sensor mounting, I think the cam knows how the sensor is mounted
and therefor the driver knows (driver -> first abstraction layer between
software and hardware). Therefor the drive has to
So, what do these two deep questions, which confound the assembled
wisdom of an entire list of Linux video developers, have to do with
tables in userspace? None that I can see, unless someone wants to
provide a mechanism for the information, having been collected in the
module, to be availab
On Wed, 25 Feb 2009, Mauro Carvalho Chehab wrote:
On Tue, 24 Feb 2009 20:12:00 -0600 (CST)
kilg...@banach.math.auburn.edu wrote:
For sure we need to have a way for retrieving this information for devices
like the sq905 cameras, where the information can't be currently be
determined by usersp
On Wed, 25 Feb 2009, Thomas Kaiser wrote:
Also an overview is often very helpful. Also trying to visualize what
might be needed in the future is helpful. All of this can be extremely
helpful. But not everyone can see or imagine every possible thing. For
example, it seems that some of the bes
On Tue, 24 Feb 2009 20:12:00 -0600 (CST)
kilg...@banach.math.auburn.edu wrote:
> > For sure we need to have a way for retrieving this information for devices
> > like the sq905 cameras, where the information can't be currently be
> > determined by userspace.
>
> Yes, indeed. Except for just o
Also an overview is often very helpful. Also trying to visualize what
might be needed in the future is helpful. All of this can be extremely
helpful. But not everyone can see or imagine every possible thing. For
example, it seems that some of the best minds in the business are
stunned when conf
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Tue, 24 Feb 2009, kilg...@banach.math.auburn.edu wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
Theodore,
You're considering just one subset of the V4L usa
On Tue, 24 Feb 2009, kilg...@banach.math.auburn.edu wrote:
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905 cameras a
On Tue, 24 Feb 2009, Mauro Carvalho Chehab wrote:
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
Theodore,
You're considering just one subset of the V4L usages: notebook webcams.
Actually, the sq905 cameras are not "notebook webcams." They are cheap,
consumer entry level
On Mon, 23 Feb 2009, kilg...@banach.math.auburn.edu wrote:
On Mon, 23 Feb 2009, Adam Baker wrote:
On Monday 23 February 2009, Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 12:53:57 +0100
>
> Hans Verkuil wrote:
> > Hi Adam,
> >
> > Sorry for the late reply, it's been very busy.
On Mon, 23 Feb 2009, Adam Baker wrote:
On Monday 23 February 2009, Mauro Carvalho Chehab wrote:
On Sat, 21 Feb 2009 12:53:57 +0100
Hans Verkuil wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Me too.
The interest in detecting if a driver provides this informnation is
On Monday 23 February 2009, Mauro Carvalho Chehab wrote:
> On Sat, 21 Feb 2009 12:53:57 +0100
>
> Hans Verkuil wrote:
> > Hi Adam,
> >
> > Sorry for the late reply, it's been very busy.
>
> Me too.
>
> > > 1) Reuse the existing HFLIP and VFLIP controls, marking them as
> > > read-only Pros : No ch
On Mon, 23 Feb 2009 08:34:08 +0100
Hans Verkuil wrote:
> On Monday 23 February 2009 00:56:40 Trent Piepho wrote:
> > On Mon, 23 Feb 2009, Hans Verkuil wrote:
> > > On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
> > > > Trent Piepho wrote:
> > > > > On Sun, 22 Feb 2009, Hans de Goede wro
On Sat, 21 Feb 2009 12:53:57 +0100
Hans Verkuil wrote:
> Hi Adam,
>
> Sorry for the late reply, it's been very busy.
Me too.
> > 1) Reuse the existing HFLIP and VFLIP controls, marking them as read-only
> > Pros : No change needed to videodev2.h
> > Cons: It is confusing to have controls that
Trent Piepho wrote:
On Mon, 23 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced a
On Monday 23 February 2009 00:56:40 Trent Piepho wrote:
> On Mon, 23 Feb 2009, Hans Verkuil wrote:
> > On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
> > > Trent Piepho wrote:
> > > > On Sun, 22 Feb 2009, Hans de Goede wrote:
> > > >> Yes that is what we are talking about, the camera havi
On Mon, 23 Feb 2009, Hans de Goede wrote:
> Trent Piepho wrote:
> > On Sun, 22 Feb 2009, Hans de Goede wrote:
> >> Trent Piepho wrote:
> >>> On Sun, 22 Feb 2009, Hans de Goede wrote:
> Yes that is what we are talking about, the camera having a gravity switch
> (usually nothing as advanced
On Mon, 23 Feb 2009, Hans Verkuil wrote:
> On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
> > Trent Piepho wrote:
> > > On Sun, 22 Feb 2009, Hans de Goede wrote:
> > >> Yes that is what we are talking about, the camera having a gravity
> > >> switch (usually nothing as advanced as a gyros
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a stru
On Sunday 22 February 2009 23:54:42 Hans de Goede wrote:
> Trent Piepho wrote:
> > On Sun, 22 Feb 2009, Hans de Goede wrote:
> >> Yes that is what we are talking about, the camera having a gravity
> >> switch (usually nothing as advanced as a gyroscope). Also the bits we
> >> are talking about are
On Sun, 22 Feb 2009, Hans de Goede wrote:
> Trent Piepho wrote:
> > On Sun, 22 Feb 2009, Hans de Goede wrote:
> >> Yes that is what we are talking about, the camera having a gravity switch
> >> (usually nothing as advanced as a gyroscope). Also the bits we are talking
> >> about are in a struct whi
Trent Piepho wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to us
On Sun, 22 Feb 2009, Hans de Goede wrote:
> Yes that is what we are talking about, the camera having a gravity switch
> (usually nothing as advanced as a gyroscope). Also the bits we are talking
> about are in a struct which communicates information one way, from the camera
> to userspace, so there
On Sun, 22 Feb 2009, Hans de Goede wrote:
Yes that is what we are talking about, the camera having a gravity switch
(usually nothing as advanced as a gyroscope). Also the bits we are talking
about are in a struct which communicates information one way, from the camera
to userspace, so ther
kilg...@banach.math.auburn.edu wrote:
On Sun, 22 Feb 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it
is relevant to point out that flags can be toggled. Here is what I mean:
Supp
On Sunday 22 February 2009, Hans de Goede wrote:
> We want to be able to differentiate between a cam which has its sensor
> mounted upside down, and a cam which can be pivotted and happens to be
> upside down at the moment, in case of any upside down mounted sensor, we
> will always want to compent
On Sun, 22 Feb 2009, Hans de Goede wrote:
kilg...@banach.math.auburn.edu wrote:
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it is
relevant to point out that flags can be toggled. Here is what I mean:
Suppose that we have two flags 01 and 10 (i.e
kilg...@banach.math.auburn.edu wrote:
Hans and Adam,
I am not sure how it fits into the above discussion, but perhaps it is
relevant to point out that flags can be toggled. Here is what I mean:
Suppose that we have two flags 01 and 10 (i.e. 2), and 01 signifies
VFLIP and 10 signifies
On Sun, 22 Feb 2009, Hans de Goede wrote:
Hans Verkuil wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Same here :)
On Wednesday 18 February 2009 01:30:52 Adam Baker wrote:
(linux-omap included in distribution as lots of omap systems include
cameras so this could be re
Hans Verkuil wrote:
On Sunday 22 February 2009 12:17:58 Hans de Goede wrote:
Agreed, but it still is something which should be avoided if possible,
implementing polling also means adding a lot of IMHO unneeded code on the
userspace side.
I would prefer to make the "realtime" pivotting sta
On Sunday 22 February 2009 12:17:58 Hans de Goede wrote:
> Hans Verkuil wrote:
> >> Cons: Would require polling to support the case of a camera being
> >> turned toward / away from the user while streaming.
> >
> > Polling applies only to the bits that tell the orientation of the
> > camera. See be
Hans Verkuil wrote:
Hi Adam,
Sorry for the late reply, it's been very busy.
Same here :)
On Wednesday 18 February 2009 01:30:52 Adam Baker wrote:
(linux-omap included in distribution as lots of omap systems include
cameras so this could be relevant there.)
Background
A number of the we
Hi Adam,
Sorry for the late reply, it's been very busy.
On Wednesday 18 February 2009 01:30:52 Adam Baker wrote:
> (linux-omap included in distribution as lots of omap systems include
> cameras so this could be relevant there.)
>
> Background
>
> A number of the webcams now supported by v4l have
Hello Hans.
I went too far.
Just forgot what we can do through porting job.
You are right. That should be board specific item.
Cheers,
Nate
2009. 02. 18, 오후 11:36, Hans de Goede 작성:
DongSoo(Nathaniel) Kim wrote:
Hello Adam,
I've been thinking exactly the same issue not usb but SoC based
DongSoo(Nathaniel) Kim wrote:
Hello Adam,
I've been thinking exactly the same issue not usb but SoC based camera.
I have no idea about how usb cameras work but I am quite curious about
is it really possible to make proper orientation with only querying
camera driver.
Because in case of SoC bas
Hello Adam,
I've been thinking exactly the same issue not usb but SoC based camera.
I have no idea about how usb cameras work but I am quite curious about
is it really possible to make proper orientation with only querying
camera driver.
Because in case of SoC based camera device, many of camera I
(linux-omap included in distribution as lots of omap systems include cameras
so this could be relevant there.)
Background
A number of the webcams now supported by v4l have sensors that are mounted
upside down. Up to now this has been handled by having a table in libv4l of
the USB IDs of affect
37 matches
Mail list logo
