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:	Tue, 17 Feb 2015 13:32:16 +0200
From:	Sakari Ailus <sakari.ailus@...ux.intel.com>
To:	Hans Verkuil <hansverk@...co.com>,
	Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>,
	Hans Verkuil <hans.verkuil@...co.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Antti Palosaari <crope@....fi>, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jacek Anaszewski <j.anaszewski@...sung.com>
Subject: Re: [PATCH] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls

Hi Hans,

Hans Verkuil wrote:
...
>> Unfortunately, it only works one time, because the next time the user writes
>> a zero to the control cluster_changed returns false.
>>
>> I think on volatile controls it is safer to run s_ctrl twice than missing a
>> valid s_ctrl.
>>
>> I know I am abusing a bit the API for this :P, but I also believe that the
>> semantic here is a bit confusing.
> 
> The reason for that is that I have yet to see a convincing argument for
> allowing s_ctrl for a volatile control.

Well, one example are LED flash class devices which implement V4L2 flash
API through a wrapper. The user may use the LED flash class API to
change the values of the controls, and V4L2 framework has no clue about
this. The V4L2 controls are volatile, and the real values of the
settings are stored in the LED flash class.

This is the current implementation (not merged yet); an alternative, a
more correct one, would be to use callbacks to tell about the changes in
control values. I haven't pushed for that, primarily because the
patchset is already quite complex and I've seen this as something that
can be always implemented later if it bothers someone.

Cc Jacek.

-- 
Kind regards,

Sakari Ailus
sakari.ailus@...ux.intel.com
--
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