From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (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 8286C1DED42 for ; Sat, 7 Mar 2026 22:53:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772923982; cv=none; b=sX7CNwSG+sknhh8xZPcobU87Nu9f6du+L2r7C2HhSKrxi2uVnZdZhkKIzVHmDOW7CXUns1Hk0cTpcEdQN48vezeyphZo+ifYVufK1sHkfvkfhcmqqdzoIzYPuM2b5CvLiXijitlWXYd6ztGjWd5kk6/RntyszP7BgCYyzzsbA6k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772923982; c=relaxed/simple; bh=onuSXtg6F2LCy0LxbZ/34VrpJdyeiEFGVxLttUdYP3s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iZsyXf2UWSysXKGMmevAMgMoi8mnVSxYuabyImIorR+I3VEWnAsbQ8R844ocAMhmMctBbDqROKJQeoaBDlRRYgKmMHdQuHxWJLqw+ZbYkJaQLB6f4MDWbJCpQAwsFF63XUmCmSpRa2TUpSUnYVSMtl4InrqFx4HM1JJ/ARHNPCA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=p0mw1HKA; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="p0mw1HKA" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8c70b5594f4so1066995185a.1 for ; Sat, 07 Mar 2026 14:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1772923979; x=1773528779; 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=csKDsiBXgnWt/0Smw1tLZwTuHlhZeD6UkDDjhH+moI4=; b=p0mw1HKAR0Ynllgi5cdAuMq576fHQl1VVQrNmwJrauVgoxvG57fP0zssEdbRxToTFQ d7hNkJpl2mUGvbKbCufFNMF+MPQvdgii73IT9eLLf/ieDE/epwjgzzYzMkhicetwsiGS f+8lKnLhWkxZZunFJmlzvbd+YJ7pb/DJaSmhUBvr1uTSODhtiFypOSBM25IZMpf9xuoY j48cMoTH3mw93SHGEB6+k9I28PYGDwCtVpSrXGQu76exfpCruvyCFWqieZ9OExotCJWT hRmGQDlDOaSKNxBsTN2E7R/+LzKScydN7z1pU0kklkYL6BA5elyttSDLsvJYHxmlOXNe LyUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772923979; x=1773528779; 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=csKDsiBXgnWt/0Smw1tLZwTuHlhZeD6UkDDjhH+moI4=; b=L2ORCzk7Am8SzlAuXMrb4M9xFRGHxmkyW/JBhzNyKOb54NVKWmKhOOEod/NQuoMxIr vdmifwJ6UPEXIeovIbUvz5PWI7eE2WaTwsTry4MREv5nJzI5DUJPo9XBT2rKZU9A60tC wwIZ6k2VVZSBJQATh5FYOLThPmZGPT0UnUfE6XKGlNCGrp0h3DiTH7eP7sOezZV2hgsN 13uM12hwAnlazAGd18XrBRa/L0BBFlCLh+PpqypGlzbSKduw8K2WJm5tWze1V2J1Qtga pdKJUvVfeokeYuz/Ph8GpqPED5IUeba8dze/AhObPsrbn/+YqKePdIju9rhzSiwLMjsr 0koA== X-Forwarded-Encrypted: i=1; AJvYcCXnYzElMJXjmdgRKE5ZAOLZatkz65mKxkRIXM2o2la8bQvX9hZPsb+sm/4E5iRpCMGd+Ggq9IaFM8+xZkw=@vger.kernel.org X-Gm-Message-State: AOJu0YxNyJoX2RLtFFfVhSec0ESpK8g0QDvxvKRNq6FW9ym2IylxE7A2 RiWjZb0Qi9d0l2teg5kbYNaElPsnStcztB3ClA9i5EqgAhxCs9DoBN9fvKZiNOplxQ== X-Gm-Gg: ATEYQzwELH0ryaYnyWHKGgBW4z7TYMbnMHGtLZWWb+5a7Dd7pZ1UudEYALA8lA0QVt1 Wz6uEkOCRtdi+hPvgkG9EC75RhMU8MB3DGMllGudZvD5MbI17q082fOeVkg5tINT3nRF8ebk2jW bSbbP0w3G3vtbTfWYL3L8kFsDqG9dODS9qTi4az3hfHHsooONAqKK7nHm5uJHcYjpklL7T27+qp zCqP7dAyuCWZndWeKwRWeh/Dog1XPVDXASsTAzxAvpJWyLuohB3icppKiz6VX31XD6xULLxNHVm 0tHrcGG0aM59pB/ZVVWbu4NjHOXq6ts6zxSt/7s/Znynn70AWwzgZ8OUKkjUXuUgWunlPPOs4Yh tNW8A6CcqktzotsoojbNnJODa1cyWr3NULfXlmOm2YNpCL3IqfVpc17bhhEsOPJ51m147iygDuy RvEfFiAckY57Ma3mJGoqEJ50wi X-Received: by 2002:a05:620a:580f:b0:8cd:75a9:eab9 with SMTP id af79cd13be357-8cd75a9ec10mr410940685a.14.1772923979416; Sat, 07 Mar 2026 14:52:59 -0800 (PST) Received: from rowland.harvard.edu ([2601:19b:d01:d210::687c]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cd7e857037sm90933585a.20.2026.03.07.14.52.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Mar 2026 14:52:57 -0800 (PST) Date: Sat, 7 Mar 2026 17:52:54 -0500 From: Alan Stern To: Liam Mitchell Cc: Jiri Kosina , Benjamin Tissoires , Oliver Neukum , linux-usb@vger.kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] usbhid: tolerate intermittent errors Message-ID: <6cbc6c70-8252-43d0-8701-e1613ddc769f@rowland.harvard.edu> References: <20260307-usbhid-eproto-v2-1-e5a8abce4652@gmail.com> 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: <20260307-usbhid-eproto-v2-1-e5a8abce4652@gmail.com> On Sat, Mar 07, 2026 at 07:57:09PM +0100, Liam Mitchell wrote: > Modifies usbhid error handling to tolerate intermittent protocol > errors, avoiding URB resubmission delay and device reset. > > --- > Protocol errors like EPROTO can occur randomly, sometimes frequently and are often not fixed by a device reset. > > The current error handling will only resubmit the URB after at least 13ms delay and may reset the USB device if another error occurs 1-1.5s later, regardless of error type or count. > > These delays and device resets increase the chance that input events will be missed and that users see symptoms like missed or sticky keyboard keys. > > This patch allows one protocol error per 500ms to be tolerated and have the URB re-submitted immediately. > > 500ms was chosen to be well above the error rate of a malfunctioning > device but low enough to be useful for users with devices noisier than > mine. > > Signed-off-by: Liam Mitchell > Link: https://lore.kernel.org/linux-input/CAOQ1CL6Q+4GNy=kgisLzs0UBXFT3b02PG8t-0rPuW-Wf6NhQ6g@mail.gmail.com/ > --- Liam, take a look at https://bugzilla.kernel.org/show_bug.cgi?id=221184 On Roman's system, these protocol errors occur fairly regularly, apparently caused by high system load. Do you think a better approach might be to reduce the 13-ms delay to just 1 or 2 ms, and perform a reset only there has been no successful communication for about one second? This might perhaps be _too_ lenient sometimes, but I don't think such situations will arise in practice. The reason for having at least a small delay is to avoid getting into a tight resubmit/error loop in cases where the device has been unplugged. Alan Stern