From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752782AbdCFMbL (ORCPT ); Mon, 6 Mar 2017 07:31:11 -0500 Received: from mx2.suse.de ([195.135.220.15]:53907 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752807AbdCFMbC (ORCPT ); Mon, 6 Mar 2017 07:31:02 -0500 Date: Mon, 6 Mar 2017 13:15:27 +0100 (CET) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Benjamin Tissoires cc: Dmitry Torokhov , David Herrmann , Oliver Neukum , Jason Gerecke , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH] HID: get rid of HID_QUIRK_NO_INIT_REPORTS In-Reply-To: <20170105092144.17120-1-benjamin.tissoires@redhat.com> Message-ID: References: <20170105092144.17120-1-benjamin.tissoires@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 5 Jan 2017, Benjamin Tissoires wrote: > For case 1, the hiddev documentation provides an ioctl to do the > init manually. A solution could be to retrieve the requested report > when EVIOCGUSAGE is called, in the same way hidraw does. I would be > tempted to not change the behavior and hope that we won't break any > userspace tool. I'd like to be applying the HID_QUIRK_NO_INIT_REPORTS removal as soon as possible so that it gets exposure in linux-next over the whole development cycle. I am however too conservative to ignore the potential hiddev breakage, I am afraid. This has a real potential of breaking systems, and administrators having hard time figuring out of happened; essentialy, this is userspace-visible behavior change (regression) for which we haven't done any long-term depreciation (such as printing a warning "please talk to your hiddev driver vendor" in case the driver seems to assume initialized reports) at least for a few years. I think that either doing it at a connect time, or during first EVIOCGUSAGE ioctl() call is a must. Otherwise, I'd be super-happy to finally get rid of this giant PITA. Thanks! -- Jiri Kosina SUSE Labs