On Sat, Feb 25, 2012 at 01:59:41PM +0900, Julien Guertault wrote: > On Sat, Feb 25, 2012, Thomas Adam : > > On Fri, Feb 24, 2012, Michael Grosser : > > > >> Would it make sense to let touch screen support be a project idea > >> for GSoC 2012 or any other year in the future? > > > > No -- because I, nor anyone else really knows what "touch screen" is. And > > even then I don't understand what the problem is. FVWM isn't an application > > which needs changing to work on a touch screen interface; it manages those > > applications instead.
"Multi-touch support landing in X" http://lwn.net/Articles/475886/ If you have a new enough X server it is available to start playing with. > I suppose a first step would be to support multiple mouse pointers. I think they are independent problems. They both use a related extended cookie event system to access, once you can use one the other is easier to support, but it sounds to me like applications can make use of the touch events without a window manager that supports them, where applications can't really make use of multi-pointer X without window manager support because now you have two (or more) actively focused windows that need their keyboard pointed to follow the mouse, where as the touch interface is still one keyboard to track. I could be wrong with the touch interface as it's pretty new. The multi-poiner X is something I could make use of right now. It's easy enough to enable with two mice and the xinput program, then you have two pointers moving around. Generally anytime a program isn't using the new events, X picks which pointer to use in response to any queries, and in general a non-multi-pointer aware program will work fine as long as only one pointer tries to interact with it at one time. It's unusable though without a multi-pointer X aware window manager. It partly works with fvwm right now, the last pointer to enter a window shows focus, if one pointer is in one program and another pointer is in another program both can type to their window, but move the second pointer into the first window and the first keyboard continues typing to that window, but the second keyboard types to the window it left not the window with both pointers. That last one was the killer for me, I could live with the hilighted window being limited to one window, but having to move the other mouse into another window for the first to use it is unusable, if both keyboard could be pointed at the window and multiplexed, that would be enough. Especially in my case where I wanted a second mouse/pointer but still just one keyboard. Start out with a master pointer and master keyboard, create another set, find out the device id= values, move a pointer and a keyboard over to the new pointer and keyboard. Be careful of what you move where or you might not be able to type anymore, or better yet ssh in. I'm running X.Org X Server 1.11.3.901 2012-01-06, and the X server crashed the first attempt to remove the new master, so there are some bugs to be worked out yet. xinput create-master random_name xinput list Virtual core pointer id=2 [master pointer (3)] Synaptics Touchpad id=6 Virtual core keyboard id=3 [master keyboard (2)] AT Translated Set 2 keyboard id=10 random_name pointer id=12 [master pointer (13)] random_name keyboard id=13 [master keyboard (12)] xinput reattach 6 12 xinput reattach 10 13 then when you've had enough, xinput reattach 6 2 xinput reattach 10 3 xinput remove-master 13 I looked at adding multi-pointer X support to fvwm at one point in time, but figured the changes wouldn't be accepted unless it could fall back to the current input events, and that was more work than I wanted to hack together. > Then the user would probably want to have at least some conditional in > his configuration files to change the behavior when using a mouse > pointer that comes from the touchscreen. Because really, you don't > want to touch your windows with your fingers the same way you click at > them. > > You also want to know if the device has changed its mode to > touchscreen, to change the layout accordingly (bigger buttons, maybe > less decoration, etc). I'm thinking of tablet laptops here; they are > getting more and more popular, and when the interface is implemented > correctly, it really comes handy. > > -- > Julien Guertault -- David Fries <da...@fries.net> PGP pub CB1EE8F0 http://fries.net/~david/
