Op 07-02-12 17:12, Henrik Rydberg schreef:
Ok, so it's pretty clear the consensus is that there should be a
different interface to push the data to user space.
My initial reaction is V4L, as the data is basically a stream of
monochrome frames, this kind of fits the video description. Also,
this could be of some benefit to all those
emulate-multi-touch-using-webcam projects.
On the other hand, your device, and the ones to come, are likely not
normal ccd cameras, and the interface is bound to be different; you
would most likely prefer the stream to be silent when there are no
touches, for instance, and only generate interrupts or new-data events
as there is something to react to.
True, I had forgotten about that. There are no HID packets sent when
nothing touches the surface and the CPU shouldn't needlessly spent
cycles on parsing an empty stream.
Other options I see are mmap on the input device, creating a
separate (char?) device, UIO or even having the whole thing in
userspace.
Personally, I think mmapped input devices would be a great extension
to the input subsystem. I am thinking event types distributed in a 2D
plane, maybe one node per type, and signalled by normal input events
of the data-to-read type.
Ok, I'll look into that!
However, there's one tiny hack I'd like to have and I'm unsure
whether this can be done from userspace: as the mouse has only one
physical push button, it can't distinguish between left, middle or
right click.
Obviously, it can do this based on the information it gathers from
its touch surface, however the firmware has only the following dumb
implementation: when only one finger is present on the right part of
the surface, assume right click; otherwise assume left click. This
means that you need to lift your left finger when performing a right
click.
Now, the receiver is represented as 3 HID devices: one keyboard
descriptor, one mouse descriptor and one miscellaneous/control
descriptor (containing touch surface data). My plan was to intercept
mouse clicks on the mouse descriptor and look at what part of touch
surface (left/right) has the most pressure and, if needed, swap the
click to a right click.
Any hints on how to do this in userspace? Of course I could hack up
xf86-input-evdev, but I'd like to do this at the highest possible
layer, ie the input subsystem.
The application you describe could well be implemented in the driver
you submitted; a simple handling of the MT data resulting in normal
input events.
Yes, that was my initial idea. But as I had the impression that an
userspace solution was preferred, I wondered how to solve that.
--
Maurus Cuelenaere
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
