lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 30 Aug 2009 23:41:14 -0300
From:	Mauro Carvalho Chehab <mchehab@...radead.org>
To:	Németh Márton <nm127@...email.hu>
Cc:	Jean-Francois Moine <moinejf@...e.fr>,
	Thomas Kaiser <thomas@...ser-linux.li>,
	linux-media@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND][PATCH 1/2] v4l2: modify the webcam video standard
 handling

Hi Németh,

Em Sun, 23 Aug 2009 11:30:42 +0200
Németh Márton <nm127@...email.hu> escreveu:

> From: Márton Németh <nm127@...email.hu>
> 
> Change the handling of the case when vdev->tvnorms == 0.
> 

This patch (together with a few others related to tvnorms and camera drivers)
reopens an old discussion: should webcams report a tvnorm?

There's no easy answer for it since:

1) removing support for VIDIOC_G_STD/VIDIOC_S_STD causes regressions, since
some userspace apps stops working;

2) It is a common scenario to use cameras connected to some capture only devices
like several bttv boards used on surveillance systems. Those drivers report STD,
since they are used also on TV;

3) There are even some devices that allows cameras to be connected to one input and
TV on another input. This is another case were the driver will report a TV std;

4) Most webcam formats are based on ITU-T formats designed to be compatible
with TV (formats like CIF and like 640x480 - and their multiple/sub-multiples);

5) There are formats that weren't originated from TV on some digital webcams,
so, for those formats, it makes no sense to report an existing std.

Once people proposed to create an special format for those cases
(V4L2_STD_DIGITAL or something like that), but, after lots of discussions,
no changes were done at API nor at the drivers.

While we don't have an agreement on this, I don't think we should apply a patch
like this.



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ