From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BF25BC28CC5 for ; Sat, 8 Jun 2019 10:52:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92B12214C6 for ; Sat, 8 Jun 2019 10:52:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559991134; bh=kV46yONNbVuFQFsT+giJeL1QokbE/1eKyFDNw+3LHiI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=fTyDxpv3fwzINT4SMLDG/SL4ePHUDPTNUknz0kSf+o+xAY1WO70SLhLs4haUDNDW2 6GVLmWtDRM0N9DoyFa+X7EMUyIYQxEmVI68VPR4G8E1x/sLaBaGMv9ALLtmjEIiMGZ 8PnJCrLKvSAFMv0jzg1DVcbv/Fih2G/GC8R6kYuc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726879AbfFHKwO (ORCPT ); Sat, 8 Jun 2019 06:52:14 -0400 Received: from mail.kernel.org ([198.145.29.99]:41244 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726692AbfFHKwN (ORCPT ); Sat, 8 Jun 2019 06:52:13 -0400 Received: from archlinux (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 429C92146E; Sat, 8 Jun 2019 10:52:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559991132; bh=kV46yONNbVuFQFsT+giJeL1QokbE/1eKyFDNw+3LHiI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=y1YwB0TXeqd5hJSYiQ6zC3kS+Fl5VQmIUx7CUBQpf+O6kAOPiZsbKyqwkurdSXByE SLoexhcmM9ANbe+SdH8IbCSzgpR+FuoWQkJgGZzdi/1+yWzzobJ70vwN1+kZ6Klcok xO6dCD6OGBOdSAp2oLtqpthh0b4G8LLsPcsmpjCo= Date: Sat, 8 Jun 2019 11:52:07 +0100 From: Jonathan Cameron To: "H. Nikolaus Schaller" Cc: linux-input , Dmitry Torokhov , Eric Piel , linux-iio , kernel@pyra-handheld.com, lkml , Lars-Peter Clausen , Peter Meerwald-Stadler , Hartmut Knaack , Discussions about the Letux Kernel , Bastien Nocera Subject: Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface Message-ID: <20190608115207.22a6fa9a@archlinux> In-Reply-To: References: <195994ebff28de22eae872df134d086c761b83b8.1554026986.git.hns@goldelico.com> <20190407133037.0ad98897@archlinux> <20190414124029.1f1f6084@archlinux> <20190422152014.7c6637ab@archlinux> <20190511120536.647c8676@archlinux> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-iio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-iio@vger.kernel.org On Mon, 3 Jun 2019 09:30:40 +0200 H. Nikolaus Schaller wrote: > Hi Jonathan, > sorry again for the long delay. I just now found a little time to summarize and try to > get the discussion boiled down to the key difference. > > > Am 11.05.2019 um 13:05 schrieb Jonathan Cameron : > > > > On Thu, 9 May 2019 19:02:49 +0200 > > "H. Nikolaus Schaller" wrote: > > > >> > >> If you close the lid, the display is turned upside down and y and z axes reverse sign. > >> > >> So there remains only the issue that user-space must know which sensor device file is which sensor > >> and can do the calculation of the lid angle. This is possible because the iio accelerometer name > >> is available through the input event ioctls. > >> > >> In summary this case also does not need policy or configuration. Just user space using the information > >> that is already presented. > > > > I disagree with that last statement. If there is a lid angle sensor, policy is > > needed to know which of your associated orientation is the base one and which > > device indicates the lid angle. > > > > > Actually most of the time what you will do is pick one 'correct' sensor under > > some configuration of the device and use that. That is policy. Yes, you could > > bake the policy in to device tree, but then you can also bake in the association > > between the underlying IIO sensor and any virtual input sensor. > > Ah, maybe I did not understand what you mean by policy here. > > Indeed, choosing the right sensor is always something which is application specific > and something user-space must obviously dictate. And we agree this should *not* be > in device tree (or user-space scanning device tree) because that describes hardware > and not user-space interaction. > > But I still do not think that this requires a new mechanism where user-space > *tells* the kernel which sensor to use and present as which device. > > Equally well, the kernel can present all sensors it knows about and a set of properties > that allow the user-space to simply choose the right one ("apply policy"). Properties > could be file name (e.g. provided by udev), device name, label (provided by DT) or similar. > > If it were absolutely necessary to tell the kernel to map iio devices to something before > use, I think Bastien would not have been able to implement his library. He also has to > choose the right sensors. This seems to work and not need a new mechanism. > > > > > Anyhow, we still disagree on whether any such virtual input interface > > should be a userspace policy decision. So far I haven't seen any compelling > > argument why it shouldn't be and the flexibility such a policy based interface > > provides is its major advantage. > > I still think it is not needed because kernel already provides necessary information > to user-space to make policy decisions (by ignore unwanted interfaces) without needing > a new interface where the user-space tells the kernel to activate some interfaces. > > So the key difference is about the question if user-space needs to tell the kernel first > that it wants to see a specific interface or just makes use of it if present. Absolutely. Good summary, but I don't think either of us is going to persuade the other. I've started work on my proposal but things have been 'interesting' in the last few weeks so it may be a little while yet before I have anything to share. Jonathan > > BR and thanks, > Nikolaus >