 Okay, we're very slightly late, so without further ado, I will introduce Keith Packard, who will speak to you on the future of Linux graphics. Thank you. Yeah, good. Everybody hear me okay? Yeah, my throat's a little hoarse today, so if I speak a little quietly, just remind me and I'll try to speak up. So I'm going to talk about the direction that we're trying to take in Linux graphics in a lot of different areas. The key that we're planning to do here is we're trying to integrate things together in a way they haven't been up to date. Graphics runs on Linux in a lot of different environments. We have graphics, we obviously have Linux desktop, how many of you running the X server and the usual graphics Linux desktop, yeah, or BSD. And that obviously runs on workstations, laptops, and occasionally on a server if you're crazy. And then Linux runs in a lot of mobile devices, how many of you have a mobile Linux device in your pockets, Android or Nokia device or something like that, yeah. How many of those are running X? Well, the Nokia runs X, yeah. Thank you, Daniel. The Android devices don't, though, and that's for some reasonably good reasons. It's not running X, obviously saves a bunch of memory and lets them make all the applications distinct from other platforms. And obviously there are a growing number of Linux tablets right now. You see things like the Nook and other Linux e-readers and you see Intel ARM based and Intel based Linux tablets. Many of those are running X, a lot of those are not. A lot of those are running Android, obviously. And we're starting to see a growth of Linux in media. How many of you have a television at home that's running Linux? Yeah, already those running X? Not so much, not so much. How many of you have a car that has a Linux machine in it? BDL. BDL, you have a suburban. Yeah, and even your little GPS device, I have a Tom Tom GPS on my dash, it's running Linux. And then there's a huge array of embedded Linux systems all over the planet from McDonald's signage to billboards to in-store stuff and medical systems in your hospital are all running Linux. A huge range of those. Some of these are running X and some of these aren't. And one of the big problems we've had as the open source community is basically not engaged in any area that's not X. That seems to me like a huge lost opportunity. I mean we have a great opportunity to integrate and unify Linux graphics across all these devices and bring a lot of marginal open source players kind of into the fold. Embrace and extend, right? Not at all, not at all. So of course one of the requirements is that nothing break. Well, that's always the hard part. We'll try to see what we can do. So in all these environments, who actually wants X? The X ability to run applications remotely over the network. The X ability to interact with applications written in 1988. The X ability to run motif applications. Who actually wants that? Does anybody care if you can run motif? You run motif. The dominant use today in the Linux environment of X desktops is because the two dominant toolkits GTK plus and QT both use X in the Linux environment. Now obviously both of these also have additional backends that don't use X. But in terms of acceleration on a regular Intel laptop or something, obviously you're going to be running X because that's how you get at the acceleration. Aside from the Linux desktop market which wants to use X because that's how you get at acceleration, nobody really cares. Telephones, TVs, cars, nobody cares about X. So instead of resisting the other environments and saying, no, you all have to run X so that you can join the open source fold. I'm suggesting that we embrace them and extend our notion of the Linux desktop graphics environment to embrace a broader swath of the environment. Now in the Linux ecosystem, what are the useful rendering APIs? Note which is distinctly missing here. The most useful rendering API in the Linux ecosystem is OpenGL. All of your high-speed applications, anything that wants to actually go fast uses OpenGL. The other APIs that I put up here via API or VDPAU or what's the Radeon one? Xvd. Those get at the native media decode hardware in a nice way. Obviously X doesn't natively support any of those. These all get at the native hardware efficiently, unlike, say, the X protocol which has wide lines and arcs. So what are we using X for right now? We're using it for controlling the hardware. We use it for mode setting. We use it for 2D graphics because we don't have anything running on GL today, maybe tomorrow. We obviously want, we have to have an input demultiplexer. Your mouse and your keyboard are essentially a multiplex stream of input events being targeted at multiple applications. So you need some semantic demultiplexer to take this unidirectional stream of input events and divide it out among all the applications. We use it for keyboard mapping because keyboards are a nightmare. And obviously we use it right now. The traditional X system uses it for allocating screen real estate. And we do that in the traditional X system with clipping. And the other thing that we use X for in the Linux ecosystem is for the shared GLX required objects between multiple applications. So if you have two applications rendering GL to the same window, then they're supposed to share the back buffer, which, by the way, is insane. That just should not be allowed. So why was X in charge of graphics? How did we get to the state where we don't have any native kernel support for credible graphics? Well, the main reason was mode setting. If you look at the other competing graphics systems in the open source space that have come along over the years, they've all come up against this wall. They would work on Matrox, and then they'd stop. Or they'd work on Mox64, and then they'd stop. Because the hardest part about starting a graphic system, just to get it running at all, is getting the video card lit up and painting pixels on the screen. There used to be an enormous pile of code. Fully three-quarters of the Intel 2D driver was mode setting. That's just a huge amount of information and hacks over the years. Duplicating that in another system is just totally intractable. There's no way you're going to get it to be as compatible. And of course, the other thing X was doing was clipping. You'd allocate some screen real estate. X was the only one who knew where, what the window stacking order was, and what the clipping regions for each window were supposed to be. The great part was that DRI tried to hack around this, and it actually shared the clipless between the X server and the application so the application could do its own swap buffers. That meant that your DRI application had to lock the desktop, including the entire X server, paint a scene, and then unlock it. This was the old DRI 1, or the original DRI extension, where it actually had a lock that was passed between the applications of the X server. So you run your application under GDB, right point, and your X server is frozen. It's awesome. The other thing that X was used for is for memory management. You have all this off-screen memory in your video card. Somebody has to be in charge of allocating it and managing the region of space in the video card. And the X server used to partition out the video memory so that 3D had this part and your media acceleration had this part and your PIX maps were allocated over here. And X got to do that. The best part about this was that DRI applications had no persistent on-card state. So if you wanted to render temporary images in DRI 1, not so much. It kind of made us limited in our GL support. Let's see. X is not just a single server. It's actually a collection of servers now. You have your X server, which does all the management of the clip lists and the fundamental access to the graphics card. And then you have your window manager, which is another application that controls around on the screen and paints title bars and pops up menus occasionally. And then you have your external compositing manager, which is what these days we use for all our fancy on-screen effects. And so you have a system of interconnected servers. It's kind of like the mock microkernel, right? You have these interconnected servers interoperating with... How many of you think that's a great architecture for operating systems? Yeah, not so much. Why does it have to be this way? Well, because we want the window manager and the compositing manager to run an unprivileged space. And when the X server is talking to your hardware directly, it's running as root. And so we're trying to keep the amount of privileged code in the system to a minimum. And so we externalized all these stuff with these very complicated protocols, the damage protocol and all the synchronous grab mechanisms so that window managers can... You can click in a window and start typing right away and the window manager has a synchronous grab and then sets the focus so that when your typing goes to the right window, extremely complicated. And it's made the system very fragile over a long time because application programmers have to be aware of all of this. How many of you have written your first application where you map a window and then paint to it and nothing appears on the screen? Yeah, exactly. The dumbest possible X application doesn't actually paint anything on the screen because it's asynchronous. That's insane. Okay, how have things changed? Well, how many of you were writing graphics applications in 1985? Yeah. There's a couple of us. Back then, Unix, because we didn't have Linux yet, didn't have shared libraries. And so if you wanted to share code, you either put it in the Unix kernel, which is what we did in V7. We started putting all the terminal drivers and all this crap in Unix kernel. Or you stuck it in a server, which is what you want to do with your mail server and your FTB server and all these various services. And you talk to the server to get some service done. It's like D-Bus, right? There's an external D-Bus server instead of a shared library. A lot of that's for security reasons, but also a lot of that was this historical architecture where Unix didn't have shared libraries and the only way to share code across applications and take advantage of your massive 1 megabyte of memory was to externalize a lot of the functionality of the system into a shared server. There's a rendering code in it, right? Not because we think it's great to have rendering done in the X server. It's useful, but also because it was the only way to share the code between applications. Since 1985, the amount of data that you pumped onto your screen has changed dramatically. We used to paint stuff like this, a couple of rectangles, a little tiny logo, and a bunch of text. The X protocol is fabulous at that. That's probably 200 bytes of X protocol data to paint that screen, except for the image, which is probably 10 kilobytes all by itself. X was fabulous at this, but how many of you have a solid black background on your desktop? Not so many. How many of you have a nice picture of a friend or some important event in your life? Yeah, exactly. Huge amounts of data. How many of you run 3D applications in the next year? That's full screen size. What? Screen? Yeah, yeah. Yeah, exactly. Screen savers just hammer the machine with huge amounts of data. Both in terms of vertices and textures. We're getting dramatically more detail on the screen in every possible way. And we have this new remote application access protocol that's really powerful, HTTP and HTML. You can run form fill out applications and all the way up to flash applications over this fine new protocol. It's the moderate equivalent of the IBM 3270. I was in a shop a couple of weeks ago and I actually saw somebody running an IBM 3270 emulator on their PC to do their daily work. I was like, wow, that's amazing. The other cool thing is we have themable UIs now. We have some notions about how theming works and it is possible to get a pretty consistent look and feel across multiple toolkits. Windows is famous for this. If you look at Windows, the applications look consistent. That's not because they're all using the same toolkit. It's because somebody spent a bunch of time making all the toolkits look alike. And making things fast enough is a lot easier today. The notion of all the fancy asynchronous grab mechanisms and all this delayed mouse motion motion history stuff. We don't actually need a lot of that anymore. Oh, by the way, in 1985, I had a black and white screen. Yeah, I'll bet they do. So what I want to talk about is reintegrating the Windows system. I want to simplify the system architecture by pulling all these separate servers into a single, common server. Integrate the compositing manager, integrate the Windows management and provide synchronous operations entirely within a single address base and with a single application, dramatically easing the development of these systems and making things. Giving a nice, imperative programming model instead of this event-driven model, which is very confusing and difficult to deal with. Obviously, when we've reduced the number of processes, we're going to improve performance because you don't have to contact switch. So right now, when you click a button and paint something new on the screen, you've got three processes involved. You've got the application which sends the rendering commands to the X server or directly to the card which paints it off-screen memory, which sends an event to the compositing manager and the image. You've got a huge number of applications involved and a lot of contact switching. Questions obviously remain. How do we deal with broken applications? What happens if an application locks up the hardware? Right now, with 2D applications, the 2D X protocol is not programmatic at all. You draw lines and you draw text and you draw rectangles. Nice and confined. So applications have no ability in the X protocol to lock up the hardware unless you draw wide arcs. Different, I promise. And the other question is, what do we do about...you look at Compiz. Compiz has how many plugins? 200, 300 plugins now? People obviously want a lot of shiny in a lot of ways. I don't know what to do about that. Other than tell them, you're insane. Okay, so what do we do about remote applications? Right? Obviously, this is a nice solution for native applications. You do direct rendering and compositing manager window system, integrated system, and that puts the stuff up on the screen. Well, for the typical form fill out application, like filing your LCA registration, did you use an X application for that? Yes, you used your browser. But the actual network protocol is over HTTP. So a lot of stuff that we use X for today, the old ancient motif applications that just had a bunch of forms, most of that is migrating to HTML today. We obviously have VNC at our desktop which are nice protocols that just do screen scraping and pumping the data over the wire. The smallest representation for complicated 3D systems is usually the final pixels. You don't have to send extra texture levels or anything like that. You don't have to send the changes and vertices. You just send the pixels. It's also nice and consistent. You know how many pixels there are. You can set a specific bandwidth and adjust it. Now you can use a server-resident GPU. Fortunately, the new Intel CPU CPU-GPU Combination Sandy Bridge lets you render into cacheable memory. So this whole notion of get-image being slow has gone away. So at least you can do that. Obviously, it's not going to work so well if you want to do 50 users on the same system running 3D applications. But we run 50 users running simple 2D applications using VNC or our desktop quite easily. Another protocol that Intel's been working on is something called YDI, which is basically a wireless display. So you run your server on your laptop and you display it on a remote screen. It's really just a screen. It's not a computer at all. Well, of course, it's a computer. But it looks just like a screen. So you can paint your application image over even a wireless connection. And that uses reasonably lossy compression. Maybe something like JPEG-2000. And that would be great for the presentation environment in here. I wouldn't have to try to plug in and hope that the VGA is going to work. And, of course, you can still run X. If you think that your application needs to be erodable, there's no reason you can't run X. X is happy to run in this environment. It's just another application that paints stuff on the screen and it can expose a network socket and you can paint your stuff over X. And the best thing about that is that the performance of your X applications will be unchanged. Because right now, X is just a DRI application that paints stuff using the same DRI infrastructure that your 3D applications do. So when we move to a system where X is a separate server running as an unprivileged user, your performance won't change. Obviously, the cool part, okay, so I want to be able to provide some broad system architecture support. Obviously, we need to provide mode settings so I can play with a lot of different systems here. I need to provide input access and we need to provide some rendering and merry management. All these things need to be in a shared area, right? And all these need to be privileged. Now, what's our privileged environment in the Linux system? It's the kernel, right? So we stuck all these things into the kernel and now, all of a sudden, all of my graphics applications can run unprivileged. All the graphics applications have access to these fundamental Linux infrastructure which is the privileged environment. So I don't have to run the X server running because I can't run the X servers directly from user space. What could possibly go wrong? Now, the nice thing is that these particular interfaces aren't really Linux specific, right? There's nothing in these interfaces that are specific to Linux. We can port these interfaces to other operating systems and that means that once you have these interfaces in your other operating system, the other services will just work. So it also gives us, it gives us a similar level of operating system portability, although not quite as much because now I have to port it into the kernel instead of just M mapping my device and writing to the raw registers. So what are the missing pieces? What do we need to make this happen? We have a bunch of infrastructure available. One of the big parts we are missing right now is keyboard mapping. The keyboard mapping is extremely complicated in X. Daniel gave a talk in the Plumbers mini-con a couple of days ago and laid out the complexity of keyboards and at the time he does that, it's like, you've got to be kidding. Somebody designed this. They must have been on drugs. So fortunately, Daniel and Christian Hogeberg are working on pulling all of this XKB stuff out of the X server into a shared library. So we'll be able to share the X key mapping in user space, not in the kernel. The X key mapping and event processing infrastructure for keyboards and systems. Input drivers, the EVDev infrastructure is really not sufficient. EVDev gives you a very low level view of the system. When you talk about touch devices with multiple touch points, there's a huge amount of complexity there that we're going in in the multi-touch stuff in X right now. I'm treating the multi-touch stuff at X as kind of a prototype of how we want the stuff to work in a real system which won't involve X. It's kind of interesting to see how it works because I don't expect it's going to last that long. I'm hoping to bail on the whole X stuff sooner than that. But it is interesting to note that we're getting some pretty well-defined semantics that are totally dependent on the Windows system and not dependent upon the X-Grab nightmare infrastructure at all. Another big piece is the accessibility in APIs. Back in the 1990s, we had a whole bunch of work on accessibility in X in terms of the XKB extension and mouse keys and all that kind of stuff. And more recently, in the GTK and QT systems, we had a bunch of work in accessibility for those in terms of color schemes and alternate input methods. So those need to be integrated into the new system. Obviously GTK and QT, those systems should just port over but certainly the XKB infrastructure will need to be moved as well. And that has to go into the Windows system or into the input demultiplexer part of the Windows system. Obviously, we want to make it flexible. Right now, X is kind of a huge ungainly beast. We have deleted a lot of code in the X-server in the last five years or so. I think we've deleted well in excess of 500,000 lines of code in the X-server. Has anybody noticed? Thanks for managing my problem for me, Linus. Actually, that was just the core X-server. That wasn't the device drivers. That was just the core X-server with none of the stuff related to devices at all. No, that's 500,000 lines have been removed from the core server. So has anybody noticed any reduction in functionality? Yeah, we... Not so useful. Those are obviously bugs in the input infrastructure that we're trying to fix. When Hoody and Daniel were changing input infrastructure to support multiple pointers and multi-touch, they may have broken some stuff. We're trying to fix them. So we're trying to make the X-system smaller, but we still have like a half a million lines of code in the X-server that doesn't do much. Obviously, we're trying to move from X ecosystem APIs like GLX, two more generic APIs like EGL. We're trying to extend our GL support from just OpenGL to also support GLES. Fortunately, the Mesa project does that now, so we can actually write GLES applications that run on top of GLX or EGL and those work in the X environment or in a not X environment. And we're moving from these very eccentric media APIs like XV and XVMC into DRI APIs that aren't specific to X. So applications that use these new media APIs won't be... that part of the application won't be dependent upon X. So we're reducing the amount of X-specific code already in applications. The goal is to make it easier for applications to transition to a not X environment if they choose, or to continue running in X if they want to do that. There's no need. No need to move if you don't want to. And obviously we want to mix and match. X and not X. If you want to run legacy X applications, we'll still have an X-server available that will draw your lovely X stuff on the screen with loving care of every pixel in place just so. Okay, so the original goals of the composite extension were to provide for fancy desktop effects. We wanted to add the shiny to the X-system. We wanted to eliminate expose events and we wanted to use it for... We wanted to use render for drawing the stuff. The original plan was just use render for all the actual on-screen drawing. We're going to draw some shadows with little Gaussian blurrers, blah, blah, blah. The additional results of the composite extension will no longer do clipping. A window is drawn off-screen, the full size of the window. There's no clipping to siblings or to its parents' geometry or anything. So all of a sudden applications can render directly to an off-screen buffer and be totally ignorant of the window system clipping. The only thing that needs to do clipping is a compositing manager with stuff on the screen. The other nice thing is that now we have most of our compositing managers use GL and so the screen contents are not even... the screen update doesn't even go through and it's all done with DRI. So the application paints a DRI to an off-screen buffer and then tells the X server I've updated this off-screen buffer which tells an application the compositing manager, the buffer was updated and the compositing manager uses DRI to paint. So the only thing going through X right now is the notion that a buffer contents have been changed. That's it. No rendering goes to the X server, no nothing. The gem kernel API, the original goals that were to fix the kernel infrastructure so I could actually have persistent off-screen storage for graphics objects. And in order to have persistent storage obviously the objects have to be pageable because otherwise any application can DOS the system just by running it off memory. That's not good. I wanted to be able to do zero copying from a texture to a pixel map and from a pixel map to a texture. I wanted to be able to do the fancy compositing effects without having to shuffle pixels around. And I wanted obviously to have these... I wanted to have persistent storage, right? Our old DRI infrastructure, if the 3D application wanted to have an FBO you rendered that in software and painted it meticulously with the CPU. And the other cool part about gem was that I wanted to be able to share objects between rendering API. So I wanted to share the output of X rendering with a GL application. I wanted to share the output of a media application with GL or X and so all of a sudden I needed what I wanted is a global namespace of bags of pixels. A gem buffer object which is just a bag of pixels in a graphics in a hardware specific manner. It's got all the information that the hardware needs to know in order to render to and from it efficiently. The additional results of the gem infrastructure, DOI2, is that now I have lockless rendering, right? Applications don't need to lock the X server to do any rendering because there's no clipping involved. They own their buffer and it's a separate buffer from the rest of the applications on the screen. So they can get totally oblivious of the X server and not interacting with it at all until it's all done and ready to be put up on the screen. Direct rendering applications, obviously, their output is persistent. So if you render to a buffer, the system doesn't care where that buffer is if it's on screen or off screen. It's an object that the application owns and so the pixels don't go away until the application destroys it. And obviously you can share these applications, these objects between the applications and with the window system. So right now the way that you update the screen is the application renders to the back, the application asks the X server to render a back buffer with GLX. The application draws to the back buffer and then it tells the server to copy data from the back buffer to the front buffer. That means the only involvement the X server has is the allocation that's required by GLX and then the final copy to the screen which is where the clipping has to happen. Mode setting, obviously what we're trying to actually work, if you do mode setting especially with modern devices like DisplayPort or the new lovely Intel FDI flexible display interconnect it's basically impossible to do that from user mode because you have tight timing requirements as you're doing the training. So we really need to do that in the kernel space. The other thing we wanted to be able to offer was panic messages on the screen. How many of you have had your system freeze because the network card crashed and you can't see the panic message or can't paint anything and can't get out of the way to show the panic message? That really sucks. Well because now we have KMS in the kernel, the kernel can flip the screen to the console and you can actually see your panic message and that actually worked successfully for me the first time like six months ago and it was like, wow, what's that? Oh yeah it's supposed to do that. Yeah, oddly my wireless card crashed. The unfortunate thing of course is that if the video card crashes you still don't get a stack trace. Yeah, serial console. Oddly, most of the crashes that I experience are because my video card is broken because I run potentially unstable code. So the additional results here is that it's trivial to build a non-X window system. I mean, Christian Huggsburg built Wayland in the initial mode setting part of Wayland in a couple weeks. All of a sudden he has a window system which is not dependent upon X and which supports everything that KMS supports with no additional work. A fabulous result. So all of a sudden we have a migration path out of the morass of X and into a bright shiny new future where X is a potential API but not a required API. And you can even build now windowless systems where you render directly to EGL on the entire screen. Obviously TVs might want to do this where you have a single application rendering all the contents on your screen and so you can get rid of the footprint of another window server and a bunch of other infrastructure and shrink the size of your flash image and whatever you want to do. So you can build systems that use a window system or don't. EGL is an API that was an alternate API for talking about window systems from GL. GL kind of has historically had this kind of nightmare API which is specific to each operating system. They have WGL and they have AGL, WGL for Windows and AGL for the Apple system and they have GL for the X system. So every application that wants to port between various operating systems has to use a different API to talk about the window system. And it's worse than that because a lot of the objects you need to allocate in the GL environment come out of this API. So you end up with a ton of window system specific code in your nominally portable GL application which is a pain. And so we have a new API called EGL. The goal was to make it so that you have portable cross-platform applications. Well for us it's great because we want to get rid of GLX so if applications are written to EGL I can run them in an X or non-X environment with very small changes to the application. They need to talk to the new window system and then they can use the EGL API to do the rest of their window system interactions. So here's our old environment nearly done where we had the X kind of owning the entire world everything that you could ever possibly want to do with the system and the poor little Linux penguin sitting there lonely at the bottom it's device address it's device mapped into the X server and its registers poked and its PCI buses prodded it's feeling pretty sorry for itself with all this stuff wedged into the X server and all the various APIs are sitting on top of that and they all go through X. And here's our new environment where we have all these APIs that talk directly to the Linux kernel where Linus will make sure that the APIs are stable and consistent and reliable and all of a sudden my job gets a whole lot easier because I'm just a has been add-on right? I'm just this little X add-on on the side if you want to run some old ancient crufty motif applications you might start an X server so and all of your other APIs sit on top of that and you can run whatever window system you want you want to run Wayland you want to run X you can do whatever you like so any questions this afternoon? Thanks Keith we've got my microphone I'll just bring around and put the hand up for anyone who needs a question Thanks How many people want questions? We'll get down the front because it's so packed if there's too many. Are you all looking nervous and shy or something? Alright now don't hang on to it too long No this will be real quick I'm just wondering if these changes will affect support for secondary screens Would these changes affect the support for secondary screens? Not at all Run cleaner or nicer? The nice thing about the gem infrastructure and the kernel is that all the video cards use the same API to user space and so your applications use a common API across all the video cards of course one of the basic problems with direct rendering is that the different video cards have different capabilities and so if you're using an API that exposes the capabilities of the video card instead of X which does not then your application is going to have to deal with the heterogeneity between multiple video cards it has to do that already today and so any GL application today if you have two cards plugged into your system it's going to run on one card or the other today there's a bunch of thought and talk about building a GL multiplexer that will expose a common subset of multiple GL cards so you can migrate stuff between cards that's really hard One of the other nice things is because the gem API is common and you can share these objects between different graphics cards you can actually paint on one screen and use the contents to another screen to a different video card obviously there will be some performance implications of that because you actually have to copy the pixels but at least it should work so it's no worse than it is today for direct rendered applications but of course we are increasing the number of direct rendered applications potentially okay anyone else anyone questions oh sorry here we go what's going to happen with licenses with what? all of the kernel code right now because it's part of the DRI project is actually still licensed under the MIT license so everything we put into the Linux kernel for mode setting and the gem infrastructure is all licensed with the BSD license which is compatible with the GPL so we can put it in the kernel without any license conflict there but it also means that code has been ported to other non-GPL environments and... and ATIs who insist on shipping binary blobs oh for binary blobs I don't care about them they are going to have a problem right now fortunately we have open drivers for both of those cards that work in this environment just fine so if they want to come and play with us they're welcome to but frankly they aren't that important for the ecosystems that I'm looking at extending ourselves into we're trying to move into an ecosystem that's a much more embedded ecosystem and if they want to come and play there that would be great they're welcome to provide APIs that are compatible with ours how does this work with authentication at the moment I can SSH to a remote machine and stuff just magically happens and most days I don't need to care about how it works it can display on my screen if we have multiple different systems for this how's that going to work well for a remoting as I talked about the remoting the remoted display APIs that I talked about were X, HTTP, VNC and those all have existing network authentication mechanisms available so if you want a remote and remote application over the wire then you're going to use one of those existing systems possibly X to remote your application and that already has kind of a broken authentication mechanism how has color management changed in the new structure right now X supports just this huge array of color video card capabilities monochrome and grayscale and pseudo color those are awesome how many of you are running an application in other than true color mode BDAL BDAL has ancient hardware so the only thing we effectively support today is true color and the only thing you do true colors change the gamma mapping you can change the mapping of input values to output values for each of the primaries and that is exposed over the KMS API but I don't imagine people are going to be running pseudo color applications for much longer others all done we've got a few minutes spare so thanks very much for coming out today very good well alright thanks very much thank you very much Keith and as a token of appreciation we have a bowl has everyone heard the story of the bowl we've got a few spare moments okay final time today I'll tell you the story of the bowl that's a crushed macadamia nut bowl that was manufactured here in Brisbane for the conference yes rather nice and the factory where that was made was actually flooded was actually being flooded as the bowls were being finished and dried apparently and shipped out the door the story I tell as the tables it was shipped on floated out down the river it was very close to that apparently the factory totally flooded so if there's any water marks on it they're genuine so thank you very much again Keith that was terrific