From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 428AF38759C for ; Mon, 9 Feb 2026 19:33:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770665589; cv=none; b=C7NKartUAWNk+O2Jtn0Fq8MkUOIzhkEqQ408UPKAaHPsX3fTAZv+XzRAnMPZp08o5OPpv3Ndq3DmgADfwaWKeG8MSvOV2Ssr9F0XKiy6IHJex0fvgKggaN9s9gIoEvPOntIwDDuC/U7+cZC7KMQ5eW6QgN5CVbZdlAd/4D4gmd8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770665589; c=relaxed/simple; bh=y4/WL8DraOGgFsWhKFSg+J7rQqnclmJ+j8KLygZoKww=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=axE09XhxqeA3fiv4q/EWzh9C4yIt01VgU68uBf4MT0Af2cEUBasUdV5ar+Zku+5c1lX6xdHP6+f7zcYg4YqgvoSC3dAFYs6wfDl8Aq4WZ3GGYZpzf7YHecrQsJRxCsDwI/nR/0CSU0ueSpH5HSbF0v68wZJFTqH3aY5ALGJVYEg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=Ob8b76U+; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Ob8b76U+" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48039fdc8aeso590045e9.3 for ; Mon, 09 Feb 2026 11:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1770665588; x=1771270388; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=bQq96nnOOaZZumZQZN40bit2z1YPrLWrmhauKMPeMdY=; b=Ob8b76U+poby8/iYxLJrSdwBjM1q4u9PLBHnDRDcbvyDFDO3G9p1heRBWp8gEgB64N SOpPfF3Yxjdd1auVXLe9pqxIF3WIMZg+HXVzXa3pul96H71OH6VaR8dRXk6RwdLjaNVo Sfwxt2tBCvBAIgoILmiFjb7O+IuGUC/wYiCik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770665588; x=1771270388; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bQq96nnOOaZZumZQZN40bit2z1YPrLWrmhauKMPeMdY=; b=js+nHlgiGqRwO52eQr1zDko9OwddD6YVBvdrOj1uhFZGLYyT3pPHWmj6gNvoBpGJQJ VNMxwGGBAmUaMbgaJLe4jRS7wYcPomPd3pH8DN0J2RwYOBCYltV6LNipv0dhJy62yMuG Y9hzyLzI9Kkf+jnVLd4JkbDK3DSs2s+ZRmfuQkrsXJ9dvo4JT8t2TQerk+VjExIRDDig XzViyhaKtlQuvxj0txsRdSsvHQc5W+wIr7pPyJKsBj+WH1NZueZQuaylyE45TrAhiRQn borQC3m0O/L89N/6tVcC6B6JRybsP+kZ+PagCtyAc056sMG01B3axpygCMR33nC/Xxek 4AXw== X-Forwarded-Encrypted: i=1; AJvYcCVKVc72uvaXHh1/ExtGTe2g/geiXXUjfphqWBufXlNXiLiVuFTKpMnXBXyEh5mSTu4b8nIivA55FJJlNsc=@vger.kernel.org X-Gm-Message-State: AOJu0Yxou9jKVFaQ7Tr2qd51vHlh8oiLEBRRpzXPo39xUZB5+gPh5Yuf asPLZcyjYtWKo80tf2K622Yi4bj5Llo8sJfQglVI3kkvAiKACUtSBywIS1zD/Tefdw== X-Gm-Gg: AZuq6aLsN8TyQHAbaEKF6dpcCiH50IepHR/wnZxyZT9fqiB4vHzGNh26LPQ7wgB5dn1 wEGtOfmV2MVY55JesCAAL6LnRBNMLRwchW2SsnueGj12ucPqt3H996PM6UABhVc+aWVN+JBKqCB kaTBv6SeTVLvUOCg07i7n7jwTkRrk6O5F5G5BdZF9mdAGjao6+LH6SgMORVK3/Qft4acaWWZUN5 ql+63/8JFVrxfWn/9sB1ORGzxU10UrunEZUEZP+udMfSQ6WIXhvrMZdeEptr6bTLiS4GOE/8QkS /okIP4HIUcczBM9MHDTtHsakQg5wjTLup3Opxy/g/BggdciIxY3RO2vrj7hNtfHMQOhOBIIbGVx WPCvDOdyKVROo5aayAJa3VF3A94IPcsF2fFI7D9vMhuW0fLFe2NYPS66myjiod7unx9fq8Z1skC Wobh+i6PdHa6+5hGvWkQ== X-Received: by 2002:a05:600c:3b23:b0:47f:8c05:786b with SMTP id 5b1f17b1804b1-4832021eae9mr177212155e9.28.1770665587652; Mon, 09 Feb 2026 11:33:07 -0800 (PST) Received: from google.com ([37.228.206.31]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4834d5d77f9sm9355785e9.3.2026.02.09.11.33.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 11:33:07 -0800 (PST) Date: Mon, 9 Feb 2026 19:33:05 +0000 From: Fabio Baltieri To: Dmitry Torokhov Cc: Benson Leung , Guenter Roeck , Tzung-Bi Shih , Simon Glass , linux-input@vger.kernel.org, chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/1] Input: cros_ec_keyb - add function key support Message-ID: References: <20260112093309.240905-1-fabiobaltieri@chromium.org> <20260112093309.240905-2-fabiobaltieri@chromium.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Feb 09, 2026 at 10:20:52AM -0800, Dmitry Torokhov wrote: > On Mon, Feb 09, 2026 at 03:46:20PM +0000, Fabio Baltieri wrote: > > On Fri, Feb 06, 2026 at 08:25:14AM -0800, Dmitry Torokhov wrote: > > > > > > I do not believe this flag is needed. Always do FN processing. If there > > > is no FN in the keymap it should work just fine. > > > > The problem is that if there is an Fn key and a keymap, hence we process > > the Fn keys in the kernel, then we don't send the Fn events, but we > > currently have devices deployed with an Fn key where the key is handled > > by the userspace and they expect KEY_FN events to be emitted, so if I > > let the "fn keymap" logic kick in it unconditionally it would cause a > > regression for existing devices. > > Hmm, I see. Then I think we really need to have it as a device property, > because keymap can be manipulated at runtime, so depending on it to > switch processing seems weird. > > It is like autorepeat, either device configuration asks for it, or it > does not... Ok, the DT folks were fairly explicit about not wanting anything that even remotely looks like configuration into dt. Right now the behavior changes based on what's in the keymap, which I think is fine. I see the keymap can be manipulated in runtime but then I guess I could just install a custom hook to idev->setkeycode, recompute cros_ec_keyb_has_fn_map() and then call input_default_getkeycode()? I'd have to make that function public but then it'd automatically change the behavior in runtime as keycodes are defined/undefined. Would that be acceptable?