by Martin Peres and Timothée Ravier
With the release of new uses of the Linux Graphic Stack (wayland, WebGL), new opportunities and challenges are facing the xorg developers. In this presentation, we talk about what the user can be expecting from the graphic stack and what is currently proposed by X11 and Weston compared to other approaches like QubesOS/PIGA-OS. We then try to analyze ways to introduce stronger security and provide some advices on how to implement some operations in the stack from the hw to the compositors.
Using Dante (my Doom 3 ES2.0 engine) as a development example it is shown where we're lacking in Mesa compared to others with proper performance analysis tools and how we could possibly fix that situation.
by Eric Anholt and Keith Packard
Aside from the dusty X Test Suite, X server testing tends to be sporadic, manual and ad-hoc. This leads to recurring bugs and breakage that may last several months.
Over the last couple of weeks, I've been working on a test suite based on googletest and xorg-gtest to automate input driver testing, bug replication and general server behaviour. In this talk, I'll give an outline of the current state of this test suite, followed by a discussion on the future direction of this test suite. Amongst the topics to be discussed are scalability, test case design, the requirement for test cases to be added to bug fixes, etc. Audience participation required and appreciated.
by Lucas Stach
by Sascha Hlusiak
The joystick input module was part of the old XFree86 distribution, but the driver was in a bad state until 2007, when development was pushed forward. It first supported the Linux joystick kernel device only, later on support for evdev devices was added, which added support for the driver to be hotplugged by hal enabled server. A FreeBSD kernel backend is available as well, but like Solaris, this is not a prominent system on workstations. Today the joystick driver is well hotpluggable using udev and supports many features and configuration possibilities, like generating mouse button events, pointer movement or key strokes. Enabling the driver to act as both, a pointer and a keyboard device, was particularly challenging. Having a second keyboard device with a different keyboard layout was a problem too, but situation improved with recent servers and XI2/MPX. Support for properties enable 3rd party programs to be written that change the configuration of the device on demand. Prominent target platforms are Linux on the PS3 or the XBox.
by Jess van Derwalker
The XCWM X Composite Window Manager library and XtoQ are two parts of a project that began as a Portland State University CS Capstone course project. Development on the project has continued as part of X.org's EVoC program.
The goal of XCWM is to create a C library that acts as a layer between XCB and OS specific window manager code that facilitates running X client windows as OS native windows on platforms such as OS X, Microsoft Windows, or Wayland. Through XCWM would allow developers to share more code, improve maintainability, and eventually remove some of the specific DDX's within the server code base.
XtoQ, which has been developed concurrently, is a proof of concept window manager application developed for OS X which uses XCWM.
The presentation will cover the basic library structure, some of its features, why certain desisions in implementation were made, and future work.
by Bart Massey
A lot of the problems with writing desktop applications are made much worse by using inappropriate programming languages (such as C/C++). I will review some of these problems, discuss alternative languages, and make suggestions about what to do about it all.
by Mario Kleiner
by Daniel Vetter
Up to now all kms drivers used the same shared crtc helper framework to implement the modeset ioctls. Intel hardware has never been a perfect fit for the crtc helper framework and we've accumulated our fair share of hacks. But with recent efforts (Haswell enabling and planned better handling of shared resources like plls) piling hacks over hacks became no longer manageable, and for kernel 3.7 i915.ko will have a new, driver-private modeset framework.
This presentation details the assumptions and limitations of the crtc helper framework that are at odds with how intel hardware works and explains the design principles of the new code and some of the implementation details.
by Rob Clark
by Rob Clark
by Maarten Lankhorst
by Martin Peres, Timothée Ravier, Kristian Høgsberg and Daniel Vetter
Following the security talks and following discussions, some propositions emerged to refine the DRM interface. This talk will present our conclusions and will request comments from the community.
The talk will majorly consist of two parts. In the first section, I will talk about my experience as an EVOC student, how I got involved and selected my area of work. Some of the early problems that I faced and I will put forward some suggestions on how to make the program better. I personally believe this is a great opportunity for students and hence recommend some ways of streamlining and publicizing it. The second section will however be a bit technical as I will describe my work. Starting with the basic setup, I will describe the need of what I did and how much I have been able achieve. This section will include Pdaemon -> Host communication and the Fermi Scripting Engine. Some details of the process will be discussed and what the future course of action is.
by Lucas Stach
by Chad Versace
Waffle is a cross-platform C library that allows GL applications to defer choice of window system until runtime. For example, on Linux, Waffle enables an application to select X11 with GLX, X11 with EGL, Wayland, or (coming soon) GBM. Its API closely resembles EGL.
Waffle will soon replace GLUT in Piglit, Mesa's OpenGL test suite. This will allow one to build Piglit once, then run its tests under different window systems. This will extend Piglit's portability to Wayland, Android, and X11/EGL. Using GBM, one will even be able to run GL tests on headless machines.
Future plans for Waffle is to add the ability to defer the choice of OpenGL API until runtime using a dynamic dispatch mechanism similar to the one currently used in Piglit.
by Ian Romanick
The last Linux OpenGL ABI dates from 2000. The world has dramatically changed since then. Thanks to the proliferation of smartphones and tables, OpenGL ES and EGL have risen in popularity. Most Linux distros don't ship either OpenGL ES or EGL, and the existing libGL requires applications to use archaic means to access any function added to OpenGL since 1998. I would like to open a discussion for a revision of the Linux OpenGL ABI and a set of recommendations for distros and application developers.
by Blaž Tomažič
OpenCL testing framework written over the course of EVoC. This talk will give an overview of the design and functionality, usage, current status and future plan.