public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gerecke <killertofu@gmail.com>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Jiri Kosina <jkosina@suse.cz>, Ping Cheng <pinglinux@gmail.com>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] HID: wacom: ask for a in-prox report when it was missed
Date: Tue, 03 Mar 2015 17:30:42 -0800	[thread overview]
Message-ID: <54F66042.60107@gmail.com> (raw)
In-Reply-To: <1425403228-19841-1-git-send-email-benjamin.tissoires@redhat.com>

On 3/3/2015 9:20 AM, 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.
>
> We don't schedule this read while we are in an IO interrupt because 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 <benjamin.tissoires@redhat.com>
Ping and I were both a little confused by this patch. Our first 
impression was that this wouldn't accomplish anything since the driver 
would see events from the tablet regardless of if a client were 
connected or not. Testing proved us wrong though, with the events 
clearly going to that great /dev/null in the sky. Is this behavior 
different from the USB and HID subsystems? IIRC, the prox code didn't 
use to behave like this...

Under the assumption that USB events are indeed being dropped until a 
client is connected, then this patch looks fairly reasonable. It 
doesn't, however, seem to work reliably across tablets. An Intuos Pro 
reacted as I'd expect (with the patch in place, already-in-prox tools 
actually send events once e.g. evemu-record is run) but didn't seem to 
do anything for an Intuos5 or Intuos3 (nothing comes through 
evemu-record until I removed the tool from prox and then put it back in).

-- 
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....

> ---
>   drivers/hid/wacom_wac.c | 18 +++++++++++++++++-
>   1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index 9ec4545..ff9a7ab 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -430,6 +430,19 @@ exit:
>   	return retval;
>   }
>   
> +static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
> +{
> +	struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
> +	struct hid_report *r;
> +	struct hid_report_enum *re;
> +
> +	re = &(wacom->hdev->report_enum[HID_FEATURE_REPORT]);
> +	r = re->report_id_hash[WACOM_REPORT_INTUOSREAD];
> +	if (r) {
> +		hid_hw_request(wacom->hdev, r, HID_REQ_GET_REPORT);
> +	}
> +}
> +
>   static int wacom_intuos_inout(struct wacom_wac *wacom)
>   {
>   	struct wacom_features *features = &wacom->features;
> @@ -609,8 +622,11 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
>   	}
>   
>   	/* don't report other events if we don't know the ID */
> -	if (!wacom->id[idx])
> +	if (!wacom->id[idx]) {
> +		/* but reschedule a read of the current tool */
> +		wacom_intuos_schedule_prox_event(wacom);
>   		return 1;
> +	}
>   
>   	return 0;
>   }

  reply	other threads:[~2015-03-04  1:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 17:20 [PATCH] HID: wacom: ask for a in-prox report when it was missed Benjamin Tissoires
2015-03-04  1:30 ` Jason Gerecke [this message]
2015-03-04 16:00   ` Benjamin Tissoires

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F66042.60107@gmail.com \
    --to=killertofu@gmail.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pinglinux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox