On Thu, Mar 11, 2010 at 5:30 AM, Peter Hutterer <peter.hutterer@xxxxxxxxx> wrote: > On Tue, Mar 09, 2010 at 11:42:34PM +0100, Mohamed Ikbel Boulabiar wrote: >> > 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 >> >> >> The hierarchy applied on multitouch isn't the best example to prove >> benefits of it. >> Hierarchy is useful with some complex input devices that have many >> axes, many buttons some accelerometers, but that are hierarchical from >> the source (integrality/separability ?). >> Then providing them as hierarchy can be useful. > > Are we talking about real input devices here or a hypothetical device? > If the former, what are examples for such an input device? What's the meaning of a hypothetical device ? Please note that here I speak about former input as to be handled by the kernel. If there is more complex handling it can be treated outside and virtual device files are created (to handle these hierarchical concepts). To eliminate misunderstanding, virtual device files represent what Stéphane first suggested as moving multitouch input (as reported from the kernel) to 2 mouse-like input reporting files. >> For multitouch devices, we don't need to make separation inside the >> multitouch protocol itself even for "simpler" devices like "double >> touch". >> >> The solution maybe to have other handlers to show virtual hierarchical >> devices in another virtual devices folder in addition to the old way. >> The handler read from the usual device file and provide other sources. >> >> Kernel modules will be then simple providing necessary input. And >> complex handling will be in an additional layer. >> User then will chose from where read the input : the old way or the >> dynamic with handler special ways. >> >> >> It should not also be in X. >> If things aren't in the kernel, they shouldn't so be in X by obligation. > > Don't forget that X' main functionality aside from displaying wobbly windows > is to be an input multiplexer. If some additional management layer is > needed, why should it be another layer on top of or below X instead of a > part of X itself? Ok, I know you represent now all the input handling in X. So I should have predicted such questions. :) The X evidence that it works as input multiplexer can't stay until the end of time. The number of projects emerging and that only use the Linux kernel without X aren't few. Why I should have access to advanced multi-touch handling ONLY in X meaning I should install also all the package ? Meaning in another software that should take care "mainly" of graphics. I will here cite some things about the past and what's is being done now : The graphics handling itself, wasn't done before in X ? And now isn't everybody tried to pull it out of it and putting it in the Linux kernel ? KMS: Kernel Mode Setting ? Isn't now better to have such handling done in kernel and have early access to graphics card without having the screen flashing many times disturbing users ? Isn't the switching to VT now better ? It's true that when X was first designed, its main functionalities were handling input&graphics in 'all' unix systems (which by case still remembers me Multics cause of failure...). Now the world changed and we should think about what system would be at least in the next 5 years. Many projects tried to replace X, from Framebuffer to Wayland without forgetting all other dead projects. Why ? ;-) Please don't see this as an attack to X.org, but otherwise a different point of view. When I've proposed, I have said that it can't be in X "by obligation". I have thoughts that is may be an additional layer, until many people decide to include it in the kernel if things become working great. This can help much embedded application that use FB or a display server but needs multi-touch and advanced input handling. Specially when comparing the number of people developing X, to those developing the Kernel. In other non-Linux systems, multi-touch is handled by a completely new input server. Anyway, forget all what I have said. How do you want to deal with multitouch and new input handling in X and why ? -- 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
