 Firstly, apologies for the quality of the talk. I broke X input about a week ago, and so I spent the time trying to fix it, so I could use X enough to give the presentation. It turns out I mostly can't, except thanks to ACPI and rousing random buttons on my laptop to do random things through ACPI. And awesome having a command line client you can use window management for. I can get this far, which is an achievement. And Facebook, so I can move to the slides from the slides in. So yeah, I'm half of the X input from ACPI. The other half is Peter, who is an insurer and awesome, but sadly he's not yet. He's been doing a lot more than me, but I'm in Europe, so I get the same fortune in conferences, and he only gets LCA for that. You know LCA is good, but we should come to it. Right. So input at the moment consists of XKB, the keyboard extension. XKB makes a lot of sense when you think about it, but then you realize that it does everything for you except for actually mapping keys to key symbols, and it sort of makes progressively less sense from there. It's not pretty. Those of you who were here two years ago in a little different way have heard me ramble about the same thing, and it's getting better incrementally. Then there's XI, the X input extension, and sadly I didn't have time to do the crap. I had about six minutes in which I got ten slides out, which I'm pretty happy with. But Peter has a brilliant graph of XI, which is applications using XI, but applications not using XI. Rounded to the nearest percentage, it was 100% zero. It didn't use XI, and it uses it quite badly. And there's also the mandatory train wreck because it's all an argument. I don't have time enough, or at the moment, actually enough, I'm kind of tired to describe how bad XKB is. So basically, keyboards started with, you know, you have a key, and a keyboard, you press it, and the letter J comes out. This is the bit XKB doesn't handle, but it turns out that if you want to name your LED, it can do that, except where it can't, because you can configure it, but it's all broken. And the failure sort of starts from there and descends into things like XKB gets keyboards by name being the function you told if you want to set a keyboard map well done. And basically, it's kind of glued together really badly, and by glued, I mean one side is kind of moist and you fluff them together and hope for the best. So basically, all the clients deal with five primitives of rules, models, layout, variants, options. So, you know, I want the US layout or I want the finished layout as much as anyone does. And options like I don't want caps lock, I want that to be controlled instead. XKB itself doesn't deal with these. There are five other primitives that no one at all uses, but because they couldn't be bothered breaking a protocol, instead you have to have basically the maps both on the client and the server. And the best part about that is XML, which sort of says a lot. But over the last few years, I've been deleting a lot of XKB. Sometimes it broke people's ability to VT switch, mostly not. And I now understand most of it, except why the VT switches are broken. Don't run master, sorry. But we have a solid client fix it now. I've got a commit pending which will remove an additional few thousand lines of code for no real reason. Because it has things like the ability to compile incomplete maps, so you can say I want symbols and I want types and compass, but I don't want indicators. And that you would think is really useful and they've sort of very painfully provided for things you need, things you want, and you can pass all this through to your map building function. Except if you don't specify all of them, then the server just falls over because it tries to unconditionally reference everything. It's like brilliant except the other one. Keith P is going to rewrite XKB.com. He said this yesterday and I'm calling him out here because I have no idea about politics and I'd really like for him to do it. Thanks, Keith. And basically everyone's a winner with XKB except for all the people who aren't, which is everyone who has a keyboard. XI is tragically unused except without all the tragedies because it's misdesigned horribly. It's sort of designed around instead of with our core input code. The core input only deals with one device. XI poses multiple devices except instead of the nice call thing of when someone clicks on my window, I'd like to get that event. The application has to open the device which is an exclusive graph. So you have to say I'm the only one getting a bet from this mouse now and basically we're back to core pretty multitasking. Excellent. So yeah that's the other 50% of the input code which is also rubbish. Thankfully the implementation is as bad as the design. So the unused it makes a lot of sense because it's more or less unusable but thankfully they've got some pretty impressive... I don't know what my machine is doing now. I can tell you that it's not the right thing now. It's got some pretty impressive things built into the protocol. It's got all the device names for every possible kind of device ever made including a book mouse. I tried to buy it but it was like 400 bucks and I wasn't that interested to be honest. But basically over core input it provides you multiple devices and tells where it's come from without having to switch keymaps under the client and be confusing. It lets you know multiple keys, so multiple keys. It lets you deal with extended buttons so you can have up to 36 axes as well. It gives you suffix or precision which is by the game user that's because Waycom tablets are actually incredibly precise. It turns out this doesn't help you draw stuff that isn't rubbish but you know it's all good. And so we've been trying to fix it for the last couple of years. We got fairly close last year or something maybe two years ago and we merged input hot log which basically rewrote a lot of the weekend generation code. But there were two problems with that. One is that we left processing the loan which was a mistake from the point of view of quality code but a win from the point of view of not having to work on it because it's nasty. And the problem is that because no one other than the game user extended events then we really honestly have no idea how to do it properly. We made educated guesses and yeah, say once that educated is turned up, mostly just guessing. So I tried to fix GTK to deal with extended events but the input code is a trainwreck and it's horrible and really, really awful. So I asked around for advice and they said we don't know no one such as Kenzoan and I asked Kenzoan if he said I don't know and just kind of like so. So I left that one alone. Yeah, and I'm not touching GTK. And then Peter Kenzoan, he was probably the 30th person to show up with a great plan for having multiple pointers. Nice one, thanks. And then he sort of said, well, at mostly work there are a couple of bugs and everyone sort of did a double take. And then after that I merged into a hot log and said thanks for MPF, now you have to rewrite half of it and it's still really nice. And he did it as well. So that was cool. And yeah, so multiple X now takes the XI idea one step further and consumes multiple cursors as well. You have multiple keyboard photos to up to 125 users can interact with the system at one time. Peter can use three mice simultaneously. He can also juggle a unicycle and other things I come to. But there's a cool demo on YouTube. If you search for MPF Totoro, his last name, they've got 18 people using one machine simultaneously with 18 pointers flying everywhere. I don't know how productive it was but it was a beautiful video. And MPX is in surprisingly good shape now. The problem is that I'm stuck with work and other missed stuff. So I can't, I don't have the time to deal with all that. And Peter's writing his thesis. But we think for 1.6 in April next year we'll have a release which contains MPX and completely fixed input. And he's just finished his thesis at the University of South Australia. If you want to hire him, you should be able to use him to add an engine. Really, really good. Right, so between Peter and I, we worked out as of January what actually happens with input. And then last week when I broke everything I worked out one further step because I didn't really understand before. So drivers call XKB in a keyboard device which compiles the key map. It stashes around 10% of the key map in the device and stores the rest in a static variable. Then it calls in a keyboard device which calls back into XKB in a device which takes the rest of the key map, applies to most of it. And then it calls XKB in a finished device in it which takes other static stuff you've stored previously and on here basically. And that's how surprising it works as it turns out because XKB is very painfully separated from the core. All of the core code is completely unaware of XKB and almost completely unable to function without it. So basically it's a series of elaborate hacks around this. That's why it gets so painful for moments because they're completely separated except what they are. So that's device initialization. Input processing. You come out of process input events. You go into process key events which is in XKB. You try to filter for accessibility stuff. Then if that fails you go to action which includes all the modifier stuff. Then it goes back into XKB process key events and XKB process key events does stuff like if this key is a modifier, clear our entire modifier map so the core input processing stuff doesn't try to do anything clever. Then it calls back into the core input processing and basically at this point everything falls apart and you're pretty impressed. This makes a lot of sense when we worked that out a few months ago and it explained a lot. And again the solution is to make them not so painfully unaware of each other because that's the moment you run through all the XKB stuff. Then the XKB stuff makes your core isn't aware of anything that's going on and doesn't try to do anything clever because the XKB is already really, really clever. Then failure ensues. This is why things like auto-repeat don't work quite properly at the moment. So LDA is our vehicle to find except that we forgot to write it down on a vehicle, luckily we remember it all is to pack everything together. At the moment input processing has a few paths. XKB has two paths depending on which type of device it is that they need to be one because it crashes into you if you do the wrong thing. XI, the extended input stuff, that has three paths and then they all call back into the one core path because it's unaware of everything that's happened before. And then all the core stuff does grabs which are horrendously complicated and they're mainly complicated because the semantics that are written down more or less make no sense and the semantics that are unused as you only discover by trial and error. When I say you, I mean Peter. I didn't touch that stuff. So basically the plan is to have a single input processing function that's aware of XKB and XI and everything and so instead of generating I think three events and passing them all through and trying to glue them together really horribly we just whack it into one piece and it does the right thing or some approximation error. The same, again, with device initialization it just becomes one piece instead of a plate, somewhere over 20. And XKB in general needs to be more or less re-driven deleting the good approximation of that and XKB coms key tiers rewriting that thanks again. XI needs a minor redesign as well. Basically the core input model is what you want in terms of how flies ask for events to say if someone clicks on my window please give me that event. Turns out this wasn't a bad idea. Yes, that's basically all I have. If anyone has any questions including about how any of this actually works or any clearing bits I've forgotten. So I think we can get a really improved deleted and rewritten XKB for 1.5 by XDS in September or October and then the plan for re-written input processing is 1.6 in April because that's when Peter will have finished his thesis and I'll be not moving the continent. It'll take a little while and it will be pretty innovative. So yeah, I think the years from now is a pretty solid plan. Anyone? No one has transmitted my input except to you. Congratulations. Sorry, I didn't understand much but I have some actually in the wrong room. But how does this impact the input methods or conflicts between languages? The input methods aren't involved with inputting. So this horrible mess is the server and it's my horrible mess but I refuse to touch the client-side libraries because relative to the server, they're a horrible mess. So that's all done in X-Lip. After the events are delivered, X-Lip sort of passes them off into this magical black box which generates magical events somehow. The code is a mess and so is the design but I think the biggest problem with input methods is that there isn't one of them. So in a one-suit, we've perpetually had the problem of which input method do we use because people who do all the Eastern languages, like CJK, a lot of them want to be able to do it genetically but they argue over whether SCIM is the best or UIM is the best. So we've been assured that every single person in Japan uses SCIM which is also because every single person in Japan apparently uses UIM. No one's really coherently looking at it. Anyone who wants to is told you. But yeah, that's another thing in Tile. So that's the client-side? Yeah, it's completely client-side. So you get to look at X-Lip. But yeah, we don't have anyone doing stuff with input methods right now. Anyone?