All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Trent Piepho <xyzzy@speakeasy.org>,
	kilgota@banach.math.auburn.edu,
	Adam Baker <linux@baker-net.org.uk>,
	linux-media@vger.kernel.org,
	Jean-Francois Moine <moinejf@free.fr>,
	Olivier Lorin <o.lorin@laposte.net>
Subject: Re: Adding a control for Sensor Orientation
Date: Mon, 16 Feb 2009 08:11:43 -0300	[thread overview]
Message-ID: <20090216081143.05dafb14@pedra.chehab.org> (raw)
In-Reply-To: <49993563.80607@redhat.com>

On Mon, 16 Feb 2009 10:44:03 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> I've discussed this with Laurent Pinchart (and other webcam driver authors) and 
> the conclusion was that having a table of USB-ID's + DMI strings in the driver, 
> and design an API to tell userspace to sensor is upside down and have code for 
> all this both in the driver and in userspace makes no sense. Esp since such a 
> table will probably be more easy to update in userspace too. So the conclusion 
> was to just put the entire table of cams with known upside down mounted sensors 
> in userspace. This is currently in libv4l and making many philips webcam users 
> happy (philips has a tendency to mount the sensor upside down).

Are you saying that you have a table at libv4l for what cameras have sensors
flipped? This is really ugly and proofs that the api is broken. No userspace
application or library should need to do any special hack based on usb id,
driver name or querycap names. All needed info should be provided via the
kernel to userspace API. Is there any other case where you need to do such
hacks at userspace?

In the case of flipping, kernel should provide this info for userspace, at
least for the cameras it knows it is flipped (based on USB ID or any other
method). In the case of DMI, it seems ok to let userspace to use the kernel DMI
support to read this info and detect if the sensor were mounted flipped on a
notebook, but for those cams where such info is known based on USB ID, we need
to have an interface to read this information. I can see some ways for doing it:

1) via VIDIOC_QUERYCAP capabilities flag;
2) via VIDIOC_*CNTL read-only interfaces;
3) another ioctl for querying the webcam capabilities;
4) some info via sysfs interface;

IMO, the easier and more adequate way for this case is creating an enumbered
control. Something like:

#define V4L2_CID_MOUNTED_ANGLE    (V4L2_CID_CAMERA_CLASS_BASE+17)

enum v4l2_mounted_angle {
	V4L2_CID_MOUNTED_ANGLE_0_DEGREES = 0,
	V4L2_CID_MOUNTED_ANGLE_90_DEGREES = 1,
	V4L2_CID_MOUNTED_ANGLE_180_DEGREES = 2,
	V4L2_CID_MOUNTED_ANGLE_270_DEGREES = 3,
	V4L2_CID_MOUNTED_ANGLE_VIA_DMI = 4,
};

Of curse, the mounted angle is read-only.

This solves the static case.

We need to discuss more the dynamic case, if this is needed by some device.

Cheers,
Mauro

  reply	other threads:[~2009-02-16 11:12 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-16  9:07 Adding a control for Sensor Orientation Hans Verkuil
2009-02-16  9:44 ` Hans de Goede
2009-02-16 11:11   ` Mauro Carvalho Chehab [this message]
2009-02-16 12:19     ` Hans de Goede
2009-02-16 14:20       ` Mauro Carvalho Chehab
2009-02-16 15:00       ` Mauro Carvalho Chehab
2009-02-16 15:24         ` Hans de Goede
  -- strict thread matches above, loose matches on Subject: below --
2009-02-16 14:00 Hans Verkuil
2009-02-16 14:25 ` Hans de Goede
2009-02-16 16:09 ` Trent Piepho
2009-02-16 12:02 Hans Verkuil
2009-02-16 11:01 Hans Verkuil
2009-02-16 11:12 ` Jean-Francois Moine
2009-02-16 12:07 ` Hans de Goede
2009-02-16  8:57 Hans Verkuil
2009-02-16  8:33 Hans Verkuil
2009-02-16 22:36 ` Adam Baker
2009-02-17  2:00   ` kilgota
2009-02-17  7:27     ` Hans Verkuil
2009-02-17 22:29       ` Adam Baker
2009-02-14 20:48 Adam Baker
2009-02-14 21:04 ` Hans Verkuil
2009-02-14 21:55 ` Hans de Goede
2009-02-14 21:59   ` Hans Verkuil
2009-02-14 22:44     ` kilgota
2009-02-15  9:08       ` Hans de Goede
2009-02-15  9:19         ` Hans Verkuil
2009-02-15  9:29           ` Hans de Goede
2009-02-15 13:03             ` Trent Piepho
2009-02-15 13:46               ` Hans de Goede
2009-02-15 23:09                 ` Trent Piepho
2009-02-16  1:46                   ` kilgota
2009-02-16  3:47                     ` hermann pitton
2009-02-16  3:55                     ` Trent Piepho
2009-02-16  8:30                     ` Hans de Goede
2009-02-16  2:26             ` Mauro Carvalho Chehab
2009-02-16  4:04               ` Trent Piepho
2009-02-16  7:44                 ` Hans Verkuil
2009-02-16  8:37                   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090216081143.05dafb14@pedra.chehab.org \
    --to=mchehab@infradead.org \
    --cc=hdegoede@redhat.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kilgota@banach.math.auburn.edu \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@baker-net.org.uk \
    --cc=moinejf@free.fr \
    --cc=o.lorin@laposte.net \
    --cc=xyzzy@speakeasy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.