public inbox for linux-input@vger.kernel.org
 help / color / mirror / Atom feed
From: Rafi Rubin <rafi@seas.upenn.edu>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jiri Kosina <jkosina@suse.cz>,
	linux-input <linux-input@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: calibrating a hid device
Date: Tue, 25 May 2010 03:15:42 -0700	[thread overview]
Message-ID: <1274782542.1572.14.camel@tron> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1005242151320.8440-100000@netrider.rowland.org>


----- Original message -----
> On Mon, 24 May 2010, Rafi Rubin wrote:
>
> > Ok, pardon that excessive attachments.  Attached is a snip of the kernel code,
> > just the sysfs function, the user space equivalent, and logs of both (with the
> > time stamps cropped out for comparison.
>
> Since the logs are the same, up to the point where the interrupt-IN
> request is cancelled, it's logical to assume that the difference was
> caused by something that happened before you began the usbmon traces.
>
> Do it again, only this time start the traces before plugging in the
> device.  That way we'll get a complete record.  And don't worry about
> cropping out the timestamps; sometimes they reveal useful information. 
> For example, here they would have told us if the interrupt-IN request
> failed because it timed out too quickly.
>
> > Also please put on slop code filter glasses before reading the code, I hold no
> > responsibility to damaged eyes or loss of sanity.  It will be cleaned up,
> > later.
>
> Aside from not using the predefined constants for the bRequestType
> values, what stands out most is that you're using I/O buffers allocated
> on the stack.  That's a no-no (not all architectures are capable of
> doing DMA to stack-based locations); I/O buffers should be allocated
> dynamically using kmalloc.
>
> Alan Stern

thanks for the feedback.  The events are really fast on one of my digitizer, yet seem to be not returning on another.  I'm also starting to think that some of the returns that I thought were erroneous on the good device, might have a different meaning, such as perhaps "already well calibrated, nothing interesting to report".

Sorry about the raw values for request types, I've been keeping them visually similar to the usbmon traffic for my benefit, until I'm comfortable that I've got it all good enough.

As for the logs, I cropped copies for inspection with a highlighting diff tool, I will make sure to send the full versions in the future.

I need to tweak it a bit more, and then should be able to give more details about what's going right and wrong.


Rafi
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2010-05-25 10:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-24 20:11 calibrating a hid device Rafi Rubin
     [not found] ` <4BFADD60.7020901-hkHJxBBPWjbG6jMu9gPlYQ@public.gmane.org>
2010-05-24 20:20   ` Jiri Kosina
2010-05-24 22:54     ` Rafi Rubin
2010-05-25  1:59       ` Alan Stern
2010-05-25 10:15         ` Rafi Rubin [this message]

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=1274782542.1572.14.camel@tron \
    --to=rafi@seas.upenn.edu \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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