> 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. > 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. > 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. Thanks, Henrik -- 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
