Thanks to drupal, I actually get quite a good picture where people are coming from when visiting this page. Every once in a while, MPX pops up in some slashdot comment. This time, it showed me that I need some additional explanation about some of MPX principles.

serialdogma writes "X11 in it self still only has one CorePointer and one set of Keyboard focus, even with mpX".

This is not true.
MPX is "X11 in it self". A lot of rules that apply for a client don't apply when you're hacking on the windowing system itself. Such as the "there is only a single focus" rule.

If you plug in 5 mice, you get 5 core pointers.

If you plug in 5 keyboards, you get 5 keyboard foci. Keyboards have to be tied to mice, and if you have 5 keyboards but only one mouse, all 5 keyboards will follow the mouse.

serialdogma continues with "MpX does indeed let you have multiply pointers and focuses, but it does this by providing a new extension to libX,"

The pointers/foci don't have anything to do with the extension. XInput was modified to provide some additional requests and events, but you only need it if you want to know which device an event is coming from. If you don't, continue to use core X events. Regardless of whether you use XInput or not, you will have multiple foci and multiple pointers.

finally "and for older non-modified clients provides a crude multi-pointer to single pointer mapping."

This is true. For all applications that don't know about multiple pointers, there ain't much I can do. Consider the following simple pseudo code.

void handleEvent(MouseEvent ev) {
   isDown = ev.button1.isdown.
}

The logic of this application only accommodates for one mouse. Any mouse event will overwrite the isDown field, regardless of what mouse it is coming from.
Think of the GIMP: if you press the Pencil button, GIMP switches to the Pencil. It does not remember that a different mouse before selected the Erasor tool. No matter what we do, we will not be able to make apps like this multi-device aware without changing the app itself.

What we can do, is adjust the event delivery to not confuse the application. So even when we use multiple mice, you can still use the app, albeit with a few interesting behaviours. I'm going through quite a lot of trouble to make standard apps work well, and so far I'm actually quite happy with the result.

Once again:
You do get multiple pointers and foci but you don't have to use XInput unless you want to.

Look at MPX on youtube. None of the apps use XInput. Only the window manager does, and by doing so it allows funky stuff like moving multiple windows simultaneously.

Woohey. After a day of hacking it's done. MPX supports multi-monitor setups.
The price for the first not-me contributer to MPX goes to .... tataaa! ... Paulo Zanoni.
Paulo sent me a patch to get the event delivery right for multi-head setups. I spent this afternoon getting the cursor rendering on the second screen done without crazy artefacts. Funnily enough, I spent about as much time hacking as I spent looking for a card with multi-head opensource drivers and getting my dualhead setup working. My testbox now features a Tseng ET3000 which we found in some old Pentium 90 box. And the old crappy monitors should ensure I get a decent tan in the upcoming winter.

Some headers changed, so you better recompile the server.

And another thing I noticed: the enter/leave and focus in/out changes I pushed a while ago seemed to have fixed up the problems with KDE. All works smoothly now.

Today one year ago I posted the first announcement of MPX on the mailing list.

We've gone from being a completely hack that only supported mice to being nicely integrated and support hotplugged mice and keyboards. Yay! Was more work than I would have guessed :)

Zephaniah had a go at the evdev driver today and ripped it's internal hotplugging out. Which means that all hotplugging stuff goes through the server now. And that the master branch can finally hotplug without problems.

And I've just pushed the changes to notify interested clients about enabled and disabled devices and - more importantly - the ability for a driver to remove itself if it gets a read error on the device. In which case the client is notified as well. Could be handy.

Only for evdev driver so far.

Those changes are on master, it will get merged into MPX soon. Paulo Zanoni sent me a patch to enable multi-head setups with MPX and I want to merge that one in first.

There are four events that deal with focus in X. EnterNotifies, LeaveNotifies, FocusIn and FocusOut. The former two are pointer focus, the latter two are keyboard focus.

Whenever the pointer moves into a window, a LeaveNotify is sent to the previous window, and an EnterNotify is sent to the new window. Some events are sent to the ancestors of those windows too.
If we have a window hierarchy like this:

A -> B -> C
 \  
   -> E -> F

Then moving the pointer from C to F will send events to C, B, E and F.

The initial solution I had was just to ignore it and let all devices send events. Now this led to confusion to a lot of apps (examples: xterm and pretty much everything using GTK), because getting a LeaveNotify may cause the app to stop listening to user input. Funny thing, when your pointer is on a button but you just can't click it. Not high in terms of usability though.

So I tried to reduce these problems by extending the original semantics of the core protocol to both work with legacy applications but also comply to the definitions in the protocol specification (translation: I made it work).

So the situation now is as follows:
EnterNotify events are sent for the first pointer entering a window.
LeaveNotify events are sent when the last pointer exits a window.
Events that go to various ancestor windows are still sent for each device. But if an ancestor windows has a pointer inside it's boundaries, it won't get those events.
FocusIn and FocusOut events use the same semantics.

I have been asked repeatedly what the use cases are for MPX, so here's the main ones I can think of for now:

Single-user:

• Two-handed interaction. Allows you to move two axis at once, so it is good for 3D, music apps where you may have to move two sliders simultaneously, etc.
• Multi-touch touchscreens. It can be handy to tell that you pressed a button with the middlefinger of the right hand. (fortunately, how the touchscreen identifies the finger is not my problem :)

Multi-user:

• Structured collaboration. You have a projector setup in a meeting room, all meeting attendees can interact. Good for keeping minutes or brainstorming.
• Ad-hoc collaboration. Ever had a problem and needed your co-worker's help? Ever got frustrated by having to pass the keyboard around? Just plug in another mouse and keyboard and you can fix whatever is the issue independently.
• Games. A unified interface to get independent mouse coordinates. Useful

Now I admit that those ideas aren't necessarily new. Two-handed interaction was researched by e.g. Buxton in the 80s, multi-touch screens are available now and every man and his dog (including me of course) has written a multi-device toolkit.
Writing an app that supports two mice is easy. But if you don't provide multiple devices at the windowing system level, you can't get very far, especially when it comes down to supporting standard applications. Which is how MPX got started.

And there are other ideas I didn't think of: XAT from the C3SL group in Brazil is a multi-seat solution. One computer, multiple screens, multiple users, all working away on their tasks. Cheaper than multiple computers.

I guess over time people come up with more ideas, as soon as we get the single-mouse single-keyboard limitation out of our heads.

You may want to read Groupware Support in the Windowing System, which describes some of the theory and details of the first implementation of MPX.

I filmed a short video of MPX in action this week and uploaded it to YouTube.

It shows a bit of two-user interaction, what happens when you plug in a mouse and a bit of me messing around with windows. Have fun.

Here's a hint I realised myself today:

Amongst a number of things that are changed in MPX is the input focus handling. The XSetInputFocus() call is obsolete, as it doesn't specify a device and the server has to guess one. To get proper use from multiple keyboards, the window manager has to call XSetDeviceFocus() instead, with the keyboard device as an argument.
I also put my dodgy window manager online, so you can clone it [1]. I can't recommend using it as your default window manager but it certainly shows what a WM could do if it knows about MPX.

I guess eventually I should write man pages for all the calls. Anybody volunteering?

[1] git://people.freedesktop.org/~whot/mpwm

Here's a current screenshot showing off the ClientPointer principle. The ClientPointer principle reduces ambiguity in the core Xlib APIs. Each client can have a ClientPointer set, and any call that doesn't specify a device but requires device data (e.g. QueryPointer) will default to the ClientPointer. This is a screenshot of two xeyes with different client pointers and gnome-terminal and firefox with different settings so the popup menus are owned by the different pointers.

The cursors are numbered in reality, but I had to put them in with the GIMP afterwards. When you take a screenshot with xwd, the cursors are missing from the shot. Still, it looks as it would look on the screen.

Found out that MPX is the number one link on google (both google.com and google.com.au). Not too bad for a TLA. Yay. I'm feeling lucky.