All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Moles <jeremy@emperorlinux.com>
To: linux-input@vger.kernel.org
Subject: Re: Researching An Experimental Touchscreen Driver
Date: Sat, 27 Nov 2010 17:48:23 -0500	[thread overview]
Message-ID: <1290898103.2005.13.camel@bathysphere> (raw)
In-Reply-To: <1290614820.3294.37.camel@bathysphere>

On Wed, 2010-11-24 at 11:07 -0500, Jeremy Moles wrote:
> Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> kernel (though I can easily change kernels if needed) that has attached
> to it internally a USB touchscreen device. The relevant DMESG info is
> below, and this is printed out whenever the module 'usbhid' is loaded.
> 
> --------------------------------------------------------------------
> 
> usbcore: registered new interface driver hiddev
> input: Fujitsu Component USB Touch Panel
> as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> 
> --------------------------------------------------------------------
> 
> For a long time now, we have been successfully configuring these
> machines using the device node created when this driver is loaded, often
> something like /dev/input/event5 (with a UDEV rule to make the name more
> sensible). In X, we've been using the "evtouch" driver with this device
> node, to great effect.
> 
> However, I am doing a bit of research and experimentation, and what I
> would like to do is write some custom driver code to interface with this
> device, instead of letting usbhid manage it. My question is, where is
> the best place to start?
> 
> - Since usbhid already recognizes and binds to this device, what code
> can I begin studying to see exactly how it's detecting this and
> formatting input?
> 
> - Once usbhid attaches to this device, is the device in some kind of
> lock? Is it possible to simply inject additional features or formatting
> functions, possibly via quirks? (I don't quite understand how to do
> anything with quirks other than blacklist a device).
> 
> - If I want to write a full driver for the device, what source file
> would be best to start from? I've tried hacking usbtouchscreen.c and
> hid-ntrig.c for the last few days to try and get them to bind to the
> device, but neither attempt has seen any success. My hid-ntrig change
> refuses to successfully call hid_parse(), and my usbtouchscreen change
> continually returns some error code in the IRQ callback.

I hope this isn't bad etiquette to self-bump my owns posts... I was just
curious if anyone might have any advice. I've continued to hack around,
and I'm certainly gaining more knowledge, but not quite there yet.

Is there a good primer anywhere, or does have any skeleton code they
use, for writing input drivers in Linux? The code is already there in
usbhid.ko for this particular device, so I know it's just a matter of
piecing it together, adding my modifications, and making them play
nice. :)



  reply	other threads:[~2010-11-27 22:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-24 16:07 Researching An Experimental Touchscreen Driver Jeremy Moles
2010-11-27 22:48 ` Jeremy Moles [this message]
2010-11-27 23:51 ` Dmitry Torokhov
2010-11-28  2:23   ` Jeremy Moles
2010-11-28  3:07     ` Dmitry Torokhov
2010-11-28  4:12       ` Jeremy Moles
2010-11-28  5:55         ` Dmitry Torokhov
2010-11-28  6:38       ` Dmitry Torokhov
2010-11-28 15:38         ` Jiri Kosina

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=1290898103.2005.13.camel@bathysphere \
    --to=jeremy@emperorlinux.com \
    --cc=linux-input@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.