I asked this question on the main kernel list, not realizing
linux-input existed - sorry. Let me try this again.
I have a touchscreen device that uses an egalax controller. When it
starts up, it gets grabbed by hid-generic. The basics work, but for
some reason a few manufacturers put the touch controller 90 degrees
out of whack with the actual display, so you have to do an affine
transform to rotate it either CW or CCW 90 degrees like this:
abs_y = x
abs_x = YMAX - y
The way I normally would fix this is all within xorg, but what I'm
doing right now is for android and I need to fix it up entirely in the
driver. The trouble is, hid-generic grabs the device, and there's not
really a place in there (at least not that I can see) where I would
want to do this.
What I would like to do is make a replacement driver that can,
optionally, give you a place to poke in a transformation matrix -
perhaps into /sys somewhere, I think I know how to do this:
- I added an option to Kconfig called (for now) HID_EGALAX_CHRISP
- Modified drivers/hid/Makefile to add obj-${CONFIG_HID_EGALAX_CHRISP}
+= hid-egalax-chrisp.o
- Modified drivers/hid/hid-quirks.c such that this particular VID:PID
combination does not include HID_QUIRK_MULTI_INPUT
- Make a .config that turns that driver on
My template is basically the ALPS touch driver. My driver is
basically empty right now. It declares its interest in this specific
device:
static const struct hid_device_id hid_device_table[] = { {
HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, 0xeeef, 0x0001) }, { } };
MODULE_DEVICE_TABLE(hid, hid_table);
and it declares a HID callback table that looks like this:
static struct hid_driver hid_egalax_driver = {
.name = "hid-egalax-chrisp",
.id_table = hid_device_table,
.input_mapping = egalax_input_mapping,
.input_configured = egalax_input_configured,
.raw_event = egalax_raw_event,
.probe = egalax_probe,
};
module_hid_driver(hid_egalax_driver);
All those functions just do printks so I can try to figure out what
it's doing then build up a real driver from there.
The problem I have is that even with all these declarations
hid-generic still grabs control of the device and none of my own
functions ever get called.
I have two questions here:
- What exactly is the procedure by which you tell the HID subsystem
"Don't use generic, I have a specific driver for this?"
- Is my overall approach here sound? i.e. should I be adding
a quirk instead? (Not all eGalaxy devices will be rotated, though,
so it would still have to someone be user-configurable)
--Chris
