Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751835AbbKIWyq (ORCPT ); Mon, 9 Nov 2015 17:54:46 -0500 Received: from us-mx2.synaptics.com ([192.147.44.131]:11521 "EHLO us-mx1.synaptics.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751588AbbKIWyJ (ORCPT ); Mon, 9 Nov 2015 17:54:09 -0500 X-PGP-Universal: processed; by securemail.synaptics.com on Mon, 09 Nov 2015 15:54:59 -0800 Subject: Re: [PATCH 22/26] Input: synaptics-rmi4 - Add F30 support To: Benjamin Tissoires , Linus Walleij References: <1446766950-31213-1-git-send-email-aduggan@synaptics.com> CC: Linux Input , "linux-kernel@vger.kernel.org" , Benjamin Tissoires , Dmitry Torokhov , Christopher Heiny , Stephen Chandler Paul , Allie Xiong From: Andrew Duggan Message-ID: <56412410.4030900@synaptics.com> Date: Mon, 9 Nov 2015 14:54:08 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.4.10.145] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3858 Lines: 84 On 11/09/2015 06:06 AM, Benjamin Tissoires wrote: > Hey Linus, > > first thanks for the reviews. Much appreciated. > > On Mon, Nov 9, 2015 at 2:32 PM, Linus Walleij wrote: >> On Fri, Nov 6, 2015 at 12:42 AM, Andrew Duggan wrote: >> >>> From: Benjamin Tissoires >>> >>> RMI4 Function 0x30 provides support for GPIOs, LEDs and mechanical >>> buttons. In particular, the mechanical button support is used in >>> an increasing number of touchpads. >>> >>> [BT] cured the code to rely only on the unified input node created >>> by rmi_driver. >>> >>> Signed-off-by: Andrew Duggan >>> Signed-off-by: Allie Xiong >>> Signed-off-by: Benjamin Tissoires >> I see this function driver is not yet adding any gpio_chip or >> LEDs class devices, which is fine, we can add that later when >> we have something to test. Or is iit using that LED feature >> in the input layer that corresponds to caps lock etc? F30 is currently only used in touchpads and mostly used to report the the click of the tact switch on clickpads. When the GPIO interrupts we report the appropriate button event to the host. Because the GPIOs are wired to our ASIC and not to the host I'm not sure there is any benefit to exposing it to the host using gpio_chip. Dmitry asked a similar question and here is my response to him: http://www.spinics.net/lists/linux-input/msg40458.html There are a few rmi touchpads which have LEDs in the top left corner to indicate if the touchpad has been enabled / disabled. Writing to a register in F30 would turn on and off the LED. I don't think they are being made anymore so I haven't really looked into how we would implement this. If there is something in the input layer for controlling LEDs that might be the way to do it. > Do not take my words as the official ones, but when we discussed with > Synaptics about F30 (and unified input), they told us that they > designed the driver based on the phone use case. In such use case, the > power (and maybe LEDs) are handled through F30, and the touchscreen > through F11/12. Problem is, I am not even sure there are phones around > with such F30/F11 combination. > > So in the end, from what I can see, F30 is used for buttons on > touchpads/clickpads, and LEDs when there are some on these touchpads. > > I don't know if the keyboards would use F30 for their LEDs though. > > That being said. Unless Synaptics tells us that there are uses of a > non "unified" input device somewhere, I would also agree to only keep > the "unified" input node, which would simplify both F11/12 and F30. The original architecture of the driver was to have each function have it's own input device. The reasoning was that you would have a phone with a touchscreen (F11) and maybe some capacitive buttons (F19 or F1A or something) and that the system should see these as two separate devices. I'm wondering if this is needed though. Would userspace care if a touchscreen also reported KEY_HOME, KEY_BACK, or KEY_MENU? At this point I agree, it's probably time to just have F11, F12, and F30 all report from the input device created in rmi_driver and remove the non unified option. If someday there is a function which needs to report data from a different input device it can just create it in that function. Andrew >> I don't quite get it I guess :/ >> >> But I guess it should also be squashed into the original F30 driver. > I think this is the original F30 driver :-) > > Cheers, > Benjamin -- 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/