1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Canonical's X Gesture Extension Being Re-Evaluated

X.Org

Published on 28 August 2010 12:43 PM EDT
Written by Michael Larabel in X.Org
10 Comments

Earlier this month Canonical introduced its own multi-touch framework for Ubuntu that is set to premiere with Ubuntu 10.10 "Maverick Meerkat" and it's called UTouch and is joined by their own gesture/touch language. That same day as announcing UTouch for Ubuntu that will support devices like the Apple Magic TrackPad and Dell XT2, Canonical proposed the X.Org Gesture Extension to the X.Org development community. While it's good to see Canonical making more contributions to upstream projects that it depends upon for Ubuntu Linux, the X.Org Gesture Extension is already being re-evaluated and may in fact not be needed.

Since Canonical's Chase Douglas published his xorg-devel email in which he laid out their proposed specification for X.Org Gesture Extension protocol v1.0, there's been some dissenting opinions by X.Org developers about how the gesture recognition should be handled. Part of this proposed gesture extension provides an interface for X clients to register and receive gesture primitive events and X clients to then act as a gesture engine. Canonical is of the belief that the gesture handling should be handled server-side by X while the X.Org developers -- such as Kristian Høgsberg and MPX-creator Peter Hutterer -- want this input gesture recognition to be handled client-side out of the X.Org Server.

In a new email by Chase, Canonical justifies the gesture recognition per the X.Org Gesture Extension proposal to be handled within the server for the following reasons: 1. With handling of input events (touches) that may span multiple windows, but the recognized gesture event is supposed to only affect the first window, the X.Org Server shouldn't be firing off the input events to any other windows. 2. If the handling is done by the client, there's also the possibility the recognition would occur twice -- once by the window manager and then again by any window clients that may want to recognize their own input events. Canonical admits though that if this task were to be performed twice there would be little in the way of latency problems. 3. Lastly, multi-touch events are not exposed to the client in the X.Org Server used by Ubuntu 10.10, where Canonical wants this first cut of UTouch / X.Org Gesture Extension to be deployed.

The common position against having the gesture recognition engine in the X Server and instead on the client-side (such as within the window manager instead), can be summarized by Carsten Haitzler with "I absolutely agree with peter on this. Frankly the problem is that input from a mouse, or a tablet or multiple touch-points is ambiguous. You may be painting in GIMP - not trying to "swipe to scroll". I can go on with examples (dragging a slider inside a scrollable area as opposed to wanting to scroll with a drag). Only the client has enough detailed knowledge of the window contents, application mode etc. To possibly make a reliable guess as to which one to do. It's X's job to provide as much device input to the client as it needs in a sane digestible way to make such a decision, but... that's [in my honest opinion] where the server's job ends."

Chase does acknowledge, "It's true that the logic behind point one may be perfectly fine, but having recognition through X inserts a lot of extra code into the server. If we are content with touches being split up into window regions before recognition occurs, then we may be able to get around the need for the X Gesture extension completely. The window manager use case could be supplied through input grabbing and event replaying."

We will see how this ongoing architectural debate ends, but for Ubuntu 10.10 at least it will be handled server-side.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
  2. Is The Open-Source NVIDIA Driver Fast Enough For Steam On Linux Gaming?
  3. Linux 3.18 File-System Performance Minimally Changed But Possible Regressions
  4. AMD Radeon Gallium3D Is Catching Up & Sometimes Beating Catalyst On Linux
Latest Linux News
  1. Linux 3.18 Kernel: Not Much Change With Intel Haswell Performance
  2. More File-System Tests Of The Linux 3.18 Kernel
  3. Using NVIDIA's NVENC On Linux With FFmpeg
  4. There's Talk Again About An "Open To The Core" Ubuntu Laptop
  5. PowerVR SGX Driver Code Gets Leaked
  6. V2 Of KDBUS Published For Linux Kernel Review
  7. VirtualBox 4.3.20 Arrives, Still No Sign Of VirtualBox 4.4
  8. Scientific Linux 6.6 vs. Scientific Linux 7.0 Benchmarks
  9. Qualcomm Looks To Get Into The ARM Server Business
  10. HHVM 3.4 Adds New Features, Support
Latest Forum Discussions
  1. Roadmap to Catalyst 14.10 ?
  2. Cant get working Kaveri APU - A10-7850k
  3. Debian Developer Resigns From The Systemd Maintainership Team
  4. Script for Fan Speed Control
  5. Debian Init System Coupling Vote Results
  6. The Slides Announcing The New "AMDGPU" Kernel Driver
  7. Updated and Optimized Ubuntu Free Graphics Drivers
  8. Ubuntu Developers Still Thinking What To Do About Adobe Flash Support