What To Expect From X Input 2.1; Multi-Touch Is Delayed

[phoronix]

Phoronix: What To Expect From X Input 2.1; Multi-Touch Is Delayed

While there has been an X.Org multi-touch implementation for X Input 2.1 dating back about a year, there's still no formal X Input 2.1 release (X Input 2.0 came in 2009). When X Input 2.1 is released, likely as part of X.Org Server 1.12, it won't even offer up the multi-touch support. Here's some of what you can expect to see from X Input 2.1 and then the X Input 2.2 milestone...

http://www.phoronix.com/vr.php?view=OTg2OA

[BlackStar]

Multitouch does not belong to the X server (and, in retrospect, Canonical was 100% correct to develop their own multitouch code independent of X).


High-resolution scrolling is what I'm keen on. It's been a long time coming, and it's really missing on Linux. If you have a high-res input device, the difference is obvious and ugly (compared to windows or mac os x).

[dalingrin]

I'm confused from the article xinput 2.1 and 2.2 are to be released with X.Org 1.12

"When X Input 2.1 is released, likely as part of X.Org Server 1.12"
"The plan is to have X Input 2.2 in X.Org Server 1.12"

[leif81]

Multitouch does not belong to the X server (and, in retrospect, Canonical was 100% correct to develop their own multitouch code independent of X).

I'm wondering about this too. Is any of this work Xinput work useful to Wayland?

[Remote User]

I'm running Debian Squeeze Testing and XFCE. My system detects the 3M Microtouch touchscreen and almost works, but it needs to be calibrated and the X/Y values are inverted. I can always run the Microtouch proprietary code to remedy this but I wish that the 'touchscreen experts' would get around to providing calibration code to this very popular touchscreen controller.

Close is still no cigar.

[BlackStar]

I'm wondering about this too. Is any of this work Xinput work useful to Wayland?

Not directly, that's the problem. I feel it would be better if X was confined to reporting raw events (as XInput valuators, which support multiple "streams" for multitouch devices) with the actual multitouch detection/responce being handled in a client library. This way, the library could remain portable between X, wayland and other systems without no additional cost to user applications.

Shoving extension upon extension to X just doesn't work anymore. The beast is old, complex, inefficient and suffers from many a design problem. Given the lack of manpower (how many years has multitouch been delayed again?), it doesn't really make sense to make X any more complicated than it already is.

KMS was a large step in the right direction, as is the removal of DDX drivers that was suggested recently.

[liam]

Multitouch does not belong to the X server (and, in retrospect, Canonical was 100% correct to develop their own multitouch code independent of X).


High-resolution scrolling is what I'm keen on. It's been a long time coming, and it's really missing on Linux. If you have a high-res input device, the difference is obvious and ugly (compared to windows or mac os x).

agreed, but it would've been useful only since we'd had tear-free drivers.

[liam]

[snip]...as is the removal of DDX drivers that was suggested recently.

Can you explain this a bit? How would that work? I know they are specific to X but aren't they, hence their name, Device Dependent, so they carry the code necessary to talk with X. So if you are still using X how can you get rid of this? I'm assuming gallium has something to do with this but I'm not sure what. At a high level, Gallium is supposed to be a (modern) virtual graphics card model, I think. So any modern card should be able to access analogous features through the interface (or rather the reverse, I suppose). So any state tracker should work on any card as long as the card is "modern", but each card would still need it's own driver b/c they are simply different, sometimes very different, hardware. It was that part that I thought was DDX hence my confusion. Additionally, since Intel doesn't use gallium they would have to be out of tree?

[BlackStar]

Can you explain this a bit? How would that work?

This is based on bits and pieces I've gathered from these forums and the mesa mailing list. My understanding is that DDX drivers provide acceleration for X (EXA, XRender). This is somewhat inefficient (codewise), because we have two different pieces of code that talk to the graphics card: Mesa (for 3d acceleration) and the DDX driver (for 2d acceleration).

This used to make sense back then when GPUs had two distinct engines for 2d and 3d engine (i.e. back in 2004), but modern (non-Intel) video cards do not have a 2d engine anymore. Everything is handled through the 3d engine, which is more capable and faster. (Intel is somewhat of an outlier since they still have 2d hardware in their chips. However, the state switching between 2d<->3d modes is so costly that Linux drivers now use the 3d engine throughout - there was a nice article in Phoronix a few months back with graphs showing how much faster the 3d engine is).

The proposal is to move 2d acceleration to the new X gallium3d state tracker that is being developed in Mesa. This would be much cleaner conceptually, since all acceleration code will be contained in the same codebase (2d, 3d, opencl, etc). It would also reduce the size of X, allowing its developers to focus on more important stuff.

Intel has shown legendary unwillingness to move to gallium3d, which means they'd still have to maintain their own code independently (and lose out on things such as MLAA). Fortunately, Google is maintaining gallium3d Intel drivers for their ChromeBook OS, which might pave the way for a unified stack.

agreed, but it would've been useful only since we'd had tear-free drivers.

Indeed, high-res scrolling with tear-free is awesome. I'd still take high-res with tearing over low-res with tearing, but the effect is *much* better with tear-free.

AFAIK, nouveau is the only driver left without tear-free (or is that fixed now)? Radeon, fglrx, nvidia and intel all seem to have tear-free options, at least when compositing is enabled.

(Oddly enough, fglrx is the one that can do tear-free on multiple monitors! Eyefinity support ftw.)

[daniels]

Not directly, that's the problem. I feel it would be better if X was confined to reporting raw events (as XInput valuators, which support multiple "streams" for multitouch devices) with the actual multitouch detection/responce being handled in a client library. This way, the library could remain portable between X, wayland and other systems without no additional cost to user applications.

Portability in itself buys you very little because the X11 and Wayland input systems are fundamentally different. We do have a common library, called mtdev, which does the lowest-level work. But the X11 and Wayland multitouch models will, by necessity, look nothing alike.

Most of the complexity comes from the need to have multitouch events working in parallel with legacy X pointer events (and when I say 'legacy', I don't just mean 25-year old core events, I mean XI 2.1 events too). Bearing that in mind, our aim is to do the bare minimum of work in the X server; only what's absolutely required, and the rest in clients. Funnily enough, Wayland will have a lot _more_ complexity in the compositor for multitouch than X will in the server.

As for the 2.1/2.2 confusion: what he's saying is that 2.1 will be in 1.12 unless the sky falls on our heads tomorrow. 2.2, with multitouch, will be in 1.12 if it's ready.