> One would be separation of concerns. If I'm interested in single touch > events, I'd be better off with no "multitouch noise". If I'm interested > in low level events, I'd be better off without the interference created > by all sorts of "clever" event emulation in drivers. An easy way to do > this is to have a different input node for each protocol. Keeping backward compatibility with single-touch userland does not really clutter the driver -- adding single-touch events to a clean multi-touch driver is just a handful of lines. [snip] > On another note, having multiple input nodes is a relevant question when > dealing with multitouch anyway. Let me take an example: consider two > users, each interacting with their own application in its own window but > on the same display. Now, consider these two input possibilities: either > each has their own mouse, or they both use the same dual-touch panel. In > the first case, each app can open its own input node; in the second, > they need to share the same device and perform some filtering to extract > the events they want (user1 or user2). The symmetry breaking between the > two situations is not satisfactory: you need to change the code in the > apps. Symmetry is also restored by passing all single-input devices as MT packets. > With this regard, I am a big fan of the idea of having hierarchical > devices, just like with have hierarchical file systems. Each finger on > the dual-touch panel would be a device, child of the panel device. Each > would be equivalent to a mouse, and voila, the symmetry is restored. > Conceptually, saying (panel/finger1, any event) or (panel, finger1 > events) are equivalent; but in the first case the routing is done by the > OS and in the second case it has to be done by the app, which breaks > reusability. There are other interesting perspectives, but I don't want > to get carried away too much. A hierarchy is imposing an unnecessary restriction on the graph of possible relations between point devices. Consider for instance the case of two people, each with one finger on the panel. The hierarchy says panel-person1-finger1 and panel-person2-finger1. Now have them move close enough for the fingers to touch. The hierarchy now says panel-person-(finger1, finger2). Symmetry breaking once more. The main point here is that however the data reaches userland, it will have to be processed intelligibly and collectively. The point of processing could be an MT X Driver, it could be some other input section, but it is has to be done somewhere. 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
