Have been putting off writing another post! Some nonsense about trying to crystallize thoughts…Found myself with some extra time during the work day and thought I would take some time to write about what I am working on over the last few weeks!
Currently my two largest areas of focus are:
1. Client Side Input
2. Preparation for Unity Next (Inprocess EGL)
Client Side Input
Conceptually this is exactly what it sounds like: Deliver input events (key, touch) to Mir clients! Over the last few months we’ve been working to adapt an isolated version of the Android input stack in to the Mir code base. Now that all the building blocks are coming together under test some exciting things are starting to happen. Last week code landed to hook the input dispatch subsystem (previously only functioning as a server side event filter) to the shell focus model, i.e. Which application gets which key events?
This week I am working on a pending branch for the client side API for receiving input. With this in place you can run a mir server today and receive input all the way to clients. It was pretty exciting to see the first full stack key events pass acceptance test!
I spent some time too working on Qt Mir support to enable input. Prior to the stabilization of the Ubuntu touch code there qmir was created as it’s own QPA plugin and has served us well! However now the QtUbuntu plugin from the Phone and Tablet images has become a lot more mature and come to contain a lot of useful code! So I have made a version of QtUbuntu which works on top of Mir through abstracting the Ubuntu Platform API and providing a libmirclient-based implementation.
I’d still like to write a post describing Input in Mir end to end. I think there are a lot of interesting observations (mostly not made by me ) at every level of the stack from androidinput, to Mir, to Qt, which change the problem from an un-tangleable FUD bubble to something as simple as it conceptually sounds: Read input events from physical devices and route them where needed . Hard to find the time for technical writing though.
Preparation for Unity Next
On a separate line I have been working to prepare Mir for the rendering needs of Unity next. Namely, Unity (using mirserver as a library) will wish to create surfaces and EGL contexts for rendering certain shell components (such as the Launcher or the Dash). It would be a shame (and get in the way of certain other requirements) for this to happen over the IPC protocol!
A pipeline has been in the works the last few weeks to enable this: The interface between mesa-egl-platform-mir-server was abstracted through a NativeDisplay interface with both client and server implementations. Now with pending work the same Mesa backend can work for in and out of process clients.
Using the same QtUbuntu backend mentioned before, I played around with an in-server implementation of the platform API to get a quick QML demo going up using in-server rendering!
Quick! hit publish before I get caught in endless revisionism.