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. :)
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).