From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934627AbbCPWgy (ORCPT ); Mon, 16 Mar 2015 18:36:54 -0400 Received: from mail-pa0-f44.google.com ([209.85.220.44]:35084 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934433AbbCPWgj (ORCPT ); Mon, 16 Mar 2015 18:36:39 -0400 Message-ID: <55075AF4.1000807@gmail.com> Date: Mon, 16 Mar 2015 15:36:36 -0700 From: Jason Gerecke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Tissoires CC: Jiri Kosina , Ping Cheng , Linux Input , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] HID: wacom: ask for a in-prox report when it was missed References: <1425595014-23048-1-git-send-email-benjamin.tissoires@redhat.com> <20150316192733.GD4053@mail.corp.redhat.com> <55074239.4070407@gmail.com> <20150316210417.GE4053@mail.corp.redhat.com> In-Reply-To: <20150316210417.GE4053@mail.corp.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/16/2015 2:04 PM, Benjamin Tissoires wrote: > On Mar 16 2015 or thereabouts, Jason Gerecke wrote: >> On 3/16/2015 12:27 PM, Benjamin Tissoires wrote: >>> On Mar 16 2015 or thereabouts, Jason Gerecke wrote: >>>> On 3/16/2015 7:50 AM, Jiri Kosina wrote: >>>>> On Thu, 5 Mar 2015, Benjamin Tissoires wrote: >>>>> >>>>>> If noone listens to the input device when a tool comes in proximity, >>>>>> the tablet does not send the in-prox event when a client becomes available. >>>>>> That means that no events will be sent until the tool is taken out of >>>>>> proximity. >>>>>> >>>>>> In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will >>>>>> read the corresponding feature and generate an in-prox event. >>>>>> To make some generation of hardware working, we need to unset the >>>>>> quirk NO_GET set by hid-core because the interfaces are seen as "boot >>>>>> mouse". >>>>>> >>>>>> We don't schedule this read in a worker while we are in an IO interrupt. >>>>>> We know that usbhid will do it asynchronously. If this is triggered by >>>>>> uhid, then this is obviously a client side bug :) >>>>>> >>>>>> Signed-off-by: Benjamin Tissoires >>>>> >>>>> Ping, Jason, I'd like to get your Ack on this before pushing this through >>>>> if possible. >>>>> >>>>> Thanks. >>>>> >>>> >>>> This update seems to have solved the issue I was having earlier. I do >>>> still see some weird behavior with the Intuos3 though. For whatever >>>> reason, if a tool is in prox and no client is connected, the device >>>> will repeatedly connect and disconnect from the bus. For example, >>>> while sitting at a VT after connecting the device: >>>> >>>> [ 209.890431] usb 2-1.5.4: new full-speed USB device number 10 using ehci-pci >>>> [ 209.992189] input: Wacom Intuos3 6x8 as >>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.0009/input/input26 >>>> [ 209.992475] input: Wacom Intuos3 6x8 Pad as >>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.0009/input/input27 >>>> [ 209.992846] wacom 0003:056A:00B1.0009: hidraw4: USB HID v1.00 Mouse >>>> [Tablet PTZ-630] on usb-0000:00:1d.0-1.5.4/input0 >>>> [ 213.022545] usb 2-1.5.4: USB disconnect, device number 10 >>>> [ 213.344055] usb 2-1.5.4: new full-speed USB device number 11 using ehci-pci >>>> [ 213.445779] input: Wacom Intuos3 6x8 as >>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.000A/input/input28 >>>> [ 213.446185] input: Wacom Intuos3 6x8 Pad as >>>> /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5.4/2-1.5.4:1.0/0003:056A:00B1.000A/input/input29 >>>> [ 213.446703] wacom 0003:056A:00B1.000A: hidraw4: USB HID v1.00 Mouse >>>> [Tablet PTZ-630] on usb-0000:00:1d.0-1.5.4/input0 >>>> [ 214.815925] usb 2-1.5.4: USB disconnect, device number 11 >>>> [ 215.246142] usb 2-1.5.4: new full-speed USB device number 12 using ehci-pci >>>> >>>> [ ... and so on ...] >>>> >>>> It makes using the device from a VT difficult (e.g. for debugging), >>>> but in the typical case where X is started shortly after boot and >>>> hotplugs devices as soon as they're available it shouldn't pose a >>>> problem. If Benjamin has any ideas I'd like to hear them, but in the >>>> meantime I'm comfortable seeing this go upstream: >>> >>> HID_QUIRK_ALWAYS_POLL :) >>> >>> Some usb devices do not like to not be polled and keep >>> disconnecting/reconnecting. Looks like the Intuos 3 is one of them. >>> The only cons are that the device won't save power when no one is reading >>> the inputs. Not sure if that is a requirement for Wacom tablets though. >>> >>> Note that HID_QUIRK_ALWAYS_POLL should make this patch useless in these >>> cases, the kernel will keep track of the current device because it will >>> receive the events. >>> >>>> >>>> Acked-by: Jason Gerecke >>> >>> Thanks! >>> >>> Cheers, >>> Benjamin >>> >> >> That does indeed seem to solve the Intuos3 weirdness :) >> >> Saving power is a big deal for ISDv4/5 sensors where it has a direct impact >> on runtime. If setting HID_QURIK_ALWAYS_POLL e.g. disables USB selective >> suspend then that'd be an issue. However, if it simply causes the kernel to >> respond to events even if nobody is listening then it'd probably be similar >> to the situation when we were under drivers/input. >> >> I'm inclined to say we should target that quirk at only those devices that >> need it since I know tablet PC manufacturers go to quite some lengths to >> minimize every mA of unnecessary current draw from the batteries. >> > > Just a thought, but it looks like the problematic generation have the > QUIRK_NO_GET set by hid-core (boot interface). If you are on it, could I > ask you to test to set HID_QUIRK_ALWAYS_POLL and unset HID_QUIRK_NO_GET > only if HID_QUIRK_NO_GET was set? > > IIRC, there was no problems on the Intuos 4+ with the USB suspend, so > maybe that trick would be enough. > > Cheers, > Benjamin > > I'm not sure that'll be enough. Most of our devices use a boot mouse interface, even some that work fine using the default quirks (e.g. Cintiq 24HDT). On the tablet PC side of the world, it looks like its a crapshoot whether the sensor will have a boot mouse collection or something else (though I haven't yet checked to see how they react to having a pen in prox without a client). -- Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That is to say, eight) to the two, / But you can’t take seven from three, / So you look at the sixty-fours....