From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756849AbbBQLcW (ORCPT ); Tue, 17 Feb 2015 06:32:22 -0500 Received: from mga02.intel.com ([134.134.136.20]:10653 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752038AbbBQLcU (ORCPT ); Tue, 17 Feb 2015 06:32:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,594,1418112000"; d="scan'208";a="455656765" Message-ID: <54E326C0.8040901@linux.intel.com> Date: Tue, 17 Feb 2015 13:32:16 +0200 From: Sakari Ailus User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32.1 MIME-Version: 1.0 To: Hans Verkuil , Ricardo Ribalda Delgado , Hans Verkuil , Mauro Carvalho Chehab , Sylwester Nawrocki , Antti Palosaari , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Jacek Anaszewski Subject: Re: [PATCH] media/v4l2-ctrls: Always run s_ctrl on volatile ctrls References: <1424170934-18619-1-git-send-email-ricardo.ribalda@gmail.com> <54E32358.8010303@cisco.com> In-Reply-To: <54E32358.8010303@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@linux.intel.com