From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) (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 8B159350A0E for ; Wed, 7 Jan 2026 18:14:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767809680; cv=none; b=Vcf7ng0W5C58722v9WgGOjWfhllm1xI2CZPTwkZp2lAoT+phfXNNadAVtM5r7C94zGyAiXj4Digq6VYx9sUlm4dV9w1KJHwOR7LzDqU4TcJrjt7k0k4gRoWgDG7VFB6DeJdpNxmgeHotLp8tAQY1R0Xj135Ek+67envJK76PYmc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767809680; c=relaxed/simple; bh=8EJWSyxXvZn3ks3drvaQ+EJ2owoDHVGaxI97nir3IQQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W6reV6DkfyOtVdX4VlvY4WwobJSdStdZAMn5nP5NyOIb3gflZlRHX9hlX1fF5AWLzfSBr/Wh7aiElkbl8ka0pAZFGdz0+nJdSR9u5vlOKFfWMrhxX7mBiLje8UZBmpQajQdlSRNxknrweXFwwRjJUc0wL2nyfsIxEZQ39cUBBVs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HYOkRv1b; arc=none smtp.client-ip=209.85.214.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HYOkRv1b" Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-29f1bc40b35so28706055ad.2 for ; Wed, 07 Jan 2026 10:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767809678; x=1768414478; 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=Qe39Iqhf1BjF3qspe6gNWmMU2hyiA6KzHQi/Ut/Amjo=; b=HYOkRv1b3W2jJGx5ktZY/Q5lP754UqN7yBE0Gqaj+HTyJfbVPJVcIcAUI4v+Tf6Kwf fu0hxx+rC90+alrqaUxxn/0tDIwQ4kkEGecG2l48gW3u+gm/6BdVNmYvpeUObiipbTBY XsPpZ9CZFO8O6NAg77T8LwBIVtmKSYzg5kJNq0P6kcEQ5tWv6GRLylWioUINMaM8EPV2 xhhPpzT0AHxtOAtQWi9NV+ycOMHPy/nyIVQgufQ8k71tMbMqNcGyJh3BaUGsvcZfaXrI a4fNUiMJJ7bUhF5yGKRbGjGPBtr/Ve4JerJlNZxhIAf1t4Ze0IFNb/l38rhEXdJSDTpD jZzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767809678; x=1768414478; 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=Qe39Iqhf1BjF3qspe6gNWmMU2hyiA6KzHQi/Ut/Amjo=; b=k1RiHUU6f5BP86fT462ZpmOqyvoqH3a4l/0aFGly0D4tzazPenUKPf0jugGp4TxbvN 2swyCuZWfafPNhpTH9sIZFkT1AB0afgzGr64dR+AqlV+3CMOCTbG4q0CEBQi8RQEZ1VB 7sc4wHMw4jcqIYNUNl5pm4KbNWYlfAsTQQwI0XZhy+AMhKdvZ1Qzn5xLaImmgnwfTQC5 zgb4OfmL19TTxfiyb+VKCKgDB0d982T63PsN1HgMMKxL4q26O05oMYK86QqhY/LHLxx4 pg/A21vzJy8Z5qCF8nR+uvqAOgR/Cdb6Xllni/1IK87FU+V0suHptvh0pRAwNzgff7vA YYMw== X-Forwarded-Encrypted: i=1; AJvYcCVjOyFkf5tVz4vOsBTYh/UYeGalIprgBSZlkFhgkmcO4jeoNJ2CNhbvrHQ/70aVkzCiTQoaXBEA+xu5E74=@vger.kernel.org X-Gm-Message-State: AOJu0YxAwHzX7/S3K8Xrlr3mHnZC0urVYvQcONFHTnCg8vtW0DB4rN0B 0/xbur5WsXJVeg7UskGxyWgwsrVa0O4sUT33HDEY0z1hkSroAxHBDqcD X-Gm-Gg: AY/fxX4cwZg6vU6vzk+ATHUd6R4l2IIOXqNKxG2g+M0lXRpxrt+kDmx/lrGk/WC+6W/ VZecHLfq2rO/vzBVA476p+1yZ6F2Q6k+B9Q/FD8OpsxFWtL2BIhRcrd2W4JtBzUZidKMXa4+la4 aWCITozq93wN9xOXxkETwxZxU2zQIJQ+uqM9gRbCQlrQ69qpAr3JgZidsszWWg3TOaguTU3ie/L 9j9iOAJTOBM5ZBcTl0Atbmz7/DQIyfyVaHiWpp/juunXUOPcap0Qmg+a4lG1v62v5hzoWzoTcL/ dD+Cl7JSFcuCM+aVu2cQ5I6eWvOIcQdewSnZK6+/RhQPOyhb80nk5KBahpH79b8UseYS7+fiXJZ 6Tk5gswG5Gky/Oc0DIl5udwtZ6hEpChcRHjY4BuHSfp9G2memqkhM0W2nTUGGGXyX6C252USDd8 D7/VEIDL9bmtkLVuX5xQ+BmgRclNdN8z1gcuw8FEmRCcsS9GGNHFySEVawqez007JJksjSGENnl EXqBf8jbFmNPPTo+uFTE3g1Iq7Fp9Y2ecRuxSUuQfYLyB8G3Tn/SygZVkLuFvUI95NPRIk= X-Google-Smtp-Source: AGHT+IGWpr2LvShqyKcudovm1hDHVkoNcZqvX+kvr8LCyX97C107Y54gUSFM1A6uZnW2jqIj4YBAmg== X-Received: by 2002:a17:90b:4986:b0:340:c179:3657 with SMTP id 98e67ed59e1d1-34f68ce934emr2595798a91.33.1767809677680; Wed, 07 Jan 2026 10:14:37 -0800 (PST) Received: from anonymous ([113.252.77.195]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-34f5fb7442asm5647976a91.15.2026.01.07.10.14.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 10:14:37 -0800 (PST) Date: Thu, 8 Jan 2026 02:14:29 +0800 From: kenkinming2002@gmail.com To: Benjamin Tissoires Cc: jikos@kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] HID: i2c-hid: override HID descriptors for some Haptick 5288 touchpads Message-ID: References: <20251225190822.150872-1-kenkinming2002@gmail.com> <3sbccjhicn22ubkbgz23njhsektkrva3b2udaavg2onxmo5uah@2vt472vdjehm> 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: <3sbccjhicn22ubkbgz23njhsektkrva3b2udaavg2onxmo5uah@2vt472vdjehm> On Wed, Jan 07, 2026 at 06:45:45PM +0100, Benjamin Tissoires wrote: > I'm really not found of this patch. Me neither and would be happy with a cleaner solution. > I'm really not found of this patch. AFAICT, from the archlinux bug, the > device is presenting itself to HID, and we "just" have a truncated > report descriptor. I'm not sure if you can trigger that bug at the HID > descriptor level, without scripting it (so in real case scenarios). At least I can trigger it, because I have an full disk encryption setup and my theory is that I might unintentionally touch the trackpad while typing the password. That would explain how I come across the bug. > The simplest "solution" following what you are doing is making a HID-BPF > fixup which checks whether the device properly sent the report > descriptor and if not puts the one here. The HID-BPF has the advantage > of being compatible with hid-multitouch so you won't get into troubles > with a separate module. This might be a solution but would that not only fix it just for me? I would have to look into how to do HID-BPF fixup. > The proper solution should be to detect those situations. But you > mentioned above that the detection of the interrupts wasn't working. > Could you tell us more? This is the diff that is lying in my filesystem. I do not see a nice way to do it without any race. The call to msleep(1) is just a best effort to make sure any interrupt that have fired would be seen but there is no guarantee. Now that I think about it, there might be some memory visiblity issue with multicore but I am not sure. diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index f9b9dd0d9bb8..161eb8301763 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -66,6 +66,7 @@ /* flags */ #define I2C_HID_STARTED 0 #define I2C_HID_RESET_PENDING 1 +#define I2C_HID_IRQ_HANDLED 2 #define I2C_HID_PWR_ON 0x00 #define I2C_HID_PWR_SLEEP 0x01 @@ -219,7 +220,25 @@ static int i2c_hid_xfer(struct i2c_hid *ihid, n++; } + // On some devices, what we received will may become corrupted if we + // are also supposed to receive input reports asynchronously at the + // same time, persumably because the hardware buffer in the device is + // shared. + clear_bit(I2C_HID_IRQ_HANDLED, &ihid->flags); ret = i2c_transfer(client->adapter, msgs, n); + if(recv_len != 0) + while(ret == n) + { + msleep(1); + if(!test_and_clear_bit(I2C_HID_IRQ_HANDLED, &ihid->flags)) + break; + + i2c_hid_dbg(ihid, "%s: interrupted transfer: res=%*ph\n", + __func__, recv_len, recv_buf); + + clear_bit(I2C_HID_IRQ_HANDLED, &ihid->flags); + ret = i2c_transfer(client->adapter, msgs, n); + } if (ret != n) return ret < 0 ? ret : -EIO; @@ -585,6 +604,7 @@ static irqreturn_t i2c_hid_irq(int irq, void *dev_id) { struct i2c_hid *ihid = dev_id; + set_bit(I2C_HID_IRQ_HANDLED, &ihid->flags); i2c_hid_get_input(ihid); return IRQ_HANDLED; Simply disable and enabling interrupt would not work since we would be just masking the interrupt on the cpu side. In fact, that is another fix that I have attempted: diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 63f46a2e5..28ba480e4 100644 --- a/drivers/hid/i2c-hid/i2c-hid-core.c +++ b/drivers/hid/i2c-hid/i2c-hid-core.c @@ -219,7 +219,9 @@ static int i2c_hid_xfer(struct i2c_hid *ihid, n++; } + disable_irq(client->irq); ret = i2c_transfer(client->adapter, msgs, n); + enable_irq(client->irq); if (ret != n) return ret < 0 ? ret : -EIO; > I'd very much not have a report descriptor written in stone in the > kernel when the device returns a correct one. Especially not at the > i2c-hid level (I would be happier with a HID module, but this might > break mutltiouch functionality). Same, which is why I am asking for suggestion to alternative fixes. Yours sincerly, Ken Kwok