MONDAY SEP 12
10:00 am - Jamey Sharp re: Codebase of the future
- There's lot of code duplication in the codebase. There is an ongoing effort to clean this up but it's not easy. Replacing Xnest, Xepyhr with drivers for the main Xorg server is desirable, but awkward due to the split between input and video drivers. Wanted tricks that we can't yet do:
- Video card hotplug; either real hardware coming and going (e.g. USB display devices), or virtual (moving a graphics card between servers for multiseat).
- Separation of scanout and render - target use is things like using your desktop GPU to render for a USB display device, and hacks like nVidia Optimus. Xcms needs an overhaul to bring it into line with current understanding of colour correction, and hardware capabilities.
11:00 am - Matthias Hopf re: Bringing In New Contributors
- attracting new contributors - not easy. X is difficult, steep learning curve and not sexy, what can we do?
- Guidelines for contributions - documented on the wiki
- XTS (X Test Suite)- out of date, lots of tests but a good number of them report success but may not actually be correct. Updating these and maintaining them would be a huge chore
- Piglit - good, but not many tests yet and it requires developers to be diligent in writing test cases.
- accessibility in X - what can we do? - probably not much. This belongs at a higher level like the toolkits. It was said that this is throwing the problem over the wall, but Chase pointed out that these days the client composes everything on window and the server essentially just blits the window onto the screen, so the server is completely ignorant as to what's in the window so doing accessibility isn't really possible. (CORRECT THIS IF WRONG.)
3 pm - Daniel Stone, Peter Hutterer, Chase Douglas re: Multi-Touch BoF / Wacom BoF
- Multitouch work continues. It's not as easy as you might think. Old apps will not have these new features. XKB still a pain point - no redesign has yet worked. Daniel's current plan is a XKB 1.1, losing rarely used features, and extending keycodes to 32-bit.
TUESDAY SEP 13
9:10 am - Tom re: compiler stacks
- Lots of work with LLVM - plenty of issues coming out of this, including how best to integrate LLVM codegen into Mesa. OpenCL is big driver of this work. GLSL, not so much, as shaders tend to be hand-optimized for hardware already.
10:55 am - Shinpei re: TimeGraph GPU scheduling
Fundamental trick is to implement scheduling in the DRM driver, thus avoiding the need for userspace drivers to co-operate with each other. Research prototype of code is at http://rtml.ece.cmu.edu/projects/timegraph/
2:00 pm - Alex re: GPU Virtual Memory
- planning to start with Cayman (currently shipping) -
2:40 pm - Luc's talk re: Conference planning
Fosdem Feb 2012
- still same location (ULB Brussels)
- 5000+ attendees
- programs printed in advance so need much earlier planning of program
- better planning may help get larger facility
- Luc needs minimum 6 people committing to talks by Oct 1
XDC Sep 2012 in Nuremberg
- central location
- train between Frankfurt / Nuremberg good, many flights from Frankfurt
- should be very easy to find hotels near event, if you can't find you're doing something wrong
- Egbert: enough hotels to support big trade fairs, so between fairs accomodation easy to find
- get onto Metro from airport
- beer gardens can easily hold groups of 50
- 1 hr to Oktoberfest for Michael
- location TBD, SuSE and university are options
4pm - Q&A panel on attracting new developers
WED SEP 14
9:10am - Jesse Barnes re: DRM Overlay Plane
10:00am - Ian Romanick re: OpenGL 3.0
- Intel expects to have OpenGL 3.0 support in Mesa by the end of the year, but much remains to be done. If it is, mesa 7.12 may actually be released as 8.0.
The team gathered for a 1 day activity to itemize all remaining tasks for achieving OpenGL 3.0. Went through the spec and for each requirement wrote down 1 or more tasks to achieve it onto sticky notes, with no task taking more than (1 week?) Then, given N engineers, they posted the sticky notes into N rows; the number of columns == number of weeks needed to implement. Then all tasks were written into a wiki table where people can grab tasks by adding their name. Process is being found to be simple and straightforward for distributed team work. See http://dri.freedesktop.org/wiki/WorkQueue
11:00am - Martin Peres re: GPGPU
- General purpose computing on the GPU. Processing needs from academics was discussed as well, but these cases might not fit well within open source development models.
2:00pm - Shuang He re: Auto Regression Analysis
- Intel's testing group in China does nightly automated regression testing of the X stack. Faults (lockups, crashes, test failures) are detected and recovered from (e.g. machine is power cycled), and then a regression analysis is done via automated tools, which perform automatic git bisection searches to isolate when the fault began. The system can perform up to 100 bisection iterations per night. The tools for this are not open source (yet?)
3:00pm - Jerome Glisse re: GPU kernel and userspace border
- The API from the kernel GPU driver impacts performance and maintainability and can become a critical bottleneck. Security is a major consideration (over-writing system memory, crashing the computer, etc.) So we can't permit open source drivers to directly feed GPU commands. Jerome discussed an alternative way to build the graphics stack to work around this issue, permitting both high performance and strong security.
4:00pm - Jeremy Huddleston re: Release Schedules
- Jeremy showed the past schedule of releases. X.org has gotten better at sticking to a regular schedule for rc's and releases. Any regression without a credible fix within one week is going to be reverted by Keith Packard. Should the DDX drivers be merged back into the xserver tree? Pros: Easier to propagate API changes across drivers (easier ABI); incentives driver developers to work on server; allows dropping server compat code from drivers; increased testing coverage since users would have to build server in order to test drivers. Cons: More work for distros to backport just driver changes; harder for users to upgrade drivers independently. There was much debate on this topic; there were insufficient stakeholders present to try to achieve a decision nor were any votes taken. The actual mechanics of how this would be managed were examined. A suggestion was made to perhaps post this as a referendum to the X membership.
4:45pm - X.Org Foundation session, Conclusion (XDS2012 Ideas?)