Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756671AbbBQOGk (ORCPT ); Tue, 17 Feb 2015 09:06:40 -0500 Received: from mga03.intel.com ([134.134.136.65]:47852 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756630AbbBQOGh (ORCPT ); Tue, 17 Feb 2015 09:06:37 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,595,1418112000"; d="scan'208";a="686803803" Message-ID: <54E34AE9.90505@linux.intel.com> Date: Tue, 17 Feb 2015 16:06:33 +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: Jacek Anaszewski CC: Hans Verkuil , Ricardo Ribalda Delgado , Hans Verkuil , Mauro Carvalho Chehab , Sylwester Nawrocki , Antti Palosaari , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org 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> <54E326C0.8040901@linux.intel.com> <54E347D7.6090104@samsung.com> In-Reply-To: <54E347D7.6090104@samsung.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 Content-Length: 2306 Lines: 62 Hi Jacek, Jacek Anaszewski wrote: > Hi Hans, Sakari, > > On 02/17/2015 12:32 PM, Sakari Ailus wrote: >> 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. >> > > Actually this will be not an issue for v4l2-flash sub-device anymore. > In the next version of the patch set the v4l2-flash sub-device > will be synchronizing the flash device registers with the > state of the controls on open. Ah, right --- you're preventing the use of the LED flash class whilst the V4L2 sub-device is opened? I'm not fully certain whether that'd be really useful, as the V4L2 sub-device can also be opened by multiple users at the same time. However the applications that would access the LED class API are mostly different ones and for different purposes; I don't really have a strong opinion either way here. -- Regards, Sakari Ailus sakari.ailus@linux.intel.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/