Another set of changes just went online, this time some very fundamental stuff.

First of all, I fixed the mess that was called PointerGrabs. Especially device grabs were stickytaped on that it wasn't funny and in order to make it work in MPX, I had to do quite some changes. Each device can now have two grabs, a core grab and a device grab (for the respective events). So while you can grab a device and only your client gets XI events, the device may still send core events to some other app. Basically this is what happened before, but it was hacked around the single core pointer notion and fixing it required some changes.

I introduced the notion of a ClientPointer, something that came up in talks with David Reveman and Egbert Eich after the XDC07. Each client can be associated with a pointer. Should the client send ambiguous requests (e.g. QueryPointer, GrabPointer, GrabKeyboard, etc), MPX will pick the associated ClientPointer. Note that this is limited to ambiguous requests. Event delivery is the same and you can still interact with any client, regardless of the ClientPointer setting. Ideally, the window manager should adjust the client pointer all the time as users interact with an application. It isn't perfect, but it's about the best you can do when you have a stupid app that thinks there's only one pair of input devices.

The ClientPointer and the grab fixes make it now possible to really interact independently. Before, one device could steal the popups from another device, etc. This is fixed now, as events from a non-grabbed device will only be delivered to other client applications but not to the grabbing one. Two popups on one screen seems boring, but was actually quite hard.

Another useful feature is device autopairing. If you plug in a new keyboard, it will look for a free pointer. If you fire up with two mice and two keyboards, it will pair them accordingly. So you don't have to mess around with the pairing, if you keep the number of mice and keyboards even, they will automatically pair up.

Finally, I removed the virtual core devices from the device list. They are still there, but the virtual core pointer doesn't even get rendered any more, they are just a carrier for some important function pointers and a black hole for anything ambiguous where I don't quite know what to do yet. Essentially defunct. Yay!

As usual, everything just went in and bugfixes will come soon. Have fun.

I just pushed another set of changes, the most notable one per-device access control. The need for this is obvious. In a single-user GUI anything that is there can be clicked, moved, pushed, etc. by the user. In a multi-user GUI, there may be stuff you should be able to interact with but I shouldn't. And that's where floor control kicks in. It basically allows us to restrict parts of the GUI to a set of users (well, devices). The cool thing about X is that everything is a window, so restricting a button works in exactly the same way as restricting a top-level window. And the new access control (AC) just cuts of the event stream for a device, so it won't send any events to the given window.

I had all this implemented with Atoms in the first MPX version, months ago. This time I decided to use real requests and make it a bit more flexible. The API is not fixed yet, I think once it starts getting used there may be some changes happening.

ATM, it does the following:
Any client can change access to any window it created. This allows a client to e.g. create toolbox for each user. One single client can grab take global access control (XGrabAccessControl). This client can then change any window. In theory, that would be a window manager job. As long as one client has the AC grab, no other client can grab it. Basically the same as the SubStructureNotify on the root window for window managers.

To define AC for a window you can explicitely permit devices, set a general rule or explicitely deny devices. Rules are executed in the following order until a rule applies:
- Any device explicitely permitted will send events to the window.
- If the general rule is WindowAccessDenyAll, no device will send events to the window.
- If a device is explicitely denied, it will not send events.
- If no rule is found, traverse up window hierarchy.
- If no rule is found, a device is permitted.

This allows us to e.g. set a global DenyAll on the root window, permit device 1 for a top-level application window but then deny it for the "save" button in the very same application.
I think this is fairly flexible, but I guess time will tell whether this set of rules is enough.

The mpxtest program I use to debug new API calls is online now as well, so you can check out the new calls via gitweb or clone it from git://people.freedesktop.org/~whot/mpxtest.

MPX supports hotplugging now. Plug in a mouse, you will get a new mouse cursor. Plug in a keyboard, you'll get a new keyboard.

There's a few things I recommend:
Set up your server with one mouse configured, using the "CorePointer" flag. If you don't do this, the virtual core pointer, which I haven't gotten rid of yet, will have its own cursor hanging around in the centre of the screen.

If you plug in a keyboard, you have to pair it with a pointer device. ATM, it uses the first mouse device, so all keyboards will likely end up using the same mouse pointer until you change the pairing.

If you plug in a keyboard, you have to send the Xkb options as well. I'm using enleth's python-xorg hal proxy script, so the AddKeyboard method looks like this:

def AddKeyboard(dev):
        print "Adding a keyboard."
        name = dev.GetProperty('input.product', dbus_interface=dbus_hal_intf_device)
        device = dev.GetProperty('input.device', dbus_interface=dbus_hal_intf_device)
        SendAddRequest(name, device, options=[['XkbRules', 'xorg'], ['XkbModel', 'evdev'], ['XkbLayout', 'us']])
        print "Added a keyboard."

BTW. haven't tested removing yet ;)

* Yeah, I stole that term from keithp.

daniels posted a fix to the keyboard segfaults with evdev devices yesterday and now we have multiple keyboards in MPX. I was just typing in two gnome-terminals at once. It's fairly inefficient ATM as it copies the keymap to the virtual core keyboard each time you change keyboards. This is ok for a vanilla X server, but lags when you have two people typing simultaneously. I might be able to get rid of that though.

Additionally to this, we have dynamic keyboard pointer pairing. libXi includes a XChangePointerKeyboardPairing(display, pointer, keyboard) call. Use it to hook up a keyboard device to a pointer device. By default, all keyboards will follow the first mouse.

The changes are up in the repo, but fairly untested so far.

If you want to play around with it, your config should include the following bits:

Section "ServerLayout"
        Identifier "XFree86 Configured"
        Screen "Screen0"

        InputDevice "kbd0" "CoreKeyboard"
        InputDevice "kbd1" "SendCoreEvents"

        InputDevice "mouse1" "CorePointer"
        InputDevice "mouse2"
        InputDevice "mouse3"
EndSection

Section "InputDevice"
        Identifier "kbd0"
        Driver "evdev"
        Option "Device" "/dev/input/event0"
        Option "XkbRules" "xorg"
        Option "XkbModel" "evdev"
        Option "XkbLayout" "us"
EndSection

Section "InputDevice"
        Identifier "kbd1"
        Driver "evdev"
        Option "Device" "/dev/input/event5"
        Option "XkbRules" "xorg"
        Option "XkbModel" "evdev"
        Option "XkbLayout" "us"
EndSection

Finally, after months and months of banging my head against the mouse cursor rendering code I managed to fix it. The actual changes probably look trivial, but I had all sorts of troubles with them, mostly because you had to get all the bits and pieces in place before it would work properly.

In the original code, every time the mouse moves, the area the cursor is on currently is restored from a backbuffer, then the target area is copied into the back buffer and the cursor is rendered at the target position. When doing that, we need to disable the damage extension, because it's all internal rendering.

With multiple cursors, it isn't quite that simple. When you restore an area from a back buffer, you may overwrite another cursor. This cursor has to then be rendered again. When you copy stuff into a back buffer, you may have to remove a cursor in this area before you can actually copy it. Which again means, that you have to re-render the cursor.

The hard part was actually getting the damage extension to swich on and off at the right time, because otherwise it would remove cursors when you would paint one cursor. And since I don't actually know much about how it works, I was working blindly for most of the time. And the way how cursors are rendered is to go through many many different layers. So far I only know about the top three ones, that wasn't making things easier.

Nevertheless, I finally managed to do it and I haven't seen any artefacts yet. It's funny to look at the cursors being layered, with one cursor partly obscuring another one. It may be time for a request to change the cursor stacking order, but at the moment I'm not quite sure if there'll be a real need for it.

I'm back from LCA with my motivation boosted. Talked to Daniel Stone, Keith Packard, Dave Airlie and quite a few others. The best thing is probably that pretty much everyone likes MPX.

Last day at uni before heading off to LCA in Sydney. I installed MPX on my laptop, so if you are at LCA and want to have a look, just ask me.

I pushed the changes to include enter and leave events on a per-device basis. Also, it includes a per-device cursor buffer, so you can have a different cursor shape for each device in your application now.

Xi didn't provide that at all, so a few new types had to be added to the protocol. Everything is largely compatible to the respective core requests/events [1], usage is the same as the usual Xi usage. Have a look at the Develop for MPX page to get a grip on what it does.

On a sidenote, the push also includes a fix for the bug that caused the server to segfault on restart.

After recieving my account a few days ago (thanks daniel), I pushed MPX into the main X repository now. This will make it much easier to get new versions of MPX as you don't have to apply any patches any more.

My prediction on monday was wrong. I can release before the christmas break. MPX 0.3.0 is here, shiny and sparkly.