summaryrefslogtreecommitdiff
path: root/Events
diff options
context:
space:
mode:
Diffstat (limited to 'Events')
-rw-r--r--Events/BookSprint2012.mdwn28
-rw-r--r--Events/History.mdwn64
-rw-r--r--Events/XDC2005.mdwn143
-rw-r--r--Events/XDC2006.mdwn132
-rw-r--r--Events/XDC2007.mdwn139
-rw-r--r--Events/XDC2008.mdwn39
-rw-r--r--Events/XDC2008/Attendees.mdwn63
-rw-r--r--Events/XDC2008/Notes.mdwn666
-rw-r--r--Events/XDC2008/Program.mdwn40
-rw-r--r--Events/XDC2009.mdwn39
-rw-r--r--Events/XDC2009/Attendees.mdwn41
-rw-r--r--Events/XDC2009/Notes.mdwn255
-rw-r--r--Events/XDC2009/Program.mdwn53
-rw-r--r--Events/XDC2011.mdwn120
-rw-r--r--Events/XDC2011/Attendees.mdwn40
-rw-r--r--Events/XDC2011/Notes.mdwn71
-rw-r--r--Events/XDC2011/Program.mdwn89
-rw-r--r--Events/XDC2012.mdwn135
-rw-r--r--Events/XDC2012/Attendees.mdwn64
-rw-r--r--Events/XDC2012/Hiking.mdwn0
-rw-r--r--Events/XDC2012/Hotels.mdwn38
-rw-r--r--Events/XDC2012/Proceedings.mdwn633
-rw-r--r--Events/XDC2012/Program.mdwn66
-rw-r--r--Events/XDC2012/PublicTransportation.mdwn21
-rw-r--r--Events/XDC2012/Weekend.mdwn69
-rw-r--r--Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractBartMassey.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdfbin0 -> 136330 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdfbin0 -> 139525 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractChadVersace.mdwn16
-rw-r--r--Events/XDC2012/XDC2012AbstractDanielVetter.mdwn12
-rw-r--r--Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdfbin0 -> 83563 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractIanRomanick.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn16
-rw-r--r--Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdfbin0 -> 1566056 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractKickOff.mdwn5
-rw-r--r--Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdfbin0 -> 985178 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractMartinPeres.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdfbin0 -> 50902 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdfbin0 -> 6465096 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdfbin0 -> 370750 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn14
-rw-r--r--Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdfbin0 -> 77542 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdfbin0 -> 82590 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn8
-rw-r--r--Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdfbin0 -> 124683 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn12
-rw-r--r--Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdfbin0 -> 940218 bytes
-rw-r--r--Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn10
-rw-r--r--Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdfbin0 -> 136830 bytes
-rw-r--r--Events/XDC2013.mdwn87
-rw-r--r--Events/XDC2013/Attendees.mdwn10
-rw-r--r--Events/XDC2013/CallForProposals.mdwn23
-rw-r--r--Events/XDS2007.mdwn54
-rw-r--r--Events/XDS2007/Attendees.mdwn59
-rw-r--r--Events/XDS2007/ModeSettingBoF.mdwn46
-rw-r--r--Events/XDS2007/Notes.mdwn421
-rw-r--r--Events/XDS2007/Program.mdwn57
-rw-r--r--Events/XDS2007/TTMBoF.mdwn61
-rw-r--r--Events/XDS2008.mdwn52
-rw-r--r--Events/XDS2008/Attendees.mdwn34
-rw-r--r--Events/XDS2008/Notes.mdwn169
-rw-r--r--Events/XDS2008/Notes/PredictablePointerAcceleration.pdfbin0 -> 64117 bytes
-rw-r--r--Events/XDS2008/Program.mdwn51
-rw-r--r--Events/XDS2008/Program/gfx_test_xds2008.pdfbin0 -> 317929 bytes
-rw-r--r--Events/XDS2008/Recordings.mdwn6
-rw-r--r--Events/XDS2010.mdwn74
-rw-r--r--Events/XDS2010/Attendees.mdwn65
-rw-r--r--Events/XDS2010/Hotels.mdwn137
-rw-r--r--Events/XDS2010/Notes.mdwn615
-rw-r--r--Events/XDS2010/Program.mdwn106
-rw-r--r--Events/XDS2010/Program/intro.pdfbin0 -> 238213 bytes
-rw-r--r--Events/XDS2010/xds2010-color-small.pngbin0 -> 25914 bytes
-rw-r--r--Events/XDS2010/xds2010-color.svg350
-rw-r--r--Events/XDS2012.mdwn8
88 files changed, 5778 insertions, 0 deletions
diff --git a/Events/BookSprint2012.mdwn b/Events/BookSprint2012.mdwn
new file mode 100644
index 00000000..f89d7067
--- /dev/null
+++ b/Events/BookSprint2012.mdwn
@@ -0,0 +1,28 @@
+
+**Summary**: In order to help with documentation and guides for developers, both existing and new, we will have a book sprint the two days prior to [[XDC2012|Events/XDC2012]].
+
+**When**: Monday Sept 17 & Tuesday Sept 18. Opening hours will be early in the morning (TBD, 8am?) until we call it a day (but certainly no longer than 10pm).
+
+**Where**: [[Keßlerstraße 1|http://maps.google.de/maps?f=q&source=s_q&hl=de&authuser=0&q=Keßlerstraße+1,+90409+Nürnberg,+Bayern&aq=&vps=1&jsv=402e&sll=51.151786,10.415039&sspn=14.100269,34.936523&vpsrc=1&ie=UTF8&oi=georefine&ct=clnk&cd=2&geocode=FT2y8gIdqRupAA&split=0]]. Room 4020 (4th floor, which would be 5th floor in American way of counting), a small part of the Georg-Simon-Ohm-University, in the old "[[Postbank|http://www.postbank.com/]]". It's the building at the corner, the yellow "Postbank" sign is still widely visible. In approximately the middle of the same building there is another "Postbank", with the same sign, that is the new (wrong) one.
+
+**What**: Driver Developers Guide (tentative)
+
+**Who**: The X Book Posse
+
+**Details**:
+
+Marcheu has a very nice start on a Guide. This sprint will be to review and fill in anything missing.
+
+Current Guide: [[http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf|http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf]]
+
+git: [[http://cgit.freedesktop.org/~marcheu/lgd/|http://cgit.freedesktop.org/~marcheu/lgd/]]
+[[!table header="no" class="mointable" data="""
+**Proposed Schedule (_**very_** rough storyboard. It's at least something):**||
+Mon 9am-noon | Review existing Guide and create TODO list (identify holes and what needs polish)
+Mon noon~1pm | lunch
+Mon 1pm-5pm | Fill in any holes
+Tues 9am-noon | Begin polish
+Tues noon-1pm | lunch
+Tues 1pm-5pm | finish polish
+Tues 5pm-? | beer
+"""]]
diff --git a/Events/History.mdwn b/Events/History.mdwn
new file mode 100644
index 00000000..3a7b2196
--- /dev/null
+++ b/Events/History.mdwn
@@ -0,0 +1,64 @@
+
+A collection of older events that X.Org has held, presented at, or had significant presence at. Move things here from the [[current events page|Events]] when they get too old, and if possible, link to what we did there.
+
+
+### 2011
+
+* [[X.Org Developers' Conference (XDC2011)|Events/XDC2011]]. Chicago, USA, September 12 through 14, 2011.
+* [[Linux Plumbers Conf 2011|http://www.linuxplumbersconf.org/2011/]], Santa Rosa, California, USA, September 7 through 9, 2011
+* [[GNOME/KDE Desktop Summit|http://www.desktopsummit.org/]], Berlin, Germany, August 6 through 12, 2011
+* [[linux.conf.au 2011|http://lca2011.linux.org.au/]], Brisbane, Australia, January 24 through 29, 2011
+
+### 2010
+
+* [[Linux Plumber's Conference|http://events.linuxfoundation.org/events]], Cambridge, Massachusetts, USA, November 3 through 5, 2010
+* [[X.Org Developers' Summit (XDS2010)|Events/XDS2010]]. Toulouse, France, September 16 through 18, 2010.
+* [[GUADEC 2010|http://www.guadec.org/index.php/guadec/2010]], The Hague, The Netherlands, July 24 through 30, 2010
+* [[Akademy 2010|http://akademy.kde.org/]], Tampere, Finland, July 3 through 10, 2010
+* [[FOSDEM 2010|fosdem2010]], Brussels, Belgium, February 6 and 7, 2010
+* [[linux.conf.au 2010|http://www.lca2010.org.nz/]], Wellington, New Zealand, January 18 through 23, 2010
+
+### 2009
+
+* [[VideoHackfest|http://gstreamer.freedesktop.org/wiki/VideoHackfest]], Barcelona, Spain, November 19th through 22nd, 2009
+* [[X.Org Developers' Conference 2009|Events/XDC2009]], Portland, Oregon, USA, September 28 through 30
+* [[Linux Plumber's Conference|http://linuxplumbersconf.org/2009/]]: [[X Window System track|http://linuxplumbersconf.org/ocw/events/2009/tracks/3]], Portland, Oregon, USA, September 23 through 25
+* [[Gran Canaria Desktop Summit: GUADEC & Akademy 2009|http://www.grancanariadesktopsummit.org/]], Las Palmas, Gran Canaria, July 3 through 11, 2009
+* [[FOSDEM 2009|fosdem2009]], Brussels, Belgium, February 5 through 8, 2009
+* [[linux.conf.au|http://linux.conf.au/]], Hobart, Tasmania, January 19 through 24, 2009
+
+### 2008
+
+* [[Gnome Boston Summit|http://live.gnome.org/Boston2008]], Cambridge, Massachusetts, October 10 through 13.
+* [[X.Org Developers' Summit 2008|Events/XDS2008]], Edinburgh, Scotland, September 3 through 5.
+* [[GUADEC 2008|http://2008.guadec.org/]], Istanbul, Turkey, July 7th through 12
+* [[X.Org Developers' Conference 2008|Events/XDC2008]], Mountain View, California, April 16 through 18.
+* [[xorg@fosdem 2008|fosdem2008]], February 23 - 24. Brussels, Belgium.
+* [[linux.conf.au|http://linux.conf.au/]], Melbourne, Australia, Jan 28 - Feb 2
+
+### 2007
+
+* [[Gnome Summit|http://live.gnome.org/BostonSummit]], Cambridge, Massachusetts, October 6 through 8.
+* [[X.Org Developers' Summit 2007|Events/XDS2007]], Cambridge, England, September 10 through 12.
+* [[GUADEC 2007|http://2007.guadec.org/]], Birmingham, England, July 15 through 21.
+* [[xorg@fosdem 2007|fosdem2007]], February 24-25. Brussels, Belgium.
+* [[Xorg Developer's Conference 2007|Events/XDC2007]] was held on February 7, 8, and 9 in the San Francisco Bay Area. See [[XDC2007Notes|XDC2007Notes]] for the talk transcript.
+
+## 2006
+
+* An X.Org BOF was held at [[SIGGRAPH 2006|http://www.siggraph.org/s2006/index.php]] (August 1 through 3, 2006) in Boston.
+* The [[Desktop Developers' Conference|http://lanyrd.com/2006/desktop-developers-conference/]] was held July 17 and 18, 2006, in Ottawa prior to OLS 2006.
+* X.Org presented at [[LinuxTag|LinuxTag]] 2006 in Wiesbaden, Germany May 3 - 6 2006.
+* X.Org had an [[X Developers HotHouse and X DevRoom|fosdem2006]] on February 24-26 at FOSDEM 2006 in Brussels, Belgium.
+* [[X Developers' Conference 2006|Events/XDC2006]] was held on February 8-10 2006 at the Sun Microsystems campus in Santa Clara, CA.
+
+## 2005
+
+* [[Desktop Developers' Conference|http://lanyrd.com/2005/desktop-developers-conference/]], July 18 and 19, 2005, Ottawa, prior to OLS 2005.
+* X.Org had its first European Developers meeting in Karlsruhe, Germany from June, 19 to June, 20, right before [[LinuxTag 2005|http://www.linuxtag.org]]. (Read more at [[LinuxTagMeeting2005|LinuxTagMeeting2005]])
+* [[X Developers' Conference 2005|Events/XDC2005]], February 12 through 14, in Cambridge, Massachusetts.
+
+## 2004
+
+* [[Desktop Developers' Conference|http://lanyrd.com/2004/desktop-developers-conference/]], July 19 and 20, 2004, Ottawa, prior to OLS 2004.
+* The first X Developers' Conference (well, first for the X.Org Foundation) was April 28 through 30, 2004 in Cambridge, Massachusetts. \ No newline at end of file
diff --git a/Events/XDC2005.mdwn b/Events/XDC2005.mdwn
new file mode 100644
index 00000000..9b06f0e0
--- /dev/null
+++ b/Events/XDC2005.mdwn
@@ -0,0 +1,143 @@
+
+
+## X Developer's Meeting 2005
+[[!table header="no" class="mointable" data="""
+ **XDC 2005** | [[XDC 2006 >>|Events/XDC2006]]
+"""]]
+
+We have scheduled a three day X Developer's meeting from Saturday, February 12, through Monday, February 14, at the Cambridge Research Laboratory (CRL) in Cambridge, Massachusetts.
+
+**** The meeting is now full!!! ***
+
+This meeting is intended to cover a wide variety of topics about X Window System technologies, and the as yet unmet needs of the technologies that depend on the X Window System. As a result, this meeting is intended for people working across the entire X Window System stack, including toolkits and window managers and desktop infrastructure. This meeting is not, however, intended to cover general X application development topics or concepts.
+
+There will be a number of people giving presentations or leading discussions. These presentations will likely consume no more than half of the overall meeting time so the remaining time can be spent with informal discussions, hacking, breakout sessions, etc.
+
+If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well.
+
+
+### Attend via Phone
+
+The phone bridge is not working. See below for Audio streaming.
+
+
+### Attend via IRC
+
+IRC: freenode, #xdevconf
+
+
+### Attend via Audio/Video feeds
+
+X developer's meeting audio and video feeds:
+
+* Audio: Point gnomemeeting at gabe.freedesktop.org. First, go into Audio Codecs and disable everything but G.711-uLaw and G.711-ALaw; needs a bit more bandwidth but means you can actually hear what people are saying.
+* Vide:o Depending on your browser click on [[http://freedesktop.org:9192/|http://freedesktop.org:9192/]] or [[http://freedesktop.org/~keithp/webcam.html|http://freedesktop.org/~keithp/webcam.html]].
+Will video presentations be available somewhere? Are them recorded?
+
+
+### Presentation Agenda
+
+Current presentations for the X Developer's Meeting include:
+
+
+#### Saturday, February 12
+
+* Starting at 9:00
+* Welcome, logistics, agenda, schedule bashing
+ * Freedesktop Forum: What Problems Do We Need To Solve - Havoc Penningon, George Staikos, Jim Gettys
+ * DND, Other Specification Issues - Owen Taylor and George Staikos
+ * xrestop, xephyr, and X on handhelds - Mathew Allum ([[slides|http://www.o-hand.com/xmeet/]], [[demo|http://projects.o-hand.com/matchbox/demos.html]])
+ * Testing Strategies - Stuart Anderson, Free Standards Group and X.org
+ * Short Topics - All
+
+#### Sunday, February 13
+
+* Starting at 9:00
+ * X Proxy and Multicast Demo - David Flynn, Realm Systems
+* A Unified View of Improving X Desktop Rendering - The Owen Taylor, Søren Sandmann, Kristian Høgsberg and Diana Fong show
+ * Cairo Status - Carl Worth, Red Hat (Slides: [[SVG|http://cairographics.org/talks/xdevconf_2005_02_13/svg]], [[HTML|http://cairographics.org/talks/xdevconf_2005_02_13/html]] [[PDF|http://cairographics.org/talks/xdevconf_2005_02_13/cairo.pdf]])
+ * X Input Redirection - Deron Johnson, Keith Packard ([[Intro & Slides|http://lists.freedesktop.org/archives/xevie/2005-February/000039.html]])
+ * A New Input System - Kristian Hogsberg, Jim Gettys
+ * Polling And Scheduling in the X Main Loop - Kristian Høgsberg, Red Hat
+ * Reworking the X server main loop, with proposed changes.
+ * X and Media Support - Leon Shiman
+ * 3D Graphics Pipelines - Nick Triantos, NVidia
+
+#### Monday, February 14
+
+* Starting at 9:00
+ * Open Source Legal discussion, Patents and Copyrights - Scott Peterson, Greg Jones, Linda Hamel, General Counsel, MA ITD (Information Technology Division)
+ * X on GL - David Reveman, Novell
+ * Mesa Solo - Jon Smirl
+ * Merging fbdev and DRM - Jon Smirl
+ * X.org Update - Audience
+Please all the people leave your presentations here so other people can see them.
+
+
+### Limited In-Person Attendance
+
+Due to space limitations, attendance will be limited to no more than 40 people, and we are almost full. If you would like to attend, please send mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. Having the names of attendees in advance eases building security, as we share the building with other companies.
+
+An audio feed will be made available for those attending remotely or unable to attend due to limitations on space. The meeting venue provides networking support with high speed Internet access.
+
+The hotels recommended near CRL are The Kendall Hotel, the Cambridge Marriott, and the Residence Inn. All three of these are a short walk from CRL and easily accessible via public transportation from the Kendall Square subway stop next to MIT. We have not negotiated any special rates with these hotels, so you'll need to shop around for the best rates, as they vary. A longer list of hotels is available at [[http://www.ai.mit.edu/visiting/hotels/hotels.shtml|http://www.ai.mit.edu/visiting/hotels/hotels.shtml]] . Directions to the lab can be found at: [[http://www.crl.hpl.hp.com/who/lab/directions.htm|http://www.crl.hpl.hp.com/who/lab/directions.htm]]
+
+
+### Currently Registered Attendees
+
+Currently registered attendees include:
+
+ 1. Bill Abt
+ 1. Matthew Allum
+ 1. Paul Anderson
+ 1. Stuart Anderson
+ 1. Scott Balneves
+ 1. David Boloker
+ 1. Phil Blundell
+ 1. Mirko Boehm
+ 1. Alan Coopersmith
+ 1. Egbert Eich
+ 1. Mike Emmel
+ 1. David Flynn
+ 1. Nat Friedman
+ 1. Diana Fong
+ 1. Bdale Garbee
+ 1. Jim Gettys
+ 1. Jim Glutting
+ 1. Linda Hamel
+ 1. Mike A. Harris
+ 1. Kristian Høgsberg
+ 1. Mattias Hopf
+ 1. Harold Hunt
+ 1. Miguel de Icaza
+ 1. Lars Knoll
+ 1. Tommi Komulainen
+ 1. Adam Jackson
+ 1. Deron Johnson
+ 1. Eric Kunze
+ 1. Stewart Kreitman
+ 1. Paul Litvak
+ 1. Chris Lee
+ 1. Lubos Lunak
+ 1. Duncan Mak
+ 1. Kevin Martin
+ 1. Jim [[McQuillan|McQuillan]]
+ 1. Nhan Nguyen
+ 1. Keith Packard
+ 1. Tapani Pälli
+ 1. Havoc Pennington
+ 1. Larry Rau
+ 1. David Reveman
+ 1. Andy Ritger
+ 1. Robin Rowe
+ 1. Zack Rusin
+ 1. George Staikos
+ 1. Søren Sandmann
+ 1. Leon Shiman
+ 1. Owen Taylor
+ 1. Nick Triantos
+ 1. Peter Winston
+ 1. Carl Worth
+ 1. Scott Peterson
+ 1. Greg Jones
+-- [[JimGettys|JimGettys]] - Feb. 13, 2005
diff --git a/Events/XDC2006.mdwn b/Events/XDC2006.mdwn
new file mode 100644
index 00000000..128568ff
--- /dev/null
+++ b/Events/XDC2006.mdwn
@@ -0,0 +1,132 @@
+
+
+# X Developers Conference 2006
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2005|Events/XDC2005]] | **XDC 2006** | [[XDC 2007 >>|Events/XDC2007]]
+"""]]
+
+
+### Overview
+
+As a followon to previous conferences, we invite presentations on all topics related to the development and furtherance of X Window System technologies.
+
+If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well.
+
+
+### Location and Dates
+
+The next X.Org Developer's Conference will be held from February 8, 2006 to February 10, 2006 at the [[Sun Microsystems Santa Clara (Agnews) Campus|http://www.cr.nps.gov/nr/travel/santaclara/agn.htm]] in Santa Clara, CA, USA. ([[Driving Directions|http://www.sun.com/aboutsun/media/presskits/directions.html#sc]])
+
+
+#### Building Change
+
+Same Sun Santa Clara Campus, but we have acquired a room inside the Fortress. The Building Name is SCA15, room "HARVARD" on the first floor. This building is accessed from the North``East side of the campus, a short, direct walk from the River``Mark Plaza shopping area/Sierra Suites area.
+
+([[Google Map of the Sun Campus, Centered on SCA15|http://maps.google.com/?t=k&ll=37.394948,-121.952373&spn=0.003077,0.005456&t=k]])
+
+We have an attended lobby with badges for everyone listed on this Wiki page. If you do not see your name here, let me know ASAP or you will not gain admittance to the conference.
+
+
+### Registration
+
+REGISTRATION IS CLOSED
+
+Simple: Send email to [[stuart.kreitman@sun.com|mailto:stuart.kreitman@sun.com]]
+
+
+### Conference Notes
+
+Notes from the presentations are being maintained by Adam Jackson ([[Presentation Notes|http://people.freedesktop.org/~ajax/xdc2006-notes.txt]]). (thanks, Adam! skk)
+
+
+### Conference Schedule
+
+
+#### Wednesday, February 8, 2006
+
+ * 8:00 AM Room Open, Get Togethers, Continental Breakfast 9:00 AM Real Start: Welcome, logistics, agenda, schedule bashing 9:30 AM Board of Directors Introductions
+ * 10:00 AM "Xgl" - David Reveman, Novell ([[Slides|http://www.freedesktop.org/~davidr/xdevconf06/]]) 11:00 AM "Avalon" - Matthias Hopf 12:00 AM Lunch 1:00 PM "Status Update on Project Looking Glass" - Deron Johnson, Sun 1:30 PM "Coordinate Redirection" - Keith Packard 2:00 PM "NVIDIA Driver Internals" - Andy Ritger, Nvidia ([[Slides|http://developer.nvidia.com/object/xdevconf_2006_presentations.html]]) 3:00 PM "Development Challenges for X and GL" - Kevin Martin, Red Hat ([[Slides|http://people.freedesktop.org/~kem/kem-xdevconf2006.pdf]]) 4:00 PM "Device Driver Issues TBD" - David Airlie 5:00 PM "X on Small Devices, Nokia 770" - Tapani Pälli, Nokia ([[Slides|https://stage.maemo.org/svn/maemo/projects/haf/doc/presentations/xdevconf2006_770.pdf]]) 6:00 PM Shuttle to El Torito's Mexican Restaurant (2950 Lakeside Dr, Santa Clara), Dinner Hosted by [[StarNet|StarNet]] Communications 9:00 PM Shuttle back to Campus, Hotels
+
+#### Thursday, February 9, 2006
+
+ * 9:00 AM Soft Start (joint Board/Sponsor's headbashing from 7:30 to 10:00)
+ * 10:00 AM Real Start 10:00 AM "What Accessibility Needs from X" - Peter Korn, Sun 11:00 AM Open Time Slot - BREAKOUT SESSIONS
+ * XCB status update - Keith Packard
+ * GLX_EXT_texture_from_pixmap spec wrangling - numerous people 12:00 AM Lunch "Open Solaris, Open Source Development at Sun"
+ * - Stephen Harpster, Director of Open Solaris, Sun Microsystems
+1:00 PM "Accelerated Indirect GLX" - Kristian Høgsberg, Red Hat ([[slides|http://people.freedesktop.org/~krh/aiglx.pdf]])
+2:00 PM "A preview of the GNOME compositing manager" - Søren Sandmann Pedersen, Red Hat
+3:00 PM "Deconstructing X Server Configuration" - Adam Jackson, Red Hat ([[slides|http://people.freedesktop.org/~ajax/xdc2006.pdf]])
+4:00 PM Break, Depart for Intel computer museum 6:00 PM Shuttle to Mountain View Castro Street Restaurant District 8:30 PM Everyone meet at Tied House Brewery off of Castro 10:00 PM Shuttle back to conference center
+
+#### Friday, February 10, 2006
+
+ * 8:00 AM Continental Breakfast 9:00 AM Start 9:00 AM "Power Management for Graphics Subsystems" - Jay Cotton, Sun ([[slides|http://mediacast.sun.com/share/alanc/xdevconf06-fbpm.pdf]])
+ * 10:00 AM "Beyond Modelines: Xorg Display Configuration" - Stuart Kreitman, Sun 11:00 AM "Challenges of [[OLPC|http://www.laptop.org/]] Graphics" - Jim Gettys, OLPC 12:00 AM Lunch 1:00 PM "New DRI memory manager and i915 driver update" - Keith Whitwell & Thomas Hellstrom, Tungsten Graphics ([[slides|http://www.tungstengraphics.com/xdevconf2006.pdf]]) 2:00 PM "Evolving" - Zack Rusin (cancelled) 3:00 PM TALKS ARE OVER! Beer by the case. We'll keep the room open till 6 6:00 PM BYE ALL!!
+
+##### Hackfesting, Brainstorming, and Beer
+
+In response to feedback from previous Developer Conferences, we will enable good amounts of time, infrastructure, and space for getting actual work done.
+
+Proposed Breakout Sessions/Hacking Focus on:
+
+* Display configuration
+* Accessibility
+* Composite-aware managers
+* Composite-aware screen magnification
+* Live Video
+* Security
+* Thin Client and workstation performance analysis
+* Composite / OpenGL compatibility
+* Composite / XVideo compatibility
+* Making X pixmaps directly usable as textures by OpenGL clients
+* A session on improvements that should be made to OpenGL texture resource management in order to gracefully operate in an environment where all running programs are using textures
+Please submit your interest in these and other topics.
+
+
+#### Confirmed Attendees
+
+Mahmood Ali, David Airlie, Paul Anderson, Stuart Anderson, Jesse Barnes, Billy Biggs, Eric Boucher, David J. Brown, Ignacio Castano, Jesse Clayton, Alan Coopersmith, Jay Cotton, Jim Gettys, Alexandre Gouaillard, Thomas Hellstrom, Jay Hobson, Kristian Høgsberg, Alan Hourihane, David Hoover, Matthias Hopf, Harold Hunt, Adam Jackson, Deron Johnson, James Jones, Joe Kain, Stuart Kreitman, Tommi Komulainen, Peter Korn, Carol Lavelle, Phillip Langdale, Sam Lau, John M. Martin Jim Mc``Quillan, Kevin E. Martin, Valery Moya, Shrijeet Mukherjee, Jens Owen, Keith Packard, Tapani Palli, Stuart Parmenter, Søren Sandmann Pedersen, Aaron Plattner, Martin Porcelli, Nivedita Rao, Andy Ritger, Zack Rusin, Bankim Shah, Jamie Sharp, David Schleef, Steve Schoch, Leon Shiman, Edward Shu, Paul Swart, Carl Switzky, Vladimir Vukicevic, Keith Whitwell, Henry Zhao, Daniel Zhu,
+
+Count: 59
+
+
+#### Logistics
+
+The nearest airport is San Jose Mineta ("SJC"). Distance to Sun Santa Clara Campus Bell Tower is 3 miles. San Francisco Airport ("SFO") is larger and be more accessible by air. It is about 45 miles north of the Bell Tower, but you can take the Caltrain shuttle down to Santa Clara or up to San Francisco. The Sunway shuttle stops at various caltrain stations near Santa Clara and Menlo Park. Bicycles are permitted on the caltrain and Sunway.
+
+[[http://www.caltrain.com/caltrain_map.html|http://www.caltrain.com/caltrain_map.html]]
+
+Stay tuned for a list of closeby hotels with favorable rates and shuttle bus availability
+
+This is California. Public transportation is mostly nonexistant.You don't get anywhere without wheels. Therefore, we are working on attaching the [[SunWay|SunWay]] shuttle fleet to help move willing groups of people to the selected evening events. We will make every attempt to minimize the need for having a car during this conference. Carpooling will figure large in this endeavor, so please indicate whether you will have seats available, or will need a seat during your stay here.
+
+Update, Dec 13, 2005:
+
+It looks like we will be able to provide Sunway Shuttle service for airport pickups, hotel sweeps, and evenings out. We do need headcount for these resources ASAP. Feb 6,2006: Having received zero requests for ground transportation, this option is no longer being offered.
+
+
+#### Recommended Hotels
+
+***Sierra Suites, 3915 Rivermark Plaza, Santa Clara, CA (408) 486-0800
+
+ * +++ 3 miles from SJC, Walking Distance to Conference. +++
+*Biltmore Hotel, 2151 Laurelwood Road, Santa Clara (408) 988-8411, (800) 255-9925
+
+*Double``Tree Hotel, 2050 Gateway Place, San Jose (408) 453-4000
+
+*Embassy Suites, 2885 Lakeside Drive, Santa Clara (408) 496-6400
+
+*Hyatt San Jose, 1740 North 1st Street, San Jose (408) 993-1234, (888) 975-1234
+
+*Marriott Santa Clara, 2700 Mission College Boulevard, (408) 988-1500
+
+*Santa Clara Hilton, 4949 Great America Parkway, Santa Clara (408) 330-0001
+
+*Staybridge Suites, 900 Hamlin Court, Sunnyvale (408) 745-1515
+
+*Staybridge Suites, 1602 Crane Court, San Jose (408) 436-1600
+
+*Westin Santa Clara, 5101 Great America Parkway, Santa Clara (408) 986-0700
+
+*Wyndham Hotels, 1350 North 1st Street, San Jose (408) 453-6200
diff --git a/Events/XDC2007.mdwn b/Events/XDC2007.mdwn
new file mode 100644
index 00000000..491146b2
--- /dev/null
+++ b/Events/XDC2007.mdwn
@@ -0,0 +1,139 @@
+
+
+# XDC2007: Xorg Developer's Conference
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2006|Events/XDC2006]] | **XDC 2007** | [[XDS 2007 >>|Events/XDS2007]]
+"""]]
+
+
+## February 7,8,9 2007 San Francisco Bay Area
+
+Conference organizer: [[Stuart Kreitman|mailto:stuart.kreitman@sun.com]]
+
+Live notes are going up at [[XDC2007Notes|XDC2007Notes]]. Play along!
+
+
+## Location
+
+We're a go for the [[TechShop|http://techshop.ws./]], a very cool Maker's workshop very near Sun's Menlo Park campus, and close to Palo Alto and Menlo Park Hotels and dining.
+
+Address/Map: [[120 Independence Drive, Menlo Park, CA 94025|http://maps.google.com/maps?q=120+Independence+Dr,+Menlo+Park,+CA+94025]]
+
+
+## Getting There, Getting Around There
+
+[[San Jose (SJC) Airport|http://www.sjc.org/]] is 16 miles south of Menlo Park airporter shuttle (1-800-XXX XXXX)
+
+[[San Francisco (SFO) Airport|http://www.flysfo.com/]] is 20 miles north of Menlo Park
+
+
+## Recommended Hotels
+
+* Hampton Inn, 390 moffett blvd, Mountain View CA
+* Marriot Residence Inn, 4460 El Camino Real, Los Altos
+* Marriot Residence Inn, # 1854 El Camino Real West Mountain View , CA
+* Sheraton Palo Alto
+* Westin Palo Alto
+* Stanford Park Hotel
+_range of price/convenience options, The above listed are good places in good locations_
+
+
+## Agenda (Presenters: Get your talk listed here. If you need a change, negotiate directly with other presenters and update the wiki)
+
+_each item corresponds roughly to one hour of programming_ _Each day, we're planning 3 1 hr slots before lunch, and 2 1 hr slots after lunch, then breakouts_
+
+_In response to feedback from last year's conference, we are leaving more open space in the schedule for structured and unstructured un-conferencing each day_
+
+
+### Wednesday 9AM -> 5 PM
+
+* Introductions, Overview - Stuart Kreitman
+* [[MultiPointer|MultiPointer]] X - Peter Hutterer
+* Virtual Multihead - Philip Langdale, VMware
+* Lunch
+* Randr 1.2 - Keith Packard, Intel
+* 7.2/7.3 Roadmap - Adam Jackson, Red Hat
+* Breakout Sessions - All
+* Breakout Reports - All
+
+### Thursday 9AM -> 5 PM
+
+* Board of Directors Report, Q&A
+* Display Technology, EDID, VESA - Joe Miseli (Sun)
+* Lunch
+* Secure X - Eamon Walsh ([[SecurityTalkAgenda|SecurityTalkAgenda]])
+* Cut&Paste - Bart Massey
+* Breakout Sessions - All
+* Breakout Reports - All
+
+### Friday 9AM -> 5 PM
+
+* Compiz - David Reveman
+* Beryl - Quinn Storm
+* Mesa - Brian Paul
+* Lunch
+* NVIDIA, Xinerama - Andy Ritger, NVIDIA
+* Xcb - Bart Massey, Portland State U.
+* Breakouts
+* Bash! Gunn High School's award winning Jazz Combo will play for us!
+
+### Items not covered
+
+* Virtualization (Xen)
+* (auto)-configuration
+* Open Source drivers vs Vista-certified
+* Display Port / HDMI / replacing VGA/DVI
+* Nouveau
+* One Laptop Per Child - Jim Gettys, olpc (Cancelled)
+
+## Attendees
+
+_insert your name on a separate line_
+
+* Eric Anholt, Intel
+* Jesse Barnes, Intel
+* Ben Byer, Apple
+* Erwann Chénedé, Sun
+* [[Alan Coopersmith|AlanCoopersmith]], Sun
+* Jay Cotton, Sun
+* Alex Deucher
+* Egbert Eich, SuSE
+* Behdad Esfahbod, [[RedHat|RedHat]]
+* Matthias Hopf, SuSE
+* Peter Hutterer, UniSA
+* Adam Jackson, Red Hat
+* James Jones, Nvidia
+* Stuart Kreitman, Sun
+* Philip Langdale, VMware
+* Chris Lee, VMware
+* Kevin Martin, Red Hat
+* Bart Massey, Portland State University
+* Jim [[McQuillan|McQuillan]], ltsp.org
+* Joe Miseli, Sun
+* Keith Packard, Intel
+* Brian Paul, Tungsten Graphics
+* Aaron Plattner, Nvidia
+* Niveditha Rau, Sun
+* David Reveman, Novell
+* Andy Ritger, Nvidia
+* Bankim Shah, Attachmate
+* Carl Switzky, Sun
+* Roberto Tam, Sun
+* Bernard Traversat, Sun
+* Kevin Van Vechten, Apple
+* Eamon Walsh, NSA (SELinux developer)
+* NOT ATTENDING:
+ * Carl Worth, Red Hat, (I had been planning to attend, but due to unforeseen circumstances will not be available. Have fun, everybody!);
+ * Daniel Stone, Nokia (cannot attend due to schedule clashes -- sorry!)
+ * Jim Gettys, OLPC (Thursday only)
+
+## Sharing Stuff
+
+Folks in need, and folks in a generous mood, please list your interests (or send me email if you want me to help you get matched up)
+
+
+## Other Stuff
+
+If you're finishing up the Xorg Developer's Conference, and haven't had your fill of geek stuff, head down the coast to Los Angeles on Friday. The Fifth Annual [[SoCal|SoCal]] Linux Expo will be February 9th-11th at the Westin LAX Hotel (which is a short shuttle ride from LAX). There are four speaker tracks on both Saturday and Sunday, plus BOFs and a couple of mini-conferences on Friday. If you'd like a BOF for any reason, contact [[g@socallinuxexpo.com|mailto:g@socallinuxexpo.com]] . For more info on the Expo, see [[http://socallinuxexpo.org|http://socallinuxexpo.org]]
+
+Thanks to Stu for the commercial space!
diff --git a/Events/XDC2008.mdwn b/Events/XDC2008.mdwn
new file mode 100644
index 00000000..4a9c6048
--- /dev/null
+++ b/Events/XDC2008.mdwn
@@ -0,0 +1,39 @@
+
+
+# XDC 2008
+[[!table header="no" class="mointable" data="""
+ [[<< XDS 2007|Events/XDS2007]] | **XDC 2008** | [[XDS 2008 >>|Events/XDS2008]]
+"""]]
+
+The X Developers' Conference for 2008 was hosted by Google in Mountain View, California, from the 16th through the 18th of April, 2008. The event will be held at [[1501 Salado Drive|http://maps.google.com/maps?f=q&hl=en&geocode=&q=1501+salado,+mountain+view&jsv=107&sll=37.0625,-95.677068&sspn=50.291089,80.15625&ie=UTF8&z=16]]. This is on the opposite side of the Ampitheater Parkway/Rengstorff Ave offramp from US-101 than the rest of the Google complex. Please make a note of how to get there.
+
+* [[Attendees|Events/XDC2008/Attendees]]
+* [[Program|Events/XDC2008/Program]]
+* [[Notes from the talks|Events/XDC2008/Notes]]
+We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities.
+
+Attendance is free, but you must register beforehand, by putting your name on the Attendees page.
+
+
+## Accommodation
+
+There are [[several hotels|http://maps.google.com/maps?near=1600+Amphitheatre+Parkway,+Mountain+View,+CA+94043+(Google)&geocode=6913274534084284730,37.423398,-122.086507&q=hotels&f=l&hl=en&dq=google+loc:+Mountain+View,+CA&ie=UTF8&t=h&z=13]] near the Google offices. Many of them are filling up and most have said that they are usually full a week before the day you arrive, so don't wait til the last minute. The [[Best Western Mountain View|http://book.bestwestern.com/bestwestern/productInfo.do?propertyCode=05355]] is where several of us are staying, and as of 2008 Apr 11, they still had several rooms available.
+
+
+## Travel
+
+The nearest airport to Mountain View is San Jose, California (SJC), but the one most attendees will likely be flying into is San Francisco International (SFO). SFO is about 30 miles from Mountain View, and as such, a taxicab would be rather expensive. Other options are renting a car (advised, since any hotel would be a few miles from Google) or using the BART/CalTrain to get to Mountain View, and then taking a taxicab to your hotel from there.
+
+The event will be held at 1501 Salado Drive, Mountain View. [[Map|http://maps.google.com/maps?f=q&hl=en&geocode=&q=1501+salado,+mountain+view&jsv=107&sll=37.0625,-95.677068&sspn=50.291089,80.15625&ie=UTF8&z=16]] directions are available from this point.
+
+
+## Meals
+
+Breakfast, (starting at 10:00 AM), lunch, and an afternoon snack will be kindly provided by Google, at the location. You may make your own dinner plans for Wednesday and Friday.
+
+Thursday evening, the X.org Foundation is sponsoring a dinner for all attendees. We'll meet at 7:00 PM [[Don Giovanni Ristorante|http://www.dongiovannis.com]] which is at [[235 Castro St, Mountain View, CA 94041|http://maps.google.com/maps?hl=en&ie=UTF-8&um=1&q=don+giovanni%27s&near=Mountain+View,+CA&fb=1&cid=0,0,14678227340696319431&sa=X&oi=local_result&resnum=1&ct=image]].
+
+
+## Registration, talks
+
+If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xdc2008]] for updates. Also, please add your name to the [[Attendees|Events/XDC2008/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDC2008/Program]] page.
diff --git a/Events/XDC2008/Attendees.mdwn b/Events/XDC2008/Attendees.mdwn
new file mode 100644
index 00000000..5b32da63
--- /dev/null
+++ b/Events/XDC2008/Attendees.mdwn
@@ -0,0 +1,63 @@
+
+
+# XDC2008 Attendees
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xdc2008]]) if you are planning to attend [[XDC2008|Events/XDC2008]]. Please note there is a limit at around 70 participants.
+
+1. [[JesseBarnes|JesseBarnes]]
+1. [[AlanCoopersmith|AlanCoopersmith]]
+1. [[DanielStone|DanielStone]]
+1. [[MatthiasHopf|MatthiasHopf]]
+1. [[StuartKreitman|StuartKreitman]]
+1. [[ChrisBall|ChrisBall]]
+1. [[CarlWorth|CarlWorth]]
+1. [[PatKane|PatKane]] (tentative)
+1. [[AlexDeucher|AlexDeucher]]
+1. [[JayCotton|JayCotton]]
+1. [[BryceHarrington|BryceHarrington]]
+1. [[MichaelLarabel|MichaelLarabel]] (tentative)
+1. [[AdamJackson|AdamJackson]]
+1. [[JohnBridgman|JohnBridgman]]
+1. [[JeremyHuddleston|JeremyHuddleston]]
+1. [[BenByer|BenByer]]
+1. [[EricAnholt|EricAnholt]]
+1. [[KeithPackard|KeithPackard]]
+1. [[HenryZhao|HenryZhao]]
+1. [[MatthewGarrett|MatthewGarrett]]
+1. [[RandolphChung|RandolphChung]]
+1. [[EdwardShu|EdwardShu]]
+1. [[BartMassey|BartMassey]]
+1. [[AndyRitger|AndyRitger]]
+1. [[KevinMartin|KevinMartin]]
+1. [[TiagoVignatti|TiagoVignatti]]
+1. [[KristianHoegsberg|KristianHoegsberg]]
+1. [[RinyQian|RinyQian]]
+1. [[JeromeGlisse|JeromeGlisse]]
+1. [[PauloZanoni|PauloZanoni]]
+1. [[NivedithaRau|NivedithaRau]]
+1. [[EamonWalsh|EamonWalsh]]
+1. [[EricJeong|EricJeong]]
+1. [[SooChanLim|SooChanLim]] (tentative)
+1. [[MinskeyGuo|MinskeyGuo]]
+1. [[DavidMarx|DavidMarx]]
+1. [[StefanTeleman|StefanTeleman]]
+1. [[JakeEdge|JakeEdge]] (tenative)
+1. [[ZackRusin|ZackRusin]]
+1. [[VinayBondhugula|VinayBondhugula]]
+1. Sam Lau
+1. [[StefanDoesinger|StefanDoesinger]]
+1. [[ChrisLee|ChrisLee]]
+1. Aaron Plattner
+1. Pierre-Loup Griffais
+1. [[LarryMaloney|LarryMaloney]]
+1. Jens Owen
+1. Allen Lorenz
+1. [[DavidSchleef|DavidSchleef]]
+1. Zephaniah Hull (tentative)
+1. [[LarryLehman|LarryLehman]]
+1. [[MatthewTippett|MatthewTippett]]
+1. [[YannickHeneault|YannickHeneault]]
+1. [[JoachimDeguara|JoachimDeguara]]
+1. [[JoshGargus|JoshGargus]]
+1. Mahmood Ali
+See also [[CarPoolInfo|CarPoolInfo]] if you need a lift.
diff --git a/Events/XDC2008/Notes.mdwn b/Events/XDC2008/Notes.mdwn
new file mode 100644
index 00000000..833deea9
--- /dev/null
+++ b/Events/XDC2008/Notes.mdwn
@@ -0,0 +1,666 @@
+
+
+# Adam Jackson on X release status and process
+
+We do have a list of (70) bugs blocking the release (10101):
+
+[[https://bugs.freedesktop.org/show_bug.cgi?id=10101|https://bugs.freedesktop.org/show_bug.cgi?id=10101]]
+
+But nobody other than Adam has ever looked at that.
+
+It seems we're all heads down now. There were lots of good talks at XDS in the fall about new stuff that was coming, (Gallium, etc.). But it's
+
+[[Bug 13795|https://bugs.freedesktop.org/show_bug.cgi?id=13795]]: With Mozilla and cairo now using Render, we're using lots of parts of the server/drivers that have never really been used before. As expected, they are broken.
+
+Some of the breakage is avoidable with XAANoOffscreenPixmaps.
+
+Can we drop XAA altogether? Not for this release. EXA isn't quite ready yet. And Glucose isn't happening at all.
+
+Ajax: I'm feeling kind of alone here. Nobody else is looking at this stuff? Daniels: I just closed a blocker. One fixed.
+
+Ajax: I don't feel like I'm scaling that well. There are huge swaths of the code that nobody cares about. Things change and break, but nobody takes responsibility for things.
+
+Even the drivers that are "well maintained" have problems. We see lots of churn in the drivers, but not releases. Releases are cheap guys! I don't have a solution for that except shaming people---maybe this is how I get a start.
+
+Every 6 months or so we have a session where we say "what do we want in our next release?" and we write them on the whiteboard. Then, several months later someone, (lately, Ajax), looks at the list and sees which ones are actually coming together, (about 50%), and decides those are the ones that actually go in.
+
+Example of the picaccess change that was on the "desired" list for several releases, but never went in. Finaly, we sat down and forced it in, but found that only the "top 3" drivers had been ported to it, and everything else broke. Fortunately, someone stepped in to save things after the fact. The problem is that we don't have anyone signing up for that janitorial work---or a commitment to "don't break the drivers". But we could have done the whole pciaccess change in-pace with a compatibility layer so that nothing would have ever broken.
+
+Jesse Barnes: We had a big flamewar about putting the drivers back "in tree" in one git module or whatever. That never came to consensus, but wouldn't it help? Right now, nobody cares about the "server" and the distribution maintainers end up taking on all the pain. Wouldn't it be better if driver hackers had a vested interest in getting the "big blob of server and drivers" into a releasable state together.
+
+John: Is the big problem lack of resources for driver development?
+
+Someone: Or just lack of policy?
+
+Ajax: I don't think it's lack of resources. If we had done pciaccess correctly, then it wouldn't have been any work---just a sed script.
+
+Daniel: Bisectability is really nice. People can bisect an independent driver and find Jesse's driver bug. But if we had the big blob, and someone tried to bisect, then it would all just be "Oh my God, my keyboard doesn't work". So if we did put everything together, we'd need lots of separate trees, (input, etc.).
+
+Ajax: Do git submodules help us address the issue?
+
+Eric: Zack's done more work with the submodule thing, but I don't think it gives us what we want. We don't get a master supermodule that points to all the "master" branches of the submodules. Instead, it has to have exact sha1 sums for each point. It would be great for tagging releases, but not so nice for "build master".
+
+[Discussion: What was the whole point of modularization?]
+
+Ajax: It's great to be able to build the server without having to build xedit.
+
+Daniel: It was great for distributions.
+
+Jesse: The only thing that makes sense to merge back together is the server and drivers. It's a social problem, but this technical change would help.
+
+Kevin: That puts structure onto the technical side of things, but not any structure onto the social problem.
+
+Ajax: The problem with merging things together is that it doesn't address the modularization problem. What happens when I want to package up the server, but the Intel driver happens to be broken at the time? If all I can grab is one point in the development of everything, then there's a problem there. How can I back out just the Intel driver changes?
+
+John: It sounds like we want monolithic build and test, but we want modular packaging and distribution.
+
+Ajax: One of the problems is that we're just not testing in the first place. And that's a big part of the problem.
+
+Ajax: We actually do have a test suite (XTS) that we got released under a free license a while ago, but nobody is actually running that. And nobody is adding new tests.
+
+Keith: But we can't add tests to that test suite. We are writing new ad-hoc tests. Do we create a new test suite infrastructure? Do we use something like piglet?
+
+Bart: We don't have to solve all our problems with automated tests. We do need to put together the social organization, (maybe even pay people), to make things happen.
+
+[Someone]: We have a lot of server bugs already without automated tests and they already aren't getting worked on.
+
+Jesse: We're getting a little off-topic here. The original problem was that Ajax isn't getting any help with release management.
+
+Daniel: Release manager is a misnomer anyway. There's no herding of others doing work or anything. It's just signing up to be the person that fixes all the bugs.
+
+Eric: The advantage of automated testing is that you find out the regressions quickly and you only have a couple of commits to look at to find and fix the bug.
+
+[A few minutes more discussion on technical vs. social problems, lots of missing testing from anybody. Lack of a decent infrastructure for writing new tests.]
+
+
+# Kevin Martin on roadmap and introspection
+
+Our goals include:
+
+* Embrace the dynamic world; hotplug of input and outputs, and all the technical requirements for that
+* Smooth, flicker-free user experience; graphical boot, vsync, minimal visible redraw
+* Seamless integration of Composite with the rest of rendering; redirected GL/Xv, Composite by default, no software fallbacks
+* Secure environment, run X as unprivileged user
+These are, of course, the same goals they've been for the last three years or so. We're making progress, but we're not there yet.
+
+What have we been doing?
+
+* RANDR 1.2 integration with Gnome (ssp)
+* DRI2 (krh)
+* DRM and kernel modesetting (airlied)
+* Render acceleration (cworth)
+* Cairo 1.6 and pixman (cworth and ssp)
+* Shatter and other multiscreen infrastructure (ajax)
+* Driver work (all)
+We need to finish. What do we need to finish?
+
+Memory management is critical. And it's still not done. How do we finish this?
+
+DRM, kernel modesetting, VGA arbitration.
+
+Monitor hotplug. Have the desktop-side configuration support, really just need the event from the hardware.
+
+* Ensuing discussion about how to wire it up, how to persist beyond the session. Working in Gnome, not propagated out to the global config yet.
+* Does the top level win, or does the bottom level win?
+* What do we do for input? (Implementation details)
+Sync to vertical retrace.
+
+Driver work:
+
+* Intel mostly feature-complete, needs stabilization.
+* AMD making excellent progress, but not feature complete.
+* nv/matrox/etc are nowhere near done.
+Suspend/resume. Oh dear. Matthew will talk about this later.
+
+Video. MC and iDCT and such need to get properly implemented everywhere.
+
+
+# Zack Rusin on Gallium
+
+Gallium is a rework of the DRI driver model. The driver ends up being rather large and opaque, and writing new ones is rough because it's so large.
+
+In Gallium, the driver is split up to isolate the core logic from the hardware from the window system from the OS. The core logic assumes that the driver is shaderful.
+
+This allows better reuse (state tracker stays the same, only the hardware driver changes).
+
+This allows better portability to other OSes or windowing systems.
+
+Still under development, but mostly interface-stable.
+
+Have several drivers already (i915, i965, softpipe, cell). External projects for nouveau and R300.
+
+The big pieces are the state tracker, the winsys layer, and the core driver itself.
+
+* State tracker is the API: OpenGL, OpenVG, [[D3D9|D3D9]], etc.
+* winsys layer talks to the X server and/or the kernel for environment support
+* the core driver encapsulates all the hardware knowledge
+Other pieces:
+
+* "draw", software vertex walk
+* CSO, constant state objects, responsible for optimisation of state emission
+* buffer management code
+* TGSI code, internal representation of shaders
+* LLVM integration
+It works! Software rendering path works. i915 works on both X and Windows. Works on PS3.
+
+Fallbacks are hard. Fallbacks are really hard. Ideally you wouldn't have them, but that requires a complex state tracker, since OpenGL is really big and weird. Being worked on.
+
+
+# Matthew Garrett on power management
+
+APM used to exist. It more or less worked! But when it didn't, there was no recovering.
+
+Open Firmware exists, but isn't typically relevant for desktops.
+
+Embedded things have their own stuff.
+
+ACPI basically makes no guarantees about what happens when you come back from resume.
+
+The steps are: call device suspend callbacks, platform Prepare-to-sleep method, platform Go-to-sleep method, (suspend), random BIOS stuff, platform Back-from-sleep method, platform wakeup method, device resume callbacks.
+
+ACPI doesn't require that the platform do anything, but it also doesn't require that the platform do **nothing**.
+
+Some machines will reenable text mode in BIOS. Sometimes that happens during ACPI methods. Sometimes that only happens if the platform thinks Linux is running. But you'd really rather not go back to text mode at all. Ideally, you'd restore state and go back to graphics directly.
+
+Swapping out all the state is kinda difficult, but doable. The really hard part is getting the device into a consistent state before doing the state restore. Then you need to block X until everything is back to a reasonable state.
+
+(Lots of implementation details)
+
+How do you survive video hotplug? Actually, you're not expected to be able to.
+
+Need to be cleaner about input hotplug, not doing it right right now. Just a bug.
+
+
+# Ben Byer and Jeremy Huddleston on X11.app
+
+DDX module in hw/xquartz/, old hacked-up version of Mesa
+
+Everything else is plain-jane Xorg, packaged up as X11.app
+
+History
+
+* XonX: port of XFree86 to Darwin IOKit framebuffer
+* merged into XFree86 as XDarwin
+* enhanced to do rootless mode: X windows and OSX windows in the same display
+* Apple branched XFree86 4.3 and included it in the OS
+Goals
+
+* Pleasant experience for Unix apps on a Unix OS
+* Support all traditional X11 technologies on a Mac (GLX, drag and drop, copy/paste, rootless)
+* Cater to wide range of users: sysadmins, developers, research, design
+* Take advantage of OSX features
+Keeping up
+
+* X11.app and XDarwin evolved in parallel
+* XDarwin pulled most improvements from X11.app, X11.app pulled XFree86 updates
+Decay
+
+* X11.app brought to release quality and parked in maintenance mode
+* Resync with XDarwin depended on volunteers
+* XFree86 licensing change forced a move
+Leopard X.org resync
+
+* BSD team in Apple Core OS group took on task of porting X11.app to "new code"
+* XFree86 code base severely bit-rotted
+* Xplugin shim didn't keep up with the rest of the OS
+* Non-existent developer community
+* Limited Apple resources
+* Functional, but some regressions, limited testing
+* Installed by default on Leopard
+Further open source push
+
+* xquartz.macosforge.org - trac instance, etc
+* Code maintained in freedesktop.org git branch, binaries on macosforge
+* x11-users mailing list, xquartz-devel
+* Picked up an intern! Hi Jeremy!
+X11.app today
+
+* Discarded old Darwin code, renamed DDX to Xquartz
+* apple branches in git
+* Built like a normal X server, configure && make && make install
+* Limping along on old Mesa code though
+Current challenges
+
+* Quirky input code
+* Crashy rootless code
+* Stale DRI code
+Coming projects
+
+* New DRI driver using OpenGL.framework
+* Fix rootless and/or replace with Composite
+* Better input and RANDR support
+* Smarter clipboard proxying
+* Move to open source window manager
+* Sync with git master
+
+# Kristian Høgsberg on DRI2
+
+Debriefing: A one-time, semi-structured conversation with an individual who has just experienced a stressful or traumatic event.
+
+No kernel side
+
+* uses only buffer objects and associated API
+* drmAddMap, Create/Destroy Context/Drawable are no longer used. yay!
+* intel driver has a driver-specific ioctl for communicating the hardware lock with the kernel
+* possible new ioctl for mapping a set of buffer objects (rather than just one)
+Simpler DDX driver requirements
+
+* fbconfig come from the DRI driver instead of from the DDX
+* back buffers allocated on demand by the DRI driver
+* sarea is a buffer object rather than a magic map
+* new self-describing block format for sarea records
+* sarea still necessary for describing cliprect changes
+(log showing dynamic buffer allocation)
+
+Event ring buffer
+
+* Used for communication from X server for window position and cliprects, and drawable to buffer-object mappings
+* X server is only writer. two head pointers: end of valid data, and end of event currently being written
+* client maintains per-drawable tail-pointer, checks for updates by comparing to server head pointer
+* currently checked every time you take the lock
+* protocol for catching up if the client falls too far behind the server
+Initialization and operation examples
+
+* Server setup: DDX driver opens DRM device, calls dri2 to initialize the sarea, with optional size for driver-specific blocks
+* Client setup: If DRI2 extension is available, call DRI2Connect for busid, driver name, sarea buffer object handle; call DRI driver's createNewScreen, which doesn't set up any pre-sized render buffers.
+* Tell DRI2 module that we're interested in a given X drawable. Server responds by logging it to the new sarea.
+* When the drawable is bound to a context, the DRI driver parses the sarea event log and sets up the necesary render buffers.
+* GLX_EXT_texture_from_pixmap in direct contexts for free
+Lockless options
+
+* As the server moves windows around, the cliprects change **and** you have to blit. You have to make this appear atomic to clients, otherwise the pixels and cliprects will be inconsistent
+* Introduce two new submit methods:
+ * submit and update
+ * compare and submit
+Probably makes sense to move buffer swaps to the server
+
+Technical discussion on how to implement sync to vblank.
+
+(Super hot demo)
+
+
+# Eric Anholt on Render
+
+What do app authors want?
+
+YUV picture formats as a new source picture type
+
+JPEG/PNG picture formats for compressed image transport
+
+YUV needs new filter types for hue/contrast/etc
+
+Gradients need to be properly specified, should just copy the cairo spec
+
+Gradients need dithering, and for filters to work in general
+
+Technical discussion of how to do automatic mipmapping
+
+Rendercheck needs a ton of work
+
+Transforms need to be floating point? Or at least need to be specifiable in floating point
+
+(Søren rants for a while about the imprecision of the spec)
+
+
+# Jérôme Glisse on Radeon
+
+Kernel modesetting is in progress, for all the usual reasons: suspend, flicker-free boot, reducing root code in userspace, graphical boot, graphical panic
+
+Really hard to preserve compatibility, so a new driver sounded like a good idea. Problem is the existing code is well-tested and also tedious to rewrite. Rewriting it was a mistake; should have used the existing DDX code to begin with.
+
+Why ATOM? Should work since Windows uses it. Reuses AMD engineering work. Keeps the driver from needing to know hw details. But, sometimes buggy and not always exactly what we want.
+
+What do users want? Working 3D. Accelerated video. Modesetting is uninteresting as long as it comes up.
+
+So, use ATOM to leverage the existing AMD engineering work. Reduce time to support new hardware, get on to the fun features.
+
+AMD GPU design is "like Lego blocks". Different GPUs share same modules (DAC/TMDSC, 3D engine, CP), but can move around between GPUs. Can and does. But ATOM takes care of most of this for us.
+
+Kernel code should reflect this modular design; each piece should talk only to the piece of the chip that it's responsible for.
+
+Lockups are easy to trigger. And, surprisingly hard to recover from. (Technical details.) Need to sanitize the command stream to be sure you don't do weird things, and avoid the WAIT_UNTIL feature. But this makes vsyncing hard.
+
+Lots of cases where the GPU can stall. Fencing is really hard; need to be careful about batching them. Some buffer offset registers stall until they can be done safely, so you want to avoid doing them. Context switches need some optimization for this case.
+
+Fragment programs are essential now, and optimisation is critical so you correctly run everything you claim to be able to run. LLVM will save us all.
+
+Texture indirections are a finite resource. You can reduce them by rescheduling the shader.
+
+r300 and r400 don't support all swizzling combinations. Want to redo shaders to use native swizzling when possible.
+
+Future work: DRI2, radeon gallium driver, get gears to work, fragprog compiler.
+
+
+# David Schleef on video
+
+Background: working on Dirac, which is a codec from BBC that's designed to be competitive with MPEG4.
+
+Currently: 8 bit per channel, normal color gamut, 480i/30 or 720p/30.
+
+Future: 10-12 bit per channel, wide gamut, 1080p/60, possibly stereoscopic.
+
+Pipeline:
+
+* decode video
+* post-process
+* repack
+* yuv to rgb
+* gamma to linear
+* rgb to device color space
+* linear to gamma
+* calibration curve
+* rescale/compose
+Colorspaces we care about:
+
+* BT-709 (sRGB) - the web, HD everything
+* BT-601 - DVDs, SD TV, other old stuff
+* Whatever your monitor uses
+* CIE XYZ (Digital cinema, wide-gamut video)
+(Explanation of a chromaticity diagram)
+
+Scaling/Resampling
+
+* Could go anywhere, somewhat depends on the colorspace
+* use a bicubic filter or better
+* Scaling is hard to do well, near-axis-aligned lines will alias badly
+What do apps want to know?
+
+* Exact frame rate of the output pipe
+* Exact time of image presentation
+* Sync to vblank
+XVideo API
+
+* Good sides: Zero copy with the SHM extension, simple, maps well to the original problem domain
+* Bad sides: attributes underspecified, lots of useless attributes, missing modern details, slightly desynced with X rendering, doesn't work in cairo
+XVideo implementations
+
+* Good: works everywhere, tends not to use software fallbacks
+* Bad: vertical softening, bad scaling, bad conversions, no rgb support, only one overlay
+OpenGL
+
+* Good: lots of control
+* Bad: needs GLSL for that control, very complicated, no native YUV, three ways to do vsync, not meant for video, can't connect XVideo port to OpenGL
+OpenGL implementations
+
+* Good: intel works, mostly; nvidia works, windows works.
+* Bad: works inconsistently
+Future
+
+* Pluggable pipeline
+* Extend XVideo
+* GPGPU codecs
+
+# Alex Deucher on R600 Architecture
+
+R500 was 3d build on R300. Very similar designs.
+
+(Diagram of GPU hardware evolution)
+
+R600 Overview
+
+* New surface setup
+* Expanded CP, Prefetch processor (PFP)
+* New paging and DMA engine
+* New interrupt handler
+* Virtual memory support
+* Unified shaders
+* Compose rect engine
+Host data path
+
+* 32 surfaces for tiling and swapping
+* Can do virtual or physical addresses
+* Privileged and non-privileged access per surface
+Command processor
+
+* Same basic setup and semantics as previous generations
+* New prefetch parser
+* Dedicated DMA engine
+* Lots of new Type 3 packets
+* All drawing and state can go through the CP, no need to touch registers
+* 2D packets emulated by the CP
+* Insert interrupts for event completion
+Paging and DMA engine
+
+* Has own ring buffer, async from the GPU
+* Host BLT, copy BLT, fences, interrupts
+* Different packet formats from CP
+Interrupt handler
+
+* Dedicated ring buffer for incoming interrupts
+* Source ID to map interrupt to originating block and subfunction
+Virtual memory
+
+* Translation of logical addresses seen by clients into physical addresses seen by the memory controller
+* Page fault detection (maybe not validated)
+* Page access bits (also maybe not validated)
+Unified shaders
+
+* One big program of control flow, ALU, or fetch clauses
+* 128 bit pixels, 5 way superscalar, access to vector and scalar results from previous insn
+* Five main types of shader: vertex, pixel, geometry, DMA copy, fetch
+Compose rect (crazy 1-bit text accel thing)
+
+Driver plan
+
+* TCORE programming SDK soon
+* Programming guide
+
+# Keith Packard on RANDR 1.3
+
+Proposed features:
+
+* DPMS events
+* Per-output DPMS
+* Panning rectangle
+* Projective transform
+* GPU objects
+* CRTC properties
+* Standard output properties
+DPMS
+
+* Goal is power management without polling
+* Basic plan: Enable/Disable requests, OutputDPMS request, OutputDPMSChanged and [[EnableChanged|EnableChanged]] event, IDLETIME sync counter
+* Allows DPMS transition to be decoupled from "idle"
+* Provides DPMS notification to applications
+* Leaves legacy auto-DPMS stuff around
+* New enable and disable are refcounted. Event includes the refcount.
+Panning rectangle
+
+* Bounding box for the CRTC, just moves the CRTC origin around
+* CRTC follows mouse on edge transitions
+* CRTC events will be generated, probably needs to be a [[PanningNotify|PanningNotify]] for lack of room
+Projective transform
+
+* Handles input
+* Uses existing rotation backend
+* No driver impact
+* Would be more efficient done in the compositing manager, but wouldn't handle input
+* This actually works. Whoa.
+GPU objects
+
+* Completes the object hierarchy
+* Object, list of properties, mapping to CRTC
+Standard output properties
+
+* Provide more information about outputs
+* Connector type, signalling level, etc.
+* Need a list and a definition of each
+
+# Chris Ball on tinderbox
+
+Started working on tinderbox as part of the OLPC bringup effort
+
+Got interested in adding that test harness to X
+
+It works! [[tinderbox.x.org|http://tinderbox.x.org/]]
+
+Gives you a long list of build results, properly hierarchical, triggered by commits.
+
+Also has some basic test infrastructure for sanity-checking the builds:
+
+* x11perf
+* cairo tests
+* rendercheck
+* piglet
+* etc.
+Not really clear how to measure failures. Some things never worked. Doesn't have a success metric for the tests right now besides "ran to completion"; should change to catching changes in numbers of passes/fails.
+
+What else do we need?
+
+* mozilla trender
+* cairo tools could be rewritten to get a more parseable output
+* possibility of making throwaway "tinderbox me please" branches for pre-commit testing
+* possibility of keeping build output for the last N things so you can apply new test against older builds
+* more machines
+* others?
+
+# Bart Massey on image support in XCB
+
+XCB is a replacement for Xlib: a thin C binding with latency hiding and transparent multithreading
+
+Just does a protocol binding and some language bindings
+
+... and then also has a util library
+
+In attempting to port x11perf to XCB, noticed that the image implementation is broken
+
+X image protocol is subtle and quick to anger. Not many apps use the Xlib facilities in interesting ways.
+
+The gory details
+
+* Decide XY or Z format, size, depth
+* Walk the connection data looking for valid formats
+* Compute unit, pad, byte and bit swap, size; deal with planes
+* Maybe convert or expand
+xcb/util/image provides:
+
+* Create new image with given or native format
+* Convert images between formats
+* fast get/put pixel inlines
+* User-controllable memory management
+* Protocol insulation
+xcb_bitops.h provides some fast bit-banging inlines
+
+Forced some reevaluation of some XCB design
+
+* error handling is weird
+* latency hiding in libraries
+* build mechanisms
+* util packaging
+Requests for help and further work
+
+* Finish the x11perf port
+* Image test suite
+* Specify or build other userland libs
+* Port apps to XCB
+
+# Stefan Dösinger on Wine and X
+
+Wine is a set of libraries to allow running unmodified Windows apps.
+
+Uses X for input and output, translates GDI and DirectX to X APIs
+
+Raw mouse input
+
+* Windows can report relative mouse movement
+* Mouse and keyboard notifications are windows independent
+* Client-side workaround, but fails when you hit the screen border, or when the app changes focus
+* Should be doable with XInput
+Tablet support doesn't really exist yet, but that's being worked on in X already
+
+3D rendering issues
+
+* Flat shading colors; different behaviour in GL versus D3D. extension proposal, should be easy.
+* pbuffers need to be supported in the driver, pain to implement them with FBOs. DRI2 should solve this.
+* multithreading. Our drivers break when multiple contexts run on one drawable.
+* sRGB rendering targets. GLX extension is stronger than [[D3D9|D3D9]] extension, so only works on DX10 hardware. Could get away with ability for write correction without blending.
+* GLSL. Conversion from D3D done with generated GLSL, depends on the driver to optimize.
+
+# X.org Foundation Board on the X.org Foundation Board
+
+Members! Be members. Go to [[members.x.org|http://members.x.org/]]
+
+We exist to provide education, support, and infrastructure to enable X development. If you think you could use some of that, let us know! We will do what we can.
+
+Meetings and conferences are not necessarily limited to XDC and XDS. If you want to do something smaller and local, let us know! We will do what we can.
+
+The software has been coming out. See elsewhere for details.
+
+Vendor relationships keep getting better. Docs and source keep coming out. Life is good.
+
+We are doing GSoC again. We may be doing additional direct student funding again.
+
+We are VESA members, we're about to be CEA members. We should do something about Khronos; if this is you, let us know! Getting this information out to the development community is important, so let us know if this will help you.
+
+The old LLC structure is being closed out, finally. We're within epsilon of being a 501(c)3.
+
+Apologies for the election being so chaotic last time around. There is a team working on improving this process.
+
+Current board meeting structure is bi-weekly for the whole board plus committee meetings as needed.
+
+Membership agreement is being finalised to make membership easier to agree to and sign up for.
+
+We're spending money well now. We will begin looking for sponsorships again. Healthy cash flow is healthy.
+
+Infrastructure between x.org and freedesktop.org is being merged behind the scenes, for the betterment of both.
+
+There is another major conference coming. September 10-12 (ish) is XDS 2008 at Edinburgh Zoo. Conference facilities, probably a sunset tour, general good times. Should have final details in a few weeks.
+
+
+# Eamon Walsh with A Talk
+
+[[DevPrivates|DevPrivates]]
+
+* reworked now.
+* They're lazy allocated, way simpler to program, but have some small issues.
+* Merge worked, and the changes are documented. Yay!
+* xf86AllocateEntityPrivateIndex(), probably won't be touched
+* [[AllocateFontPrivate|AllocateFontPrivate]](), also. Not really worth fixing.
+* Some minor optimizations to be had with CSE.
+Things I hate
+
+* State polling requests suck. "Give me the state of the keyboard! Including button up/down!" Doom.
+ * How do we fix? Lie? Rate limit? Visual feedback?
+ * Add a policy framework, start fixing the toolkits
+* bg=None.
+ * This is how to steal window contents
+ * But just censoring to black flickers
+ * Maybe only block [[GetImage|GetImage]] from bg=None windows? Or just fix gtk? Hmm.
+Please can we kill more extensions
+
+* Every protocol request is an entrypoint.
+* But each one has to be characterised, and it's the ioctl problem.
+* (Hateful spreadsheet)
+* EVI, XTrap/Record, [[DoubleBuffer|DoubleBuffer]], [[MultiBuffer|MultiBuffer]]. Die. (XT/R needs a closer look.)
+* MIT-SUNDRY-NONSTANDARD. Die.
+* APPGROUP. Unused. Die.
+* XFree86-DGA. Dead once we get relative mouse motion.
+* XFree86-Misc. Die.
+* TOG-CUP. Die.
+* Xinerama. Enh. Kinda hard.
+* DPMS. Can pretty much just go.
+* XFree86-[[VidModeExtension|VidModeExtension]]. Can die once we fix RANDR.
+To-do
+
+* Finish some XCB stuff.
+* GLX and DRI.
+* MPX/Input security improvements.
+* Move on to higher desktop layers.
+(Technical discussion of how to fix bg=None)
+
+
+# Lightning talks
+
+Owen Taylor is working on fixing Radeon Render performance. And making progress! Should be done as generic Render services, so everyone wins.
+
+John Bridgman raises some concern about lockstepping DRM and X as far as getting support pushed out. There's some slip, it works. But it is something the driver maintainers need to be conscious of. Also, what are the last steps to getting X to run as non-root?
+
+Paulo Zanonni and Tiago Vignatti on VGA arbitration. This needs to be done in the kernel to get it right, since each server may want to have VGA space routed to it at various times. Existing proof-of-concept as kernel+library+server code. Should just be a /dev node.
+
+Jesse Barnes on getting off of /dev/mem. Mostly there. How do we expose caching policies to maps? How do we deal with non-PCI video devices like USB?
+
+Adam Jackson on Xinerama and shatter and stuff. If you're interested, go talk to him. [[http://cgit.freedesktop.org/~ajax/xserver-shatter|http://cgit.freedesktop.org/~ajax/xserver-shatter]]
+
+Daniel Stone on input. Core, XI, and XKB. Massive amounts of duplication. This is really terrible. Lots of it is being fixed, yay! Being worked on in xkb-atkins branch. This is sort of a prerequisite for merging MPX.
+
+Bart says cut and paste is still broken.
diff --git a/Events/XDC2008/Program.mdwn b/Events/XDC2008/Program.mdwn
new file mode 100644
index 00000000..15ed0481
--- /dev/null
+++ b/Events/XDC2008/Program.mdwn
@@ -0,0 +1,40 @@
+
+
+# XDC2008 Program
+
+This is the rough program for [[XDC2008|Events/XDC2008]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk.
+
+The schedule itself will be available closer to the conference.
+
+
+## Program
+[[!table header="no" class="mointable" data="""
+ | **Wednesday** | **Thursday** _(multimedia/GL)_ | **Friday** _(clients and bits)_
+ **10am** | _coalesce, breakfast, live schedule bashing_ | _coalesce, breakfast_ | _coalesce, breakfast_
+ **10:30am** | Welcome, general socialising ([[CarlWorth|CarlWorth]] et al) | DRI2 debriefing ([[KristianHøgsberg|KristianHøgsberg]]) | Tinderbox with tests ([[ChrisBall|ChrisBall]])
+ **11:15am** | [[X11R7|X11R7]].4 status ([[AdamJackson|AdamJackson]] et al) | Future plans for XRender ([[EricAnholt|EricAnholt]]) | Image support in XCB ([[BartMassey|BartMassey]])
+ **12pm** | Introspection ([[KevinMartin|KevinMartin]]) | Radeon state of the art ([[JeromeGlisse|JeromeGlisse]]) | Wine and X ([[StefanDösinger|StefanDösinger]])
+ **1pm** | _lunch_ | _lunch_ | _lunch_
+ **2pm** | Mesa/Gallium overview ([[ZackRusin|ZackRusin]]) | Fixing video ([[DavidSchleef|DavidSchleef]]) | X.Org Foundation (Foundation board members) and [[impromptu XDS presentation with cute fluffy animals|http://www.flickr.com/photos/tags/edinburghzoo/interesting/show/]]
+ **3pm** | Suspend and resume ([[MatthewGarrett|MatthewGarrett]]) | r6xx architecture ([[AlexDeucher|AlexDeucher]]) | A talk not about SELinux ([[EamonWalsh|EamonWalsh]])
+ **4pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_
+ **4:30pm** | Xquartz ([[BenByer|BenByer]]) | RandR ([[KeithPackard|KeithPackard]]) | Lightning Talks (5 minutes each) Owen Taylor (by proxy): Fixing glyph performance. John: What's the transition plan for kernel modesetting? Paulo Zanoni and Tiago Vignatti: Multiseat and blocker bug on X server master. Jesse Barnes: Getting off of /dev/mem (helping to run server as non-root). Daniel Stone on input. Adam Jackson on doing Xinerama right.
+"""]]
+
+
+## Ideas
+
+* [[EricAnholt|EricAnholt]]: 3D driver optimization for TTM
+* [[ChrisBall|ChrisBall]]: An X tinderbox with functional and performance tests
+* [[BartMassey|BartMassey]]: X image support in XCB
+* [[KristianHøgsberg|KristianHøgsberg]]: DRI2 Debriefing
+* [[ZackRusin|ZackRusin]]: Mesa/Gallium overview/update
+* [[StefanDoesinger|StefanDoesinger]]: Wine and X
+* [[MatthewGarrett|MatthewGarrett]]: Suspend and resume in modern graphics drivers
+* [[BenByer|BenByer]]: State of Xquartz
+* [[JeromeGlisse|JeromeGlisse]]: Radeon state of the art
+* [[DavidSchleef|DavidSchleef]]: Getting Video Right from a media framework perspective
+* [[AlexDeucher|AlexDeucher]]: Radeon R6xx Architectural Overview
+* [[BartMassey|BartMassey]], [[KeithPackard|KeithPackard]], [[AdamJackson|AdamJackson]], [[EricAnholt|EricAnholt]], [[CarlWorth|CarlWorth]], [[DanielStone|DanielStone]]: X.Org Foundation status etc
+* [[KevinMartin|KevinMartin]]: What have we been up to lately? and what's next?
+* [[AdamJackson|AdamJackson]]: Shattered pixmaps and the future of Xinerama \ No newline at end of file
diff --git a/Events/XDC2009.mdwn b/Events/XDC2009.mdwn
new file mode 100644
index 00000000..5a6a3f94
--- /dev/null
+++ b/Events/XDC2009.mdwn
@@ -0,0 +1,39 @@
+
+
+# XDC 2009: Portland, Oregon September 28-30
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2008|Events/XDC2008]] | **XDC 2009** | [[XDS 2010 >>|Events/XDS2010]]
+"""]]
+
+The X Developers' Conference for 2009 will be held at Portland State University (PSU) in Portland, Oregon, from Monday September 28 through Wednesday September 30. PSU is within walking distance of Portland's downtown area and a wide variety of dining, lodging, and public transportation options.
+
+The conference is scheduled to follow directly after [[Linux Plumbers Conference 2009|http://linuxplumbersconf.org/2009/]] so that people attending both LPC and XDC can do that with a single trip.
+
+The conference will be held at the [[University Place|http://cegs.pdx.edu/stay/upl/]] hotel and conference center on the edge of the PSU campus.
+
+* [[Attendees|Events/XDC2009/Attendees]]
+* [[Program|Events/XDC2009/Program]]
+* [[Notes from the talks|Events/XDC2009/Notes]]
+We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities.
+
+Attendance is free, but you must register beforehand, by putting your name on the Attendees page.
+
+
+## Accommodation
+
+We encourage attendees to stay at the conference hotel ([[University Place|http://cegs.pdx.edu/stay/upl/]]) for convenience. We have initially reserved a block of 20 rooms for the conference, (so let them know you're with the conference when making a reservation). We will attempt to increase that block size as needed, (so please make your reservation as early as possible).
+
+
+## Travel
+
+Portland is easily accessed by the [[Portland International Airport(PDX)|http://flypdx.com]]. Portland has a very nice public transportation system, ([[TriMet|TriMet]]), including the MAX light-rail system with the red line service between the airport and downtown, and the green line serving PSU. Use [[TriMet's trip planner|http://ride.trimet.org/]] to find good transportation options. And note that you can simply enter "PDX" for the airport and "PSU" for the University.
+
+
+## Meals
+
+Portland is a city of many food carts, and there is a large selection (Thai, Mexican, vegan African-Caribbean, soup, sandwiches, etc) right outside PSU, in the parking lot at the corner of 4th & College Sts.
+
+
+## Registration, talks
+
+If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xdc2009]] for updates. Also, please add your name to the [[Attendees|Events/XDC2009/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDC2009/Program]] page.
diff --git a/Events/XDC2009/Attendees.mdwn b/Events/XDC2009/Attendees.mdwn
new file mode 100644
index 00000000..b0c18512
--- /dev/null
+++ b/Events/XDC2009/Attendees.mdwn
@@ -0,0 +1,41 @@
+
+
+## XDC2009 Attendees
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xdc2009]]) if you are planning to attend [[XDC2009|Events/XDC2009]]. Please note that attendance will be limited, so list yourself early to ensure your ability to attend.
+
+ 1. [[CarlWorth|CarlWorth]]
+ 1. [[BartMassey|BartMassey]]
+ 1. [[AlanCoopersmith|AlanCoopersmith]]
+ 1. [[KeithPackard|KeithPackard]]
+ 1. [[BryceHarrington|BryceHarrington]]
+ 1. [[EamonWalsh|EamonWalsh]]
+ 1. [[AlexDeucher|AlexDeucher]]
+ 1. [[MichaelLarabel|MichaelLarabel]] (maybe)
+ 1. [[JakobBornecrantz|JakobBornecrantz]]
+ 1. [[DanielStone|DanielStone]]
+ 1. [[JeremyHuddleston|JeremyHuddleston]]
+ 1. [[KennyGraunke|KennyGraunke]]
+ 1. [[CorbinSimpson|CorbinSimpson]]
+ 1. [[BenByer|BenByer]]
+ 1. [[StuartKreitman|StuartKreitman]] (day2,3)
+ 1. [[UrosNedic|UrosNedic]] (depends from sponsorship)
+ 1. [[JameySharp|JameySharp]]
+ 1. [[JimGettys|JimGettys]]
+ 1. [[AdamJackson|AdamJackson]]
+ 1. [[MatthewGarrett|MatthewGarrett]]
+ 1. [[ChrisWilson|ChrisWilson]]
+ 1. [[PingCheng|PingCheng]]
+ 1. [[TiagoVignatti|TiagoVignatti]]
+ 1. [[McFaddenOliver|McFaddenOliver]]
+ 1. [[JohnChee|JohnChee]]
+ 1. [[ArvindUmrao|ArvindUmrao]]
+ 1. [[NaveenReddy|NaveenReddy]]
+ 1. [[AaronPlattner|AaronPlattner]]
+ 1. [[BernieThompson|BernieThompson]]
+ 1. [[AdamRichter|AdamRichter]]
+ 1. [[JesseBarnes|JesseBarnes]]
+ 1. [[KristianHoegsberg|KristianHoegsberg]]
+ 1. [[HenryZhao|HenryZhao]]
+ 1. [[BrianRogers|BrianRogers]]
+ 1. GregKH \ No newline at end of file
diff --git a/Events/XDC2009/Notes.mdwn b/Events/XDC2009/Notes.mdwn
new file mode 100644
index 00000000..4d917916
--- /dev/null
+++ b/Events/XDC2009/Notes.mdwn
@@ -0,0 +1,255 @@
+
+
+# XDC2009 Notes
+
+Live from sunny Portland, it's the X Developer's Conference 2009!
+
+[[!toc ]]
+
+
+## Monday, September 28
+
+Bart Massey: Welcome, Introductions
+
+
+### SoC review
+
+* Been doing this for about three years
+* Bart looking to get out of the organizer role next year; volunteers?
+* Hard to find good mentors; volunteers?
+* Corbin (only SoC student in attendance) on his project: shatter
+ * don't take summer classes if you're doing a project!
+ * also, be fearless about applying if you're a student, you'll do better than you think
+* ajax on mentoring: good, rewarding, helps if you have a routine and regular updates
+* Have we asked the students what the pain points were? Uh, no. Hmm, should do that.
+
+### Board talk
+
+* new hardware this year? yeah, probably.
+* Still finalizing 501(c)3 reorg. Paperwork! So much paperwork.
+* Elections coming up again, nominate yourself or your friends/enemies
+
+### krh: rootless X with Composite
+
+* Expose [[CompositeRedirectSubWindows|CompositeRedirectSubWindows]], hook [[CreateWindow|CreateWindow]], redirect root window in CW hook
+* Hook [[RealizeWindow|RealizeWindow]] and make GEM handles for the window pixmap, tear it down in [[UnrealizeWindow|UnrealizeWindow]]
+* Update it in [[SetWindowPixmap|SetWindowPixmap]] (resize, reparent, etc)
+* Hook [[MoveWindow|MoveWindow]] to reflect X position as Wayland moves
+
+### gregkh: Death of HAL
+
+* HAL is dead upstream!
+* Linux will probably port to libudev
+* Others will need to port to... other.
+
+### bernie: multiseat with USB video demo
+
+
+### jakob: Debugging gallium drivers
+
+* trace module for API calls
+* rbug: remote debugging, object inspection, rendering single-stepping, etc.
+* [[http://git.freedesktop.org/mesa/rbug-gui.git|http://git.freedesktop.org/mesa/rbug-gui.git]]
+
+### daniels: Release stuff
+
+* 1.7 mostly done
+* 7.5 basically just needs badging and releasing. Huzzah!
+* Development proposal: [[http://lists.x.org/archives/xorg-devel/2009-September/002231.html|http://lists.x.org/archives/xorg-devel/2009-September/002231.html]]
+* Do we merge the drivers back in? Hm.
+* The protocol header re-org made bisecting irritating. Are we done?
+* "Our release process is, we name a month, and then two months after that..."
+* General consensus on having someone to own master and manage merges
+* Given regular server releases, driver merge is generally acceptable
+* 1.8 targets: XKB2, XI2.1 grab fixes, some DRI2 proto enhancements, RANDR proto enhancements, GLX 1.4, VDPAU token in DRI2
+* Corbin: "shatter by 1.10"
+* Testing. We should really do some of that.
+* Testing: should get hardware for it (scan grabber, etc)
+
+### mjg59: Power management
+
+* What draws power? GPU, VRAM, outputs, and displays
+* GPU: clock gating, reclocking
+* VRAM: framebuffer compression, reclocking
+* Outputs: Load detection, PLLs
+* Displays: LVDS reclocking, DPMS
+* Until recently, all we had support for was DPMS, enabling clock gating, static power policy
+* Moving to more on-demand response
+* Savings: LVDS reclock ~0.5W, gpu/memory reclock 10-15W
+* Could reclock the HT link on AMD IGP
+* Could use sideport RAM on IGP too
+* Could change PCIE lane count, but that requires ~3 frames to do... probably machine-dependent
+* Should do adaptive screensaver timeouts
+* Could D3 the entire card? Really touchy.
+* How far can we go with input policy? Screensaver for example, you could suspend the keyboard.
+ * daniels: when we update grabs, we'll add flags
+
+## Tuesday, September 29
+
+
+### idr: OpenGL 3 and Mesa
+
+* Several patented technologies in OpenGL that we want in Mesa
+ * Floating point textures and render targets (in core GL3), certain compressed texture formats
+* external libraries solve some of it (for S3TC), could kinda do that with fp textures... but not targets
+* could act like freetype (configure switch for patented technologies)
+* could try to get OIN to help on the patent license front
+* plan: yes, do both of those
+
+### krh: Stitching together FBOs + KMS + EGL
+
+* Goal is to be able to do EGL straight on top of KMS
+* KMS: drmAddModeFB, drmModeSetCrtc, drmModePageFlip
+* EGL: eglCreateWindowSurface, eglCreatePixmapSurface, eglSwapBuffers
+* FBO: glGenRenderbuffers, glRenderbufferStorage
+* Possibility: use EGL images to do glue together KMS objects to GL
+
+### idr: GL shaders for shader model 3/4
+
+* Advanced assembly shader extensions for Mesa
+* middleware wants to generate assembly shaders: wine/cedega, Cg
+* ARB_vertex_program is really basic, no branches/predication/texture fetching
+ * Enough for most GLSL shaders; supported in hw on 965/r200/nv20
+* NV_vertex_program2 adds predication, branches, procedure calls
+ * supported in hw on nv30 and (kinda) 965
+* NV_vertex_program3 adds texture lookups, address push/pop, relative indexing into attr/result arrays, second condition code register; basically shader model 3
+ * supported in hw on nv40 and ~965
+* NV_vertext_program4 adds integer insns, structured branching, unified insn set with fragment processor; shader model 4
+ * G80, ~965
+* ARB_fragment_program: base support, no branches, no predication
+ * r300, i915, nv30, r500
+* NV_fragment_program: predication, partial derivatives, packing/unpacking insns
+ * nv30, ~965, r500
+* NV_fragment_program2: structured branching (no unstructured), fragment facing attribute, misc insns
+ * nv40, ~965, r500
+* NV_fragment_program4: integer insns, unified instruction set with vertex processor
+ * G80, ~965, r600
+* lots of nvidia extensions that match their hardware but not really anybody else's
+ * instructions only on nv hardware, no structured branched on vertex model, different predication model...
+* what we want is supportable across a range of hardware: 965, R500; 915 and R300 stuck at existing ARB level
+* want structured branching, predication, vertex textures, partial derivatives
+* Is this worth doing? Less work than making GLSL rock, but we kinda need to do that anyway
+* Nice for middleware, but does it help app developers?
+* Modest support; we'll bang something out in the working session later.
+
+### aaronp: Synchronisation and presentation
+
+* No defined ordering between X and direct rendering
+
+* GLX APIs are only good for your own X and GL stream, not useful between apps
+* X sync objects, like GL sync objects. Contains nothing but binary state: triggered or not.
+* Rendering streams could be stalled until sync object reaches triggered.
+* Export these to other APIs so you can sync between them
+* Also need control over where and when presentation happens, and feedback on when buffers are in use by presentation
+* Explicit multibuffering: allocate multiple backing pixmaps, explicitly set backs to be the new front; kind of like existing multibuffer extension?
+* Sync counters not _that_ close of a match, since hardware really only has boolean triggers
+* Presentation requests forwarded to the current CM, or else automatically composited
+
+### bernie: multiseat technical stuff
+
+* udev script runs on plug and fires up a seat by launching gdm on the device
+* Walkthrough of scripts at [[http://libdlo.freedesktop.org/wiki/MultiSeatTerminal|http://libdlo.freedesktop.org/wiki/MultiSeatTerminal]]
+
+### jbarnes: intel driver update
+
+* DDX
+ * EDID fixes, hang fixes, XvMC for new chipsets, KMS output transforms, KMS-only build available, cursor flicker fix, regen fixes
+ * Future: Removal of UMS, glamour, maybe cairo-drm?
+* 3D: Big pile of GL features, texture tiling, hang fixes
+ * Future: various GLX and DRI2 sync extensions, GL3 features; XXX [[MissingFunctionality|MissingFunctionality]] on DRI wiki
+* Kernel 2.6.31: dynamic clock control, self-refresh support, error detection, FIFO watermark support, misc output fixes, vbios parsing fixes, [[DisplayPort|DisplayPort]] support, MCHBAR allocation, new chipsets
+* Kernel 2.6.32: GPU hang recovery, FBC support, tracepoints, hang fixes, misc output improvements, madvise support, memory shrinker, display cleanups
+* Kernel future: per-process GTT, context support, page flipping, DRM events, GPU scheduling, zone rendering
+
+### agd5f: AMD driver update
+
+* 3D driver for R600 and R700! Pretty much works, which is awesome.
+* Working on IRQ support for R600 and R700
+* More power management work in KMS
+* R800 support coming up
+* HDMI audio
+* XvMC in gallium for R300-R500 now, 600 and 700 soon
+* Lot of suspend and resume fixes
+* sideport scanout support
+* debugfs support in 2.6.31
+* usual future stuff like pageflipping
+
+### krh: wayland
+
+* New, minimal, composited display server
+* Server and compositor is one process
+* Not a remote display protocol
+* All clients are direct rendering; efficient buffer sharing is assumed (GEM, TTM, etc)
+* Either allocate a buffer, render, and pass to wayland; or incrementally update an existing buffer
+* Needs input, which is basically copied MPX and XI2
+* Multipointer, all events have a device ID; hotplug, axis and button labels
+* Passes on evdev codes
+* XKB as a client side library
+* Transforms screen input coordinates to surface coordinates
+* Not like earlier attempts - Fresco, Y, SDL - by reusing X components
+* X runs on wayland, either rooted or rootless, so your apps still work.
+
+## Wednesday, September 30
+
+
+### tiago: PCI and VGA arbitration updates
+
+* X used to do all PCI management and direct hardware access
+* RAC was built to handle multiple PCI devices
+* libpciaccess pulled most of this out from the server, but broke multiple device support
+* RAC recently removed, needed to be in kernel for multiple X server support anyway
+* VGA arbiter landed in linux kernel, allows multiple X servers to work again
+* Most recent hardware actually doesn't need the arbiter, but needs driver support
+* X is very cautious about wrapping everything for arbitration, could probably be optimized
+* int10 outside X, something like udev to trigger it for non-KMS devices
+* Todo: remove old probe scheme, last bits of RAC
+* Future: hotplug graphics, hybrid graphics
+
+### eamon: XACE updates
+
+* compiz plugin with security context in menu, permanent overlay for context display
+* firefox running in a different security context; different frame colors for different contexts
+* Defeats xspy! Defeats [[GetImage|GetImage]]! It's like the future.
+* Has MPX support, so you can give different contexts to different devices, bind keyboards to password dialogs, etc.
+* DRI2 needs better lockdown so you can't just attach to arbitrary buffers
+
+### corbin: Why Xorg Sucks
+
+* Classes of users: Naïve, Informed, Experienced
+* Naïve complaints: old, bloated, my youtube doesn't work, flash, java, fglrx/nvidia
+* Rebuttal: Mature, full features, backward-compatible, out-of-tree is not our problem
+* Informed complaints: m12n was a bad idea, X protocol is old, 3D doesn't work, HD video doesn't work, hotplug displays don't...
+* Mostly just a matter of wanting the moon on a stick
+* Linux haters: no FBOs or pbuffers, no GLSL, no DRI2, no GL2 or GL3, no GLX 1.4
+* Actual state of 3D: decent, getting better
+* Not that far from actually satisfying the complaints!
+
+### tiago and oliver: Embedded Xorg
+
+* Mostly moved from kdrive to Xorg
+* Supports newer extensions, and is actively developed, but has much larger RSS
+* Xorg is already shrinking, which is good
+* Basic configuration will disable dga, dri, glx, ipv6, xinerama, xaa...
+* Could add more configuration options to disable more things; worth the complexity? Probably.
+* x86emu, vgahw, ddc, etc... could reasonably be optional
+* lots of the core is still kind of large, but is mostly .text, so meh
+* RANDR happens a lot, should be fast; external screensaver control would be nice
+
+### ajax: Future of the DDX
+
+* Is our goal X, or the stuff to enable things like X; Arguably should be the latter
+* Moving enablers out of X (already: kms, pixman; future targets: xkb, x86emu/libx86)
+* What about X config?
+* Move EDID and DisplayID parsers to a lib; Make drivers/apps use it.
+* Move i2c into a separate lib
+* fbdevhw could be removed
+* Remove non-randr 1.2 stuff?
+* randr extension for full display state setup (full set of outputs and crtcs in one shot)
+* DPMS and screensaver extensions; should be only one
+* Remove DPMS, add new functionality to randr, tell internal screensaver something else is managing the screensaver
+* Extra cruft: old ramdacs, gatos tuners/decoders, bank switching, PC98, [[ScrnInfoRec|ScrnInfoRec]]
+* MAXSCREENS/MAXFORMATS/MAXDEVICES
+* One DDX with loadable backends
+* Xinerama - unify proto with randr; Make most of the screen stuff global; need shatter
+* Adding YUV/JPEG/opaque data source pictures to render
+* Moving Xv to render so we can do Xv in the DIX? \ No newline at end of file
diff --git a/Events/XDC2009/Program.mdwn b/Events/XDC2009/Program.mdwn
new file mode 100644
index 00000000..dfeb057f
--- /dev/null
+++ b/Events/XDC2009/Program.mdwn
@@ -0,0 +1,53 @@
+
+
+# XDC2009 Program
+
+This is the rough program for [[XDC2009|Events/XDC2009]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk.
+
+
+## Program
+[[!table header="no" class="mointable" data="""
+ | **Monday** | **Tuesday** | **Wednesday**
+ **10am** | _coalesce, breakfast, live schedule bashing_ | _coalesce, breakfast_ | _coalesce, breakfast_
+ **10:30am** | Welcome, general socialising ([[CarlWorth|CarlWorth]] et al) | Mesa, OpenGL 3.x and patents (Ian) | PCI rework debrief (Tiago)
+ **11:15am** | Summer of Code debrief (SoC students) | GL extension for MMs/KMS/fbos, (and Wayland) (krh) | XACE update (Eamon)
+ **12pm** | Lightning talks (krh, et al) | OpenGL shaders for SM3.0/SM4.0 hw (Ian) | Why Xorg sucks and what to do about it (Corbin)
+ **12:45pm** | _lunch_ | _lunch_ | _lunch_
+ **2pm** | Debugging Gallium drivers (Jakob) | Synchronisation and presentation (Aaron) | X on embedded platforms (Oliver & Tiago)
+ **2:45pm** | 7.5 post-partum, 7.6 planning (Daniel) | Technical overview of multi-seat plug-and-play (Bernie) | Future of the XFree86 DDX (ajax)
+ **3:00pm** | | Intel driver update (jbarnes) Followed by _Working sessions_ |
+ **4pm** | Power management in X (Matthew) | _Working sessions_ | X with alternate toolkit architectures (Bart)
+"""]]
+
+
+## Lightning talks (add your own here!)
+
+* Composite-based rootless X server (krh)
+* X.Org Foundation update ([[AdamJackson|AdamJackson]], [[AlanCoopersmith|AlanCoopersmith]], [[BartMassey|BartMassey]], [[CarlWorth|CarlWorth]], [[DanielStone|DanielStone]], [[DonnieBerkholz|DonnieBerkholz]], [[EricAnholt|EricAnholt]], [[KeithPackard|KeithPackard]])
+* HAL dependancy removal (GregKH)
+* Plug-and-play multi-seat (Bernie)
+
+## Talk proposals
+
+[If we're doing our job right, each of these appear in the schedule above.]
+
+* [[Google Summer of Code|http://socghop.appspot.com/org/home/google/gsoc2009/xorg]] &amp; X.Org Vacation of Code students: _How I spent my Summer Vacation_
+* [[MatthewGarrett|http://mjg59.livejournal.com/]]: _[[Power management at the X-related platform level|http://lists.freedesktop.org/archives/xorg-devel/2009-June/001265.html]]_
+* [[CorbinSimpson|CorbinSimpson]]: _Why end-users say Xorg sucks, and what to do about it_
+* [[McFaddenOliver|McFaddenOliver]], [[TiagoVignatti|TiagoVignatti]]: _Challenges of Xorg on Embedded Platforms_ (Late in the day preferred)
+* [[TiagoVignatti|TiagoVignatti]] (and the virtual presence of [[DavidAirlie|DavidAirlie]]): _fclose([[PciReworkProposal|PciReworkProposal]]);_ (I'll need half hour only here)
+* [[AaronPlattner|AaronPlattner]]: _Synchronization and presentation in a composited desktop environment_ ([[description and slides|http://lists.x.org/archives/xorg-devel/2009-September/002194.html]])
+* [[JakobBornecrantz|JakobBornecrantz]]: _Debugging Gallium drivers_
+* [[EamonWalsh|EamonWalsh]]: _XACE Update_
+* [[BartMassey|BartMassey]]: _X with alternate toolkit architectures_
+* [[CarlWorth|CarlWorth]]: _Why can't I bisect my X server?_
+* [[IanRomanick|IanRomanick]]: _Mesa, OpenGL 3.x, and Patents: Where do we go from here?_
+* [[IanRomanick|IanRomanick]]: _OpenGL assembly shader for SM3.0 / SM4.0 hardware_
+* [[AdamJackson|AdamJackson]]: _Future of the XFree86 DDX_
+* [[PeterHutterer|PeterHutterer]], [[DanielStone|DanielStone]]: _X.Org 7.5 post-partum, 7.6 planning_
+* [[KristianHøgsberg|KristianHøgsberg]]: _COMPOSITE based rootless X_ (lightening talk... wait, do we do lightening talks?)
+* [[KristianHøgsberg|KristianHøgsberg]]: _Wayland_ (recycled LPC talk, now with technical details)
+* [[KristianHøgsberg|KristianHøgsberg]]: _A GL extension to integrate MMs, KMS and FBOs_ (BOF style)
+* Someone: What's the deal with XF86 keysyms?
+* [[YourNameHere|YourNameHere]]: _Your interesting topic here_
+* ... \ No newline at end of file
diff --git a/Events/XDC2011.mdwn b/Events/XDC2011.mdwn
new file mode 100644
index 00000000..07342372
--- /dev/null
+++ b/Events/XDC2011.mdwn
@@ -0,0 +1,120 @@
+
+
+# XDC2011: Chicago, United States
+[[!table header="no" class="mointable" data="""
+ [[<< XDS 2010|Events/XDS2010]] | **XDC 2011** | [[XDC 2012 >>|Events/XDC2012]]
+"""]]
+
+* [[Attendees|Events/XDC2011/Attendees]]
+* [[Program|Events/XDC2011/Program]]
+* [[Notes|Events/XDC2011/Notes]]
+XDC2011 is to take place in from the 12th through the 14th of September in Chicago, Illinois, United States. The event is being hosted at the Illinois Institute of Technology within the [[McCormick|McCormick]] Tribune Campus Center in the Ballroom.
+
+The [[Chicago XDS proposal|http://www.michaellarabel.com/misc/xds-chicago-proposal.pdf]] has additional information that was prepared for the foundation board.
+
+
+## Venue
+
+The XDC2011 event is taking place at the Illinois Institute of Technology at the [[McCormick Tribune Campus Center|http://en.wikipedia.org/wiki/McCormick_Tribune_Campus_Center]]. It's immediately due-south of downtown Chicago by just a few minutes with easy public transportation. Thanks go out to the Association for Computing Machinery in helping X.Org secure this venue at an affordable rate in conjunction with IIT.
+
+
+## Program
+
+If you would be interested in providing a talk during the event, please add it to the [[program page|Events/XDC2011/Program]].
+
+_For anyone arriving the weekend prior to XDC2011, [[MichaelLarabel|MichaelLarabel]] will already be showing around a few attendees various places around Chicago and various pubs in the evening. Contact him and you're more than welcome to meet-up with other attendees. His locations will also be [[tweeted|http://twitter.com/MichaelLarabel]] for those that may be showing up at a moment's notice. Sunday evening there might also be a pre-XDC2011 gathering at a local establishment._
+
+
+## Travel
+
+Chicago has two main airports, Chicago O'Hare (ORD) and Chicago Midway (MDW). Most attendees, especially international visitors, will likely arrive at O'Hare. Midway is common for the budget domestic airlines and other general aviation traffic. ORD is one of the lowest-cost airports in the United States to fly in from Europe with direct flights.
+
+Both airports are connected to the city via local train. There are also shuttle buses to major hotels within the city.
+
+
+## Local Transit
+
+Chicago is much better than most cities in the United States with regard to public transportation. There's buses and trains (also referred to as 'El') that go under and above ground depending upon location. Trains are generally on time and most preferred as buses are often late, missing, or crowded, but still better than most US locations.
+
+All events should be within close proximity to a train line for a quick and easy commute around the city.
+
+Public transportation is served by the [[Chicago Transit Authority|http://www.transitchicago.com/]]. Local routes can also be planned using [[Google Maps|http://maps.google.com/]], which tends to provide accurate information for the city.
+
+The event itself at the [[McCormick|McCormick]] Tribune Campus Center is located along [[the CTA green line|http://en.wikipedia.org/wiki/Green_Line_%28Chicago_Transit_Authority%29]] directly at the [[35th–Bronzeville–IIT|http://en.wikipedia.org/wiki/35th%E2%80%93Bronzeville%E2%80%93IIT_%28CTA%29]] stop. There is also a red line Sox-35th stop within walking distance too, which is the train stop used for accessing the White Sox baseball stadium (Cellular Field).
+
+"The bus lines that run to IIT are the 29 (directly to MTCC from Navy Pier/Loop), the 24 (from the Loop down Wenworth/LaSalle, one block west of MTCC) and the 4 (from downtown on Michigan to one block east of MTCC). They are often slow, but they may be more convenient than the train depending on where you are staying."
+
+"There is a free IIT shuttle bus that takes people directly from the IIT downtown campus to the MTCC. The information is at [[http://www.iit.edu/directory/2011-2012IITShuttleBusSchedule.pdf|http://www.iit.edu/directory/2011-2012IITShuttleBusSchedule.pdf]] Technically it's only for IIT students/faculty but you might be able to hop on by saying you're with the CS department."
+
+
+## Accommodations
+
+With Chicago being a popular tourist destination, there's a variety of accommodations in and around the city of Chicago for all price ranges. [[Hotels.com|http://www.hotels.com/]] is able to provide a list of Chicago area hotels. For those on a budget, the accommodations near O'Hare International Airport may be most economical (with an easy 20~30 minute train ride to reach the center of the city) while the hotels in the proper city center are the most expensive options.
+
+* [[Central Loop Hotel|http://www.centralloophotel.com/]] - heart of downtown right in the "loop" whereby all the public train lines wrap around. Convenient location. Circa $170~180 USD per night.
+* [[Club Quarters Chicago|http://www.clubquarters.com/loc_chicago.php]] - Same as Central Loop Hotel in terms of price / central location.
+* [[Travelodge Downtown Chicago|http://www.travelodge.com/Travelodge/control/Booking/property_info?propertyId=10073]] - In the center of downtown Chicago as well. Likely the least expensive hotel that one can find while still being in a very central location; circa $100~140 a night (as of 14 May on Hotels.com is $100 USD per night at a supposed discount of $40)
+* [[Chicago South Loop Hotel|http://www.chicagosouthloophotel.com/]] - Same central location, slightly south / closer to IIT. $169 USD per night. The area around the hotel, however, has been reported to not be a nice area. It's been advised now that it's advised not to walk around in this neighborhood... So ideally better to be elsewhere or to use only taxi/bus for commuting. An IIT professor writes, "the Chicago South Loop Hotel used to be shady, but that whole neighborhood is much better than it was 5 years ago. That would definitely be the closest (8 minute walk) safe place to stay. It's a little far from the train, but there are cabs coming directly to it because many people who have conferences at the [[McCormick|McCormick]] Place stay there."
+
+## Chicago Dining
+
+Chicago has many dining options for all price ranges. Chicago is particularly known for unique styles of pizza and hot dogs. According to [[WikiTravel|http://wikitravel.org/en/Chicago]], Chicago is evidently also known for greasy, large sandwiches that are simply called "Italian Beef."
+
+Beer in America is an unfortunate travesty. Particularly for European visitors, if beer quality is even the smallest concern, avoid most restaurants near Wrigley Field and other sporting venues. For any other recommendations, consult [[MichaelLarabel|MichaelLarabel]].
+
+The XDC2011 dinner and social event is TBD.
+
+Below are some unofficial recommendations on particular establishments.
+
+* Resi's Bierstube [2034 W Irving Park Road] - Good place. Small biergarten. Decent selection of good beer and food. Favorite local German beer hall.
+* Laschet's Inn [2119 W Irving Park Road] – This along with Resi's is the best German food you'll be able to find in Chicago.
+* The Berghoff Restaurant [17 W. Adams Street] - Another German restaurant, but this one at least is downtown.
+* Fogo de Chao [661 N [[LaSalle|LaSalle]] Blvd] – A good Brazilian Steakhouse. It's expensive by American standards, but well worth it.
+* Moto [945 W Fulton Market] - Favorite restaurant in Chicago, one of my favorites in the world. Quite a unique experience, but expensive and can be difficult to obtain a reservation in short notice.
+* Hot Doug's [3324 N California] - Likely the best hot dogs in Chicago.
+* English [444 N La Salle] - Decent bar downtown.
+* Moe's Cantina [155 W Kinzie] - Good Mexican restaurant.
+* Gibsons [1028 N Rush] - Good steakhouse.
+* Portillo's [100 W Ontario Street] - Inexpensive restaurant and beer.
+* Hopleaf [5148 N Clark] - Good bar and restaurant, good food. Bit far north, however.
+* Goose Island [1800 N Clybourne or 3535 N Clark] – Decent local brewery and restaurant.
+* Gino's Pizza [Multiple Locations] - Chicago style deep dish pizza.
+* Giodano's Chicago Pizza [Multiple Locations] - Chicago style deep dish pizza.
+* Kingston Mines [2548 N Halstead] - One of the oldest and most well known Chicago Blue's music joints.
+If you would like any other recommendations about particular places or bars, ask [[MichaelLarabel|MichaelLarabel]].
+
+
+## Dining Near The Venue
+
+Below are a few restaurants / bars located near the IIT [[McCormick|McCormick]] Tribune Campus Center itself, if looking for additional food or drink during the event itself. Additional places can easily be found with Google Maps using "restaurant loc: The [[McCormick|McCormick]] Tribune Campus Center, Chicago, IL 60616"
+
+* 7-Eleven - There's a convenience store at the venue itself.
+* Starbucks [3506 South State Street]
+* Einstein Bros Bagels [3241 S Federal Street] - A cafe / bagel shop right near the venue.
+* Cork & Kerry at the Park [3258 South Princeton Avenue] - Bar restaurant.
+* Rocky's Bar & Grill [234 West 31st Street] - Bar restaurant, plus an outdoor "biergarten".
+* Fratellini Pizza & Pasta [3258 South Wells Street] - Pizza and pasta.
+* Miller Pizza Company [17 West 35th Street] - Normal pizza.
+* Jimmy John's [3506 South State Street] - Cheap sandwiches.
+* "Chinatown" is a short distance away from IIT with a wide selection of Chinese food.
+
+## Registration
+
+If you will be attending XDC2011, add your name to the [[attendees page|Events/XDC2011/Attendees]]. Additionally, subscribe to the [[X.Org events mailing list|http://lists.x.org/mailman/listinfo/events]] for further details. This is a low-volume mailing list.
+
+
+## Remote Participation
+
+If physical participation is not possible but would be interested in participating remotely via IRC and ideally live audio / video streams, make your interest known to [[MichaelLarabel|MichaelLarabel]] that you would like live streaming of the event.
+
+
+## Miscellaneous
+
+The United States uses standard North American 120V / 60Hz power plugs. American Express, VISA, and [[MasterCard|MasterCard]] are all common in Chicago and accepted by most retailers and restaurants.
+
+[[Wikitravel|http://wikitravel.org/en/Chicago]] and [[TripAdvisor|http://www.tripadvisor.com/Tourism-g35805-Chicago_Illinois-Vacations.html]] are great sources for other travel advice and recommendations.
+
+
+## Contact
+
+Feedback and any other inquiries regarding the organization of the event -- or questions if encountered when in Chicago at the event -- can be directed to Michael Larabel <[[michaellarabel.com|http://www.michaellarabel.com/]]> or via SMS / voice-mail at +1.601.871.0456 (US) or +49.089.8091.2991 (DE). Note: these telephone numbers are screened for public callers. Michael can also be contacted on [[FreeNode|FreeNode]] IRC via the michaellarabel handle.
diff --git a/Events/XDC2011/Attendees.mdwn b/Events/XDC2011/Attendees.mdwn
new file mode 100644
index 00000000..8f28f575
--- /dev/null
+++ b/Events/XDC2011/Attendees.mdwn
@@ -0,0 +1,40 @@
+
+
+## XDC2011 Attendees
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDC2011|Events/XDC2011]]. Attendance will be limited to approximately 60 people. For organizational purposes, if you would like to add when you will be arriving/departing and where you will be staying, that may be to the convenience of others.
+
+ 1. [[MichaelLarabel|MichaelLarabel]] (out Thurs 15)
+ 1. [[KenGraunke|KenGraunke]]
+ 1. [[DanielStone|DanielStone]]
+ 1. [[ShuangHe|ShuangHe]] (in Sat 10, out Fri 16, Amber Inn)
+ 1. [[JeremyHuddleston|JeremyHuddleston]] (in Sun 11, out Fri 16, Chicago South Loop) **Extra bed available if you want to split a room**
+ 1. [[Matt Turner|Matt Turner]] (in Sat 10, out Wed 14, Travelodge Downtown)
+ 1. [[StuartKreitman|StuartKreitman]]
+ 1. [[ChrisHalseRogers|ChrisHalseRogers]]
+ 1. [[BryceHarrington|BryceHarrington]]
+ 1. [[AlexDeucher|AlexDeucher]] (in Sun 11, out Wed 14, Travelodge Downtown)
+ 1. [[JeromeGlisse|JeromeGlisse]]
+ 1. [[MartinPeres|MartinPeres]] (in Fri 09, out Fri 16, HI Chicago)
+ 1. [[AlanCoopersmith|AlanCoopersmith]] (in Sun 11, Out Thu 15, Club Quarters Central Loop)
+ 1. [[PeterHutterer|PeterHutterer]] (in Sun 11, out Wed 14, Travelodge Downtown)
+ 1. [[IanRomanick|IanRomanick]]
+ 1. [[JesseBarnes|JesseBarnes]] (Crown Plaza Magnificent Mile)
+ 1. [[KeithPackard|KeithPackard]] (Crown Plaza Magnificent Mile)
+ 1. [[MatthiasHopf|MatthiasHopf]]
+ 1. [[LucVerhaegen|LucVerhaegen]]
+ 1. [[JayCotton|JayCotton]]
+ 1. [[ChaseDouglas|ChaseDouglas]]
+ 1. [[JasonGerecke|JasonGerecke]]
+ 1. [[MattDew|MattDew]]
+ 1. [[SimonFarnsworth|SimonFarnsworth]] (in Sat 10, out Thur 15, Travelodge Downtown)
+ 1. [[BenSkeggs|BenSkeggs]]
+ 1. [[ArvindUmrao|ArvindUmrao]]
+ 1. [[EamonWalsh|EamonWalsh]]
+ 1. John Bridgman (in Mon 12, out Wed 14, Travelodge Downtown)
+ 1. [[TomStellard|TomStellard]] (in Sun 11, out Wed 14, Travelodge Downtown)
+ 1. [[ShinpeiKato|ShinpeiKato]]
+ 1. [[BrianCameron|BrianCameron]]
+ 1. [[CorbinSimpson|CorbinSimpson]] (in Sun 11, out Thurs 15, Travelodge Downtown)
+ 1. [[LindaGoldstein|LindaGoldstein]]
+ 1. [[EgbertEich|EgbertEich]] \ No newline at end of file
diff --git a/Events/XDC2011/Notes.mdwn b/Events/XDC2011/Notes.mdwn
new file mode 100644
index 00000000..7d4bd54d
--- /dev/null
+++ b/Events/XDC2011/Notes.mdwn
@@ -0,0 +1,71 @@
+
+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|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/|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|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?)
diff --git a/Events/XDC2011/Program.mdwn b/Events/XDC2011/Program.mdwn
new file mode 100644
index 00000000..e7ad1748
--- /dev/null
+++ b/Events/XDC2011/Program.mdwn
@@ -0,0 +1,89 @@
+
+
+# XDC 2011 program
+
+
+## Schedule
+
+**If you would like to add a talk or change information regarding your talk, please edit the Ideas section below the schedule or contact [[MichaelLarabel|MichaelLarabel]], and it will be added to the schedule or if anything needs to be re-arranged.**
+
+**11 September (Sunday; ~14.00+):** For anyone arriving into Chicago early, on Sunday at around 2:00PM (and will likely be there for several hours thereafter) there will be several X.Org developers meeting up at [[Snickers|http://www.yelp.com/biz/snickers-chicago]] ([[Google Maps|http://maps.google.com/maps/place?cid=17973169954687798724&q=Snickers+Chicago&gl=us&ved=0CBEQ-gswAA&sa=X&ei=q-JnToWkMZugMuv_4LYE]], a fairly traditional and decent American "dive bar". The location is quite ideal (located at 448 N State St and one block away from a Red line CTA train), there's several other bars and restaurants within easy walking distance to go after meeting up, a good selection of alcohol with decent prices, friendly bartenders, and we should have nearly the entire bar to ourselves. Several developers may also end up on there on Saturday. If any questions or more info contact [[MichaelLarabel|MichaelLarabel]].
+[[!table header="no" class="mointable" data="""
+ **12 September (Monday)** |||
+ 9:00 | Welcome coffee - registration | [[MichaelLarabel|MichaelLarabel]]
+ 10:00 | Codebase of the future | [[JameySharp|JameySharp]]
+ 11:00 | Bringing In New Contributors | [[MatthiasHopf|MatthiasHopf]]
+ 12:00 | Lunch break ||
+ 14:00 | XKB 1.1 | [[DanielStone|DanielStone]]
+ 15:00 | Multi-Touch BoF / Wacom BoF | [[DanielStone|DanielStone]], [[PeterHutterer|PeterHutterer]], [[ChaseDouglas|ChaseDouglas]]
+ 16:00 | Driver Support BoF | Daniel Stone
+"""]]
+[[!table header="no" class="mointable" data="""
+ **13 September (Tuesday)** |||
+ 9:00 | Welcome coffee | ```Coffee Table```
+ 9:10 | Compiler Stacks | [[TomStellard|TomStellard]]
+ 10:10 | Nouveau | [[MartinPeres|MartinPeres]]
+ 10:55 | [[TimeGraph|TimeGraph]] / GPU Scheduling | [[ShinpeiKato|ShinpeiKato]]
+ 11:30 | LLVM In Mesa | Ian Romanick
+ 12:30 | Lunch break ||
+ 14:00 | _Phoronix-Sponsored Beer Afternoon_ (~2:30PM to 5PM) |
+ 14:10 | Graphics Memory Management | [[AlexDeucher|AlexDeucher]]
+ 16:00 | [[Contributing To X.Org & Open-Source Panel Discussion|http://www.phoronix.com/scan.php?page=news_item&px=OTg3NQ]] | [[MichaelLarabel|MichaelLarabel]] Panel: [[PeterHutterer|PeterHutterer]], [[MartinPeres|MartinPeres]], [[CorbinSimpsom|CorbinSimpsom]], [[KeithPackard|KeithPackard]], [[MattDew|MattDew]], [[KenGraunke|KenGraunke]]
+"""]]
+[[!table header="no" class="mointable" data="""
+ **14 September (Wednesday)** |||
+ 9:00 | Welcome coffee | ```Coffee Table```
+ 9:10 | DRM overlay plane | [[JesseBarnes|JesseBarnes]]
+ 10:00 | OpenGL 3.0 | [[IanRomanick|IanRomanick]]
+ 11:00 | GPGPU | [[MartinPeres|MartinPeres]]
+ 11:45 | Lunch break ||
+ 14:00 | Auto Regression Analysis | [[ShuangHe|ShuangHe]]
+ 15:00 | GPU kernel and userspace border | Jerome Glisse
+ 16:00 | Release Schedules | [[JeremyHuddleston|JeremyHuddleston]]
+ 16:45 | X.Org Foundation session, Conclusion (XDS2012 Ideas?) |
+"""]]
+
+
+## Ideas
+
+* Multitouch BoF ([[DanielStone|DanielStone]], [[PeterHutterer|PeterHutterer]], [[ChaseDouglas|ChaseDouglas]])
+ * Status, plans, etc
+* XKB 1.1 ([[DanielStone|DanielStone]])
+ * Not XKB 2.
+* Auto regression Analysis ([[ShuangHe|ShuangHe]])
+ * Introduction, plans
+* Nouveau ([[MartinPeres|MartinPeres]],[[ShinpeiKato|ShinpeiKato]])
+ * Community, past, present and future work (30 minutes) ([[MartinPeres|MartinPeres]])
+* [[Towards DRM-compliant GPU scheduling at the device driver level|http://rtml.ece.cmu.edu/projects/timegraph]] ([[ShinpeiKato|ShinpeiKato]])
+ * To be scheduled after the Nouveau talk, if possible
+ * 30-45 minutes, to be scheduled on the 13th or the 14th
+* DRM overlay plane API ([[JesseBarnes|JesseBarnes]])
+ * review of new ioctls, platform considerations
+* GPGPU (Informal talk? Proposed by [[MartinPeres|MartinPeres]])
+ * What we can already do, what do we want and what needs to be done
+ * Meant as a follow-up of the OpenCL GSoC and the pscnv work
+ * A compute abstraction layer (driver-side): [[ShinpeiKato|ShinpeiKato]]
+ * 30 minutes, to be scheduled on the 13th or the 14th
+* Automated Per-Commit Testing Of Mesa Drivers ([[MichaelLarabel|MichaelLarabel]])
+ * Introduction, Demonstration of Nouveau/Radeon/Intel
+ * Seek feedback, ideas
+* Driver support BoF
+* BoD BoF (X.Org [[BoardOfDirectors|BoardOfDirectors]])
+* Release Schedules (Volunteer: [[JeremyHuddleston|JeremyHuddleston]], Voluntold: [[KeithPackard|KeithPackard]], [[AlanCoopersmith|AlanCoopersmith]])
+ * Rolling drivers into main xserver?
+* Wacom BoF ([[PeterHutterer|PeterHutterer]])
+ * Status, where to go from here? (probably not of interest to those not working on wacom)
+* LLVM as a requirement for Mesa ([[IanRomanick|IanRomanick]], discussion)
+ * It's useful for a lot more than generating code for shaders...
+* Compiler Stacks ([[TomStellard|TomStellard]])
+ * Supporting OpenCL
+ * Using LLVM as an IR
+ * Better code generation for backends
+ * Discussion about the current status of various MESA IRs?
+ * Remaining refactors leading to using GLSL IR to represent ARB_vertex_program / ARB_fragment_program assembly shaders ([[IanRomanick|IanRomanick]])
+* Codebase of the future! (discussion, [[JameySharp|JameySharp]])
+ * X needs to do more in less code. What are our biggest cleanup targets?
+ * To kick things off: in xserver, I suggest unifying DDX and DIX as the big goal.
+* Contributing To X.Org & Open-Source [Panel Discussion, [[MichaelLarabel|MichaelLarabel]]]
+* The long, hard road to OpenGL 3.0 ([[IanRomanick|IanRomanick]])
+* Methods of Attraction - How to gain more contributors ([[MatthiasHopf|MatthiasHopf]]) \ No newline at end of file
diff --git a/Events/XDC2012.mdwn b/Events/XDC2012.mdwn
new file mode 100644
index 00000000..2c54436b
--- /dev/null
+++ b/Events/XDC2012.mdwn
@@ -0,0 +1,135 @@
+
+
+# XDC2012: Nürnberg, Germany
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2011|Events/XDC2011]] | **XDC 2012** | XDC 2013
+"""]]
+
+* [[Attendees|Events/XDC2012/Attendees]]
+* [[Program|Events/XDC2012/Program]]
+* [[BookSprint|Events/BookSprint2012]]
+* [[Weekend Event|Events/XDC2012/Weekend]]
+* [[Proceedings and Recorded Videos|Events/XDC2012/Proceedings]]
+* Experimental Live Video - Closed
+The 2012 X.Org Developer Conference (XDC2012) is to be held from September 19th thru 21st 2012 in N&uuml;rnberg (Nuremberg), Germany. The event will be hosted by [[SUSE|http://www.suse.com]] at their company headquarters in Nuernberg. Please join us to celebrate the 25th anniversary of the first [[X11 release|http://groups.google.com/group/comp.windows.x/browse_thread/thread/3454f7031d88a3b8#]] (15 September 1987, but we'll round a bit) during this conference, we are looking forward to seeing you. An after-conference weekend event will be organized to honor this date [[(check below)|Events/XDC2012]].
+
+
+## Venue
+
+The conference will be held in the main conference room at the SUSE headquarters at [[Maxfeldstrasse 5|http://maps.google.de/maps?f=q&source=s_q&hl=de&authuser=0&q=Maxfeldstra%C3%9Fe+5,+Altstadt+und+Engere+Innenstadt+90409+N%C3%BCrnberg,+Bayern&aq=&vps=1&jsv=402e&sll=51.151786,10.415039&sspn=14.100269,34.936523&vpsrc=1&ie=UTF8&oi=georefine&ct=clnk&cd=2&geocode=FT2y8gIdqRupAA&split=0]].
+
+The conference room is easy to find: it is directly accessible from the outside. If you are coming from Pirckheimerstrasse turn into Maxfeldstrasse and walk uphill along the blue building on the right until you get to a free area on your right. From there you can enter the conference room directly. You will find a sign at the door.
+
+Please note: for security reasons the door is locked. The door will be open in the morning before the conference and after lunch. If you need to get in at other times and you find the door locked you will find my mobile number on a sign at the door. Please call me so I can let you in. As attendee you will get a conference badge, please carry the badge with you at all times when you are inside the building.
+
+
+## Program
+
+There are two ways to submit a presentation for this event:
+
+1. There is a [[Call for Papers|http://www.x.org/wiki/Other/Press/CFP2012_supplemental]]. The deadline for submission is August, 15, 2012.
+1. For more informal presentations you may add your talk to the [[program page|Events/XDC2012/Program]]. The deadline for submission here is September 14, 2012.
+For more information please also check [[here|http://www.x.org/wiki/Other/Press/CFP2012_supplemental]]. A schedule will be available shortly.
+
+
+## Videos
+
+Recorded videos of the session are available from [[YouTube|http://www.youtube.com/phoronix]].
+
+
+## Registration
+
+If you want to attend XDC2012 please add your name to the [[attendees page|Events/XDC2012/Attendees]]. Additionally please subscribe to the [[X.org events mailing list|http://lists.x.org/mailman/listinfo/events]] where we will post regular updates.
+
+
+## Accommodation
+
+There are a number of affordable hotels in Nuernberg (especially since we painstakingly avoided any week with a major trade show), many close to the conference venue.
+
+We have a recommended conference hotel as we are in the process of negotiating a special conference rate. This hotel should not only offer you good rates it is also at a convenient 5 minute walking distance from the conference venue. There is a separate [[hotel page|Events/XDC2012/Hotels]].
+
+
+## Travel
+
+Nuernberg can be reached:
+
+* By **plane**. The Nuernberg Airport is close to the city and can be reached by local transportation in just a few minutes. Nuernberg airport is serviced from some international locations, still expect to travel via Franfurt or Munich. If possible you should avoid Munich at that time as Octoberfest will start directly following the event. If you fly via Frankfurt, you have the choice between flying on to Nuernberg or taking the train and enjoying a bit of the countryside: An railroad station is located right at the airport (Frankfurt(M) Flughafen Fernbf.) where you can board a high speed train going to Nuernberg at least every hour. The train offers more comfort and leg room than coach class on airplanes and also provides electrical power outlets.
+* By **train**. Nuernberg is located conveniently on a major high speed train line (ICE) running to Munich (1 hour), Frankfurt (2h), Cologne, Berlin and several other major cities. It can also be reached conveniently by train from anywhere else in Europe, too. You can search for [[connections|http://www.bahn.de]] and [[purchase tickets|http://www.bahn.de]] ([[English website|http://www.bahn.com/i/view/USA/en/index.shtml]]) on-line with any major credit card. The train station is just a few subway stops away from the conference venue and preferred hotel. The train station in Nuernberg is **Nürnberg Hbf**, and the train station at the Frankfurt airport is **Frankfurt(M)Flughafen**
+* By car. The conference hotel offers guest parking (for an additional charge). Those of you who do plan to take the car will figure out the rest ;-)
+
+## Local transportation
+
+Nuernberg has an excellent public [[transportation system|http://www.vng.de]]: Most locations in Nuernberg can easily be reached by public transportation.
+
+Tickets are available from vending machines at any stop (see also our hints on using public transportation). The conference venue and hotel can be reached on subway line 3. Please also check out our [[tips on public transportation|Events/XDC2012/PublicTransportation]].
+
+It is unlikely that you will need any public transportation during the time of the conference, though, as the venue is conveniently located just north of the inner city. The inner city can conveniently be accessed by foot: it is only roughly 1km from east to west and 1.5km from north to south. For lines please check [[here|http://www.vgn.de/liniennetze/schienennetz_nuernberg_furth/]].
+
+
+## Local Dining
+
+The conference venue is right outside the old city wall, thus in close walking distance from the city center. There are many restaurants close-by as well as towards the city center. Just walk down the street or ask for recommendations on site.
+
+Also check out the [[Nuernberg Tourist Information|http://tourismus.nuernberg.de/]].
+
+
+## Remote Participation
+
+For those who cannot make it to the conference we are planning to record the sessions. We may even have a live stream, also participation via IRC should be available.
+
+
+## Travel Sponsoring
+
+If you are not on a corporate budget but have something to present, please contact the X.Org Foundation Board of Directors [[board@foundation.x.org]] for travel sponsorship.
+
+
+## Miscellaneous
+
+Germany uses Type E/F [[hybrid plugs (CEE7/7)|http://en.wikipedia.org/wiki/AC_power_plugs_and_sockets]] and [[Euro plugs|http://en.wikipedia.org/wiki/Euro_plug]] at 230V/50Hz. People should remember to bring their own adapters.
+
+The currency is Euro (EUR), language is German. Hotel and restaurant staff should speak some English, since Nuernberg is a tourist town many restaurants have English menus available.
+
+Major credit cards (AMEX, Visa and M****asterCard) are accepted at most hotels and restaurants. Some pubs and beer gardens may require cash.
+
+
+## After Conference Events
+
+<a name="beer_hiking_trip"></a> If you can spare the weekend after the conference - hang around with us to celebrate the 25th anniversary of the first release of X11 and join us for [[a beer hiking trip thru the 'Fraenkische Schweiz'|Events/XDC2012/Weekend]] on Saturday. On Sunday, [[a visit to the Nazi Party Rally Grounds|Events/XDC2012/Weekend]] will take place.
+
+In nearby Munich, from 22 September to 7 October is Oktoberfest. [[Michael Larabel|http://www.michaellarabel.com/]] is able to provide tours of München / the wiesn (with either a historical and/or beer focus) at any point after the first Saturday (22nd).
+
+
+## Further Inquiries
+
+If you have any questions regarding the event please feel free to contact me at [[egbert.eich@gmail.com]].
+
+
+## Thanks
+
+The organizers want to thank:
+
+* the 'SUSE Linux Products GmbH' which provided the venue as well as funds for coffee breaks.
+* 'Phoronix' for the beer.
+Our Helpers
+
+* [[Omar Gomez Rey|http://omar-gomez-rey.de]] for setting up the conference room
+* Oliver Fecher for organizing the conference room
+* Salvatorica Serra for organizing the catering
+* Iwona Maher for infrastructure support
+* Christian Deckelmann for setting up the network
+* Jürgen Weigert for video recording
+* Gerhard Schlotter for helping out keeping the room open and getting some last minute printing done.
+
+## Links
+
+[[Email Announcement|http://lists.x.org/archives/xorg-devel/2012-March/030164.html]]
+
+[[Email Update #1|http://lists.x.org/archives/xorg-devel/2012-August/033131.html]]
+
+[[Email Update #2|http://lists.x.org/archives/xorg-devel/2012-August/033360.html]]
+
+[[Email Update #3|http://lists.x.org/archives/xorg-devel/2012-September/033634.html]]
+
+[[Email Update #4|http://lists.x.org/archives/xorg-devel/2012-September/033641.html]]
+
+[[Email Update #5|http://lists.x.org/archives/xorg-devel/2012-September/033642.html]]
diff --git a/Events/XDC2012/Attendees.mdwn b/Events/XDC2012/Attendees.mdwn
new file mode 100644
index 00000000..0eff41c4
--- /dev/null
+++ b/Events/XDC2012/Attendees.mdwn
@@ -0,0 +1,64 @@
+
+
+# XDC2012 Attendees
+
+Please list your name here (and subscribe to the mailing list) if you are planning to attend XDC2012. Attendance will be limited to approximately 60 people. For organizational purposes, if you would like to add when you will be arriving/departing and where you will be staying, that may be to the convenience of others.
+
+1. [[MatthiasHopf|MatthiasHopf]] (IRC: emmes)
+1. [[LucVerhaegen|LucVerhaegen]] (IRC: libv)
+1. [[EgbertEich|EgbertEich]] (IRC: egbert) Hotel: Azimut
+1. [[MichaelLarabel|MichaelLarabel]] (IRC: michaellarabel)
+1. [[MichelDaenzer|MichelDaenzer]] (IRC: [[MrCooper|MrCooper]])
+1. [[AlanCoopersmith|AlanCoopersmith]] (IRC: alanc) (Hotel: [[Woehrdersee Hotel Mercure|https://plus.google.com/103669440673257991258/about]])
+1. [[KeithPackard|KeithPackard]] (IRC: keithp)
+1. [[MatthieuHerrb|MatthieuHerrb]] (IRC: mherrb) (Hotel: Azimut. Arr Hbf tuesday 19h59 from FRA)
+1. [[StefanDirsch|StefanDirsch]] (IRC: sndirsch)
+1. [[MartinPeres|MartinPeres]] (IRC: mupuf)
+1. [[MarioKleiner|MarioKleiner]]
+1. [[LucasStach|LucasStach]] (IRC: lynxeye)
+1. [[SaschaHlusiak|SaschaHlusiak]]
+1. [[MattDew|MattDew]] (IRC: marcoz) (hotel: Azimut)
+1. [[MartinGraesslin|MartinGraesslin]]
+1. [[MichaelHasselmann|MichaelHasselmann]] (IRC: mikhas)
+1. [[JeromeGlisse|JeromeGlisse]] (IRC: glisse)
+1. [[DanielMartin|DanielMartin]]
+1. [[MaartenLankhorst|MaartenLankhorst]] (IRC: mlankhorst)
+1. [[U0001f42b LarsDɪᴇᴄᴋᴏᴡ U0001f42b|LarsDɪᴇᴄᴋᴏᴡ]]
+1. [[PeterHutterer|PeterHutterer]] (IRC: whot)
+1. [[BenSkeggs|BenSkeggs]] (IRC: darktama)
+1. [[DanielVetter|DanielVetter]] (IRC: danvet)
+1. [[ArvindUmrao|ArvindUmrao]]
+1. [[MichalSrb|MichalSrb]] (IRC: msrb)
+1. [[ChristianKoenig|ChristianKoenig]]
+1. [[AndyRitger|AndyRitger]]
+1. [[KristianHoegsberg|KristianHoegsberg]] (IRC: krh)
+1. [[JanArnePetersen|JanArnePetersen]] (IRC: jpetersen)
+1. [[BarryScott|BarryScott]]
+1. [[SimonFarnsworth|SimonFarnsworth]] (IRC: farnz)
+1. [[IanRomanick|IanRomanick]] (IRC: idr)
+1. [[ChadVersace|ChadVersace]]
+1. [[FranciscoJerez|FranciscoJerez]] (IRC: curro)
+1. [[EricAnholt|EricAnholt]] (IRC: anholt)
+1. [[MarcBalmer|MarcBalmer]] (IRC: mbalmer)
+1. [[SimonNiklaus|SimonNiklaus]]
+1. Supreet Pal Singh
+1. Timothée Ravier
+1. [[OliverMcFadden|OliverMcFadden]] (IRC: omcfadde) - AZIMUT Hotel Nuremberg. Arrival: Tuesday 18 Sep @ 17:45. Nuremberg Airport. Departure: Sunday 23 Sep @ 18:25.
+1. [[MichaelSchuldt|MichaelSchuldt]]
+1. [[BenBrewer|BenBrewer]] (IRC: flatmush)
+1. [[RobClark|RobClark]] (IRC: robclark) - hotel:Azimut, arrive:Tues midday(ish).. (1130@FRA, then train)
+1. [[JessVanDerwalker|JessVanDerwalker]]
+1. [[HaraldKoenig|HaraldKoenig]]
+1. [[BartMassey|BartMassey]]
+1. [[KonstaKarsisto|KonstaKarsisto]]
+1. Blaž Tomažič
+1. [[StuartKreitman|StuartKreitman]] (IRC: stukreit)
+1. [[MarcinSlusarz|MarcinSlusarz]] (IRC: joi) (hotel: Azimut)
+1. [[ChristophBumiller|ChristophBumiller]] (IRC: calim)
+1. Mathias Fröhlich
+1. [[JoeBurmeister|JoeBurmeister]]
+1. Lubosz Sarnecki (IRC: lubosz)
+1. Markus Schlüter
+1. Gerhard Schlotter
+1. Juergen Weigert
+1. [[MichaelKerrisk|MichaelKerrisk]] \ No newline at end of file
diff --git a/Events/XDC2012/Hiking.mdwn b/Events/XDC2012/Hiking.mdwn
new file mode 100644
index 00000000..e69de29b
--- /dev/null
+++ b/Events/XDC2012/Hiking.mdwn
diff --git a/Events/XDC2012/Hotels.mdwn b/Events/XDC2012/Hotels.mdwn
new file mode 100644
index 00000000..360969ac
--- /dev/null
+++ b/Events/XDC2012/Hotels.mdwn
@@ -0,0 +1,38 @@
+
+
+## XDC2012 Hotels
+
+The preferred conference hotel is the Azimut Hotel:
+
+**[[AZIMUT Hotel Nuremberg ***|http://www.azimuthotels.de/hotelstandorte/index.php?SECTION_ID=270&IBLOCK=7&SUBSECTION_ID=TOP]]
+** Kaulbachstrasse 1
+ D - 90408 Nuernberg
+ phone: +49 911 3657 - 0
+ fax: +49 911 3657 - 488
+ email: [[info.nuernberg@azimuthotels.com]]
+ for reservation: [[reservierung.nuernberg@azimuthotels.com]]
+ We've got a number of rooms held for XDC participants for **EUR 68/night** for a single room including breakfast and wireless access.
+ Please make your reservation until August 18th, 2012, state **Res.No.142733** with your reservation.
+
+Parking garage available at extra cost.
+
+**Update: the period has ended and the hotel has informed me that it is now completely booked out.** You may still be able to find a room at the other hotels listed.
+
+This hotel is [[500 meters away|http://maps.google.de/maps?saddr=Pirckheimerstra%C3%9Fe&daddr=49.4608619,11.0772507+to:Maxfeldstra%C3%9Fe+5,+904\09+N%C3%BCrnberg&hl=de&ie=UTF8&ll=49.461507,11.08115&spn=0.003563,0.008529&sll=49.461556,11.078886&sspn=0.003563,0.008529&geocode=FX228gIdZgapAA%3BFX228gIdggapACnHInTZsFefRzFBH6SaMtoeEw%3BFae18gIdRx6pACl_i-ksulefRzFD1xgwc0v1Kg&dirflg=w&mra=dpe&mrsp=1&sz=17&via=1&t=m&z=17]] from the venue.
+
+
+There are a few other hotels in the area, notably:
+ **[[Hotel Burgschmiet GmbH ***|http://www.hotelburgschmiet.de/index.php/en/]]**
+ Burgschmietstr. 8
+ 90419 Nürnberg
+ phone: +49 911 93 33 60
+ fax: +49 911 93 33 620
+ email: [[info@hotel-burgschmiet.de]]
+
+**[[Noris Hotel Nürnberg ***|http://www.noris-hotel.de/]]**(formerly Nestor Hotel Nürnberg)
+ Bucher Straße 125
+ D-90419 Nürnberg
+ phone: +49 911 3476-0
+ fax: +49 911 3476-113
+ email: [[service@noris-hotel.de]]
+ Parking garage and Wifi available at extra cost.
diff --git a/Events/XDC2012/Proceedings.mdwn b/Events/XDC2012/Proceedings.mdwn
new file mode 100644
index 00000000..62e0252a
--- /dev/null
+++ b/Events/XDC2012/Proceedings.mdwn
@@ -0,0 +1,633 @@
+
+These are rough notes (provided by [[SimonFarnsworth|SimonFarnsworth]], whose travel to XDC was paid for by [[ONELAN Digital Signage|http://www.onelandigitalsignage.com/]]), plus links to the video recordings. Please feel free to improve the notes; they're there to help you decide whether to watch the recording or not.
+
+[[!toc ]]
+
+
+# Day 1
+
+
+## Board presentation
+
+[[http://www.youtube.com/watch?v=tiNU_zyDUJo|http://www.youtube.com/watch?v=tiNU_zyDUJo]]
+
+The X.org foundation supports development, rather than controlling it.
+
+Foundation is now a US 501(c)(3) charity (thanks to SFLC). Board meetings open and public.
+
+Book sprint to write developer docs has happened (one in March, one in September). Results will be published on wiki.
+
+Xorg has just joined [[OIN patent pool|http://www.openinventionnetwork.com/]].
+
+The war chest is shrinking back to a sensible size; the foundation will soon need to fundraise. Current balance is around $85,000, run rate is around $30k/year. Can burn for 3 years before going bankrupt, but would prefer to find new funding sources. Old funding sources were big UNIX workstation vendors; foundation expects new funding sources to be smaller sums per contributor.
+
+Infrastructure (shared with freedesktop.org) is a challenge, but being worked on; new sysadmin hired and will be working on web stability.
+
+EVoC had 5 students this year; 4 succeeded. Question - does EVoC replace Google Summer of Code, or does X.org need to work out why we weren't accepted and get back into GSoC in future years?
+
+Various IP issues (new logo etc). Also need to revise foundation bylaws. Note; foundation is not tied to X.org (25 years old!), and will continue with Wayland or any other graphical stack that subsumes X11.
+
+Usual need to get more developers on board.
+
+
+## EVoC
+
+[[http://www.youtube.com/watch?v=kOgh2EpKfSo|http://www.youtube.com/watch?v=kOgh2EpKfSo]]
+
+Endless Vacation of Code is inspired by Google Summer of Code, but funded by X.Org foundation. No time restrictions, but 3 month long projects (doesn't have to be summer).
+
+Goal is to get students to become X.Org developers (productive output from EVoC is a bonus); covers the entire graphics stack, basically from drivers (OpenCL, DDX, OpenGL etc) up to the layer beneath the toolkits. It's not meant to provide a wage, just to let you work on X.Org instead of flipping burgers over a long vacation.
+
+Puts extra load on mentors; honestly interested students are welcomed whole heartedly and are worth the extra load, but if you're not actually interested, please don't waste their time (EVoC is not free money for students). Mentor has to establish that student is competent to tackle project, and provide regular assistance to keep you on track. Board relies on mentor's judgement to evaluate students.
+
+
+## Graphics stack security
+
+[[http://www.youtube.com/watch?v=hJpiJii44oo|http://www.youtube.com/watch?v=hJpiJii44oo]]
+
+Inspired by driver development book sprint. These guys aren't driver developers, and had to learn for this presentation.
+
+Security is a trifecta - confidentiality, integrity, availability.
+
+Users have expectations - e.g. cross-app communication is drag-and-drop or cut-and-paste, and therefore under my control. X breaks this - get the auth cookie, you have full access (can keylog, can screenshot as credit card number is typed). Isolation is therefore between users, not between one user's apps.
+
+Problem - all apps grow, and have bugs. Any exploitable bug in any app lets you have full access to the user's desktop session.
+
+So, confidentiality breach; keyloggers, screenshots at interesting moments. Integrity breach; draw over Firefox, so that the user can't tell that you've redirected them from their bank to a phishing site. Any application can act as a "virtual keyboard", and type - another integrity breach. Availability breach - any application can act as a screen locker. ClearGrab bug - a virtual keyboard app can kill a screen locker.
+
+Current mitigations: XSELinux has fine grained access control, but normally deactivated as default distro policy doesn't confine users. Xephyr can provide virtual X screens - but coarse grained, so tricky to use right.
+
+QubesOS uses VMs to solve security problem. PIGA-OS uses SELinux + XSELinux + PIGA-SYSTRANS daemon to solve it.
+
+QubesOS groups apps into security domains. Each security domain is a Xen domU; X server provided for each domain has colourful marking to indicate security domain, inter-domain comms via a daemon in dom0, which implements MAC.
+
+PIGA maps security domains to SELinux types, labels everything. SYSTRANS grants rights as needed, prompting users if this is a cross-domain move.
+
+Wayland moves the security problem into the compositor - events unicast, so compositor has control needed to secure everything. However, compositor is then attack target - how to solve this? Privilege separation? We have an opportunity to fix things here, let's not waste it.
+
+Driver/hardware story not too bad - CPU can't access arbitrary VRAM unless root. Opensource drivers not too bad at GPU isolation between users - mix of VM contexts and switching contexts on GPU, and command validation - scan commands and stop user doing things it shouldn't. Trades context switch cost for CPU time.
+
+Goal is per-GPU-process isolation, just like we have per-CPU-process isolation on the main CPU. Think about information leakage (uncleared buffers), privileged plugins (e.g. to compositor) scanning address space (ASLR helps?) etc.
+
+
+## Solaris privilege separated X11
+
+[[http://www.youtube.com/watch?v=hphjH2KYGAw|http://www.youtube.com/watch?v=hphjH2KYGAw]]
+
+Solaris can run X without root privileges. Aim is to upstream as much of this as possible.
+
+Solaris Xorg creates a named pipe for GDM to X11 comms, and runs Xorg as root. At login, GDM tells X (via pipe) about new user. X switches UID, but keeps root as its saved UID (POSIX-compliant) so it can become root again when it needs to (VT switch, regen).
+
+Solaris has facilities to set device ownership/permissions on a VT and all associated on login; Xorg uses those facilities to ensure that it can open devices as the user, rather than becoming root.
+
+Patches linked from slides. Side note - UEFI secure boot locks out most non-KMS drivers, so we have to work out what we do about hardware like MGA.
+
+
+## Dante: chasing performance
+
+[[http://www.youtube.com/watch?v=PYGeXko_xf0|http://www.youtube.com/watch?v=PYGeXko_xf0]]
+
+Oliver took Doom3 (8 years old) GPL3+ release, ported from OpenGL 1.x with extensions (depending on backend used) to EGL and OpenGL ES 2.0 (including clean-room creation of GLSL shaders to replace the ARBfp/ARBvp shaders), then tried to make the OpenGL ES 2.0 version perform well.
+
+No good performance analysis tools for Mesa. "Best" available is `intel_gpu_top` for i965 driver hardware, but it's a top-like coarse-grained performance tools. Also not user-friendly, as represents load as hardware units (so you need to read HW docs to have a clue what's going on if it's showing an issue).
+
+Every closed driver vendor has decent tools - AMD bought gDEBugger, and made it fglrx-only, other vendors have equivalent tools. Older version of gDEBugger sort-of works with Mesa, sometimes. Mesa has nothing.
+
+Linux has perf infrastructure - lots of performance counters and sampling with source code annotation of results. Nice profiler; can we reuse for GPU performance? Hook DRM and intel_gpu_top data in, rely on existing tools for UI. Need userspace co-operation to get all the way (per-frame indication without GPU stall, so that profile can be interpreted per-frame).
+
+Mesa's best infra so far is perf_debug - but not tied to ARB_debug_output, just to stdout. Also not frame boundary aware - so no way to tie perf_debug output to render operations.
+
+Given all these hints, how do we cope with separate debugger processes?
+
+Oliver found a GLX versus EGL bug. Others may exist.
+
+Intel avoided the need for tools to fix Valve's L4D2 - they sent skilled engineers in instead - this does not scale, so tools are needed.
+
+Comment at end from audience - apitrace is being developed into one profiling tool (although only runs on captured traces, not on live apps); work is underway on a shimGL that hooks live.
+
+
+## Phoronix benchmarking
+
+No video. Contact [[MichaelLarabel|MichaelLarabel]] for more information.
+
+Michael would like developers to expose performance information (clocks, utilization %age, thermals) in a consistent fashion (e.g. standard sysfs files, with speeds in kHz). Please all behave the same, though.
+
+Remaining discussion was Michael asking how Phoronix can be useful to driver devs, even though benchmarks are end-user targeted.
+
+Some discussion of goals of benchmarks, agreement from floor that devs can write their own benchmarks to target individual bits of the driver. Big thing Michael can do is benchmark git snapshots regularly, and bisect performance regressions.
+
+
+## DRI3
+
+[[http://www.youtube.com/watch?v=ZLnl6s60YL8|http://www.youtube.com/watch?v=ZLnl6s60YL8]]
+
+DRI2 fixed the SAREA disaster of DRI1. Experience (including implementing Wayland) has shown that DRI2 has pain points, so let's discuss DRI3 to fix these pain points.
+
+Underlying issue is X server allocating buffers, and thus having to synchronise tightly with clients. DRI3 aims to make GLX buffer management similar to Wayland (clients allocate, "present frame" from glSwapBuffers becomes send buffer to X). Can we avoid having the server tell the client how big the buffer is (e.g. by relying on glViewport and providing an extension for apps where the bounding box of all viewports is not the buffer size)?
+
+DMABUF may let us remove GEM handles from the pile - pass a private DMABUF fd via the UNIX socket, instead of a guessable GEM handle. Lots to consider here - YUV buffers, buffer sharing etc.
+
+DRI3 can now flip when window size matches buffer size - blits only needed if size mismatch (so client/server disagree on window size, so something will go wrong anyway).
+
+Identifying reusable buffers is also a challenge.
+
+Discussion will be on mailing list - this talk is to get people thinking about it.
+
+
+## Board meeting
+
+[[http://www.youtube.com/watch?v=J9QpJEwfLM0|http://www.youtube.com/watch?v=J9QpJEwfLM0]]
+
+New logo is needed. The board will fund a contest if someone steps up to run it, provided the board gets trademark, copyright on resulting logo.
+
+Election cycle upcoming - 4 to replace as per bylaws.
+
+Finances are now about what the board wants to run with - time to raise money to stay put.
+
+Foundation no longer paying for hosting at MIT - now hosted at PSU, sharing infrastructure with freedesktop.org. Machines donated by Sun Microsystems.
+
+New sysadmin starting this week, will start by working on web service reliability.
+
+
+# Day 2
+
+
+## X Server Integration Testing
+
+[[http://www.youtube.com/watch?v=dZTz151SJLw|http://www.youtube.com/watch?v=dZTz151SJLw]]
+
+This is around 1 month's experience so far - most things up for change as a result.
+
+Rationale - testing is hard. Manual testing hurts. Regressions happen if there's no easy tests to find them.
+
+XTS is not the right test suite for lots of good reasons, but has 1,000 test cases to learn from. We need combined server + driver tests. It must be really easy to write test cases (otherwise no-one bothers). They must be easy to run, and the output must be easy to parse, so that people get in the habit of trying tests.
+
+New thing is XIT - based on xorg-gtest which is based on googletest C++ framework. Peter showed some example tests.
+
+Some problems; no shared library => Is gtest the right framework? Server can be slow to start - Keith thinks this should be treated as a bug (server start should always be fast). Issues with version combinations and distro-specific results. Documentation of test cases also an issue - remembering why you wrote it, and what it's supposed to tell you.
+
+Googletest good at controlled execution of subset of tests - can select by regex, for example. Would be nice to combine XIT with tinderbox, for continuous testing - we're good at fixing compile fails flagged by tinderbox.
+
+On to Q&A. Currently Linux-tied by uinput - can do equivalents for non-Linux systems. However, this also means no special hardware needed - events are faked by uinput, so you can test things you don't have.
+
+XTS is broken - written as a contracted piece of work by non-X people, so many tests are broken. How do we recover the valuable bits of XTS? Peter currently not interested in this, as wants driver tests first, protocol tests like XTS can come later.
+
+Googletest not a Google service, just a chunk of code from Google. No tie-in to G+ etc.
+
+Tests aim to observe user-visible behaviour - no driver internal state examination needed.
+
+Contrast to Wayland's test infra (simpler); will Wayland test infra become as complex as googletest, or is googletest too complex for the use case.
+
+Can be extended for output tests - rendercheck is apparently broken, but we have the concept to hand.
+
+Can also produce nice XML for processing into tinderbox-style HTML.
+
+If we redo XTS, we need to avoid the code dump problem we have - but formal specification and RFP process valuable.
+
+
+## Hardware independent accelerated graphics
+
+[[http://www.youtube.com/watch?v=Qc5dFnBCHas|http://www.youtube.com/watch?v=Qc5dFnBCHas]]
+
+Today, we have multiple DDXes; a select few do modern acceleration, and only the big three (Intel, Radeon, Nouveau) have high quality modern acceleration. We removed XAA from all DDXes, as not useful in the modern world.
+
+Hard to implement acceleration - XRender does a lot, and drivers only accelerate "popular" XRender paths - but popular changes with time. We're developer time limited - unless we acquire many developers suddenly, we won't be able to accelerate everything easily.
+
+Three attempts so far at generic acceleration - glamor, st/xorg, st/xa (OpenGL, Gallium, Gallium). Benchmarks used to determine if any of them help.
+
+All tests run on AMD E-450 with 8GB RAM, as Radeon supports EXA, glamor and Gallium. 25 cairo traces used to provide representative sample of operations. All tests baselined against image backend (CPU rendering).
+
+No graphs - Phoronix will produce if considered helpful - just some interesting points. First, only CPU and EXA accel could survive all traces - glamor triggered one panic, st/xorg triggered 3 and fails to cope with tiled scanout (interesting pictures). st/xa is not complete enough to test easily.
+
+CPU rendering usually faster (except when test is fillrate limited). Only Intel's SNA acceleration is as fast as CPU rendering in almost all cases - but don't get fooled by speed, as acceleration is also about responsiveness under load (reduced CPU use by graphics => more CPU for user applications).
+
+Glamor is only maintained option - st/xorg, st/xa not actively developed, and both have issues. But glamor is slow, and "fights" OpenGL to do 2D ops (claim from floor that this is mostly because Gallium is a heavyweight layer, and not fast).
+
+Q and A - Radeon developers at AMD open to using st/xorg, st/xa, but prefer glamor as it's maintained already (so no need for more manpower).
+
+Any measurements of what's improved? Text rendering is everything in 2D - only common operations are blit scrolling and text rendering (word processing etc); glamor will get better at text rendering when GL_ARB_blend_func_extended is supported and used by it.
+
+In the long run, apps that care about render performance will use OpenGL (matches hardware capabilities with buffer objects etc, when X is immediate mode and therefore not modern-hardware-friendly).
+
+Can Gallium overhead be reduced enough to make glamor competitive? Time will tell.
+
+
+## Joystick input driver module
+
+[[http://www.youtube.com/watch?v=Ul2em93dpX4|http://www.youtube.com/watch?v=Ul2em93dpX4]]
+
+This module is for special cases - most users don't need it. It's meant to let you operate X with a joystick or gamepad instead of a mouse (not needed for games). Uses are cheap remote, kiosk system (joystick instead of mouse), consoles, media centres etc.
+
+Needed over evdev because you want to do special axis/button mapping - e.g. absolute axes into acceleration of a moving pointer instead of position. Lots of mapping options provided, to cover most common use cases.
+
+Does not grab device, so concurrent use by (e.g.) games is possible.
+
+Distro users mostly install it in error. Needs sensible on-the-fly configuration (graphical frontends on hotplug etc), so that it doesn't cause problems.
+
+Server has a design problem; we want to be both a pointing device (mouse-like) and a slightly funky keyboard - needs to be two server-side devices, not one (leading to mess). Server doesn't cope well with funky keyboard (special driver-controlled keymap etc).
+
+Focus is on Linux systems, but works on FreeBSD as well. However, Linux consoles tend to use kernel drivers or userspace daemons to fake a "real" mouse instead of this driver. Console distro awareness therefore needed.
+
+Wiimote/Kinect not the focus of this driver - they're not joysticks, they're a different sort of input device.
+
+Some fun with force feedback (and nostalgia for ASR-33s) - XI1 allows some events, but toolkits don't use them so never ported to XI2. Doesn't mean it can't be done, though.
+
+Request from audience - please update documentation to cover everything in this talk, to help reduce confusion.
+
+
+## XCWM and XtoQ
+
+[[http://www.youtube.com/watch?v=XC3Y63PhcR4|http://www.youtube.com/watch?v=XC3Y63PhcR4]]
+
+Started as Portland State University capstone project (5/6 students doing an externally sponsored project). Goal is library to run X clients in a non-X window system (Wayland, Mac OS X, Microsoft Windows...) without needing special hacks in the server like XQuartz and XWin.
+
+Uses Damage and Composite to do the heavy lifting, with dummy drivers as needed. XtoQ was proof of concept for XCWM - can XCWM replace XQuartz?.
+
+Currently has basic WM functionality - limited ICCCM, EWMH, functional mouse + keyboard, and support for override-redirect windows.
+
+Basic idea is that XCWM runs its own XCB event loop, tracking important data in its own data structures (accessible from native window system event loop) and callbacks on interesting X-side changes. Certain amount of cross-thread excitement as native system and XCWM interact.
+
+Example code flowcharts for XCB_MAP_NOTIFY and Damage event. Damage handling is interesting - XCWM basically gives the native system damage notification, which results in the native system coming back to ask for pixmap for damaged area. When native grabs pixmap, XCWM subtracts the damage, and relies on native rendering the pixmap to get good looking output.
+
+Input event passed by native to XCWM, then XCWM uses XTest to inject into server. Nice and simple.
+
+Future work: more ICCCM, EWMH. Rethink event loop. XtoSomethingElse (Wayland or Windows) to prove that there's no Mac OS X dependency in XCWM. Real drivers for input, instead of XTest.
+
+Contributors welcome - libxcwm git repo, or e-mail Jess <[[jvanderw@freedesktop.org|mailto:jvanderw@freedesktop.org]]>.
+
+
+## Languages for X client development
+
+This talk was interrupted by a power cut, so two recordings:
+
+[[http://www.youtube.com/watch?v=3BgQU82yG5s|http://www.youtube.com/watch?v=3BgQU82yG5s]] then [[http://www.youtube.com/watch?v=WaAkkmi1ybA|http://www.youtube.com/watch?v=WaAkkmi1ybA]] when power returned.
+
+Question; why are desktop apps apparently harder to write than mobile or web apps? Is choice of language (usually C or C++) the problem? Note that webapps are rarely C or C++, mobile is usually Java or Objective C.
+
+One problem is that desktop apps are bigger with more requirements; however, mobile and web gain from GC, OOP, dynamic binding. Mobile/web is often not modular, nor do they provide big mega-apps.
+
+Any interesting domain-specifics?
+
+Issues to consider:
+
+* Correctness
+ * Threading versus event streams
+ * Callbacks and control flow
+ * Memory management
+* Modularity
+* Widget manipulation from code
+* Configuration
+ * I18N
+Lots of language choices out there.
+
+C and C++ popular with XDC attendees - we write the server and drivers in C. Is that why we use it for desktop apps? Does mainstreamness help?
+
+C libraries work well due to FFIs. Toolkits seem to continue C or C++ theme (Qt, GTK are entrenched). Structure makes using other languages hard.
+
+Basically, it's all too hard. Big Q is requirements from a programming language - is it even the right question? How do we fix things so that people go back to building X11 apps for "geek cred" instead of mobile or web apps? Code generators not the answer - too hard to work with generated code.
+
+Question - is X's age part of why other things seem simpler? We have 25 years of finding and resolving problems; web apps and mobile don't yet, and have fewer problems as a direct result (see also Android fragmentation).
+
+Question - is JavaScript the answer? Note history of JS - it's an accident that it dominates web. However, people learn it.
+
+Qt's QML suggested. Point from floor - packaging is the unsolved problem. I have a browser already, I might not have Qt, QML or other important libraries installed.
+
+
+## Wayland
+
+[[http://www.youtube.com/watch?v=L8zwnqKysfI|http://www.youtube.com/watch?v=L8zwnqKysfI]]
+
+Basic principle of Wayland is to remove the bits of X11 that toolkits don't use any more, and then clean up the cruft.
+
+In the X11 world, compositor runs as a client of the server. X server sits in the middle of everything, getting in the way. Wayland makes the compositor and the display server one process.
+
+Current plan is to have a stable release later this year; not a final finished release, but stable protocol and API so you can build against it.
+
+Buffer management is client side (see DRI3 ideas). Client allocates and manages buffers including releasing them when unused. Protocol exists to hand buffers to compositor, and to discover when the buffer is no longer used by the compositor (and when the buffer was presented).
+
+XVideo is replaced by YUV buffer support (described by fourcc). There will be a libva backend that can feed YUV buffers direct to compositor. Compositor can use YUV samplers for texture sampling; there is a Mesa extension for this already. Presentation timestamp for buffers lets you tie application clocks to presentation clocks (e.g. for movie playback with lipsync).
+
+Even better, because all you're passing is GPU buffer objects, the compositor can use hardware overlays (aka sprite planes on some hardware) instead of sampling, as and when the compsitor thinks it's a good idea. The client doesn't need to know what's going on - atomic pageflip (Rob Clark) will make it faster than today (where using sprite planes isn't full frame rate).
+
+Couple of demos - first a simple spinning triangle, then a libva movie trailer.
+
+Testing tools are Weston compositor and a toy Wayland toolkit (used for things like a terminal). Weston is a simple, usable compositor (maybe good for embedded), but desktops will end up taking your X11 compositor and making it the Wayland compositor (using same libraries as Weston to talk Wayland).
+
+List of Wayland features next; Wayland doesn't give apps global co-ordinates, so no risk of confusion by apps. Makes input redirection totally reliable, even when window has arbitrary rotation. XWayland clients find themselves at global 0,0, which leads to weirdness for things like xeyes. Events tell applications about subpixel layout, which can change live.
+
+Weston uses a framebuffer per output, so some of the reasons for clone mode go away - but clone mode still possible.
+
+X integration works a lot like XCWM; there's an XWayland module that translates X to and from Wayland as needed. DDXes need some changes to provide acceleration, but not hard to do. Basically the same idea as composited X11, but with the X server being a client of the compositor. Note that even GLX works under XWayland, although Shape extension is not yet present.
+
+Some work needs to be done on X window management - WM is in Weston, leading to a loop (Weston is a client of X is a client of Weston). Needs splitting up before deadlock bites.
+
+Wayland has a handshake protocol for popup menus, to avoid offscreen problem without global geometry.
+
+Weston reuses libxkbcommon for keymaps, to share the work done on X11 keymaps. Zoom in Weston has a "follows mouse or typing, whichever was last" policy. Also screen recording present, with useful tools. There is a Wayland "ping" protocol to check for dead clients - Weston only uses it when it needs to. Because it's UNIX socket connectivity, Wayland compositors can terminate misbehaving apps by PID; this is more reliable than X, which uses a window property.
+
+On-screen keyboard is an external process, launched by Weston as a specially privileged client. Remoting is currently a VNC-like differencing protocol, either whole-desktop or single window. As it happens, because Wayland is optimized for minimal context switches (no round trips), remoting is responsive, even with VNC-like behaviour.
+
+XWayland will be sent to xorg-devel@ list for review soon.
+
+GBM is part of Mesa, but created for Wayland use of OpenGL. It's an EGL display, providing the functions EGL needs (display, surface creation etc), plus extras for buffer swap via compositor, KMS, headless operation, cursors etc. It's been used in [[KMSCon|https://github.com/dvdhrm/kmscon]] as well as Weston.
+
+
+# Day 3
+
+
+## New i915 modesetting
+
+[[http://www.youtube.com/watch?v=ayP6bw6EBPo|http://www.youtube.com/watch?v=ayP6bw6EBPo]]
+
+The new code is entirely kernel changes backing the same userspace ABI. It's really all about why the helpers were unhelpful.
+
+Naming is a bit problematic - prepare/commit map to enable/disable. Kernel "encoder" is Intel "port", kernel "crtc" is Intel "pipe", terms get used interchangeably.
+
+The crtc helper assumes encoder/crtcs are completely split and can be enabled, disabled and routed independently without influencing each other.
+
+This is both too flexible (can call disable at unexpected times, reorders encoder and crtc enable and disable sequences depending on what changes it's making, which breaks hardware and requires driver to do state tracking to elide dangerous hardware prodding), and is also not flexible enough to cope with hardware quirks (Intel CPU eDP PLL, LVDS pin pair, Haswell DDI port).
+
+New code simplifies DPMS - with the exception of old VGA, Intel hardware only does DPMS on and DPMS off. This is connector-driven; Intel had to map to encoder state as well.
+
+Modeset sequencing is now fixed, which helps with hardware quirks. Callbacks in place to get things done in the same order at the same times, no need to elide any hardware poking.
+
+Output state got staged, so that when things go wrong, you can get back to a sane state. Hardest part of conversion job, but has had two benefits - can read out firmware state during takeover (flicker-free boot) and can compare hardware state to software intended state at suitable points, making it possible to sprinkle WARNs in to make debugging simpler.
+
+The incomplete split between crtc helper and fb helper is obvious WIP; modeset semantics that fb helper depends on were "fun" to duplicate. Cleanup in progress, including training helper to not call the driver to do things if it shouldn't have any effect.
+
+A few WTFs found - DPMS On after modeset, disabling of disconnected outputs, helper vtables not typed. Again, being fixed.
+
+Remaining todos include HPD IRQ handling - may have to move to driver to deal with things like HDMI versus DP signalling on Intel DP++ ports. Not sure why all connectors get polled on HPD IRQ - bug workaround? Tread carefully.
+
+Atomic modeset and pageflip (aka nuclear pageflip) need to understand shared resources like PLLs. Doesn't work with the current disable everything then enable pattern, but fixable.
+
+Always need to clean up dirver code, but it's happening.
+
+Seamless takeover of firmware state is happening. Output routing, firmware FB storage done, just have to deal with resources like PLLs, reference clocks, panel fitter, and state like interlacing.
+
+DP MST is going to make things interesting (but no sinks yet); currently, one crtc feeds multiple encoders. MST means multiple crtcs feed one encoder. Two ideas to consider, either DP encoder as a shared resource like a PLL, or pipes grouped and controlled as a block. Can wait until sinks exist.
+
+Question on whether this fixes flicker during modeset; answer is no, but gets code into shape to fix it. If it does fix it, it'll be because they've made a hardware quirk workaround fix actually take place now.
+
+
+## Release planning
+
+[[http://www.youtube.com/watch?v=xOr8SsKzimQ|http://www.youtube.com/watch?v=xOr8SsKzimQ]]
+
+1.13 was 2012-09-05. Target for 1.14 is thus 2013-03-05. Any reasons to delay? No.
+
+Keith would like bugs filed once in stabilization period, rather than private complaints to developers. We want to hold up the release to get the bugs out - this won't happen if Keith is unaware of the problems.
+
+There are features planned - "DRI3" (which may turn out to be just DRI2 fixes), XWayland if we can, some GLX stuff.
+
+Atomic modesetting in X as well as KMS is a target, too.
+
+Rough plan is 3 months to build new features, 2 months for general bugfixing, last month for critical bugs only.
+
+
+## Atomic modeset and pageflip
+
+[[http://www.youtube.com/watch?v=Hg-NLICrDB8|http://www.youtube.com/watch?v=Hg-NLICrDB8]]
+
+AKA nuclear pageflip if you've been confused on IRC.
+
+Atomic pageflip is update all plane and crtc fbs and properties within a single vblank. Atomic modeset relaxes the time constraint, but sets all connectors to required state in a single kernel call.
+
+Both IOCTLs have a test flag, to confirm that the hardware will do it sucessfully, as well as a live flag to do the operation requested. If test says it'll fail, you can fall back to a different option (e.g. draw a textured quad instead of using a plane, or reduce resolution on an output).
+
+Most state is now stored in property lists, to reduce the number of codepaths in pageflip/modeset/property set (avoids unexpected bugs).
+
+There's been work done to split out kernel state from user-visible state. Test flag means you need to build up proposed state and then rollback, so helpers have been written to assist.
+
+Atomic sequences become begin, check, commit, cleanup. Only commit should touch hardware, and check should be the same between the actual sequence and the test version.
+
+Patchset also cleans up the code a bit - some object properties added, the idea of "dynamic" properties (which can be changed freely, so test will always return true), signed ranges for properties.
+
+TODOs: remove plane->update_plane, crtc->page_flip. They're now obsolete. Fix the IOCTLs - still not quite stable.
+
+Question - how does core code handle things like memory bandwidth requirements? Answer - it doesn't, it punts to driver. Core checks things that are common (e.g. sane size, fbs being passed actually exist), then lets the driver cope.
+
+All checking must be done in check, commit shouldn't fail if check passed, otherwise users can't do the right thing.
+
+Can we provide better diagnostic information (e.g. an error string)? Preference is to use error numbers, so that we can evade I18N issues.
+
+
+## DRI2 video
+
+[[http://www.youtube.com/watch?v=nwpy2PNb_MQs|http://www.youtube.com/watch?v=nwpy2PNb_MQs]]
+
+Replace XV with DRI2 by pushing more buffer types.
+
+XV downsides - at a minimum, two memcpys (Xshm, XvShmPutImage). More if you don't do Xshm. Not ideal for any hardware acceleration, as can't allow for HW decoders with special memory requirements (alignment etc). Not ideal for GPUs - at best, map/unmap, at worst copy.
+
+Today's DRI2 is unscaled RGB buffers only. VA-API and VDPAU do a GPU YUV->scaled RGB blit, then compositor does at least one blit. Memory bandwidth becomes an issue.
+
+Wayland does this - get X to match capabilities on local machine.
+
+So, teach DRI2 to allocate unscaled YUV buffers (video-size, with codec borders available), including multiplanar formats. If driver/display can support it, we can scan out directly (overlays) from the unscaled buffer (zero-copy scanout).
+
+Removes at least one blit, so always helpful.
+
+New protocol to support this.
+
+Some missing bits - interlace, stereo. Client control of buffer/plane mapping (e.g. NV12 in one buffer or two) - can we fix that with DRI3 proposal. Destination co-ordinates (for fixing aspect ratio).
+
+
+## Optimus and cross-device sync
+
+[[http://www.youtube.com/watch?v=CQ1-Myt3coY|http://www.youtube.com/watch?v=CQ1-Myt3coY]]
+
+This uses DMA-BUF, X.org server, patched DDXes and xrandr 1.4 to make it work.
+
+DMA-BUF wraps buffer objects in special (shareable) fds, that can let you remap across hardware.
+
+Server needs GPU hotplug support (platform bus), xrandr 1.4 for configuration. DDXes have to learn about Optimus roles (render slave, output slave).
+
+Would be nice to use robustness extensions to enable compositors to do seamless muxed GPU switching - ideally completely user-invisible.
+
+Sync is hard - you have multiple hardware devices, and arbitrary buffer ordering and sharing, with arbitrary locking. Avoiding deadlock is done using TTM reservation code, and TTM fence primitive for cross-device sync. Make lockdep annotations possible (helps with bug fixing).
+
+All APIs are unstable - not even the name is tied down.
+
+Fence is a dumb primitive - literally "block until signalled". Can implement purely in software, but hardware implementations also work to kick things. Have one exclusive fence, and a few shared fences per device.
+
+Reservation is based on tickets to let clients make progress without deadlocking. Rules exist for using both APIs.
+
+Demo on Ubuntu system, showing that it's still not working well (although it does work), and can crash the system.
+
+The example for shared fences is a camera feeding both the GPU (for a preview display) and a hardware H.264 encoder (for recording).
+
+
+## DRM2
+
+[[http://www.youtube.com/watch?v=4fRXNHAjMIY|http://www.youtube.com/watch?v=4fRXNHAjMIY]]
+
+Problems are authentication and buffer sharing.
+
+Security model is that master has control, but can literally only stop clients authorizing. Once authorized, clients are unrestricted.
+
+Only one master at a time (needs root), but you drop master when you don't need it.
+
+Display servers need master; X uses it for limiting modesetting to active server. Isolation between clients (or at least between masters) would be nice, but not currently provided.
+
+There's a VT switch race; VT switches need us to release master in one process, gain in another. Malicious process can race for the gap.
+
+GEM buffer sharing is flink-based, and dangerous - any client can access any buffer if it guesses the handle. No confidentiality or integrity.
+
+Non-GUI apps need the GUI to authenticate them - makes GPGPU feel weird (why do I need X to co-operate)?
+
+Idea - split master into two, one for modeset, one for GEM. flink restricted to only working between a master and clients it has authed (won't break current user space). Driver + HW can then isolate clients completely.
+
+KMSCon could, in the long run, replace VT switches. It takes master, it forwards things between running display server (e.g. Weston compositor, X.org) and the hardware, and pays attention to what should and should not have access.
+
+DMA-BUF is nearly as secure as reasonable, but could be slightly enhanced by LSM (SELinux) hooks. Not used by most mortals, but some people have plans.
+
+Details as patches over the next month.
+
+
+## EVoC Nouveau project experience
+
+[[http://www.youtube.com/watch?v=n41aYIPTiiU|http://www.youtube.com/watch?v=n41aYIPTiiU]]
+
+Student started as a web developer. Moved onto KDE, but developing X seemed scary and hard.
+
+EVoC was an accident; tried to get an onsite intership at Mozilla, Google, Apple, but failed. GSoC deadline had gone past, so either Android app development, or EVoC.
+
+Student wanted a fast GPU anyway, for gaming. Bought an NVIDIA card, and found out that Nouveau couldn't do reclocking on modern cards.
+
+Presented a brief history of reclocking, from nv50 (where defaults were OK) to Fermi (default 10% of max performance).
+
+Goal was to make it work as well as it did on nv50; nv50 had HWSQ, but Fermi replaced it with PDAEMON, which changed ISA to FµC (flexible microcode).
+
+Martin Peres had already done fan management and host -> PDAEMON comms. Project had three parts; PDAEMON to Host comms, replace HWSQ, and write more documentation (audience enthused by documentation comment).
+
+PDAEMON->host comms was a simple ringbuffer with sanity checks. Tested, proven working, merged, then onto the hard bit (Fermi Scripting Engine).
+
+FSE acts as a HWSQ replacement. Implemented in FµC, provides 6 basic operations - two types of delay, MMIO read/mask/write, message to host.
+
+Send message to host is still not working, but rest works and is being tested.
+
+Did lots of good documentation on his blog [[http://supreetpal.blogspot.in/|http://supreetpal.blogspot.in/]] Also got mwk to write intro.txt in envytools.
+
+Still thinks we need more newbie docs; Supreet wrote a "Beginner's guide to KDE devel", X needs the same to get people in.
+
+On to EVoC; EVoC is a 13 week project proposed by student. Money is $1k up front, $2k mid-term, $2k completion. Can start at any time, as long as you have 13 weeks.
+
+Money was delayed, but did arrive.
+
+Moved onto discussion of EVoC with audience - how do we make it better? Important bits are that X can't afford to pay wages, and is really aiming to get people over the "X is too scary - I can't possibly contribute to it" barrier - if it wanted work done, it'd have the mentors do it.
+
+Student suggests publicity needed, and more documentation to ensure that mentor time doesn't get wasted (prerequisites for suggested projects).
+
+
+## Tegra and embedded graphics
+
+[[http://www.youtube.com/watch?v=KbMOQ5rit54|http://www.youtube.com/watch?v=KbMOQ5rit54]] Hardware is ARM CPUs + GeForce ULP (no unified shaders, no virtual memory). Sophisticated memory controller, to share bandwidth and control memory access latency for GPU/CPU accesses.
+
+Two similar display controllers - different encoders (HDMI, DSI, TV). Scanout engines have 3 plane plus cursor support, 2 YUV-capable planes, separate colorkey and palette per plane. No rotation possible at scanout.
+
+Tegra is OSS friendly - can get the TRM from developer website. No documentation for acceleration engines now, though, although there are plans to open up fully. Still a lot of work to upstream everything done so far (partly due to Android focus).
+
+There's a start on a DRM driver; KMS works, but memory management not done. Efforts underway to RE the 3D engine.
+
+Problem; no memory virtualisation at all. Security issues; all buffers must be continuous DMA memory; misbehaves under memory pressue. Fixed for Tegra 3.
+
+Challenges: low memory bandwidth - scanout can eat *all* the bandwidth. Copying data hurts more than ever before (so RandR with shadow buffers really hurts). Surface tiling required to have enough bandwidth to cope - fallbacks are proportionately more expensive.
+
+Memory again - you don't have much of it - fixed "stolen" VRAM is a waste of memory, but lack of IOMMU makes smart sharing hard.
+
+Compositing with OpenGL not preferable. Subpar use of 2D engines, no plane usage. Wayland provides some help here (makes it possible to write a 2D compositor).
+
+Q&A - is CMA a fix for the memory problem? No, as you can't easily release memory from the GPU when the CPU needs it.
+
+Nokia mentioned that hardware scanout rotation is overrated - you want things like animations, so you don't use the hardware rotate anyway.
+
+
+## Waffle
+
+[[http://www.youtube.com/watch?v=BdLEn6lji-U|http://www.youtube.com/watch?v=BdLEn6lji-U]]
+
+Motivation was improving Piglit's GL tests. Piglit is a GLUT user - GLUT is simply outdated; on Linux, is GLX only and can only do legacy GL contexts, so can't do OpenGL 3.1 core profiles, or even request a specific GL version. Lots of ugly hacks to get GLES tests, so not many ES tests.
+
+Piglit should really run on Wayland, Android, X/EGL. GLEW also an issue (for GLES and for GL > 3.0).
+
+Qualities of an ideal solution:
+
+1. Build each test once, run on each of the available systems - GLX, X/EGL, Wayland, decision at runtime.
+1. Where sane, mux a test over multiple GL APIs (e.g. ES 2, ES 3, GL 3.2, legacy GL etc). This may be a first anywhere.
+1. Benefit projects other than Piglit - so should be a separate library (e.g. for apitrace to reuse with glretrace).
+Solution so far; can do the first with libwaffle. Getting going on the second, but more work to go.
+
+Piglit needs GL core profile support - not Waffle's fault.
+
+Waffle API resembles EGL with extras for window creation, dlsyming your GL library (with OS abstraction), getting at the underlying native objects (e.g. for input behaviour that's outside Waffle's scope).
+
+Supported platforms are all Linux display engines, Android (experimental - bugs may be Android's fault), Mac OS X (experimental, not fully tested). Patches welcome for Windows.
+
+Demo of Dante ported on top of Waffle instead of EGL. Run same binary on Wayland and EGL/X11.
+
+Waffle is not GLUT or SDL. Will never do input or audio. It's meant for demo applications and tests. See examples in repo (aims to use a GL-like attribute list API).
+
+Question: considered a wrapper header to avoid the dlsym stuff? Yes - piglit has macros to do dispatch.
+
+There is a KMS/GBM backend being written - will let you run piglit on a headless server. Side benefit - lets you work on new hardware as soon as 3D hardware works, while rest of team tackles the modesetting problem.
+
+Question: Dynamic detection of GL API? Example does a dispatch based on environment variables. As yet, Waffle can't pick for you. What are sensible defaults? Consider X on Wayland and Wayland on X (both supported options) - which is the "best" window system?
+
+Waffle dlsym just calls dlsym for you on the right library. But have to be aware of ABI - waffleGetProcAddress backs it the right way, though. EGL, GLX, CGL all have different rules on dlsym and GetProcAddress. Windows backend will trigger an API revision due to GetProcAddress weirdness. Chad is scared of Windows now, so will not be implementing that backend.
+
+
+## New GL ABI
+
+[[http://www.youtube.com/watch?v=LesAb4sTXgA|http://www.youtube.com/watch?v=LesAb4sTXgA]]
+
+Starts with a look at the current position (set down in 2000, so outdated).
+
+Lots of hoops for more OpenGL. GLES with GLX is worse. OpenGL with EGL is awkward. Indirect rendering - just don't start on it, we want to kill it with fire (can't exceed OpenGL 1.5, usually claimed in error, leading to bug reports).
+
+Things to do; split libGL into libOpenGL for OpenGL (like libGLESv2 or libGLESv1_CM) and libGLX for GLX. libGL just links to the two of them.
+
+Version libOpenGL. App developers hate GetProcAddress; how do we escape that? Versioned libOpenGL sonames? Can we bump the minimum GL version (noting old hardware is still out there)?
+
+Want to deprecate GLX, as new GLX extensions are hassle, and we've already decided to kill indirect rendering.
+
+Try and convince everyone to use EGL instead. Hassle is proprietary drivers - NVIDIA apologised, they're working on it (and already ship it for Tegra).
+
+Make OpenGL ES part of the ABI; makes it easier to port between mobile and X.
+
+Where do we go? Update loader/driver interface - closed source driver vendors showing interest, but this will be slow. Killing indirect makes it easier, because the X server stops having trouble with it.
+
+TODO now: split libGL. Convince distros to drink EGL coolaid - GLX to EGL porting guide?
+
+NVIDIA's Andy Ritger has a good proposal up at [[https://github.com/aritger/linux-opengl-abi-proposal|https://github.com/aritger/linux-opengl-abi-proposal]] and will help drive this. Discussion on mesa-dev to get it moving.
+
+Discussion on how you version libOpenGL - soname? ELF versioning? We'll work it out.
+
+Question - what is replacement for indirect? Answer is VNC-like remoting - note that we're now talking about limiting ourselves to 1999 OpenGL versions, as indirect GLX is not keeping up.
+
+NVIDIA has extended indirect GLX to newer OpenGL. Maybe though, X should learn to ship images across the wire instead of GL commands - can be done without applications to be aware of it.
+
+
+## OpenCL testing framework in piglit
+
+[[http://www.youtube.com/watch?v=J7xQn_KuPrQ|http://www.youtube.com/watch?v=J7xQn_KuPrQ]]
+
+This was an EVoC project: Use piglit to test OpenCL as well as OpenGL. Benefits TDD and regression finding.
+
+Goals; test OpenCL compliance and versions. Make test writing easy.
+
+Piglit provides concurrent execution of tests. Grouped tests. Results display.
+
+Test as much as possible, aim for all-platform, all-device tests, but tests can be tied to a device or platform.
+
+Try to make test code common. Helpers to deal with common blocks of code.
+
+A test is configuration section to set up environment, then a test section. So far, three test types (API, OpenCL program execution, and custom). Tries to reduce code you need to write if you're focusing your test. Shown example of custom test.
+
+Program tester aims to let you write an OpenCL program, specify inputs and expected outputs, and execute multiple tests on your OpenCL code, without writing a line of C.
+
+Showed that it does run its 70 tests on 3 different OpenCL implementations - 32 passes on Clover, 53 on Intel (CPU-side implementation), 55 on AMD APP.
+
+Short term - more tests, clinfo (like glxinfo, but for OpenCL). Add support for half type.
+
+Longer term, want OpenGL+OpenCL combination testing (buffer sharing). Support for SPIR (Standard Portable Intermediate Representation) binary OpenCL program format.
diff --git a/Events/XDC2012/Program.mdwn b/Events/XDC2012/Program.mdwn
new file mode 100644
index 00000000..a21ec271
--- /dev/null
+++ b/Events/XDC2012/Program.mdwn
@@ -0,0 +1,66 @@
+
+
+# XDC2012 Program
+
+**If you would like to add a talk re-arrange your schedule, please contact [[EgbertEich|EgbertEich]] <[[e4t@freenet.de]]> or [[MatthiasHopf|MatthiasHopf]] <[[mat@mshopf.de]]>. Please add an abstract to your talk if there is none available yet.**
+
+
+## Tracks
+[[!table header="no" class="mointable" data="""
+General business | &nbsp;Security&nbsp; | Performance | X.org: Server | X.org: Environment | &nbsp;Wayland&nbsp; | Gfx Hardware | DRI/DRM/Kernel | 3D Graphics
+"""]]
+
+
+## Schedule
+[[!table header="no" class="mointable" data="""
+ | **Wednesday** | **Thursday** | **Friday**
+ 09:00 | **Members of the Board**: [[XorgFoundation Status Update, Book Sprint Results, EVoC Results|Events/XDC2012/XDC2012AbstractKickOff]] | **Peter Hutterer**: [[X server integration testing. Yes, it's possible|Events/XDC2012/XDC2012AbstractPeterHutterer]] | **Daniel Vetter**: [[New i915 modeset infrastructure Code|Events/XDC2012/XDC2012AbstractDanielVetter]]
+ 09:30 | **Lucas Stach**: [[Discussing approaches for hardware independent accelerated graphics drivers|Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent]]
+ 10:00 | **Martin Peres**: [[Return of experience on the EVoC : How to better prepare the Students|Events/XDC2012/XDC2012AbstractMartinPeres]] | **Sascha Hlusiak**: [[Development State and Features of the Joystick Input Module|Events/XDC2012/XDC2012AbstractSaschaHlusiak]] | **Rob Clark**: [[DRM/KMS Atomic-Modeset / Nuclear-Pageflip|Events/XDC2012/XDC2012AbstractRobClark-KMS]]
+ 10:30 | _Break_ | _Break_ | _Break_
+ 11:00 | **Martin Peres, Timothée Ravier**: [[Recap, Vulnerabilities, Attacks and Discussions on the graphic Stack's Security|Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier]] | **Jess van Derwalker**: [[XCWM, the X Composite Window Manager library and XtoQ, an OS X Window Manager|Events/XDC2012/XDC2012AbstractJessVanDerwalker]] | **Rob Clark**: [[DRI2Video|Events/XDC2012/XDC2012AbstractRobClark-Video]]
+ 11:30 | **Maarten Lankhorst**: [[Optimus support|Events/XDC2012/XDC2012AbstractMaartenLankhorst]]
+ 12:00 | **Alan Coopersmith**: [[X server privilege model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable|Events/XDC2012/XDC2012AbstractAlanCoopersmith]] | **Bart Massey**: [[Programming languages for X Application Development|Events/XDC2012/XDC2012AbstractBartMassey]] | ** Kristian Hoegsberg,Martin Peres,Timothée Ravier, Daniel Vetter**: [[DRM2|Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter]]
+ 12:30 | _Lunch_ | _Lunch_ | _Lunch_
+ 14:00 | **Michael Larabel**: [[Benchmarking, Request for Phoronix Benchmarks / graphics Tests, Feedback or Flames|Events/XDC2012/XDC2012AbstractMichaelLarabel]] | **Kristian Hoegsberg**: [[Wayland/Weston Status/Overview|Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland]] | **Supreet Pal Singh**: [[EVOC Experience and Project "Nouveau - Software scripting Engine for Fermi Architecture based GPUs"|Events/XDC2012/XDC2012AbstractSupreetPalSingh]]
+ 14:30 | **Oliver Mc****Fadden**: [[Dante: Doom3 GPLv3+; Teaching an old Engine new Tricks, Community building, Performance on embedded Hardware|Events/XDC2012/XDC2012AbstractOliverMcFadden]] | **Lucas Stach**: [[A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general)|Events/XDC2012/XDC2012AbstractLucasStach-Tegra]]
+ 15:00 | **Keith Packard, Eric Anholt**: [[DRI3|Events/XDC2012/XDC2012AbstractPackard+Anholt]] | - | **Chad Versace**: [[A quick Look at Waffle, deferring Choice of GLX, X11/EGL, Wayland/EGL, its use for testing Mesa|Events/XDC2012/XDC2012AbstractChadVersace]]
+ 15:30 | _Break_ | _Break_ | _Break_
+ 16:00 | **Members of the Board**: [[X.org Board Meeting|BoardOfDirectors/IrcLogs]] | **Kristian Hoegsberg**: [[Composite based rootless X server. How does it work? How do we get it upstream?|Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX]] | **Ian Romanick**: [[Discuss the future of EGL, GLX, and OpenGL ES on Linux|Events/XDC2012/XDC2012AbstractIanRomanick]]
+ 16:30 | **Blaž Tomažič**: [[OpenCL Testing Framework for Piglit. Project Overview and future Plans|Events/XDC2012/XDC2012AbstractBlažTomažič]]
+ 17:00 | - | <del>**Mario Kleiner**: [[How Neuro-Scientists Use the Open Source Graphics Stack: some Examples|Events/XDC2012/XDC2012AbstractMarioKleiner]]</del> | -
+ 17:30 | - | - | -
+ 19:00 | - | Evening event, meet at 19:00 at Schoener Brunnen: [[picture of meeting point|http://commons.wikimedia.org/wiki/File:Nuernberg-schoener-Brunnen-gp.jpg]], [[Google map of route from conference venue to meeting point|https://maps.google.com/maps?saddr=maxfeldst,+nuernberg&daddr=Unknown+road&hl=en&ll=49.45892,11.086922&spn=0.015342,0.052314&sll=49.453888,11.078591&sspn=0.001918,0.006539&geocode=FbTG8gIdRzepACldcIiowFefRzHhDivEyJXe3Q%3BFVmc8gIdZAWpAA&dirflg=w&mra=dme&mrsp=1&sz=18&t=m&z=15]]; | -
+"""]]
+
+
+## Topics
+
+As usual, we are open to talks across the layers of the graphics stack, from the kernel to applications, and about how we make things better for the developers who build them. If you're not sure if something might fit, mail or add it anyway, and find out if there's room in the schedule.
+
+
+## Ideas
+
+* [[XorgFoundation|XorgFoundation]] status update, [[BookSprint|Events/BookSprint2012]] results : [[BoardOfDirectors|BoardOfDirectors]]
+* Return of experience on the EVoC : How to better prepare the students : [[MartinPeres|MartinPeres]]
+* Recap, vulnerabilities, attacks and discussions on the graphic stack's security : [[MartinPeres|MartinPeres]], Timothée Ravier
+* X server privilege model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable: [[AlanCoopersmith|AlanCoopersmith]]
+* 15 minute talk about development state and features of the joystick input module : Sascha Hlusiak
+* X server integration testing. Yes, it's possible: [[PeterHutterer|PeterHutterer]]
+* Discuss the future of EGL, GLX, and OpenGL ES on Linux.
+* Wayland/Weston status/overview.
+* xwayland: Composite based rootless X server. How does it work? How do we get it upstream?
+* Optimus support : [[MaartenLankhorst|MaartenLankhorst]] / danvet (maybe?)
+* A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general): Lucas Stach
+* Discussing approaches for hardware independent accelerated graphics drivers : Lucas Stach
+* New i915 modeset infrastructure code. My blog post about it caught the wrath of some *bsd guys so some explaining might be in order: Daniel Vetter
+* Dante: Doom3 GPLv3+ (OpenGL 1.x, GLX) through to Dante (OpenGL ES2.0, EGL, GLSL); Teaching an old engine new tricks, building a ad-hoc community, and the struggle for performance on embedded hardware. : [[OliverMcFadden|OliverMcFadden]]
+ * Overlap with "Discuss the future of EGL, GLX, and OpenGL ES on Linux."?
+* A quick look [15min] at [[Waffle|http://people.freedesktop.org/~chadversary/waffle]], a library that allows one to defer choice of GLX, X11/EGL, Wayland/EGL until runtime, and how it is used for testing Mesa. : Chad Versace
+* Benchmarking, request for Phoronix benchmarks / graphics tests, feedback or flames, etc : Michael Larabel
+* drm/kms atomic-modeset / nuclear-pageflip : [[RobClark|RobClark]]
+* Programming languages for X application development : Bart Massey
+* EVOC experience and project[Nouveau - Software scripting engine for Fermi architecture based GPUs] : [[SupreetPalSingh|SupreetPalSingh]]
+* xcwm and XtoQ, a library for X compositing window managers and a proof of concept OS X window manager that uses it. Project overview and status : [[JessVanDerwalker|JessVanDerwalker]]
+* OpenCL testing framework for Piglit. Project overview and future plans (15 min): Blaž Tomažič
+* "Special needs": Some example uses of computer graphics in neuro-science and our wishlist for the ideal graphics stack: Mario Kleiner \ No newline at end of file
diff --git a/Events/XDC2012/PublicTransportation.mdwn b/Events/XDC2012/PublicTransportation.mdwn
new file mode 100644
index 00000000..e2f02bb6
--- /dev/null
+++ b/Events/XDC2012/PublicTransportation.mdwn
@@ -0,0 +1,21 @@
+
+
+# Some Hints on Public Transportation for XDC2012
+
+
+## Local Destinatons
+
+The conference venue and hotel can be reached easily
+
+* from the **airport**: Take subway line 2 (destination Roethenbach), change at Rathenauplatz to line 3 (destination Friedrich-Ebert Platz).
+* from the **main railroad station**: Take suway line 3 (destination Friedrich-Ebert Platz).
+Get off:
+
+* for the **conference venue** at Maxfeld and walk 350 meters to the [[building|http://maps.google.de/maps?saddr=Goethestra%C3%9Fe&daddr=Maxfeldstra%C3%9Fe+5,+90409+N%C3%BCrnberg&hl=de&ie=UTF8&ll=49.462616,11.085505&spn=0.001782,0.004265&sll=49.462856,11.085752&sspn=0.001782,0.004265&geocode=FTvA8gIdfCWpAA%3BFae18gIdRx6pACl_i-ksulefRzFD1xgwc0v1Kg&dirflg=w&mra=mift&mrsp=0&sz=18&t=m&z=18]]
+* for the **conference hotel** at Kaulbachplatz and walk 270 meters to the [[hotel|http://maps.google.de/maps?saddr=Schweppermannstra%C3%9Fe&daddr=Kaulbachstra%C3%9Fe&hl=de&ie=UTF8&sll=49.461266,11.078108&sspn=0.001782,0.004265&geocode=FQTA8gIdcgepAA%3BFeS28gIdLwepAA&dirflg=w&mra=mift&mrsp=1&sz=18&t=m&z=18]].
+The announcements on the subways are made both in German and English.
+
+
+## Tickets
+
+You can buy single ride tickets, "Streifenkarten" for 5 rides and day passes at vending machines at every stop. The single ride tickets are presently EUR 2.40 and are valid for 90 minutes. You can change between subway (U-Bahn), Trams and buses as often as you want during this time. "Streifenkarten" cost EUR 9.70 for 5 rides. You need to fold back and stamp 2 strips per ride. These tickets are useful if several people are traveling together as you can put each one on a single ticket.
diff --git a/Events/XDC2012/Weekend.mdwn b/Events/XDC2012/Weekend.mdwn
new file mode 100644
index 00000000..1cbb6afc
--- /dev/null
+++ b/Events/XDC2012/Weekend.mdwn
@@ -0,0 +1,69 @@
+
+
+# XDC2012 Weekend Events
+
+<a name="saturday"></a>
+## Saturday: BierWanderung
+
+We are going to have a hiking trip to the Frankonian countryside on Saturday, Sept 22. On this trip you will have the opportunity to visit some local brewery beergardens and have a taste of a small selection from the numerous local beers.
+
+The trip itself will be an extended inverse 5 Seidla Steig: a well known tour around the city of Graefenberg.
+
+* We meet up at the Nord-Ost Bahnhof at 9:10. This station can be easily reached with subway line 2 'U2' or 'U21' going to the airport (Flughafen) or Ziegelstein. Please check [[the line map|http://www.vgn.de/liniennetze/schienennetz_nuernberg_furth/]]. We will meet on the platform of the train. To get there leave the subway station building towards the north, keep right, proceed further north until you cross the tracks, then turn right. There's a ticket vending machine on the platform.
+* At 9:30 the train will leave for Graefenberg where we will arrive at 10:11.
+* A bus will take us to Egloffstein at 10:20, and we will arrive there at 10:38.
+* We will then hike to Thuisbrunn. This is a steep treck with a few very interesting views in which we will cover about 3.5km and 250heightmeter. At the Elch-Brau brewery in Thuisbrunn we will have lunch, and can enjoy our first beer.
+* A short 1.5kms later, we are in Hohenschwaerz, where we will have a quick refreshment at the Hofmann brewerey.
+* Afterwards, we have a 5km mostly flat walk to Graefenberg where we will enjoy a Lindenbrau in the afternoon,
+* For the final part of our journey, we gratuitously walk up a hill again, so we can have another nice view of the valley and the Weissenhohe abbey on the way down (3km, 100heightmeter). Down at the brewery we will enjoy a hearty supper and some beer (they even sell Mass for the october fest frequenters), and then we can roll the last few meters back to the train.
+* At XX:40, a train will take us back to the Nuremberg Nord-Ost-Bahnhof. Last train out is at 23:40.
+The cost of this trip should be estimated by EUR 10 per meal (2x), EUR 3 per beer (4x + ...) and about EUR 8 for transportation (either 'Bayernticket' or 'Tagesticket plus'). Bring at least around EUR 50 in cash as the breweries probably are not equipped with card terminals, and beware, the ticket-vending machines tend to only take up to 20 euro bills. The preferred ticket is probably a tagesticket-plus, which costs 16.20EUR. This gives two people (when traveling together) the ability to travel through the whole VGN network on both Saturday and Sunday.
+
+While 4 breweries are visited, this tour is not just about beer. A total of close to 13km and 450heightmeters will be covered, so it is also going to be some taxing physical activity for the less well-trained among us. There are a few steep bits, but nothing dangerous or scary, and the way the route and schedule are planned means that the whole can be done leisurely. But if the sole goal is to simply consume alcohol, then please, stay in Nuremberg.
+
+An approximate map of the route is available at [[google maps|http://maps.google.de/maps?saddr=Talstra%C3%9Fe%2FST2260&daddr=49.6937682,11.2574561+to:49.6920439,11.2509813+to:49.68974,11.24964+to:49.684786,11.249122+to:49.6778521,11.2474872+to:49.677654,11.2523543+to:49.6654383,11.2600493+to:49.6554344,11.253826+to:49.650872,11.250426+to:49.6455589,11.2487438+to:49.639797,11.257334+to:49.6345251,11.255666+to:49.62971,11.25226+to:Bahnhofstra%C3%9Fe&hl=en&ie=UTF8&sll=49.694382,11.259356&sspn=0.007842,0.016887&geocode=Fa1k9gIdGdCrAA%3BFUhE9gIdcMarACk_SxboXO6hRzG1sSY3I6G2Xw%3BFYs99gIdJa2rACnlu3t9RO6hRzFtarXh5MERtw%3BFYw09gId6KerACn5CTxNRO6hRzGOE8r71g9Pvw%3BFTIh9gId4qWrACnXN3-tT-6hRzHhI2GbMtoeEw%3BFRwG9gIdf5-rACl9IDNUre-hRzExHWCbMtoeEw%3BFVYF9gIdgrKrAClZP_0gU-6hRzFxLWCbMtoeEw%3BFZ7V9QIdkdCrACkJhyB2CO-hRzGQjmGbMtoeEw%3BFYqu9QIdQrirACnpiaVUde-hRzFG1jvG-s5GzQ%3BFbic9QId-qqrACkfTITsne-hRzFWnjQ5WcnoFg%3BFfaH9QIdZ6SrAClZf6yugu-hRzGhVWybMtoeEw%3BFXVx9QId9sWrACmr3AiAfO-hRzGQY2ebMtoeEw%3BFd1c9QIdcr-rACk7Ms-ch-WhRzEJ_mUPoACwiA%3BFQ5K9QIdJLKrACk3BFYkhOWhRzGopwLoeXYkAw%3BFfhJ9QIdfKirAA&t=h&dirflg=w&mra=dpe&mrsp=1&sz=16&via=1,2,3,4,5,6,7,8,9,10,11,12,13&z=17]].
+
+When you are taking part in this activity, it is necessary that you add yourself to the below list before Thursday 20th 17:00 as we need to make reservations. Please also indicate if you will bring someone with you:
+
+1. [[MatthiasHopf|MatthiasHopf]] (+ company)
+1. [[StefanDirsch|StefanDirsch]]
+1. [[LucVerhaegen|LucVerhaegen]]
+1. [[EgbertEich|EgbertEich]]
+1. [[LucasStach|LucasStach]]
+1. [[MichaelLarabel|MichaelLarabel]]
+1. [[ArvindUmrao|ArvindUmrao]]
+1. [[MichelDaenzer|MichelDaenzer]]
+1. [[AlanCoopersmith|AlanCoopersmith]]
+1. [[SaschaHlusiak|SaschaHlusiak]] (+ company)
+1. [[BenBrewer|BenBrewer]]
+1. Supreet Pal Singh
+1. [[HaraldKoenig|HaraldKoenig]] (+ company??)
+1. [[JessVanDerwalker|JessVanDerwalker]]
+1. [[JoeBurmeister|JoeBurmeister]]
+1. [[SimonFarnsworth|SimonFarnsworth]]
+1. [[MarcBalmer|MarcBalmer]]
+1. [[VeraHardmeier|VeraHardmeier]]
+1. [[MaartenLankhorst|MaartenLankhorst]]
+1. Martin Peres
+1. [[RobClark|RobClark]]
+1. Timothée Ravier
+1. [[IanRomanick|IanRomanick]]
+1. [[KonstaKarsisto|KonstaKarsisto]]
+<a name="sunday"></a>
+## Sunday: Nazi Party Rally grounds
+
+On Sunday a trip to the [[Reichsparteitagsgelände|http://en.wikipedia.org/wiki/Nazi_party_rally_grounds]] is planned. This site is one of the most important historic sites of Europe, with a few Speer buildings in their typical megalomaniac style still standing. It includes [[a museum|http://www.museums.nuremberg.de/documentation-centre/index.html]] (Dokumentationszentrum) which provides an excellent overview of events leading up to the Holocaust, WWII and all the horrors involved. It is a must for anyone with any interest in the history of the last century, and an important lesson on a history worth preventing in future.
+
+On Sunday, Sept. 23:
+
+* At 10:00 we will meet at the tram-station in front of the main railway station. Bring your tagesticket-plus from the beerhike :)
+* We will then ride the 10:27 No. 9 tram all the way to the 'Dokuzentrum', where we will arrive about 10 minutes later.
+* A walk around the grounds and a visit to its most marked landmarks will lead us to the "Gutmann am Dutzenteich" beergarten for lunch.
+* After lunch the documentation center will be visited to take the 2-3h tour around the permanent exhibit called "Fascination and Terror".
+Entrance to the Museum is EUR 5, which includes an audio-guide in various languages.
+
+1. [[LucVerhaegen|LucVerhaegen]]
+1. [[EgbertEich|EgbertEich]]
+1. [[MatthiasHopf|MatthiasHopf]]
+1. [[HaraldKoenig|HaraldKoenig]]
+1. Martin Peres \ No newline at end of file
diff --git a/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn b/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn
new file mode 100644
index 00000000..64c2a5e0
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn
@@ -0,0 +1,10 @@
+
+
+### X server Privilege Model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable.
+
+
+### Alan Coopersmith
+
+Solaris includes Xorg built with patches that drop root privileges after startup, relying on the kernel to handle input device access for hotplugging & vt switching, and utilizing patches to gdm to pass information to Xorg on authenticated users. This talk will go over some of the details and open a discussion on what should be upstreamed.
+
+[[video|http://www.youtube.com/watch?v=hphjH2KYGAw&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractBartMassey.mdwn b/Events/XDC2012/XDC2012AbstractBartMassey.mdwn
new file mode 100644
index 00000000..97217a93
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractBartMassey.mdwn
@@ -0,0 +1,10 @@
+
+
+### Programming languages for X Application Development
+
+
+### 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.
+
+[[video part 1|http://www.youtube.com/watch?v=3BgQU82yG5s&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] [[video part 2|http://www.youtube.com/watch?v=WaAkkmi1ybA&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn b/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn
new file mode 100644
index 00000000..ce8a7b81
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn
@@ -0,0 +1,10 @@
+
+
+### OpenCL Testing Framework for Piglit. Project Overview and future Plans
+
+
+### 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.
+
+[[slides|XDC2012-OpenCL-2.pdf]] [[video|http://www.youtube.com/watch?v=J7xQn_KuPrQ&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf
new file mode 100644
index 00000000..522b9d65
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf
new file mode 100644
index 00000000..1f8a017d
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractChadVersace.mdwn b/Events/XDC2012/XDC2012AbstractChadVersace.mdwn
new file mode 100644
index 00000000..28b15bec
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractChadVersace.mdwn
@@ -0,0 +1,16 @@
+
+
+### A quick Look at Waffle, a Llbrary that allows one to defer choice of GLX, X11/EGL, Wayland/EGL until Runtime, and how it is used for testing Mesa
+
+
+### 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.
+
+[[http://people.freedesktop.org/~chadversary/waffle|http://people.freedesktop.org/~chadversary/waffle]]
+
+[[slides|http://people.freedesktop.org/~chadversary/waffle/files/talks/2012.09.21-xdc/notes.txt]] [[video|http://www.youtube.com/watch?v=BdLEn6lji-U&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn b/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn
new file mode 100644
index 00000000..6bb1ed11
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn
@@ -0,0 +1,12 @@
+
+
+### New i915 modeset infrastructure Code
+
+
+### 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.
+
+[[video|http://www.youtube.com/watch?v=ayP6bw6EBPo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn
new file mode 100644
index 00000000..cdde429e
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn
@@ -0,0 +1,10 @@
+
+
+### DRM2 : Let's fix the DRM authentication policy and buffer sharing
+
+
+### Kristian Høgsberg, MartinPeres, Timothée Ravier & 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.
+
+[[slides|drm2_xdc2012.pdf]] [[video|http://www.youtube.com/watch?v=4fRXNHAjMIY&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf
new file mode 100644
index 00000000..987f2462
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn b/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn
new file mode 100644
index 00000000..2fd6a518
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn
@@ -0,0 +1,10 @@
+
+
+### Discuss the future of EGL, GLX, and OpenGL ES on Linux
+
+
+### 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.
+
+[[video|http://www.youtube.com/watch?v=LesAb4sTXgA&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn b/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn
new file mode 100644
index 00000000..1e704a74
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn
@@ -0,0 +1,16 @@
+
+
+### XCWM, the X Composite Window Manager library and XtoQ, an OS X Window Manager that uses it: Overview and Project Status
+
+
+### Jess VanDerwalker
+
+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.
+
+[[slides|xdc2012_xcwm_presentation.pdf]] [[video|http://www.youtube.com/watch?v=XC3Y63PhcR4&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf b/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf
new file mode 100644
index 00000000..37a289fb
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractKickOff.mdwn b/Events/XDC2012/XDC2012AbstractKickOff.mdwn
new file mode 100644
index 00000000..feb9ebc4
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractKickOff.mdwn
@@ -0,0 +1,5 @@
+
+
+### XorgFoundation Status Update, Book Sprint Results, EVoC Results
+
+[[video|http://www.youtube.com/watch?v=tiNU_zyDUJo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn
new file mode 100644
index 00000000..23a2b5e4
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn
@@ -0,0 +1,8 @@
+
+
+### Composite based rootless X server. How does it work? How do we get it upstream?
+
+
+### Kristian Høgsberg
+
+[[video|http://www.youtube.com/watch?v=Y9VYvAevjiU&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn
new file mode 100644
index 00000000..51d68e0c
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn
@@ -0,0 +1,8 @@
+
+
+### Wayland/Weston Status/Overview
+
+
+### Kristian Høgsberg
+
+[[video|http://www.youtube.com/watch?v=L8zwnqKysfI&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn b/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn
new file mode 100644
index 00000000..9c223659
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn
@@ -0,0 +1,8 @@
+
+
+### Discussing approaches for hardware independent accelerated graphics drivers
+
+
+### Lucas Stach
+
+[[video|http://www.youtube.com/watch?v=Qc5dFnBCHas&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn b/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn
new file mode 100644
index 00000000..5c20890c
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn
@@ -0,0 +1,8 @@
+
+
+### A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general)
+
+
+### LucasStach
+
+[[video|http://www.youtube.com/watch?v=KbMOQ5rit54&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn b/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn
new file mode 100644
index 00000000..2cf283cb
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn
@@ -0,0 +1,8 @@
+
+
+### Optimus support
+
+
+### MaartenLankhorst
+
+[[video|http://www.youtube.com/watch?v=CQ1-Myt3coY&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn b/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn
new file mode 100644
index 00000000..dea5136a
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn
@@ -0,0 +1,8 @@
+
+
+### How Neuro-Scientists Use the Open Source Graphics Stack: some Examples
+
+
+### Mario Kleiner
+
+This talk gives some examples on how neuro-scientists / brain-researchers use computer-graphics for conducting experiments on human perception and cognition, and what kind of sometimes slightly special requirements this imposes on the graphics stack in terms of features, robustness, accuracy and control and what the pain points and wishes of the developers and users of such research software are. Basically we will talk about how one can make live better (or worse) for developers/users of such research software.
diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn
new file mode 100644
index 00000000..5484ca90
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn
@@ -0,0 +1,10 @@
+
+
+### Recap, Vulnerabilities, Attacks and Discussions on the graphic Stack's Security
+
+
+### MartinPeres, 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.
+
+[[slides|secu_xdc2012.pdf]], [[video|http://www.youtube.com/watch?v=hJpiJii44oo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]], [[LWN coverage|https://lwn.net/Articles/517375/]]
diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf
new file mode 100644
index 00000000..be0bf376
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn b/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn
new file mode 100644
index 00000000..e5fa2660
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn
@@ -0,0 +1,10 @@
+
+
+### Return of experience on the EVoC : How to better prepare the Students
+
+
+### Martin Peres
+
+With the X.org foundation not participating to the GSoC program, we have seen many students apply to the X.org equivalent of the GSoC, the Endless Vacation of Code (EVoC).
+
+[[slides|evoc.pdf]] [[video|http://www.youtube.com/watch?v=kOgh2EpKfSo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf b/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf
new file mode 100644
index 00000000..d9b3a178
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn b/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn
new file mode 100644
index 00000000..25f2f0b3
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn
@@ -0,0 +1,8 @@
+
+
+### Benchmarking, Request for Phoronix Benchmarks / graphics Tests, Feedback or Flames
+
+
+### MichaelLarabel
+
+[[slides|michaellarabel-xdc2012.pdf]]
diff --git a/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf b/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf
new file mode 100644
index 00000000..280b0ee0
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn b/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn
new file mode 100644
index 00000000..a22cfb81
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn
@@ -0,0 +1,10 @@
+
+
+### Dante: Doom3 GPLv3+ (OpenGL 1.x, GLX) through to Dante (OpenGL ES2.0, EGL, GLSL); Teaching an old Engine new Tricks, building a ad-hoc Community, and the struggle for Performance on embedded Hardware
+
+
+### Oliver McFadden
+
+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.
+
+[[slides|Dante.pdf]] [[video|http://www.youtube.com/watch?v=PYGeXko_xf0&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf b/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf
new file mode 100644
index 00000000..d89cd30b
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn b/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn
new file mode 100644
index 00000000..56e2a73e
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn
@@ -0,0 +1,8 @@
+
+
+### DRI3
+
+
+### Keith Packard, Eric Anholt
+
+[[video|http://www.youtube.com/watch?v=ZLnl6s60YL8&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn b/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn
new file mode 100644
index 00000000..a1c94771
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn
@@ -0,0 +1,14 @@
+
+
+### X Server Integration Testing. Yes, it's possible
+
+
+### Peter Hutterer
+
+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.
+
+[[Slides|xorg-integration-testing.pdf]] [[Video|http://www.youtube.com/watch?v=dZTz151SJLw&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
+
+See [[http://who-t.blogspot.de/2012/08/xorg-integration-test-suite.html|http://who-t.blogspot.de/2012/08/xorg-integration-test-suite.html]] for more info and (links to) examples
diff --git a/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf b/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf
new file mode 100644
index 00000000..283fdd05
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn b/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn
new file mode 100644
index 00000000..53fcc453
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn
@@ -0,0 +1,8 @@
+
+
+### DRM/KMS Atomic-Modeset / Nuclear-Pageflip
+
+
+### Rob Clark
+
+[[slides|xdc2012-atomic-pagefilp.pdf]] [[video|http://www.youtube.com/watch?v=Hg-NLICrDB8&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf b/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf
new file mode 100644
index 00000000..e2bf0a8f
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn b/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn
new file mode 100644
index 00000000..92d14805
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn
@@ -0,0 +1,8 @@
+
+
+### DRI2 Video
+
+
+### Rob Clark
+
+[[slides|xdc2012-dri2video.pdf]] [[video|http://www.youtube.com/watch?v=nwpy2PNb_MQ&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf b/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf
new file mode 100644
index 00000000..5483d340
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn b/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn
new file mode 100644
index 00000000..c733b629
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn
@@ -0,0 +1,12 @@
+
+
+### Development State and Features of the Joystick Input Module
+
+
+### 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.
+
+Slides: [[xf86-input-joystick.pdf|xf86-input-joystick.pdf]]
+
+Presentation: [[http://www.youtu.be/Ul2em93dpX4|http://www.youtu.be/Ul2em93dpX4]]
diff --git a/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf b/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf
new file mode 100644
index 00000000..c25fb82c
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf
Binary files differ
diff --git a/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn b/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn
new file mode 100644
index 00000000..ae61de59
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn
@@ -0,0 +1,10 @@
+
+
+### EVOC Experience and Project 'Nouveau - Software scripting Engine for Fermi Architecture based GPUs'
+
+
+### Supreet Pal Singh
+
+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.
+
+[[slides|XDC 2012 Talk.pdf]] [[video|http://www.youtube.com/watch?v=n41aYIPTiiU&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]]
diff --git a/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf b/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf
new file mode 100644
index 00000000..bdd6e1ac
--- /dev/null
+++ b/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf
Binary files differ
diff --git a/Events/XDC2013.mdwn b/Events/XDC2013.mdwn
new file mode 100644
index 00000000..bbfbb953
--- /dev/null
+++ b/Events/XDC2013.mdwn
@@ -0,0 +1,87 @@
+
+
+# XDC2013: Portland, Oregon, USA
+[[!table header="no" class="mointable" data="""
+[[<< XDC 2012|Events/XDC2012]] | **XDC 2013** | XDC 2014
+"""]]
+
+* [[Attendees|Events/XDC2013/Attendees]]
+* [[Program|Events/XDC2013/Program]]
+* [[Proceedings and Recorded Videos|Events/XDC2013/Proceedings]]
+The 2013 X.Org Developer Conference (XDC2013) is to be held from September 23rd thru 25th 2013 in Portland, Oregon, USA. The event will be held at the University Place conference center adjacent to the Portland State University campus.
+
+
+## Venue
+
+The conference will be held at the University Place Conference Center.
+
+
+## Program
+
+There are two ways to submit a presentation for this event:
+
+1. There is a [[Call for Proposals|Events/XDC2013/CallForProposals]]. The deadline for submission is August, 1, 2013.
+1. For more informal presentations you may add your talk to the [[program page|Events/XDC2013/Program]]. The deadline for submission here is September 22, 2013.
+A schedule will be available shortly before the conference.
+
+
+## Videos
+
+Recorded videos of the session will be available from [[YouTube|YouTube]].
+
+
+## Registration
+
+If you want to attend XDC2013 please add your name to the [[attendees page|Events/XDC2013/Attendees]]. Additionally please subscribe to the [[X.org events mailing list|http://lists.x.org/mailman/listinfo/events]] where we will post regular updates.
+
+
+## Accommodation
+
+There are a number of affordable hotels in Portland (especially since we painstakingly avoided any week with a major trade show), many close to the conference venue.
+
+We have arranged a special room rate at Univeristy Place, the conference venue.
+
+
+## Travel
+
+The Portland Airport is close to the city and can be reached by local transportation in about 40 minutes. There are flights from Amsterdam and Tokyo, as well as many cities within the US.
+
+
+## Local transportation
+
+Portland has an reasonable public transportation system: Most major locations in Portland can easily be reached by public transportation.
+
+Tickets are available from vending machines at any rail stop or aboard any bus (see also our hints on using public transportation). The conference venue and hotel can be reached on the Max Yellow line.
+
+
+## Local Dining
+
+The conference venue is at the southern edge of the downtown area. There are many restaurants and food carts close-by as well as north towards the city center. Feel free to ask for recommendations on site.
+
+
+## Remote Participation
+
+For those who cannot make it to the conference we are planning to record the sessions. We may even have a live stream, also participation via IRC should be available.
+
+
+## Travel Sponsoring
+
+If you are not on a corporate budget but have something to present, please contact the X.Org Foundation Board of Directors [[board@foundation.x.org]] for travel sponsorship.
+
+
+## Further Inquiries
+
+If you have any questions regarding the event please feel free to contact me at [[keithp@keithp.com]].
+
+
+## Thanks
+
+The organizers want to thank:
+
+* 'Phoronix' for the beer.
+Our Helpers
+
+* Bart Massey for organizing the venue
+* Ian Romanick for organizing the paper committee
+
+## Links
diff --git a/Events/XDC2013/Attendees.mdwn b/Events/XDC2013/Attendees.mdwn
new file mode 100644
index 00000000..ce5dcaea
--- /dev/null
+++ b/Events/XDC2013/Attendees.mdwn
@@ -0,0 +1,10 @@
+
+
+## XDC2013 Attendees
+
+(please leave this in alphabetical order by surname)
+
+* [[Alan Coopersmith|AlanCoopersmith]]
+* Keith Packard
+* [[Daniel Stone|DanielStone]]
+* Tom Stellard \ No newline at end of file
diff --git a/Events/XDC2013/CallForProposals.mdwn b/Events/XDC2013/CallForProposals.mdwn
new file mode 100644
index 00000000..66fd2909
--- /dev/null
+++ b/Events/XDC2013/CallForProposals.mdwn
@@ -0,0 +1,23 @@
+
+
+# Call For Proposals
+
+**2013 X.Org Developers Conference (XDC 2013)**
+ **23-25 September 2013**
+ **Portland, Oregon USA**
+
+The [[2013 X.Org Developers Conference|Events/XDC2013]] is the annual technical meeting for [[X Window System|http://x.org]] and [[Free Desktop|http://freedesktop.org]] developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public.
+
+The XDC 2013 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2013. While any serious proposal will be gratefully considered, topics of interest to [[X.org|http://x.org]] and [[FreeDesktop.org|http://freedesktop.org]] developers are encouraged. There are three particular types of proposal the TPC is seeking:
+
+ 1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2013. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc.
+ 1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2013, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance.
+ 1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2013, available on a print-on-demand basis online.
+XDC 2013 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC).
+
+Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion.
+
+**Proposals due:** Thursday 1 August 2013 17:00 UTC
+ **Accepted formats:** PDF and ASCII text.
+ **Notification of acceptance:** Thursday 8 August 2013
+ **E-mail:** board at foundation.x.org
diff --git a/Events/XDS2007.mdwn b/Events/XDS2007.mdwn
new file mode 100644
index 00000000..207c3c6c
--- /dev/null
+++ b/Events/XDS2007.mdwn
@@ -0,0 +1,54 @@
+
+
+# XDS 2007
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2007|Events/XDC2007]] | **XDS 2007** | [[XDC 2008 >>|Events/XDC2008]]
+"""]]
+
+The X Developers' Summit for 2007 was held at [[Clare College|http://www.clare.cam.ac.uk]], [[Cambridge|http://wikitravel.org/en/Cambridge_(England)]], UK (not the one near Boston), from the 10th-12th September.
+
+* [[Attendees|Events/XDS2007/Attendees]]
+* [[Program|Events/XDS2007/Program]]
+* [[Notes from the talks|Events/XDS2007/Notes]]
+We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities.
+
+Attendance is free, but you must register beforehand, by putting your name on the Attendees page.
+
+
+## Accommodation
+
+Accommodation has been arranged through Clare College for around £70 per night, please take advantage of this if possible to help defray the costs of the meeting. The rooms are single rooms with a private ensuite (i.e. own bathroom and toilet). Currently, everyone who has listed themselves on the attendees page without 'non-college accommodation' next to their name is assumed to be staying in the college. We'll have a system set up for you to provide your details and payment shortly. The rooms will have wireless internet access.
+
+The rooms are available for checkin on Sunday afternoon (the 9th, at 2pm), and checkout on Thursday morning (the 13th, at 9:30pm). Luggage storage will be available.
+
+
+## Travel
+
+Cambridge is located closest to London Stansted airport (STN), a major hub for low-cost carriers, but is also reachable from London Heathrow (LHR) via train (approximate travel time: two, to two and a half, hours). More travel information is available from Wikitravel. Clare College itself is accessible from Cambridge railway station.
+
+* From Stansted, there's an hourly train service from underneath the airport, to Cambridge, and a bus during the night/early morning.
+* From Heathrow, you have a few choices:
+ * Take the tube (Underground, any Picadilly line train) direct to Kings Cross (~75m, ~£6), or the Heathrow Express to Paddington (~15m, £13) and then the tube (Underground, Hammersmith & City or Circle line) to Kings Cross (~20m, ~£2). Once at Kings Cross:
+ * Saturday & Sunday: Take a mainline train service from Kings Cross to Peterborough, changing at Stevenage for a bus service to Cambridge (~2h, ~£15); the train is unavailable due to engineering works.
+ * Monday-Friday: Take a mainline train service from Kings Cross to Cambridge (~45m, ~£15).
+ * Take a National Express bus directly from Heathrow to Cambridge (~2-3h, ~£25.50).
+* From Gatwick, take the Gatwick Express (~30m, £15) to Victoria, then the tube (Victoria line, going north, ~20m, ~£4) to Kings Cross. See above for how to get from Kings Cross to Cambridge.
+* From Luton, a bus runs straight from Luton airport (~90m, £14) to Cambridge bus station.
+* From Paris/Belgium/Netherlands/Köln: Eurostar (~2h15/2h30) to Waterloo, then the tube (Northern line going north, changing to either Picadilly or Victoria lines, ~30m, ~£4) to Kings Cross, and see above for how to get from Kings Cross to Cambridge. You get power sockets, GSM reception, and less hassle than the plane.
+For train times, please see nationalrail.co.uk, and nationalexpress.com for bus times. Nationalrail has a [[Printable Pocket Timetable|http://ojp1.nationalrail.co.uk/en/pj/jp]] that seems quite useful.
+
+You should probably plan to arrive on Sunday night, and leave late Wednesday night or early Thursday morning, as there is a (free for attendees) four-course dinner at the college on Wednesday night. The conference itself will run from roughly 9am to 6pm during the three days. We're also planning some optional social activities for the nights: Cambridge, however, has a stupendous number of pubs, and a great many restaurants, cafés, and other places to hang out (all non-smoking now).
+
+
+## Registration, talks
+
+If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xds2007]] for updates. Also, please add your name to the [[Attendees|Events/XDS2007/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2007/Program]] pagee.
+
+
+## Links
+
+* [[Clare College|http://maps.google.com/maps?f=q&hl=en&geocode=&q=trinity+lane,+cambridge,+uk&sll=52.202544,0.131236&sspn=0.085007,0.233459&ie=UTF8&ll=52.207686,0.116258&spn=0.010625,0.029182&t=h&z=15&iwloc=addr&om=1]] map
+* [[Clare College information|http://www.clare.cam.ac.uk]]
+* [[Cambridge travel information|http://wikitravel.org/en/Cambridge_(England)]] from Wikitravel
+* [[Cambridge information|http://en.wikipedia.org/wiki/Cambridge]] from Wikipedia
+* [[UK Train Times|http://www.traintimes.org.uk]] \ No newline at end of file
diff --git a/Events/XDS2007/Attendees.mdwn b/Events/XDS2007/Attendees.mdwn
new file mode 100644
index 00000000..874a5363
--- /dev/null
+++ b/Events/XDS2007/Attendees.mdwn
@@ -0,0 +1,59 @@
+
+
+# XDS2007 Attendees
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xds2007]] if you are planning to attend [[XDS2007|Events/XDS2007]]. THERE ARE NO MORE PLACES LEFT FOR XDS. Sorry!
+
+If you do _not_ plan to use the college accommodation, please note this next to your name.
+
+1. [[DavidAirlie|DavidAirlie]]
+1. [[MatthewAllum|MatthewAllum]]
+1. [[DanAmelang|DanAmelang]]
+1. [[EricAnholt|EricAnholt]]
+1. [[MarcBalmer|MarcBalmer]]
+1. [[JesseBarnes|JesseBarnes]]
+1. [[JakobBornecrantz|JakobBornecrantz]]
+1. [[RobBradford|RobBradford]]
+1. [[JohnBridgman|JohnBridgman]]
+1. [[MichelDaenzer|MichelDaenzer]]
+1. [[AlexDeucher|AlexDeucher]]
+1. [[JimGettys|JimGettys]]
+1. [[BriceGoglin|BriceGoglin]]
+1. [[JeromeGlisse|JeromeGlisse]]
+1. [[BryceHarrington|BryceHarrington]]
+1. [[ThomasHellstrom|ThomasHellstrom]]
+1. [[MatthieuHerrb|MatthieuHerrb]]
+1. [[AlanHourihane|AlanHourihane]]
+1. [[KristianHøgsberg|KristianHøgsberg]]
+1. [[ZephaniahHull|ZephaniahHull]]
+1. [[PeterHutterer|PeterHutterer]]
+1. [[AdamJackson|AdamJackson]]
+1. [[StuartKreitman|StuartKreitman]]
+1. [[StephaneMarchesin|StephaneMarchesin]]
+1. [[BartMassey|BartMassey]]
+1. [[KeithPackard|KeithPackard]]
+1. [[VedranRodic|VedranRodic]]
+1. [[ZackRusin|ZackRusin]]
+1. [[RolandScheidegger|RolandScheidegger]]
+1. [[DodjiSeketeli|DodjiSeketeli]]
+1. [[DanielStone|DanielStone]]
+1. [[MatthewTippett|MatthewTippett]]
+1. [[TiagoVignatti|TiagoVignatti]]
+1. [[ZhenyuWang|ZhenyuWang]]
+1. [[KeithWhitwell|KeithWhitwell]]
+1. [[CarlWorth|CarlWorth]]
+1. [[PauloZanoni|PauloZanoni]]
+1. [[ZouNanhai|ZouNanhai]]
+1. [[EamonWalsh|EamonWalsh]]
+1. [[BenSkeggs|BenSkeggs]] (tentative)
+1. [[MichaelDales|MichaelDales]] (non-college accomodation)
+1. [[EgbertEich|EgbertEich]] (non-college accommodation)
+1. [[MatthewGarrett|MatthewGarrett]] (no college accommodation)
+1. [[MarcusGranado|MarcusGranado]] (non-college accommodation)
+1. [[ThomasHunger|ThomasHunger]] (non-college accomodation)
+1. [[DaveJones|DaveJones]] (non-college accommodation)
+1. [[KyleMcMartin|KyleMcMartin]] (non-college accommodation)
+1. [[DavidReveman|DavidReveman]] (non-college accommodation)
+1. [[PaulSladen|PaulSladen]] (non-college accomodation)
+1. [[LucVerhaegen|LucVerhaegen]] (non-college accommodation)
+There are only 50 spots: this is a hard limit!
diff --git a/Events/XDS2007/ModeSettingBoF.mdwn b/Events/XDS2007/ModeSettingBoF.mdwn
new file mode 100644
index 00000000..ea6f6a8c
--- /dev/null
+++ b/Events/XDS2007/ModeSettingBoF.mdwn
@@ -0,0 +1,46 @@
+
+This page is to get a preliminary idea of what people want to discuss at the modesetting BOF at XDS.
+
+The BOF will mostly be concerned with the push to add modesetting to kernel space on Linux platforms, which is useful for suspend/resume and also for smooth GUI bootup.
+
+[[DavidAirlie|DavidAirlie]]: 1. Bash out the correct API level, at the moment modesetting-101 possibly does too much in-kernel. 2. Add a control drm device node that is persistent. 3. Userspace daemon vs none.
+
+
+
+---
+
+
+
+* [[JakobBornecrantz|JakobBornecrantz]]: 1. Persistent- vs dynamic memory allocation for scanout buffers.
+
+
+---
+
+
+
+* [[SylvainBertrand|SylvainBertrand]]: 1. suspend/resume/power management kernel interfaces to implement are specific to each driver model. Creating a DRM interface which would suit all driver models may not be reasonable. Another approach would be to have driver model specific code (with all the suspend/resume/power management kernel interfaces implementations) and a perfectly orthogonal DRM interface (As far as I understood current DRM, it provides almost a full blown driver model abstraction layer, I may be wrong though). The mode setting interface would be part of the "perfectly orthogonal DRM interface". 2. What's up with ACPI model (see ACPIspec30a.pdf pages 591&592)?
+
+
+---
+
+
+
+* [[JesseBarnes|JesseBarnes]]: my main concern is the current fb layer. The current code & design duplicates a lot of fb functionality (getting mode lists, setting modes, exporting interfaces to userland). How much duplication is acceptable? Should we extend the fb APIs or accept the duplication? Should fb be obsoleted entirely by this new code? Should we share code? If the answer to the last question is no, I think we can expect a lot of pushback from the fb and broader kernel community...
+
+
+---
+
+
+
+* [[JeromeGlisse|JeromeGlisse]]:
+1. Do we want to emulate framebuffer in kernel ? The scanout buffer format might be a little bit complicated to handle in kernel (stride, tiles, ...) and we may want to avoid to put such knowledge in the kernel. Then how kernel can tell you when anythings when it panics (asking for the modesetting to provide a failsafe and easy to use mode might help but also might not work in all case). This was already discussed a bit on IRC and mail.
+
+2. IOCTL versioning versus tag based arguments. Maybe it's good to think now to possible interface change rather than find out in couple of month, years that changing the interface is painfull (as it is now).
+
+3. For power management i would like to see the kernel exporting each hw capacity through somethings like HAL so we can then use some project like ohm which i believe is aimed to centralize all this power things. But i don't think this really fit modesetting topic and likely we could already work on this without drastic change in drm.
+
+
+
+---
+
+
diff --git a/Events/XDS2007/Notes.mdwn b/Events/XDS2007/Notes.mdwn
new file mode 100644
index 00000000..44ee6f7d
--- /dev/null
+++ b/Events/XDS2007/Notes.mdwn
@@ -0,0 +1,421 @@
+
+Various notes from XDS2007 presentations. Please fill this out with links to slides, project pages, etc.
+
+[[!toc ]]
+
+
+# Day One
+
+
+## John Bridgman, Matthew Tippet - AMD/ATI
+
+* NDA-less 2D specs coming soon, 3D specs coming later, r300 3D specs coming even later
+* Dedicated developer support team too
+* Modesetting to use ATOM BIOS for some things: set of data tables, and interpreted code, which means you can do native POST on any architecture. Windows driver and BIOS already using this, so it's very capable (not another VESA).
+* Legal issues regarding HDCP and DRM video decoding, which means those parts become harder.
+* AMD using the doc release process to improve internal documentation quality too
+
+## Dave Airlie - Red Hat X.Org work
+
+* Fedora 9 in May/June of 2008
+* Composite needs to be on by default. What needs to be fixed for that?
+* GLX needs to obey window redirection
+* Likewise for Xv
+* 2D acceleration should work, hardware accel all the way through rendering
+* Need a proper memory manager to tie all these things together
+* krh has been working on redirected GL
+* airlied working on getting TTM mergeable into the kernel
+* cworth been optimising intel EXA and benchmarking
+* Smooth GUI booting: no mode switches and annoying flashes.
+* Requires kernel modesetting, which requires TTM.
+* X thus requires DRM, which hurts the BSDs and Solaris, which don't really have it everywhere.
+* Life's tough, can't hold back development for OSes which lack development resources.
+* Some Linux developers want the DRM to become a Linux-only project and not cross-platform anymore, but airlied and others have been admirably resisting this.
+
+## Stuart Kreitman - Sun Desktop Update
+
+* EOL of Xsun! Solaris-wide commitment to Xorg
+* Transition complete for x86, in process for SPARC and [[SunRay|SunRay]]
+* S10_U4/SXDE3 are on Xorg 7.2. S10_U5/SXDE4 are Xorg 7.3.
+* Features TSOL, Composite, RANDR 1.2, wide hardware support
+* Primary support for ATI, Intel, and NVIDIA
+* SPARC hardware projects: ffb, elite3d, PGX64, XVR100, PGX32
+* Xorg has a DTrace provider now
+* Belenix: Merged osol and Xorg packaging
+* Martux: SPARC distro, includes the various SPARC drivers
+* FOX project: OSOL project to integrate X efforts among OSOL distros
+* [[http://www.opensolaris.org/os/community/desktop/|http://www.opensolaris.org/os/community/desktop/]]
+
+## Alex Deucher - driver/xf86-video-ati, yesterday, today, and tomorrow
+
+* Yesterday: Hardcoded crtc to output mappings
+* 2 output limit, randr-like functionality through mergedfb
+* Today: full randr 1.2 support, all outputs supported, initial mac support
+* Tomorrow stuff!
+ * RMX, the panel scaler. Off, full, center, aspect.
+ * In principle can be used on any output, currently only used on LCDs.
+ * DVO, external connections for outputs. DAC, TMDS, etc.
+ * Needed for external TMDS. x86 legacy bios has external TMDS table.
+ * Non-VBE posting. Code for legacy BIOS that doesn't quite work.
+ * ATOM BIOS should get this for free with the new parser.
+ * ATOM parser should get folded into radeon too.
+ * Planning to merge r128 into radeon.
+ * Probably want to split mach64 out and drop the old ATI wrapper
+ * Composite transforms need fixing on R100 and R200 so rotation works
+ * More TV-out modes, fix PAL, random bugfixes
+* Day after tomorrow
+ * TTM. Needs DRM support. airlied did some experimental work.
+ * R300/R400 Composite. Render accel and rotation support.
+ * PCI rework, kernel modesetting.
+
+## Zack Rusin - Accelerating Desktops
+
+* Render has good text handling, but is quirky and complicated
+* So what gets used? Composition, rasterisation, transforms and gradients
+* What is easy to accelerate? Composition, transform, gradients. Rasterisation is a problem.
+* EXA doesn't require DRI, is self-contained, basic composition is easy
+* EXA syncs. And syncs. And shares state with 3D engine.
+* Using the 3D engine from the 2D driver requires writing the code twice.
+* (long technical discussion about where to put code)
+* Things that still aren't accelerated: Tesselation, Image effects, Curve decomposition
+* (lots of head nodding and general planning)
+
+## X.Org Board Update
+
+* Trying to convert from LLC to 501(c)3
+* Also trying to divest a cash backlog, since we should be not-for-profit
+* Most of the current cash reserve is from heldover consortium fees
+* Still need other ideas for things to do! Ask!
+* We are now VESA members.
+* May join Khronos soon for GL stuff.
+* Developers, please sign up for Foundation membership!
+
+## Zhenyu Wang - XvMC and stuff
+
+* XvMC status, VLD extension issues
+* H.264/AVC intro
+* new XvMC API proposal for H.264/AVC
+* slides at [[http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf|http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf]]
+
+## Keith Packard - Intel Status Update
+
+* 2D driver for i810 through present
+* 3D driver splits at major architectural changes: 830, 915, 965
+* Include old hardware support for new features
+* Test environment includes at least one of each chipset
+* Ship new features when ready
+* BIOS-free modesetting, hotplug monitors, rotation, other randr1.2 hotness
+* TV-out supported on all mobile chips
+* Current driver: OpenGL 1.5, overlays on hardware that has it, textured video on everything else
+* Next driver: OpenGL 2.1, HW MPEG decode, output scaling, HDMI, power savings
+* DFGT, DRRS, DPST, D2PO. Magic acronyms with no definition.
+* OpenGL performance measurement and tuning planned
+* Future media: MPEG iDCT, VLD, H.264, VC-1, de-interlace, etc.
+* Output support: kernel modesetting, eliminate POST on S3 resume
+* Moving to TTM and new memory manager, lots of optimisation there
+* GLSL with minor issues. TTM mostly working. Shipping GL 2.1 by January.
+
+## Carl Worth - EXA/i965 Performance
+
+* [[http://cworth.org/tag/exa/|http://cworth.org/tag/exa/]]
+* Cairo adoption: gnome (librsvg, poppler, evince), mozilla, webkit-gtk
+* Stack: app, cairo, Render, EXA
+* Benchmarks! Wouldn't those be nice
+ * cairo-perf: git://git.cairographics.org/git/cairo, make perf. synthetic, micro
+ * x11perf. synthetic, micro, very poor Render coverage
+ * mozilla trender. [[http://cworth.org/trender_bookmark/|http://cworth.org/trender_bookmark/]]. real, macro.
+* Results. EXA does blit and solid fill really really well.
+* EXA is a slowdown for trender, which is primarily a glyphs benchmark.
+* i965 problems. hidden RMW cycles, synchronous compositing, pinned glyphs.
+* Improvements. Fixed RMW cycles.
+* Posted patches to store glyphs as pixmaps and eliminate some fallbacks
+* Idea for "[[PolyComposite|PolyComposite]]" hook.
+* Future work: memory management, fallback elimination, transforms
+* Want to do trapezoid/polygon rasterisation and gradients in hardware too
+
+## Vedran Rodic - OpenGL performance
+
+* Performance is really bad. How can I help?
+* Gamers want high performance, aren't finding it in OSS drivers
+* R100 was released in 2000, didn't get HyperZ until 2004
+* gears is ~twice as slow on linux than windows for 945GM
+* (sysprof profile, technical discussion about implementation details)
+* Need better documentation for GPU instruction sets
+* Ideas
+ * Cross-platform performance and conformance test suite
+ * Test farm with all supported hardware for regression testing
+ * Driver developers should work from beginning of product development
+
+# Day Two
+
+
+## Zou Nan Hai - GLSL
+
+* GLSL is the OpenGL shading language, a feature of GL 2.0
+* There are other high level shading language: Cg, HLSL
+* Supports vertex and fragment programs with the same syntax
+* Provides C like language: function calls, onditionals, branches
+* Some builtins and keywords are different between vertex and fragment shaders
+* Use "varying" variables to pass values between vertex and fragment stages
+* (example programs)
+* Mesa includes a GLSL frontend, IR, and software backend
+* Intel working on 965 backend based on existing program emit code
+* 965-glsl branch in Mesa, many demos are working
+* Not fully tested yet, some IR ops not implemented yet, error report needs work
+* Ideas about optimization (register allocation, various builtins)
+* Future ideas: debugger, profiler, wider adoption
+
+## Keith Whitwell - Gallium, softpipe, Cell, and beyond
+
+* Historically we had a complete core and very compact drivers
+* This has been changing: more complex drivers, harder bringup
+* Want to fix this. Driver model is no longer correct
+* Impose new interfaces and objects
+* Stack: Mesa, state tracker, Gallium hardware driver, os/window layer, dri/drm
+* New model inspired by GL3, NV_GPU4, 965, etc.
+* constant state objects, simple drawing interface
+* unified shading language as bytecode, private buffers as reder targets
+* ability to re-target hw drivers to new APIs, window systems, and OSes
+* interface: create/bind/delete state, draw, buffer management, fencing, flush
+* state tracker reduces GL to this small interface, deals with GL quirks
+* winsys layer does two interfaces: glx/dri and hw/drm
+* glx/dri is the window system, cliprects, swapbuffers, etc.
+* hw/drm is the kernel, command buffer dispatch, etc
+* reference driver is "softpipe", the reference/sample software renderer
+* looks very much like a GPU pipeline written for a CPU
+* also a proof of concept driver for i915
+* two winsys backends: xlib and dri
+* Mesa-GL3 basically talks to gallium drivers directly
+* eliminates most of the state tracker complexity of GL1/GL2
+* Also means you can port the gallium drivers to DX/Vista
+* future: softpipe + llvm, pervasive codegen for the whole driver
+* should have initial targets of x86 and cell
+* failover driver, moves fallback handling out od driver and state tracker
+
+## Kristian Høgsberg - Redirected Direct Rendering
+
+* ... and GLX 1.4, and zero-copy tfp, and lazy buffer alloc, and cleanup
+* DDX and EXA changes. DDX allocates all buffers as DRM buffer objects
+* Shared ancillary buffers allocated dynamically
+* EXA calls DDX driver hook to allocate pixmaps as buffer objects
+* DRI module changes. Add DDX driver hook to allocate ancillary buffers.
+* Adds pixmap private to store ancillary buffers so client sharing works
+* This works for all pixmaps, including the screen pixmap
+* (technical discussion of senamtics of back buffers)
+* Hooks [[SetWindowPixmap|SetWindowPixmap]] to allocate ancillary buffers when redirection happens
+* On buffer reallocation, signal the DRI driver through the SAREA
+* From DRI driver perspective, redirecting and resizing are the same operation
+* Again, works for the screen pixmap too
+* Breaks the DRI API slightly, removing X assumptions
+* New extension mechanism for the DRI driver to advertise new functionality
+* (example of DRI_COPY_SUB_BUFFER extension)
+* Redirected direct rendering falls out for free, because the front buffer moves
+* GLXPixmaps are mostly the same as a redirected window now
+* GLXPbuffers are also easy to create
+* Add support for glXChangeDrawableAttributes for API reasons
+* ... but we never clobber them, so you never need to send out the event
+* glXGetProcAddress is already done, so with all that, we get GLX 1.4!
+* Need to fix visual setup so you can advertise fbconfigs with pbuffer support
+* GLX_texture_from_pixmap gets cooler too
+* Pixmaps are now buffer objects, so you can bind them to textures directly
+* SAREA is now the only user of drmAddMap/drmMap
+* Suggestion for SAREA journal and/or deletion, and upgrade path
+* (really hot demo)
+
+## Lots of people - TTM BoF
+
+* Things to fix for upstreaming: accounting pinned memory, initial memory size
+* Is the API finished? Is superioctl correct?
+* There's a NO_MOVE flag and a NO_EVICT flag, discussion about why both
+* Want to remove hardware lock requirement for creating buffers
+* Split buffer creation and buffer validation
+* Locking issues surrounding the 'kernel context'
+
+## Dan Amelang - jitblt
+
+* Addresses the problem of the complexity of Render compositing operations
+* Currently implemented as a big case explosion of unpack/composite/pack
+* Plus some special casin for fastpaths
+* jitblt replaces that with a dynamic code generator
+* implemented in a lispish microlanguage called jolt
+* declarative syntax for pixel formts and compositing operators
+* optimization passes for constant folding, algebraic identities, and CSE
+* pixman goes from 9500 lines to ~750
+* faster than pixman for anything in fbCompositeGeneral
+* comparable for many common fastpaths. slower for arm and for memcpy.
+* still lots of room for optimization
+
+## Michael Dales - drivers for non-local graphics and input
+
+* Currently, the usage model is one computer per person
+* This doesn't scale well: cost, energy, resources, maintenance
+* How do you share the system without degrading the user experience?
+* "nivo": network in, video out. vga+input over ethernet, ultra-thin client.
+* Also available as vga+input over usb, available in many products
+* Currently driven as a pipe to Xvnc
+* Developing an Xorg driver as well for better performance
+* not a typical driver: both input and output, no modesetting, not pci
+* Working on Xorg 7.x, DVD playback over USB with no optimisation effort
+* Need to finish keyboard, rotation, Xv, hotplugging
+
+## Daniel Stone - Input overview and plans
+
+* Xi, hotplug, MPX, XKB, DDX/DIX status, event refurbishment
+* Xi was developed for "one mouse for normal UI, plus a spaceball"
+* Basically only used in the gimp.
+* Exposes a device with an arbitrary number of buttons, axes, keys.
+* You walk the device list, open your device, and get exclusive event delivery
+* Horrible event model though. The better model would be core + device id.
+* Once you do that, hotplug is pretty easy.
+* MPX is multiple pointers with multiple cursors. Which means multiple foci.
+* "Multiple grabs mean head-exploding issues."
+* XKB is wretched. Exposes bad binary format over the wire.
+* API was defined in terms of (bad) implementation.
+* New API that matches use was patched on as badly as possible.
+* But, it's very necessary. So how do you fix it?
+* Delete the old API, everything is rules-model-layout-variant-options
+* Fold xkbcomp into the server to speed up startup and make it work
+* Far too much stuff was handled in the DDX, identically among all of them
+* input hotplug moves as much as possible to the DIX layer
+* Get*Events return a pile of wire protocol xEvents
+* Requires much back-inference to actually send the events
+* Needs a rework, there is a plan
+* Remaining issues
+* High keycodes - can't solve without a protocol bump
+* More than four layouts - either a ridiculous server hack, or a protocol bump
+* Multiple pointers - almost done!
+* Code quality is wretched, needs to be redone for bugs' sake
+* Input hotplug basically not adopted yet
+
+## Peter Hutterer - MPX
+
+* MPX basics
+* Currently, there's only one pointer and keyboard; how lame
+* MPX splits that into a cursor per device
+* core pointer and keyboard are now virtual, only for compatibility
+* multiple devices in any client, multiple clients at a time
+* nothing changed if you only have one set of devices
+* (demo)
+* MPX quirks
+* Enter/Leave and [[FocusIn/FocusOut|FocusIn/FocusOut]] changed.
+* First pointer in sends an Enter event, last one out sends a Leave
+* Same for Focus; first keyboard in sends a [[FocusIn|FocusIn]], last one out sends [[FocusOut|FocusOut]]
+* Keyboard has to be paired with a pointer
+* Pairing rules
+* Pair keyboard with first unpaired pointer
+* Else, pait keyboard with first pointer
+* Else if no real pointer, pair with the virtual core pointer
+* API for changing the default rules
+* For ambiguous requests, the client is assigned a "client pointer"
+* Grabs: formerly, core devices with core grabs, single device with Xi grab
+* Now, grabs act on a single device, so multiple clients can grab
+* For core events, grabs mean the whole UI is bound to just that device
+* Core grab means 1:1 mapping between device and client
+* Xi device grab means device bound to client but client can talk to many devices
+* Passive grabs are owned by the device that activates the grab
+* Remaining issue: N devices per cursor and grab semantics
+* XGE
+* The core event spec is painfully constrained. 32 bytes per event, 64 events.
+* Generic events fix this, more space per event, more event types
+* Server can't send a long event until the client says it knows about them
+* MPX uses this for several things, required for multitouch
+* MPX multitouch
+* Mouse is fine for point events, but some touchscreens send mutiple blobs
+* New XBlobEvent that just shoves data to the clients
+* 282 lines for all this plus pointer emulation on the hotspot
+
+# Day Three
+
+
+## Matthew Garrett - ACPI
+
+* ACPI started as a replacement for APM, MP-BIOS, interrupt routing, e820
+* Interface between the firmware and the OS, bonghits, misc, other
+* Often extended in undocumented, inconsistent ways by vendors
+* ACPI 2.0 added an optional video extension; now required by Vista
+* Gives you display switching, brightness control, EDID, POST device
+* _DOS method (display output switch) switches displays and gives you an event
+* Sometimes you can suppress the system from doing this and handle it yourself
+* Brightness control gives you events on change, and a get/set interface
+* But the platform may change brightness anyway without telling you
+* Display enumeration gives you CRTCs and physical connectors
+* Might tell you connection status, if you're lucky
+* Will tell you whether the port is currently present (or on a dock)
+* ROM method if you don't have a PCI BAR, except it's not the ROM
+* Can query the boot adaptor, and can set the boot adaptor
+* EDID method mandatory if it's not available some other way
+* Impossible to map the ACPI video ID to a PCI slot
+* [[OpRegions|OpRegions]] (unpublished spec) provides a backchannel for communication
+* ACPI doesn't require anything of the gfx hardware over suspend
+* So we try to POST and hope, and sometimes that works
+* Or you can do VBE save and restore state, and sometimes that works
+* Or you can do pre-VBE set text mode, and sometimes that works
+* Mostly it just doesn't
+
+## Dave Airlie, Jesse Barnes, Jakob Bornecrantz - Kernel Modesetting BoF
+
+* API looks pretty much like the RANDR protocol now
+* Add a DRM control file for persistent state (since we can't with current DRM)
+* Use privileged switcher for fast user switching
+* Requires some enhancements to the resume path to really work nicely
+* Memory eviction on suspend is hard
+
+## Adam Jackson - Monitors and why they hate you
+
+I didn't take notes on my own talk. Anybody?
+
+
+## Egbert Eich, Luc Verhaegen - ATI Driver Status
+
+* When ATI dropped support for the open driver, distros lives got hard
+* SuSE has a end-user installer, but that's still not perfect
+* Started discussions about how to enable an open source driver again
+* ATI approached SuSE to develop a driver, working on it for the last ~6 weeks
+* Mostly working, still some output setup buglets
+* (Details about some bringup issues)
+* First code drop planed on Monday
+* Docs approved for release without NDA about 45 seconds ago
+
+## Zack Rusin - LLVM for Mesa
+
+* LLVM has two primary components: optimizer and codegen, and gcc front-end
+* Standard suite of SSA-based optimizations, support for many targets
+* Strongly typed, extensible, vector-aware IR
+* Good pipeline, link time opt, jit, easy to work ith and learn
+* Well maintained, BSD licensed, great for us to use but not care about
+* So: Cg/HLSL/GLSL -> LLVM IR -> Optimizer -> codegen or jit
+* Minor problem since it assumes the target CPU has branches
+* But really easy to wire up already
+
+## Daniel Stone - KDrive futures
+
+* Xorg within spitting distance of being as small as KDrive
+* Move generally useful Xorg stuff to DIX, at which point there's not much difference between the two
+* Smaller systems mostly running KDrive on framebuffer because everyone else is
+* Pure size isn't too much of an issue, compared to FPU/cache locality/etc
+
+## Eric Anholt, Adam Jackson, Daniel Stone - Future releases
+
+* 1.4.1: 1st November, 2007. Daniel as RM, nominate on [[Server14Branch|Server14Branch]] as usual.
+* 1.5.0: 1st March, 2008
+* Scribbled on the board for 7.4/1.5: XGE, XACE, RandR 1.3 (GPU object), input transformation, pci-rework, XKB 2, _X_EXPORT, DRI memory manager, GLX 1.4, Glucose
+* 7.5 features: MPX, lifting DMX up to DIX
+
+## Stephane Marchesin, Jerome Glisse - Reverse Engineering
+
+* We have kernel source, but no driver source.
+* So we can watch everything the closed driver does and try to figure it out
+* Or, that's the theory
+* Simple tools: register dumper, BIOS emulator
+* Complex tools: libsegfault (unmap the card, trap the fault, record, put back)
+* Later done better as valgrind-mmt. But all this is userspace only.
+* mmiotrace works on kernel-level accesses too
+* renouveau: find the command fifo, feed it GL, watch for changes
+* Inspect one thing at a time: single video mode at different refresh rates, eg
+* Do lots of dumps so you can identify the commonalities and differences
+* (example of delta finding)
+* Future work on higher level tools, other architectures, etc.
+
+## Eamon Walsh - XACE Demo
+
+* (Demo of protected windows) \ No newline at end of file
diff --git a/Events/XDS2007/Program.mdwn b/Events/XDS2007/Program.mdwn
new file mode 100644
index 00000000..03f53192
--- /dev/null
+++ b/Events/XDS2007/Program.mdwn
@@ -0,0 +1,57 @@
+
+
+# XDS2007 Program
+
+This is the rough program for [[XDS2007|Events/XDS2007]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk. Please contact Dave Airlie < [[airlied@gmail.com|mailto:airlied@gmail.com]] > for any scheduling suggestions or changes.
+
+Refreshments (coffee, tea, biscuits, etc) will be served throughout the day. Breakfast will be served at 8am for those in the college. Lunch and dinner will be off-campus.
+
+
+## Program
+[[!table header="no" class="mointable" data="""
+ | **Monday** (Drivers) | **Tuesday** (OpenGL and related, Input) | **Wednesday** (Future plans, misc, other)
+ **9am** | Welcome and Foundation overview ([[DanielStone|DanielStone]] and crew) | GLSL ([[ZouNanhai|ZouNanhai]]) | Local compositing with DMX ([[DavidReveman|DavidReveman]])
+ **10am** | Red Hat X.org Overview ([[DavidAirlie|DavidAirlie]]) / Sun X.org overview ([[StuartKreitman|StuartKreitman]]) | [[Softpipe|http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007.odp]] ([[KeithWhitwell|KeithWhitwell]]) | Embedded systems ([[DanielStone|DanielStone]])
+ **11am** | _morning tea_ | _morning tea_ | _morning tea_
+ **11:30am** | [[Radeon driver status|http://www.botchco.com/alex/xorg/radeon-xds.pdf]] ([[AlexDeucher|AlexDeucher]]) | TTM and redirected DRI ([[KristianHøgsberg|KristianHøgsberg]]) | ACPI and video driver interactions ([[MatthewGarrett|MatthewGarrett]])
+ **12:15pm** | Render acceleration improvements ([[ZackRusin|ZackRusin]]) | TTM BoF ([[KeithWhitwell|KeithWhitwell]]) | Kernel Modesetting BoF ([[DavidAirlie|DavidAirlie]])
+ **1pm** | _lunch_ | _lunch_ | _lunch_
+ **2pm** | XvMC ([[ZhenyuWang|ZhenyuWang]]) | Jitblt ([[DanAmelang|DanAmelang]]) | Long lunch
+ **3pm** | Intel driver architecture ([[KeithPackard|KeithPackard]]) | Ndiyo ([[MichaelDales|MichaelDales]]) | Monitor specs ([[AdamJackson|AdamJackson]])
+ **3:30pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_
+ **4pm** | EXA/i965 performance ([[CarlWorth|CarlWorth]]) | [[Input overview and plans|http://www.fooishbar.org/talks/xds2007-input.pdf]] ([[DanielStone|DanielStone]]) | LLVM for acceleration ([[ZackRusin|ZackRusin]])
+ **5pm** | OpenGL performance ([[VedranRodic|VedranRodic]]) | MPX ([[PeterHutterer|PeterHutterer]]) | Reverse engineering ([[JeromeGlisse|JeromeGlisse]], [[StephaneMarchesin|StephaneMarchesin]])
+ **7pm** | _be social_ | _be social_ | four-course dinner at the college
+"""]]
+
+
+## Ideas
+
+* Input ([[DanielStone|DanielStone]]): explanation of how our input code works today, and what we're planning (e.g., the input thread and its mini-status given by [[TiagoVignatti|TiagoVignatti]]).
+* Small devices ([[DanielStone|DanielStone]]): The challenges _actually_ facing X on small devices, such as the Nokia N800; what are we going to do with KDrive?
+* EXA/i965 performance issues ([[CarlWorth|CarlWorth]]): How can we make our newest free-software supported hardware really fast?
+* Reverse-engineering tools ([[JeromeGlisse|JeromeGlisse]], [[StephaneMarchesin|StephaneMarchesin]]): The tools and techniques you need for reverse engineering. (Not that you'd ever want to ...)
+* Intel driver architecture ([[KeithPackard|KeithPackard]]): How the intel driver works today and where the cool new features are landing.
+* MPX and XGE ([[PeterHutterer|PeterHutterer]]): Update on the status, what works, what doesn't yet.
+* Fixing Xrender's rasterization ([[ZackRusin|ZackRusin]]): General talk on ways in which we could improve Xrender's rasterization semantics and algorithm to make it more acceleration friendly.
+* LLVM and graphics ([[ZackRusin|ZackRusin]]): What's LLVM, how it works and what are the most interesting things about it when viewed from a perspective of graphics.
+* Accelerating desktops ([[ZackRusin|ZackRusin]]): Problems and challenges in building a robust acceleration framework for modern desktops. Focused on acceleration of font and complex polygon rendering.
+* OLPC display and power management ([[JimGettys|JimGettys]]): The OLPC XO-1 has a unique, novel LCD panel, and can suspend the processor leaving the LCD alive. If I can persuade [[AdamJackson|AdamJackson]], we'll probably do a tag team about how this came to be and how it's been implemented.
+* GLSL support in Intel driver ([[ZouNanhai|ZouNanhai]]): How GLSL is implemented on Intel graphic card and mesa driver.
+* X.Org Foundation (Foundation board): What the Foundation has done, what we're planning to do, and general status.
+* X Protocol in Java ([[RomanKennke|RomanKennke]]): Introducing and discussing [[Escher|http://escher.sourceforge.net]], an X protocol implementation written completely in Java.
+* Jitblt ([[DanAmelang|DanAmelang]]) Just-In-Time compilation of image compositing kernels in pixman.
+* XvMC improvement ([[ZhenyuWang|ZhenyuWang]], [[HaihaoXiang|HaihaoXiang]]): How's current XvMC support on Intel graphics, what's needed to be improved for hw accelerated H.264/AVC decoder.
+* coming Red Hat X.org attractions ([[DavidAirlie|DavidAirlie]]) - Overview of upcoming roadmap for X.org in Fedora and RHEL - compositing + modesetting
+* Modesetting BOF (David Airlie) - [[ModeSettingBoF|Events/XDS2007/ModeSettingBoF]]- A BOF session on moving modesetting interfaces into the kernel
+* If it wasn't for those pesky kids ([[DavidAirlie|DavidAirlie]]) - current status of open source drivers for X.org
+* Softpipe, whats all that about then? ([[KeithWhitwell|KeithWhitwell]]) - Tungsten Graphics and others plans for renewing the Mesa software rasterizer, creating a Cell driver, and a new driver model for Mesa.
+* TTM BOF ([[KeithWhitwell|KeithWhitwell]]) - Wiki page at [[TTMBoF|Events/XDS2007/TTMBoF]] I see lots of disjoint conversations about the memory manager, I think we need to take this opportunity to get some alignment amongst all the groups using & developing TTM.
+* 3D driver performance ([[VedranRodic|VedranRodic]]): I'll focus on the intel915 driver since I own the hardware. 915tex driver helps Quake3 (about 50% faster), but [[SecondLife|SecondLife]] is still much slower than Windows
+* Redirected direct rendering, TTM based texture-from-pixmap and GLXPixmaps (Kristian Høgsberg) - presenting a working prototype and discussing required interface changes.
+* New monitor standards (and/or ones we just don't implement yet) and their impact on RANDR and the driver model. ([[AdamJackson|AdamJackson]])
+* radeon driver: where we were, where we are now, where we are going ([[AlexDeucher|AlexDeucher]])
+* Ethernet & USB Thin Client drivers: Some bits of the ethernet Nivo think client work and drivers for USB monitors from based on the Display Link chipset ([[MichaelDales|MichaelDales]])
+* Using Xdmx as a remote proxy X server that allows compositing to be done locally ([[DavidReveman|DavidReveman]])
+* The interaction between ACPI and video drivers ([[MatthewGarrett|MatthewGarrett]])
+* What happens in the year of the desktop ([[MatthewTippett|MatthewTippett]]) \ No newline at end of file
diff --git a/Events/XDS2007/TTMBoF.mdwn b/Events/XDS2007/TTMBoF.mdwn
new file mode 100644
index 00000000..6e057c67
--- /dev/null
+++ b/Events/XDS2007/TTMBoF.mdwn
@@ -0,0 +1,61 @@
+
+Discussion list for TTM BoF at XDS 2007.
+
+Please just add your name and a list of things you would like to raise...
+
+
+
+---
+
+
+
+* [[DavidAirlie|DavidAirlie]]
+1. Unfenced list removal
+
+2. removal of any unused interfaces to avoid long term support in upstream kernels
+
+3. Mandatory super ioctl in the driver.
+
+4. Relocation types.
+
+5. fake buffer type (do we need to pass in the type at all, really userspace dc or user can be worked out from the pointer - krh) - agreed to remove this from interface.
+
+
+
+---
+
+
+
+* [[JeromeGlisse|JeromeGlisse]]: There was a discussion on irc about handling of cliprect i am not sure this truely fit this topic and likely could be worked before TTM. The things is that if we want multiple consumer of DRM (could be two X server running at the same time using the same hw but each one having its head or one visible while the other in background, whatever) for that i think it would be better to move all sarea and other DRI initialization bit out from DDX to libdrm for instance, also providing API to handle cliprect in libdrm (this was proposed by [[KristianHøgsberg|KristianHøgsberg]]). So libdrm handle remaining initialization of DRI that were done in DDX. In such scheme we might need to have some notion of master/slave or parent/child in libdrm so parent|master own the framebuffer and authorize who can have a dri context for this framebuffer|scanoutbuffer and also is the only one who can update cliprect of its child|slave. This is just my feeling and wish (i tend to always ask too much to Santa :-)) and i could also be totaly wrong about all this as i never truely looked deep into this part of the code )
+ * [[KristianHøgsberg|KristianHøgsberg]]: I'm no longer convinced that we need to push this into libdrm and the kernel modules. Optimizing the way the server communicates cliprects will probably go a long way. I've been working on a system BO based 'journal' idea, where the xserver writes changes to cliprects, window positions and drm_drawable_t -> ancillary buffer objects mappings. DRI clients read from this journal and keep their own tail pointer. This way,clients can quickly see if they're behind, and can catch up without doing protocol do the server (ie while holding the lock).
+ * [[KeithWhitwell|KeithWhitwell]]: Cliprects are just evil anyway. Switching to a private-backbuffer arrangement leads to drivers which are vastly easier to understand and deal with, and then you only have to examine cliprects once per frame which is not a significant cost with the existing DRI facilities. In any case they certainly have nothing to do with the buffer manager - if you care about cliprects it is because of choices you have made in the window-system integration layer, in my opinion the buffer manager shouldn't care about this at all.
+
+
+---
+
+
+
+* [[JesseBarnes|JesseBarnes]]:
+ * per-process GTT entries
+ * page fault support I can look into what Intel hardware supports in this regard; hopefully we can fit this stuff into the current design without too much trouble.
+
+
+---
+
+
+
+* [[KeithWhitwell|KeithWhitwell]]:
+ * Relocations are great, but sometimes you really need to know where a buffer is going to be.
+ * Software zone/tiled rendering - can generate 10,000's of relocations. The CPU overhead of this would otherwise defeat the technique.
+ * Reusing buffers containing relocations over multiple scenes -- eg. caching generated programs/state which themselves contain relocations.
+ * Approaches for dealing with this -- 'prevalidation', investigating NO_MOVE buffers.
+ * Differences between NO_MOVE and NO_EVICT. Both are important but for different reasons.
+ * Private backbuffers --> We need to be able to allocate tiled buffers on Intel IGPs.
+ * Private backbuffers and pageflipping. How will this work?
+---
+
+
+
+ * [[KristianHøgsberg|KristianHøgsberg]]:
+ * Can we drop drmBODestroy and only use drmBOUnreference? Sometimes the X server creates a BO and the DRI driver running in a DRI client may end up being the last user. The X server can't just call drmBODestroy, since others may be using it, at the same time, the DRI client can't destroy it because it didn't create it.
+ * We need to talk about how the private back buffer work overlaps with redirected direct rendering. \ No newline at end of file
diff --git a/Events/XDS2008.mdwn b/Events/XDS2008.mdwn
new file mode 100644
index 00000000..38b6934c
--- /dev/null
+++ b/Events/XDS2008.mdwn
@@ -0,0 +1,52 @@
+
+
+# XDS 2008
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2008|Events/XDC2008]] | **XDS 2008** | [[XDC 2009 >>|Events/XDC2009]]
+"""]]
+
+The X Developers' Summit for 2008 was held at [[Edinburgh Zoo|http://www.edinburghzoo.org.uk]], [[Edinburgh|http://wikitravel.org/en/Edinburgh]], UK, from the 3rd-5th September.
+
+* [[Attendees|Events/XDS2008/Attendees]]
+* [[Program|Events/XDS2008/Program]]
+* [[Notes from the talks|Events/XDS2008/Notes]]
+* [[Audio Recordings of the talks|Events/XDS2008/Recordings]] (courtesy of [[Phoronix|http://phoronix.com/]])
+We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities.
+
+Attendance is free, but you must register beforehand, by putting your name on the Attendees page; attendance is currently limited to 60 people.
+
+
+## Accommodation
+
+Unlike XDS 2007, on-venue accommodation has not been arranged. We will, however, arrange a group booking rate with an affordable and accessible hotel: hold tight.
+
+
+## Travel
+
+Edinburgh has its [[own airport|http://en.wikipedia.org/wiki/Edinburgh_Airport]] (EDI), 10 miles west of the city. Edinburgh is not an enormous international hub, but there are very frequent services from all London airports (Heathrow, Gatwick, Stansted, City, Luton) with all alliances, decent European connectivity, plus Continental and Delta flights to JFK/Newark. A full list of destinations is available from the airport site. From the airport, the 100 and 35 buses connect you to the city.
+
+Edinburgh Waverley train station is very close to the city centre, and has good connections to the rest of the UK, including a 4h30m fast east coast service to London, and a ~7h overnight sleeper service. For more details, as well as booking, please check the [[Scotrail site|http://www.firstgroup.com/scotrail/]]. For those under the age of 25, buying a 16-25 Railcard (£20, valid for a year, can halve ticket prices) will likely save you a great deal on a long train journey: more information is available from nationalrail.co.uk.
+
+Edinburgh Zoo is easily accessible from the centre of the city, with the 12, 26, 31 and 100 (Airlink) [[Lothian buses|http://lothianbuses.com/]] all departing from Princes St; the trip is roughly 15 minutes.
+
+
+## Sponsorship
+
+As usual, we will be running a travel sponsorship program. If you are unable to afford travel/accommodation on your own, please investigate the cheapest reasonable way for you to get to Edinburgh, and let us know a ballpark price. Full details are in the [[list post|http://lists.x.org/archives/events/2008-July/000000.html]] (note that the deadline is Wed 6th Aug).
+
+
+## Registration, talks
+
+If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/events]] for updates; note that as a general-purpose mailing list, this will be reused for future events, so please remember to unsubscribe afterwards if you don't plan on attending future events. Also, please add your name to the [[Attendees|Events/XDS2008/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2008/Program]] page.
+
+
+## Misc, other
+
+Scotland uses UK plugs. There will no doubt be all kinds of foreign power boards and adaptors floating around, but please do remember to bring your own. The currency is the British Pound (GBP), and the language mostly resembles English.
+
+[[Google Maps: Edinburgh Zoo|http://maps.google.co.uk/maps?f=q&hl=en&geocode=&q=edinburgh+zoo&sll=53.800651,-4.064941&sspn=12.061542,28.212891&ie=UTF8&ll=55.946701,-3.225861&spn=0.044602,0.110207&z=13]].
+
+
+## Contact
+
+If you have any problems or questions, please contact Daniel Stone -- [[daniel@fooishbar.org|mailto:daniel@fooishbar.org]].
diff --git a/Events/XDS2008/Attendees.mdwn b/Events/XDS2008/Attendees.mdwn
new file mode 100644
index 00000000..47a1d924
--- /dev/null
+++ b/Events/XDS2008/Attendees.mdwn
@@ -0,0 +1,34 @@
+
+
+# XDS2008 Attendees
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDS2008|Events/XDS2008]]. List here any special dietary requirements you have or anything we'd otherwise need to know. Even if you haven't got it confirmed yet, please put your name down with 'pending' next to it, so we can plan better.
+
+1. [[JakobBornecrantz|JakobBornecrantz]]
+1. [[EgbertEich|EgbertEich]]
+1. [[LucVerhaegen|LucVerhaegen]]
+1. [[JohnTapsell|JohnTapsell]]
+1. [[JakubLamik|JakubLamik]]
+1. [[MichaelLarabel|MichaelLarabel]]
+1. [[MatthieuHerrb|MatthieuHerrb]]
+1. [[AlexDeucher|AlexDeucher]] (not likely)
+1. [[RobertBragg|RobertBragg]]
+1. [[JeromeGlisse|JeromeGlisse]]
+1. [[KeithWhitwell|KeithWhitwell]]
+1. [[AlanHourihane|AlanHourihane]]
+1. [[AndyShaw|AndyShaw]]
+1. [[JeremyHuddleston|JeremyHuddleston]] (herbivore, pending funding)
+1. [[AlanCoopersmith|AlanCoopersmith]]
+1. [[PeterHutterer|PeterHutterer]] (lactose-free if possible, otherwise normal grub)
+1. [[TiagoVignatti|TiagoVignatti]] (carnivore)
+1. [[SimosXenitellis|SimosXenitellis]] (pending)
+1. [[GordonJin|GordonJin]]
+1. [[EricAnholt|EricAnholt]]
+1. [[KeithPackard|KeithPackard]]
+1. [[IanRomanick|IanRomanick]]
+1. [[JesseBarnes|JesseBarnes]]
+1. [[JayCotton|JayCotton]]
+1. [[StuartKreitman|StuartKreitman]] (no haggis or porky things)
+1. [[SimonThum|SimonThum]] (leaving sep 5th, omnivore)
+1. [[TomasFrydrych|TomasFrydrych]]
+1. [[KristianHøgsberg|KristianHøgsberg]] \ No newline at end of file
diff --git a/Events/XDS2008/Notes.mdwn b/Events/XDS2008/Notes.mdwn
new file mode 100644
index 00000000..e9bf6e3d
--- /dev/null
+++ b/Events/XDS2008/Notes.mdwn
@@ -0,0 +1,169 @@
+
+
+## X.Org Board report out
+
+* still have a good amount of money in the bank
+* conference schedule going from 2 to 1 per year, with developer days at FOSDEM
+* elections for board "soon"
+* current business includes setting up 503(c) status
+* members site needs work
+* still need work to handle donations
+* next X developer meeting in Portland next September (maybe near Plumbers)
+
+## Sysadmin's status report (Ben Close via email)
+
+Done:
+
+ * Shifted www.x.org /www.freedesktop.org and other sites to moin 1.6
+capta's added
+
+ * Spam pages removed from above sites
+ * 22k emails moderated
+ * Bugzilla upgraded o Many new projects/accounts created
+ * Tinderbox setup (many thanks to Chris Ball for maintaining/running this)
+In progress
+
+ * Shifting remaining websites on gabe -> annarchy ..slowly
+ * Slowly patching machines up to a known security level
+ * Moderating all fd.o mailing lists at least weekly
+ * Trying to zero out the sitewranglers/freedesktop product bug list
+Future
+
+ * Build in www redundancy (ie multiple frontends so one can be taken down for maintainence)
+ * gitweb->cgit replacement.. currently pending on cgit needing features - lots of rewrite rules to make this happen (cat /etc/apache2/sites-available/gitweb.freedesktop.org if interested)
+ * Begining to enforce mentoring rules (ie must used [[SignedOff|SignedOff]] By etc)
+ * Making the websites flow together - ie remove the disjointedness of sites. Ie from pkg-config.freedesktop.org you can easily see it's part of fd.o and go back to www.freedesktop.org)
+ * User/Project cleanup. Remove stale projects/users
+ * Mailing list cleanup
+ * Better spam filtering
+ * community based email moderation via capthca
+ * lots more...
+
+## Input Status
+
+ * Daniel Stone did a lot of clean-up work on X Input in recent times.
+ * MPX / Multi-Point X was merged to master in May of this year.
+ * Focus model is currently semi-broken.
+ * Direct Rendering Infrastructure 2 will fix the blinking software cursors within MPX.
+ * Device properties have been back-ported to X Input 1.5 without input API breakage.
+ * xf86-input-synaptics is the newest addition and is no longer under the GPL but now MIT license. SHMConfig is being replaced with device properties in this new version.
+ * xf86-input-evdev 2.1 version will likely include drag lock and wheel emulation.
+ * 30 different X input drivers on the [[FreeDesktop|FreeDesktop]] infrastructure, but only eight listed maintainers. There are lots of dead input drivers.
+ * Remove dead input drivers from the next X.Org release, but the code will live on within the X.Org git repository
+ * Daniel Stone working on cleaning up XKB.
+
+## Pointer Acceleration
+
+ * Previously X pointer acceleration has had no scaling in DIX, parallel acceleration, and sometimes there were overshoots.
+ * behavior is now predictable, improving usability
+ * Outlook: Expose device properties for cool UI happenings and the ability to upload user-defined profiles.
+ * Possible sub-pixel fixed coordinates not only for touch screens (XI2).
+see [[PredictablePointerAcceleration.pdf|PredictablePointerAcceleration.pdf]]
+
+
+## Improving Input Latency
+
+ * Strategy #1: Only the event generation is done in a separate thread (Status: Hopefully Done)
+ * Input Thread: It was expected that the cursor footprint would always live on RSS when the pointer device still is in movement, but it wasn't the case.
+ * pthread vs. clone input thread code: clone was abandoned due to performance issues. Likely easy to port to using clone in the future.
+ * Strategy #2: Push input event generation in kernel. Coolest method, but would involve having to avoid two identical sets of code for different contexts in the case of software cursors. This strategy also involves significant code modification. It comes down to being a comcompleteplete redesign but would solve all latency issues.
+ * Why this latency input work? This would improve usability and performance with a drop-in replacement (input-thread). If moved into the kernel, it would provide similar X independence to kernel-based mode-setting.
+
+## Graphics Power Management
+
+ * Chipset power management varies from different vendors.
+ * Intel Power Management: No direct control over hardware, just bits to set that should powerdown unused hardware.
+ * ATI: PLLs for separate hardware components and can clock down the GPU core and memory frequencies (Note: [[PowerPlay|PowerPlay]]).
+ * NVIDIA: Can clock-down core and memory frequencies (Note: [[CoolBits|CoolBits]] / Powermizer)
+ * How low can we go in clocking down the core and memory frequencies without visual artifacts?
+ * Universal or vendor/driver-specific power management needs to be considered.
+ * Too much latency in software-controlled backlight
+ * Ideally, when a monitor is hot-plugged an interface should pop up asking the user what they want to do, but don't enable it by default.
+ * With Intel 945 hardware (and presumably newer), a register is magically set when VGA is hot-plugged.
+ * Frame-buffer compression on Intel works relatively okay if disabling Render acceleration. This should conserve power with having to scan less memory.
+ * Newer notebook platforms with support for discrete and integrated graphics with the ability to switch between the two makes things difficult.
+
+## X Input 2
+
+ * MPX made X Input Extension version 2 needed.
+ * Some of the ideas: device properties as a significant part, XGE (X Generic Events) as a requirement, axis labeling, relative motion events, force feedback, sub-pixel accuracy, mixed axes, dynamic capabilities, and a decent mask event interface.
+ * How much of Xi1 will be left in Xi2? KeithP says leave in as much as possible to support. Peter responded that Xi2 can support it all but not in a meaningful way.
+ * Proposed ideas: Hot-plugging events (proposed by Keithp) but already in X Server 1.4+ but with bugs, increasing device IDs up to 16 bits, range grab, keysym grab, a method for a key grab that is immune to keyboard grabs, virtual input devices for multimedia keys on keyboard, and separate Xi and Xi2 parsers but end up in a common API.
+
+## Gallium 3D
+
+ * Recapping known features: New 3D driver environment, a lot simpler to work with than Mesa/DRI, multiple API support for free, taking away the nasty stuff within DRI drivers, easy to adopt for new environments, and strong interfaces.
+ * Core support for Gallium is essentially done for OpenGL and DirectX 9
+ * Additional APIs for Gallium 3D is on the way, but Tungsten Graphics doesn't want to comment on which ones at this time.
+ * GL support and sample drivers in Mesa gallium-0.1-branch.
+ * Intel 915 driver is complete but not fully optimized.
+ * Gallium 3D is now in a stabilization phase. Keith Whitwell: "We're done with the first iteration and now in a bug-fixing phase."
+ * Current work: building debug, tracing, and replay tools. Also working on new API front-ends and performance measurement and tuning.
+ * Fairly close to a point where Gallium will be merged to Mesa trunk. Before that, however, they intend to fix interface glitches, architecture oddities, and apply the lessons from the first couple of drivers.
+ * Tungsten has done a new driver for a newer class of GPU hardware, but no comment on what it is or when it will be released.
+ * A little bit of work left in some of the per-device driver components
+ * The winsys API will be hidden to the state tracker during the clean-up process of the Gallium code.
+ * It's time to think about putting together a Gallium specification and would help in the clean up process.
+ * Textures/Resources: unify surfaces and textures, remove the concept of a free-standing surface that owns its storage, possibly rename texture to resource to avoid confusion, textures own the storage and image data, 90% done.
+ * Future Possibility: Tungsten believes that 2D should be layered on 3D. They propose to define a 2D-friendly abstraction (such as pipe_context_2d) and provide a default implementation layered on the existing 3D-friendly interfaces.
+
+## Intel Graphics Testing
+
+ * [[AutoBuildAutoTest|AutoBuildAutoTest]] - Intel's suite for building from source the driver components and running its tests.
+ * Call for increasd quality of bug reports.
+ * Intel wants more community testers. Intel community team created to have test coverage for their old hardware.
+
+## Radeon
+
+ * R100-200: No Gallium support planned and limited development restricted to kernel mode-setting and memory management.
+ * R300-400: Gallium, Vertex shader, pixel shader, memory management, and kernel mode-setting planned.
+ * R500: Vertex shader, pixel shader, support loop with limited depth, kernel mode-setting through AtomBIOS, memory management, and power management.
+ * R600/700: Unified pixel/vertex shader, complex, drawing triangle, power management is critical.
+ * R500 3D support should be the same as the R300/400 support.
+ * Command Submission is easier with modern ATI hardware where it takes a hardware formatted stream that can be sent directly to the hardware.
+ * Producing hardware shader code from a high-level shading language like GLSL is one of their biggest tasks ahead.
+ * Kernel mode-setting for R100 to R400 was ported from their DDX code and for the R500 series and lter it's using the new AtomBIOS parser.
+ * The ATI support will use the GEM API but underlying code will be powered by TTM.
+
+## GLSL
+
+ * Language extensions allow many language intrinsics to be written in GLSL: <ins>constructor, _operator, </ins>asm.
+ * GLSL 1.30 support not even started.
+ * Really Bad State: one-off parser generator, linker can't support multiple compilation units on the same shader target, ARB_fragment_program is the IR.
+ * Desired infrastructure: sensible parser infrastructure, back-end independent IR, parser re-written using flex and bison.
+ * Language features they want: A compliant linker, real integer support, and full GLSL 1.20 and 1.30 support.
+ * Other features needed: geometry shader support, code-generator generator. Assembly shaders to MIR (modeled after GCC),
+ * Current GLSL infrastructure will continue on for at least a year.
+
+## Graphics Execution Manager
+
+ * Past: i830_memory.c, exa_offscreen.c, texmem.c.
+ * Multiple memory allocators are a problem: can't talk to each other, static limits, etc.
+ * New solution was needed for: composited OpenGL, EXT_framebuffer_object, EXT_texture_from_pixmap, reduce memory consumption, private backbuffers.
+ * Kernel execution managfement: keep track of which cache domains memory is dirtied in, keep track of which cache domains memory is valid in, and automatically transition for the clients when they access buffers in new cache domains.
+ * Hard parts: system memory controller and cache management tuning.
+ * Next GEM plans: fence register management, hardware contexts, userland cache management, rectangular pwrite, GTT mmap, and fault-based flushing.
+ * Keith Packard requests a common API for GEM to be used across multiple drivers.
+
+## Plymouth Boot Experience
+
+ * Uses kernel mode-setting drivers.
+ * When prompted for encryption key when booting, graphics now show prompt instead of dropping back to text mode.
+ * Get into native graphics mode as soon as possible.
+ * Keith Packard: "On a netbook with an SSD, we can get GRUB, the kernel, and X loaded within two seconds of POST."
+ * Work to get fbdev on KMS is done, but it's ugly. Multi-head in particular causing problems.
+ * Aims to ship with Fedora 10 either as a preview feature or mainline feature depending upon progress.
+
+## X Release Plans
+
+ * xf86-video-intel 2.5.0 release to come in September, xf86-video-intel 2.6.0 to come in December.
+ * Intel current and 2.5 features: XvMC, KMS, DRI2, UXA, Render accel.
+ * Intel working with Windows driver team to share video code between Linux and Windows teams.
+ * UXA: EXA API plus GEM. When Keith figures out the differences, EXA will be split into pixmap management and acceleration architecture for the other.
+ * X Server 1.6 should have fixed EXA and UXA should be removed.
+ * X Serve 1.6 should be released perhaps by end of year.
+ * Clean up X/Mesa build system and avoid duplicating source files between packages.
+ * Ideal goal of KeithP: no generated files in git.
+ * Matthias Hopf is currently blocking RandR 1.3 release with standard properties. RandR 1.3 will close in about one month.
+ * X Server 1.6: DRI2, RandR 1.3, Xkb rewrite (if ready), Xi2 or Xi 1.5 with device properties, and MPX if Xi2.
+ * X.Org 7.5 for March of 2009. Looking for release maintainer or building a release team. \ No newline at end of file
diff --git a/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf b/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf
new file mode 100644
index 00000000..42917dc8
--- /dev/null
+++ b/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf
Binary files differ
diff --git a/Events/XDS2008/Program.mdwn b/Events/XDS2008/Program.mdwn
new file mode 100644
index 00000000..eae6ee87
--- /dev/null
+++ b/Events/XDS2008/Program.mdwn
@@ -0,0 +1,51 @@
+
+
+# XDS2008 Program
+
+This is the rough program for [[XDS2008|Events/XDS2008]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk.
+
+Refreshments (coffee, tea, biscuits, etc) will be served throughout the day; a light breakfast will be served in the morning (coffee, tea and pastries), and lunch will be served on-campus. Dinner is at your own discretion, as long as you're out of the zoo by 6pm. There's a pub across the road from the zoo, which is apparently quite good.
+
+On Thursday, there'll be a guided tour of the zoo at sunset, going from 6pm-7:30pm, after which there'll be a drink and some finger food back at Mansion House.
+
+Feel free to fill the bof/demo/misc slots if you want to talk about something.
+
+
+## Program
+[[!table header="no" class="mointable" data="""
+ | **Wednesday** (input and misc) | **Thursday** (GL-related happiness) | **Friday** (other)
+ **9am** | _tea/coffee/pastries, coalesce_ | _tea/coffee/pastries, coalesce_ | _tea/coffee/pastries, coalesce_
+ **9:30am** | Welcome and Foundation overview ([[MatthewGarrett|MatthewGarrett]], Foundation board) | Gallium3D status ([[TungstenGraphics|TungstenGraphics]]) | Plymouth graphical boot synergies ([[KristianHøgsberg|KristianHøgsberg]])
+ **10:30am** | _morning tea_ | _morning tea_ | _morning tea_
+ **10:45am** | Input summary ([[PeterHutterer|PeterHutterer]]) | Gallium3D, i915, and you ([[JakobBornecrantz|JakobBornecrantz]]) | DRI2 v2 ([[KristianHøgsberg|KristianHøgsberg]])
+ **11:45am** | Pointer acceleration ([[SimonThum|SimonThum]]) | [[Intel Graphics Testing|http://www.intellinuxgraphics.org/testing/gfx_test_xds2008.pdf]] ([[GordonJin|GordonJin]])
+ Radeon KMS, memory management, etc ([[JeromeGlisse|JeromeGlisse]]) | More DRI2 hilarity
+ **12:30pm** | _lunch_ | _lunch_ | _lunch_
+ **1:30pm** | [[Improving input latency|http://www.inf.ufpr.br/vignatti/talks/XDS08-ImprovingInputLatency.pdf]] ([[TiagoVignatti|TiagoVignatti]]) | [[GLSL|http://web.cecs.pdx.edu/~idr/publications/xds2008-GLSL_work.pdf]] ([[IanRomanick|IanRomanick]]) | Everybody loves Intel ([[KeithPackard|KeithPackard]])
+ **2:30pm** | Runtime GPU power management ([[MatthewGarrett|MatthewGarrett]]) | (2:15pm) [[Penguin Parade|http://www.edinburghzoo.org.uk/visiting/daily-events/]] | XKB stuff ([[SimosXenitellis|SimosXenitellis]])
+ **3:15pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_
+ **3:30pm** | Live XI2 spec drafting ([[PeterHutterer|PeterHutterer]]) | GEM: The easy and simple memory manager everyone's gonna love ([[EricAnholt|EricAnholt]]) | Lock doors, no-one leaves until [[7.4|Releases/7.4]] released ([[EricAnholt|EricAnholt]], possible virtual presence from [[AdamJackson|AdamJackson]] and [[DanielStone|DanielStone]])
+ **4:30pm** | (bof?) | (bof?) | (continuation of previous?)
+ **6pm** | _be social_ | _sunset zoo tour then drinks/nibbles in Mansion House_ | _be social_
+"""]]
+
+
+## Ideas
+
+* Input and related:
+ * Input summary ([[PeterHutterer|PeterHutterer]]): Current state of input, XI2, MPX.
+ * Improving input latency ([[TiagoVignatti|TiagoVignatti]]): Current state of input-thread and other ideas.
+ * Introduction to pointer acceleration: a few slides on ptr accel ([[SimonThum|SimonThum]]; not on sep 5th)
+ * Interactive session: XI 2 Protocol specification Draft 0 ([[PeterHutterer|PeterHutterer]])
+* X.Org Foundation ([[EricAnholt|EricAnholt]], [[EgbertEich|EgbertEich]], [[MatthieuHerrb|MatthieuHerrb]], [[KeithPackard|KeithPackard]], feat. all of [[AdamJackson|AdamJackson]], [[BartMassey|BartMassey]], [[DanielStone|DanielStone]] and [[CarlWorth|CarlWorth]] in spirit): Rough overview of how and what the Foundation's up to, begging for members, etc.
+* Peace full talk on radeon kms, memory management, cache coherency, command submission and various others topics ([[JeromeGlisse|JeromeGlisse]])
+* DRI2 version 2! Now without sarea or locks ([[KristianHøgsberg|KristianHøgsberg]])
+* The Plymouth Graphical Boot Experience ([[KristianHøgsberg|KristianHøgsberg]])
+* State of Gallium3D (TG)
+* Gallium3D, i915 and you ([[JakobBornecrantz|JakobBornecrantz]])
+* Runtime power management of graphics hardware - interfaces and capabilities ([[MatthewGarrett|MatthewGarrett]])
+* Graphics testing ([[GordonJin|GordonJin]]): what community can help on testing, how to file a good bug report.
+* Rah rah Intel rah rah ([[KeithPackard|KeithPackard]])
+* Probably something to do with Mesa ([[EricAnholt|EricAnholt]])
+* Everyone loves OpenGL 3 ([[IanRomanick|IanRomanick]])
+* X.Org 7.5, server 1.6, and similarly cheerful topics ([[EricAnholt|EricAnholt]] with [[AdamJackson|AdamJackson]] and [[DanielStone|DanielStone]] in spirit and possibly heckling via IRC) \ No newline at end of file
diff --git a/Events/XDS2008/Program/gfx_test_xds2008.pdf b/Events/XDS2008/Program/gfx_test_xds2008.pdf
new file mode 100644
index 00000000..0ae039d5
--- /dev/null
+++ b/Events/XDS2008/Program/gfx_test_xds2008.pdf
Binary files differ
diff --git a/Events/XDS2008/Recordings.mdwn b/Events/XDS2008/Recordings.mdwn
new file mode 100644
index 00000000..5ca28ff3
--- /dev/null
+++ b/Events/XDS2008/Recordings.mdwn
@@ -0,0 +1,6 @@
+
+Audio recordings of the 2008 XDS talks were made and posted by Michael Larabel of [[Phoronix|http://phoronix.com/]]:
+
+* [[Day 1|http://www.phoronix.com/vr.php?view=12810]]
+* [[Day 2|http://www.phoronix.com/scan.php?page=news_item&px=NjcwMg]]
+* [[Day 3|http://www.phoronix.com/scan.php?page=news_item&px=NjcwNw]] \ No newline at end of file
diff --git a/Events/XDS2010.mdwn b/Events/XDS2010.mdwn
new file mode 100644
index 00000000..1bbbedac
--- /dev/null
+++ b/Events/XDS2010.mdwn
@@ -0,0 +1,74 @@
+
+
+# XDS2010: Toulouse, France, September 16-18
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2009|Events/XDC2009]] | **XDS 2010** | [[>> XDC 2011|Events/XDC2011]]
+"""]]
+
+[[!img xds2010-color-small.png]
+
+The last X Developers' Summit was held at the University of Toulouse 1 Capitole, in France, during September 16th-18th.
+
+* [[Attendees|Events/XDS2010/Attendees]]
+* [[Program|Events/XDS2010/Program]]
+* [[Notes|Events/XDS2010/Notes]]
+We ran the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities.
+
+
+## Venue
+
+The conference has been held in the "_Colloque - Guy Isaac_" Amphiteather at the old Tobacco Factory (_manufacture des tabacs_ in french) a few hundred meters from the initially planned location.
+
+See the map below for details.
+
+The _Guy Isaac_ amphitheater is in the building **I** on [[this map of the Manufacture des Tabacs|http://www.univ-tlse1.fr/94522330/0/fiche___pagelibre/&RH=FR_01-06]].
+
+
+## Accommodation
+
+On-venue accommodation will not be arranged. However we provide a [[list of hotels|Events/XDS2010/Hotels]] where you should be able to find rooms at reasonable rates. Use the wiki or the mailing list if you'd like to share rooms and need to find roomates.
+
+
+## Travel
+
+Toulouse can be reached:
+
+* By **plane** to the [[Toulouse-Blagnac|http://www.toulouse.aeroport.fr/en]] (TLS) airport. From there you can take the [[flybus|http://www.toulouse.aeroport.fr/airport/access-transport-car-park/access/public-transportation/navette-city-centre]] bus shuttle or a taxi to downtown.
+ The airport of [[Carcassonne|http://www.carcassonne.aeroport.fr/uk/]] (CCF) hosts a low cost company. It's 90km away from Toulouse, but has good train connections.
+* By **train** to the [[Toulouse-Matabiau|http://www.gares-en-mouvement.com/gare.php?gare=frxyt]] station, TGVs run from Paris in 5-6 hours, depending on the schedule. Tickets can be [[purchased on-line|http://www.voyages-sncf.com/]]; as of 2010-08-12, it was possible to get a Paris<->Toulouse round trip in first class for €104, from tgv-europe.com or the much more reliable voyages-sncf.com. Note that the iDTGV is a special 'youth' train, so expect lots of hair gel and bad house music if you book that.
+* Avoid the car if possible. It's difficult and expensive to park in the city center and driving in Toulouse may be a nightmare for those who are only used to large and straight avenues.
+
+## Sponsorship
+
+As usual, we will be running a [[travel sponsorship program|http://lists.freedesktop.org/archives/xorg-devel/2010-August/011776.html]]. If you are unable to afford travel/accommodation on your own, please investigate the cheapest reasonable way for you to get to Toulouse, and let us know a ballpark price.
+
+
+## Registration, talks
+
+If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/events]] for updates; note that as a general-purpose mailing list, this will be reused for future events, so please remember to unsubscribe afterwards if you don't plan on attending future events. Also, please add your name to the [[Attendees|Events/XDS2010/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2010/Program]] page.
+
+
+## Misc, other
+
+Toulouse uses [[Type E/F hybrid|http://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Type_E_.2F_F_hybrid]] plugs (CEE7/7) and [[Euro plugs|http://en.wikipedia.org/wiki/Euro_plug]] at 230V/50Hz. There will no doubt be all kinds of foreign power boards and adaptors floating around, but please do remember to bring your own. The currency is the Euro (EUR), and the language is french. Many shops, bars and restaurant speak some level of English.
+
+[[A Map of Toulouse with the University and a few hotels nearby|http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=109509719165610042544.00046bd61e2c98b82d61e&z=15]]
+
+[[Touristic informations|http://www.toulouse-tourisme.com/accueil/index_en.php]] to visit Toulouse and the area after/before the summit.
+
+
+## Thanks
+
+The X.Org foundation thanks the following sponsors who made the event possible:
+
+* [[Intel|http://www.intel.com]]
+* [[Arcapos.ch|http://www.arcapos.ch]]
+
+## Contact
+
+If you have any problems or questions, please contact Matthieu Herrb -- matthieu DOT herrb AT laas DOT fr
+
+
+## Downloads
+
+* [[XDS2010 SVG logo|xds2010-color.svg]] \ No newline at end of file
diff --git a/Events/XDS2010/Attendees.mdwn b/Events/XDS2010/Attendees.mdwn
new file mode 100644
index 00000000..b03a7e12
--- /dev/null
+++ b/Events/XDS2010/Attendees.mdwn
@@ -0,0 +1,65 @@
+
+
+## XDS2010 Attendees
+
+**Update 2010/09/01**: Registration is now closed the maximum number of participants has been reached. Contact matthieu . herrb AT laas DOT fr if you are not registered yet and really want to attend, to check for opportunities.
+
+Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDS2010|Events/XDS2010]]. Please note that attendance will be limited (50 persons approximatly), so list yourself early to ensure your ability to attend.
+
+Please keep this list in alphabetical order by last name.
+
+ 1. [[OwainAinsworth|OwainAinsworth]]
+ 1. [[ZenoAlbisser|ZenoAlbisser]]
+ 1. [[MarcBalmer|MarcBalmer]]
+ 1. [[JesseBarnes|JesseBarnes]] (Arrive 15 Sept, depart 19 Sept, staying at Le Gran Balcon)
+ 1. [[JakobBornecrantz|JakobBornecrantz]] (Arrive 15 Sept, depart 19 Sept)
+ 1. [[MohamedBoulabiar|MohamedBoulabiar]]
+ 1. [[CyrilBrulebois|CyrilBrulebois]] (tentative)
+ 1. [[AndreaCanciani|AndreaCanciani]]
+ 1. [[RemiCardona|RemiCardona]] (tentative)
+ 1. [[ErwannChenede|ErwannChenede]]
+ 1. [[PingCheng|PingCheng]]
+ 1. [[AlanCoopersmith|AlanCoopersmith]] (Arrive 15 Sept, depart 20 Sept)
+ 1. [[JayCotton|JayCotton]]
+ 1. [[JulienCristau|JulienCristau]]
+ 1. [[MichelDaenzer|MichelDaenzer]] (tentative)
+ 1. [[AlexDeucher|AlexDeucher]] (arrive 15 Sept, depart 19 Sept)
+ 1. [[MattDew|MattDew]] (Arrive 15 Sept, depart 19 Sept)
+ 1. [[ChaseDouglas|ChaseDouglas]]
+ 1. [[DenisDzyubenko|DenisDzyubenko]]
+ 1. [[AlexandrosFrantzis|AlexandrosFrantzis]]
+ 1. [[JeromeGlisse|JeromeGlisse]]
+ 1. [[ChrisHalseRogers|ChrisHalseRogers]]
+ 1. [[MatthieuHerrb|MatthieuHerrb]]
+ 1. [[MatthiasHopf|MatthiasHopf]]
+ 1. [[PeterHutterer|PeterHutterer]]
+ 1. [[KristianHøgsberg|KristianHøgsberg]]
+ 1. [[AdamJackson|AdamJackson]]
+ 1. [[JamesKetrenos|JamesKetrenos]] (arrive 15 Sept, depart 19 Sept)
+ 1. [[MarioKleiner|MarioKleiner]]
+ 1. [[MichaelLarabel|MichaelLarabel]]
+ 1. [[JoséLuisLopezCastillo|JoséLuisLopezCastillo]]
+ 1. [[BartMassey|BartMassey]]
+ 1. Duncan [[McGreggor|McGreggor]]
+ 1. Uros Nedic
+ 1. [[KeithPackard|KeithPackard]] (Arrive 15 Sept, depart 19 Sept)
+ 1. [[MartinPeres|MartinPeres]]
+ 1. Ian Romanick
+ 1. [[JameySharp|JameySharp]]
+ 1. [[EdwardShu|EdwardShu]] (tentative)
+ 1. [[CorbinSimpson|CorbinSimpson]]
+ 1. Maria Starodubtseva (tentative)
+ 1. [[BenjaminTissoires|BenjaminTissoires]]
+ 1. Josh Triplett
+ 1. [[MiodVallat|MiodVallat]] (logistics)
+ 1. [[DanielVetter|DanielVetter]]
+ 1. [[ChrisWilson|ChrisWilson]]
+ 1. Henry Zhao (tentative)
+ 1. Richard Li
+ 1. [[LucVerhaegen|LucVerhaegen]]
+ 1. [[KenGraunke|KenGraunke]]
+ 1. [[TiagoVignatti|TiagoVignatti]] (Arrive 15 Sept, depart 20 Sept, staying at Holiday Inn City Centre)
+ 1. [[TapaniPaelli|TapaniPaelli]]
+ 1. [[GowriRies|GowriRies]]
+ 1. [[PascalAuriel|PascalAuriel]]
+ 1. [[EgbertEich|EgbertEich]] \ No newline at end of file
diff --git a/Events/XDS2010/Hotels.mdwn b/Events/XDS2010/Hotels.mdwn
new file mode 100644
index 00000000..b57be4eb
--- /dev/null
+++ b/Events/XDS2010/Hotels.mdwn
@@ -0,0 +1,137 @@
+
+
+# Hotels in Toulouse
+
+Prices given here are subject to change. Contact the hotel directly to confirm availability and price.
+[[!table header="no" class="mointable" data="""
+**HOTEL DU TAUR** **
+2, Rue du Taur
+31000 Toulouse
+phone: +33 561 21 17 54
+fax: +33 561 13 78 41
+E-Mail: contact AT hotel-du-taur DOT com
+web: [[http://www.hotel-du-taur.com|http://www.hotel-du-taur.com]]
+rate: 50/72 €
+breakfast included
+**HOTEL PATIO WILSON** **
+7, rue Lafaille
+phone: +33 561 62 74 74
+fax: +33 561 99 15 44
+web: [[http://www.hotelpatiowilson.com/|http://www.hotelpatiowilson.com/]]
+E-mail: hotelpatiowilson AT orange DOT fr
+rate: single standard: 61 € single standard large bed: 70 € single superior: 86 €
+Breakfast: 5 €
+**HOTEL DE FRANCE** **
+5, Rue d'Austerlitz
+31000 Toulouse
+phone: +33 561 21 88 24
+fax: +33 561 21 99 77
+E-Mail: contact AT hotel-france-toulouse DOT com
+web: [[http://www.hotel-france-toulouse.com|http://www.hotel-france-toulouse.com]]
+rate: single 63/76 €, double 86 €
+breakfast: 7 €
+**HOTEL VICTOR HUGO** **
+26, Bd de Strasbourg
+31000 Toulouse
+phone: +33 561 63 40 41
+fax: +33 561 62 66 31
+E-Mail: contact AT victorhugo-hotel DOT com
+web: [[http://www.victorhugo-hotel.com/|http://www.victorhugo-hotel.com/]]
+rate: single 73/78 €, double 88/93 €, twin 93 €
+breakfast included
+**HOTEL WILSON SQUARE** **
+12 Rue d'Austerlitz
+31000 Toulouse
+phone: +33 561 21 67 57
+fax: +33 561 21 16 23
+E-mail: contact AT hotel-wilson DOT com
+web: [[http://www.hotel-wilson.com|http://www.hotel-wilson.com]]
+rate: single 64 €, double 74 €, twin 84 €, triple 94 €
+breakfast included
+Free WIFI
+**HOTEL CASTELLANE** **
+17, Rue Castellane
+31000 Toulouse
+phone: +33 561 62 18 82
+fax: +33 561 62 58 04
+E-Mail: castellanehotel AT wanadoo DOT fr
+web: [[http://www.castellanehotel.com|http://www.castellanehotel.com]]
+rate: single/double 74 €, twin 78 €
+breakfast: 8,50 €
+Parking: 10 €/24h
+**HOTEL ALBERT 1er** **
+8, Rue Rivals
+31000 Toulouse
+phone: +33 561 21 17 91
+fax: +33 561 21 09 64
+E-Mail: toulouse AT hotel-albert1 DOT com
+web: [[http://www.hotel-albert1.com|http://www.hotel-albert1.com]]
+rate: 79/98 €
+breakfast: 10 €
+**HOTEL IBIS CENTRE** **
+2, Rue Claire Pauilhac
+31000 Toulouse
+phone: +33 561 63 61 63
+fax: +33 561 63 07 46
+E-Mail: H1429 AT accor-hotels DOT com
+web: [[http://www.ibishotel.com|http://www.ibishotel.com]]
+rate: week: 94 €, week-end: 69 €
+breakfast: 7,50 €
+Free WIFI
+**Citadines Toulouse Wilson**
+8, boulevard de Strasbourg
+31000 Toulouse
+phone: +33 534 41 75 00
+Fax: +33 561 99 07 55
+E-mail: wilson AT citadines DOT com
+web: [[http://www.citadines.com/fr/france/toulouse/wilson.html|http://www.citadines.com/fr/france/toulouse/wilson.html]]
+rates: Studio (2 pers.): 90 € / 2 rooms (4pers.): 132 €
+**HOTEL de BRIENNE** ***
+20 Boulevard Maréchal-Leclerc
+31000 Toulouse
+phone:+33 561 23 60 60
+fax: +33 561 23 18 94
+E-mail: direction DOT hoteldebrienne AT wanadoo DOT fr
+web: [[http://www.hoteldebrienne.com|http://www.hoteldebrienne.com]]
+rate: 81/93 € (week), 70/80 € (week-end)
+breakfast: buffet 10 € or continental 5 €
+**HOTEL MERMOZ** ***
+50, Rue Matabiau
+31000 Toulouse
+phone: +33 561 63 04 04
+fax: +33 561 63 15 64
+E-mail: reservation AT hotel-mermoz DOT com
+web: [[http://www.hotel-mermoz.com|http://www.hotel-mermoz.com]]
+rate: single or twin 99 €
+breakfast: 14 €
+Free WIFI
+Private parking: 12 €
+**HOTEL MERCURE MATABIAU** ***
+Boulevard Pierre-Semard
+31000 Toulouse
+phone: +33 534 41 36 70
+fax: +33 534 41 36 71
+E-mail: H1259 AT accor DOT com
+web: [[http://www.mercure.com|http://www.mercure.com]]
+rate: single 95 €, double 105 €
+breakfast: 13 €
+**HOTEL MERCURE ATRIA** ***
+ Boulevard Lascrosses
+ 31000 Toulouse
+Phone: +33 561 11 09 09
+fax: +33 561 23 14 12
+E-mail: H1585 AT accor DOT com
+web: [[http://www.mercure.com|http://www.mercure.com]]
+rate: 121/153 €
+breakfast: 15 €
+Free WIFI
+**HOTEL HOLIDAY INN (CAPOUL)** ***
+13, Place Wilson
+31000 Toulouse
+phone: +33 561 10 70 70
+fax : +33 561 21 96 70
+E-mail: hi AT capoul DOT com
+web: [[http://www.hotel-capoul.com|http://www.hotel-capoul.com]]
+rate: 141/194 €
+breakfast: 16 €
+"""]]
diff --git a/Events/XDS2010/Notes.mdwn b/Events/XDS2010/Notes.mdwn
new file mode 100644
index 00000000..1dbd51b0
--- /dev/null
+++ b/Events/XDS2010/Notes.mdwn
@@ -0,0 +1,615 @@
+
+IRC transcript of the notes from XDS2010.
+
+
+## Thursday, September 16
+
+
+### Board (Alan Coopersmith, Matthieu Herrb)
+
+
+[[!format txt """
+<@ajax> right, intro over, board presentation time
+<@ajax> board is alanc, mherrb, dberkholz, agd5f, anholt, keithp, bart massey
+<@ajax> the foundation exists to make life easier for X developers (conference travel and sponsorship, nda documentation, etc)
+<@ajax> vote in the next board election! become a member to do that if you're not already.
+<@ajax> currently mostly working on the 501(c)3 paperwork
+<@ajax> also working on trademark issues. apparently some brazilian company has a logo that looks very similar to the current X logo?
+< daniels> yeah, it's in the meeting minutes
+<@ajax> general opinion is the current logo is too ugly to be worth fighting for, so, looking for new designs
+<@ajax> (mhopf is also on the board, apologies for leaving him out)
+<@ajax> SoC student and anybody else: if you have things you want to work on that require funding for equipment, let the board know! that's what they're there for.
+<@ajax> question from (i believe) libv: how's the paperwork situation?
+<@ajax> background is that we need ~5 years of paper trail for the bank account for the 501(c)3 switch
+<@ajax> paperwork was still going to leon's house and getting thrown away; only last 11 months easily available from the bank, so stukreit harassing the bank to get that filled in
+<@ajax> egbert says he has the records through 2006ish
+<@ajax> board also looking into xts5 licensing, it's under non-clarified artistic which is non-dfsg and non-osi
+<@ajax> http://wiki.x.org/wiki/BoardOfDirectors/MeetingSummaries/2010/08-17
+<@ajax> questions for the board: board@foundation.x.org
+<@ajax> watch for election announcements soon, four seats up for election every year. run if you have the time, vote if you don't.
+< alanc> http://www.nettv.tv.br/images/stories/logo.gif is the brazilian tv logo in question, rendered much shinier than ours
+"""]]
+
+### DRI2 updates (Jesse Barnes)
+
+
+[[!format txt """
+<@ajax> dri2 landed about 18 months ago
+<@ajax> pretty reasonable but lacked support for some of the common glx extensions (page flipping and other swap control stuff)
+<@ajax> DIR2SwapBuffers through DRI2SwapInterval in dri2proto.h are new
+<@ajax> also, two new events
+<@ajax> SwapBuffers was originally a round trip, is now just a normal async request
+<@ajax> has (protocol) support for scheduling future swaps, either as msc frame number or divisor/remainder like in the sgi glx extensions
+<@ajax> DRI2GetMSC (media sync counter) to get the current frame number
+<@ajax> DRI2WaitMSC to wait for a particular frame
+<@ajax> DRI2WaitSBC to wait for a particular swap (SBC == Swap Buffer Counter)
+<@ajax> DRI2SwapInterval to (obviously) set the swap interval for throttling
+<@ajax> events: BufferSwapComplete and InvalidateBuffers
+<@ajax> apps never really see any of these, these are all just to support the GLX extensions
+<@ajax> lots of new hooks for the drivers to support these, see hw/xfree86/dri2/dri2.h for details
+<@ajax> (wow, documented function pointer hooks! mad props to jbarnes)
+<@ajax> drivers have some leeway to optimize flips (eg if src and dst are both screen-sized)
+<@ajax> intel implementation: drm file descriptor can give you events on swap events and etc, so just select() on it
+<@ajax> intel impl will also block if it tries to do any further GL after a swap
+<@ajax> question from keithp: how much parallelism does that actually allow?
+<@ajax> well, we don't have any real data, but that tends to be what the toolkits and games do: swap, compute the new scene, then resume more GL commands
+< airlied> tap tap is this thing on?
+< airlied> ajax: q from down under, what about triple buffering?
+<@ajax> (some discussion about where blocking actually happens and etc.)
+<@ajax> dileks: not that i'm aware of
+<@ajax> triple buffering: "all the code is there for that..."
+<@ajax> still some issues in implementation, so, not actually done.
+<@ajax> qquestion from the room (wish i could remember this person's name): why don't you want vblank events on every frame?
+<@ajax> well, because it's expensive, you keep the CPU awake so you can't stay in deep sleep states. but you will get every frame event you ask for, so if you're rendering continuously it's the same as getting them all the time.
+<@ajax> another room question: no events for render completion?
+<@ajax> not in DRI2, but GL sync events do give you that.
+<@ajax> but that is planned, since you do want it for a) async main loop type toolkits, b) ordering between rendering APIs. (gl sync only gives you query and block, not events)
+<@ajax> ("GL sync events" above are not events in the X protocol sense)
+<@ajax> some discussion about details of how you actually put the swap to the hardware: in the command ring, or through an mmio write
+<@ajax> ie, does the hardware accept the mmio write immediately or does it effectively get queued anyway
+<@ajax> (all in the context of fairness among clients)
+<@ajax> (audience participators: tapani paelli, mario kleiner)
+<@ajax> (also owain ainsworth, i believe)
+<@ajax> relevant wiki page: http://dri.freedesktop.org/wiki/CompositeSwap
+<@ajax> hint to app writers: OML_swap_method is part of the fbconfig, which means we basically have to report "unknown" since swap method can change at runtime
+<@ajax> all the above is about BufferSwapComplete
+<@ajax> InvalidateBuffers: glViewport used to be the trigger for getting buffer coords and clip
+<@ajax> but that can change multiple times per frame, and it's roundtrips, and it's not really correct anyway since Viewport isn't a clip and rendering outside it should show up
+<@ajax> so InvalidateBuffers is a new event to tell the clients about buffer changes as they happen instead
+<@ajax> SwapBuffers _is_ a round trip right now, though it could be request/event, because you need the sync point with the server; otherwise client doesn't know what buffer to render into
+<@ajax> yet more discussion about particular bits of hardware and optimising
+"""]]
+
+### Documentation (Matt Dew)
+
+
+[[!format txt """
+<@ajax> speaker background: linux geek, electrical engineer by trade, recently back to school
+<@ajax> started working on documentation as a break from studies, emailed bart asking how to help, got a response! oh my.
+<@ajax> X seemed to be really understaffed, wanted to help grow the developer pool, and be a part of something important
+<@ajax> was it hard to get involved? yes!
+<@ajax> why? intimidating, seems complicated (crowd: yeah, it kind of is!), no idea what to do or who to ask or where to look
+<@ajax> bart and gaetan kept replying to emails and giving encouragement
+<@ajax> mostly working on organizing information. gathering what already exists, and making it findable and searchable. not really working on new content except for TOCs etc.
+<@ajax> from thinkwiki: "As usual with X, good documentation is hard to find"
+<@ajax> why not me? spend lots of time reading specs and white papers, so appreciate good docs. also spent some time writing it, realize it takes effort.
+<@ajax> why documentation? because it really really matters.
+<@ajax> http://stashbox.org/122385/xorg%20architecture2.pdf
+<@ajax> (and then we all check out that pdf and say "yeah that's too simple")
+< vignatti> jbarnes: for sure is manually done, this diagram
+<@ajax> question (jay cotton i think): what are you trying to document?
+<@ajax> "anything that's useful", but that's also not an easy question
+< alanc> yes, thats jay
+<@ajax> alanc: the ferrari mouse was a giveaway
+<@ajax> (presenter's focus possibly more about "how to write an app to use this stuff" rather than "how do you implement it")
+<@ajax> so, mostly working on rounding up existing documenttion rather than writing new stuff; the docs _are_ findable, but only if you find it can you use it
+<@ajax> then, searchability, toc/index, structure, de-duplication.
+<@ajax> after that, start filling in the holes.
+<@ajax> also trying to convert things to a consistent file format; still not complete consensus on what the right format is, but framemaker is not it
+<@ajax> aside: hey developers, use doxygen comments
+<@ajax> docbook conversion: changing from/to and why, what's involved, what's done, what's left
+<@ajax> major formats: troff, tex, docbook, framemaker, asciidoc
+<@ajax> moving to docbook/xml, at lrast just to have one instead of five.
+<@ajax> (aside from whot earlier: authoring tools for db/xml would be nice)
+< dottedmag> ajax: Q: does it include protocol specs?
+<@ajax> status: troff done, tex done, db/sgml in progress, framemaker needs someone to export, others unfinished
+<@ajax> dottedmag: "it"?
+< dottedmag> ajax: conversion
+<@ajax> yes.
+<@ajax> by mid-january aiming for finishing the conversions, proofreading, crosslinking, and css-ization
+<@ajax> after that: diagrams, picking a docbook tag subset, style, what goes in book vs wiki
+<@ajax> BFTBX: Big [mutter] Turquoise Book of X
+<@ajax> complete book of everything you could want to know (that doesn't change that much). note: project, not a real artifact yet.
+<@ajax> more future: wiki organization
+<@ajax> open questions: what's missing? (man, if only we knew) what's going to be documented? eventually, everything, but wants some prioritization
+<@ajax> timeline: summer of 2012 docs should be good if not great. "great" is a not sure.
+<@ajax> http://www.osource.org/xorg - temporary wiki
+<@ajax> _temporary_. going away.
+<@ajax> but the stylesheet sure is nicer
+<@ajax> question from jay: how do you purge everything else from the web that's wrong?
+<@ajax> well, you don't, but you just make sure everything on the X wiki is authoritative
+< alanc> helps if ours is less wrong than everyone elses
+<@ajax> tapali comment: currently writing some docs on dri2 development, need review for whether it's actually correct enough
+<@ajax> if anybody wants to help with this, talk to matt! no, really, we will love you forever.
+<@ajax> matt@osource.org
+<@ajax> and there's plenty of work to do
+<@ajax> use xorg-devel@ for the moment, will split off list later if necessary, but for now probably best to keep it in one place
+<@ajax> remarkable number of newbies at the conference, ~1/5 or so. what was useful to those people?
+<@ajax> blog more! example of agd5f's radeon get-started blogs.
+<@ajax> ideally would like to have content _in_ the wiki, not just a collection of links; but do send links to source documents
+"""]]
+
+### Development process (Peter Hutterer, Keith Packard)
+
+
+[[!format txt """
+<@ajax> mostly motivated by various failings in releases; bad schedule follow-through, quality issues, content definition, etc.
+<@ajax> wasn't satisfying either distro maintainers or driver developers
+<@ajax> whot put together release process document; no real surprises in it nor any major discussion
+<@ajax> as projects become more central to the OS they seem to naturally develop a formal release process, so, it was time.
+<@ajax> keithp as release manager is really trying to be just quality control not content control
+<@ajax> first phase is pretty wide open, change whatever, as long as there's rough consensus.
+<@ajax> second phase is more bugfix oriented, abi changes and such are still acceptable but needs to be bug focused.
+<@ajax> third phase is stabilization
+<@ajax> aaronp now actually monitoring ABI and asking when/if we're ABI stable. woo!
+<@ajax> third phase is where we're really saying distros should start testing; regressions at that point _will_ get looked at
+<@ajax> "blocker" is sort of a misnomer, more of a tracker
+<@ajax> really only security regressions would be a serious release blocker
+<@ajax> comment from libv: we still see a pretty large vendor merge window, wasn't that the promise of m12n?
+<@ajax> ajax and mherrb: we try to merge down but there's portability issues that prevent a lot of those.
+<@ajax> so you oscillate
+<@ajax> jamey says "patchwork was a huge win for me, once i filter down to just my patches, but it seems underused"
+<@ajax> request for keith to reply to anything that gets merged
+<@ajax> stable branch maintainers (jeremy and ajax for 1.9) need your help, cc them on stable-worthy candidate
+<@ajax> (s)
+"""]]
+
+## Friday, September 17
+
+
+### Multitouch session
+
+
+[[!format txt """
+<@ajax> got to the multitouch talk late, sorry about that
+<@ajax> let's see if i can't backfill from what i heard since coming in
+<@ajax> unlike mpx, you have to glue all the touch points together as one device, since otherwise you have to do device create/destroy notifies for every touchpoint, which will wake up every client and that's lame
+<@ajax> multitouch and gestures are actually separate things, there are plenty of use cases that want multiple touches without gestures
+<@ajax> touch and pointer events are probably separate things; pointer and touch grabs would ignore each other, if A has a pointer grab B would still recieve touch events
+<@ajax> event replay makes for many weird issues, events can get delivered out of order
+<@ajax> some devices can report events as bitmaps (actually rgb images); ouch, imagine queueing all that up in the server until the events replay
+<@ajax> "everyone wants multitouch, but nobody wants multitouch"
+<@ajax> experience with app development is that they end up 99% singletouch with a sprinkling of pinch/zoom or similar
+<@ajax> mt probably not going to happen for 1.10
+<@ajax> multitouch workshop earlier in the week was mostly violent agreement for the short term and then fuzzier after
+<@ajax> timeline is hard to predict; chase should have more time for it after maverick, daniels working on it, so, _something_ will happen.
+<@ajax> ms surface has a ui principle of "no touch left behind", every touch has visual feedback. otherwise people think the app is broken and poke the screen harder and harder
+<@ajax> only ~5 gestures are intuitive (swipe, pinch/zoom, etc); after that the UI needs to give feedback to show what's happening
+<@ajax> (some technical discussion about how to draw that feedback, hardware cursors or ...)
+<@ajax> how do we help? test! write an actual app and find out how it doesn't work.
+<@ajax> peter's not an app guy or a toolkit guy, so he's kind of driving blind without that kind of feedback
+"""]]
+
+### Gestures session
+
+
+[[!format txt """
+<@ajax> "gestures" here means intuitive gestures only (again, as above, pinch zoom swipe rotate etc), not "magic" gestures like draw a star to close an app
+<@ajax> general consensus that gestures need to be client-side for the most part, X just demuxing events
+<@ajax> which isn't how it works now, but, getting there
+<@ajax> mtdev: multitouch tracking translation library. eats raw multitouch data (tracked or not), emits tracked data and filtered coordinates
+< whot> http://bitmath.org/code/mtdev/
+<@ajax> utouch-grail: gesture recognition and instantiation library. eats tracked touches, emits gestures if they're recognized or passes through if not
+<@ajax> gestures only emitted if the client has expressed interest in _that_ gesture (if you don't care about rotates, you won't get them)
+<@ajax> utouch-geis (pronounced like "geist" without the t): gesture engine interface support. input is platform-specific gesture events, output is common gesture event interface.
+<@ajax> geis is api for apps to register for gestures
+<@ajax> (architecture diagram)
+< remi|work> could someone in the room point out that Metisse has infrastructure for that? it already supports gestures (done with the mouse) which you can "cancel" if you've messed up, in which case metisse replays the mouse events for the underlying windows
+ * whot waits for ajax asciiart skills
+< remi|work> not that I'm pushing for Metisse directly, the code is a mess and I wouldn't force it on anyone other than me :D
+<@ajax> xcb-gesture is private implementation-detail protocol to get this out of xserver up to geis and unity
+<@ajax> another architecture diagram, this one moves stuff out to client side
+< whot> remi|work: discussion on what is mettise ensues :)
+<@ajax> motivation is about pluggable gesture recognizers and keeping complexity out of the server
+< remi|work> whot, may I assume you've described what it does? :)
+< whot> ajax did, roughly, yes
+< whot> metisse is not something easily explained in 30 sec :)
+< remi|work> haha, right :P
+< remi|work> well the 2 core features are window compositing and per-window input redirection
+< remi|work> the rest is just fluff :)
+<@ajax> unity has a use model where 3 and 4 finger gestures are window and environment controls, so want to make those things that you "unlock"; how do you design that well? not really clear.
+<@ajax> whot points out that direct (touchscreen) and indirect (touchpad) multitouch are pretty different usage models, not clear that you want to conflate them.
+<@ajax> list of hardware with interface style and number of touches
+<@ajax> big categories are touchscreen, trackpad, and apple magic mouse.
+<@ajax> (demo)
+<@ajax> question: have you seen any blob devices? (shrug, no)
+<@ajax> usual licensing discussion
+"""]]
+
+### XCB session
+
+
+[[!format txt """
+< JoshTriplett> So, notes from the XCB BoF...
+< JoshTriplett> "Apparently XTS uses some interface in Xlib which allows direct use of the X protocol, and this doesn't exist in Xlib/XCB."
+<@ajax> hey xcb people, have you looked at this: https://bugs.freedesktop.org/show_bug.cgi?id=29657
+< JoshTriplett> Discussion attempting to find out what interface...
+< krh> ebassi: right
+< JoshTriplett> "Perhaps someone should port XTS to XCB natively?"
+< JoshTriplett> ajax: Yes, we have, and we're in the process of giving that some thought.
+< remi|work> JoshTriplett, you're filling in for ajax ?
+< JoshTriplett> remi|work: Yes, it seemed appropriate for a BoF to note discussion and show it on the projector.
+< JoshTriplett> So if you have questions for the BoF or the room, pretend you're here and ask. :)
+< JoshTriplett> The room will see it.
+<@ajax> i like the sherrif's star next to my nick. that might be the only thing i like about xchat.
+<@ajax> wait, that's not xchat, is it.
+< JoshTriplett> ajax: Pidgin.
+< alanc> it was already mentioned that Xlib 1.4 (RC1 out now, final release out RSN) will always have the XCB integration and no longer support building without it
+< JoshTriplett> alanc: Thanks for making sure that didn't get missed.
+< alanc> ajax: xchat gives you green balls, not sheriff's stars
+< remi|work> JoshTriplett, Q: "plans for API/ABI stability in xcb and various other libs (eg, never ever change like libX11? or perhaps majors breaks every now and then?)
+< remi|work> "
+< JoshTriplett> Current discussion: Handling of events in Qt and GTK+, and non-incremental porting of the event handling from Xlib to XCB.
+< JoshTriplett> remi|work: queued.
+< remi|work> thanks
+< mbalmer> Bonjour from row 3, seat 6729.
+< JoshTriplett> Q from ajax: "What about XIfEvent, why can't we look ahead in the XCB event queue?"
+< remi|work> JoshTriplett, (not sure if this is the right BoF for this question) "Is anyone working or planning to work on cairo xcb/xlib-xcb ?"
+< JoshTriplett> A: "You should process events in order, and if you really want a queue, you can build one on top of XCB."
+< JoshTriplett> remi|work: sure.
+< JoshTriplett> Followup: "You can't always process input events in order, you might need to look ahead."
+< JoshTriplett> "You can just handle that via the callbacks after the event receipt..."
+< JoshTriplett> "...just queue a callback later, don't forward the event into the application"
+< JoshTriplett> "Effectively you can get motion compression"
+< alanc> this is the sort of thing we need to document as recommendations/best practices
+< JoshTriplett> Followup from ajax: "Having to port all of the event handling at once seems painful"
+< JoshTriplett> A: "Not trivial to demux events to Xlib and XCB simultaneously, you have to pick one"
+< JoshTriplett> Much discussion about Xlib and XCB's event queue.
+< JoshTriplett> "The main problem: Xlib's event queue is a data structure in the Display structure"
+< JoshTriplett> "keithp: Don't move events out of XCB, copy them out of XCB"
+< JoshTriplett> remi|work: Discussion in the room about the answer to your question: "yes, we intend to guarantee API/ABI stability for libxcb since the 1.0 release; we might add new functions but we won't break existing ones"
+< JoshTriplett> remi|work: Currently discussing cairo.
+< remi|work> JoshTriplett, many thanks :)
+< JoshTriplett> note from ajax: "You have a bajillion libraries"
+< Kayden> remi|work: (however, it was noted that xcb-util is still very much an experimental playground, and is not API/ABI stable)
+< JoshTriplett> Kayden: Thanks. Yes, though things split *out* of xcb-util should provide API/ABI stability.
+< remi|work> indeed, that's the one I had in mind
+< JoshTriplett> "ajax: ~31 libxcb-* libraries, each one wastes 3 fragments of pages due to shared libraries"
+< JoshTriplett> "ajax: We should be using ELF filters, which let us expose the same API/ABI of various libxcb-*.so libraries but have them live in a single libxcb-ext.so"
+< JoshTriplett> General consensus that that seems like a *great* idea.
+< JoshTriplett> Question for the IRC channel: who did the SoC work on XKB? Was that mceier?
+< remi|work> ajax, care to tell how that works when you have a minute? I'm curious
+< vignatti> ELF filters sounds so hacky
+< whot> mceier: you did xcb input GSOC, right?
+< mceier> mceier: yes, I've done the XML part.
+< mceier> :p
+< JoshTriplett> "keithp: Keep libxcb and the extensions in the same library, don't bother with a separate libxcb-ext either"
+< whot> mceier: well, you're on TV now :) what's the current state of XI and XKB in XCB?
+< JoshTriplett> mceier: IRC is on the projector at XDS right now. :)
+< whot> your 15 minutes of fame
+<@ajax> vignatti: hey man, you're the anti-size queen.
+<@ajax> i'm on your side here.
+< vignatti> ajax: I' am. And I don't want a couple of unused extensions for my system though in one single library
+< vignatti> :)
+<@ajax> so build them out.
+< mbalmer> tiago++
+< oga_> oh no, you might have a couple of K disk space wasted.
+< oga_> or just don't build them, indeed
+< vignatti> okay, we'll need a configurable way to do so then
+< JoshTriplett> vignatti: We have that.
+< vignatti> sweet
+< JoshTriplett> vignatti: configure options
+< vignatti> JoshTriplett: I hope we don't get in the same state as xserver configure options disaster though :)
+< JoshTriplett> :)
+< mceier> well the XML part is complete, although it's not tested - it needs an implementation of some new tags in XML->C generator.
+< mceier> like <switch> :)
+< JoshTriplett> "ajax: I can try to find out how long ELF filters have been supported in binutils"
+< JoshTriplett> (In response to the note that some embedded systems use antique binutils and such that might not support ELF filters.)
+< JoshTriplett> mceier: Thanks!
+< JoshTriplett> Sounds like XI has similar need for <switch>, though somewhat less insane than XKB (not hard to do).
+< JoshTriplett> Discussion about API/ABI of extension libraries when the extension revs the protocol.
+< JoshTriplett> Question of whether anyone cares about supporting multiple extension versions simultaneously. "ajax: mmmm, no"
+< JoshTriplett> "ajax: but some library systems make it possible to support multiple library versions"
+< JoshTriplett> General consensus from the room: protocol extensions should not break backward compatibility, whether it bumps the major or minor number. Always change the name of the extension; e.g. DRI2, XI2...
+< krh> but never DRIng
+< JoshTriplett> This certainly makes XCB's job easier; libxcb-xi2 versus libxcb-xi
+< krh> "next generation" is verboten
+<@ajax> IGDNG!
+< oga_> IGD was just worse
+< oga_> you mean like.... ALL OF YOUR GRAPHICS DEVICES?
+< JoshTriplett> Wave goodbye to the room. :)
+< ickle> but IGDNG^W sandybridge!
+< alanc> Further consensus from the room: "rootless" sucks as feature name, call it "unprivileged" or "hosted"
+< Kayden> clearly IGDNG5...like R5RS :)
+< mbalmer> or non-root...
+< tilman> alanc: yay
+< Kayden> (revised revised revised revised revised report on Scheme...)
+< alanc> mbalmer: non-root-user or non-root-window ?
+< mbalmer> yeah, that's confusing...
+"""]]
+
+### Unprivileged X
+
+
+[[!format txt """
+<@ajax> apropos of which, next talk is on unprivileged X
+<@ajax> major question is input. you have to trust whatever opens the input device.
+<@ajax> (you have to trust the X server to close input devices on the way off the vt)
+< alanc> Keith's requirements: 1. No display server should be privileged - should not have control of which server gets input events from devices
+< mbalmer> Hmm, I think this input switching problem could be solved in a rather elegant way, at least I knew how I would approach it in the BSD kernel (and I assume in Linux it's not hard either)
+<@ajax> details about where we put that mechanism: cgroups or whatever
+< oga_> mbalmer: how?\
+< oga_> krh: btw, your flink_to idea a while back was sound, what happened to that?
+< krh> oga_: the linux kernel got released earlier than expected so I stopped working on it for a bit
+< JoshTriplett> flink_to sounds like an interesting call; link file descriptor to new filename?
+< mjg59> krh: Yeah, shipping in 1991 was kind of unexpeted
+< oga_> JoshTriplett: no, this is gem filehandle stuff
+< JoshTriplett> ah.
+< oga_> krh: I was thinking of something similar about a year ago, we should move forward on that
+< krh> JoshTriplett: yeah, flink_to for fds makes sense too
+< JoshTriplett> "ajax: My model assumes code injection attacks don't happen" (between processes running as the same user)
+< JoshTriplett> "keithp: So you want security theatre?"
+<@ajax> someone else keep writing notes
+< alanc> 3 issues: 1) switching input devices between servers 2) switching front buffer control 3) RunFromSmartParent
+< alanc> Wayland is the answer to everything, as long as you can afford another 1000 context switches/second
+< mbalmer> for every byte send from a mouse, oh my....
+< oga_> it is wayland all the way down
+< whot> mhmmm, turtles... *drool*
+"""]]
+
+### EGL in Mesa
+
+
+[[!format txt """
+<@ajax> gl is just a rendering api, you also need window system bindings (wgl, agl, glx, etc0
+<@ajax> egl is "embedded" gl, useful for when there's no window system, but is also used to be agnostic of your window system.
+<@ajax> since all the binding apis are fairly similar, it's easy to implement egl interms of say glx
+< bobo1on1> egl is to gles what glx is to gl right?
+<@ajax> ennh.
+<@ajax> egl can encapsulate lots of rendering apis. vg, gles, gl proper...
+<@ajax> gles (embedded subset) comes in fixed-function gles1 and programmable gles2
+<@ajax> mesa can implement the gles api in terms of dri drivers
+<@ajax> egl has an image extension for sharing pixels across APIs
+<@ajax> which works in mesa! yay. gallium drivers can even do vg (well, they have a state tracker for it anyway)
+<@ajax> mesa extension to image extension to create your own image objects (normally you have to pull them out of a rendering api), with hints like "am i scanout" or "am i shared between processes"
+<@ajax> these map pretty directly to gem objects
+<@ajax> working on official khronos extension for image sharing across processes
+<@ajax> useful for accelerated compositing in separate processes
+<@ajax> mesa can create contexts for a particular api (gles or full gl, etc)
+<@ajax> demo: es2gears under X
+<@ajax> (tsk, only 360fps)
+< whot> ajax: those are metric seconds though ;)
+< MrCooper> FWIW the Mesa VG demos have worked for me with r300g, should be easy to get it working with any other Gallium driver
+< RAOF> The Mesa VG demos have worked for me with nvfx and r600g, also.
+"""]]
+
+### Board meeting
+
+
+[[!format txt """
+<@ajax> people have started sending submissions for new logos? weird,.
+<@ajax> minor legal issues around signing over rights etc.
+<@ajax> so if someone wants to help organize that, please do talk to the board (contest etc)
+<@ajax> $3000 in checking, $120k-ish in stash, paid out $13500 ish in sponsorships and travel
+<@ajax> did agree to sponsor an xcb workshop, though there's no date for that
+<@ajax> again, willing to sponsor special-topic workshops, if you have ideas talk to the bord
+<@ajax> board@foundation.x.org
+<@ajax> checks for xds sponsorships are in keithp's bag, so, bother him if that applies to you
+<@ajax> possibility to hold next xdc in brazil? difficult for travel reasons, but possible.
+<@ajax> possible colocation/contemporary with bossa or fisl
+<@ajax> really needs local organizer though
+<@ajax> tiago says there are brazilian nokians that could probably do organization
+<@ajax> some discussion about costs
+<@ajax> other suggestion to colocate with desktop conference in (berlin? germany anyway)
+< vignatti> actually Bossa been happening lately in March
+<@ajax> no real decision yet; send suggestions to the board, either in email or at the irc board meeting
+"""]]
+
+## Saturday September 18
+
+
+### OpenGL baseline
+
+
+[[!format txt """
+< alanc> inspired by blog from KDE developer about what OpenGL calls work in various open source drivers
+< alanc> need to better to communicate what we expect to work
+< alanc> can we just fix bugs to get closer to actually having full OpenGL 3.0 support? we're maybe 90% there
+< airlied> alanc: question from outside, if AMD/Nvidia have any interesting contributing to piglit
+< airlied> from the closed source side of the companies
+< alanc> not sure anyone came from those groups
+< airlied> well ask if the guys there can make the closed guys more aware of it
+< alanc> agd5f says that asking them to contribute to piglit would be a good idea
+< alanc> (this is a discussion session, not a presentation, so it's hard to keep up with IRC notes, especially as it broke into sub-conversations)
+< alanc> there is a discussion thread that getting more people in general contributing to piglit would be good
+"""]]
+
+### libxkbcommon
+
+
+[[!format txt """
+< alanc> "it's all daniels' fault"
+<@ajax> xkbcomp as a library, more or less
+<@ajax> which takes your xkb configuration and turns it into the big map from keycode to keysym
+<@ajax> krh working on giving it an actual api instead of being just a pile of structus
+<@ajax> we're not using it at the moment in the X server, but boy we really should be
+<@ajax> (right now there's a popen() adventure that's quite disgusting, go read it if you're into schadenfreude)
+<@ajax> not completely straightforward to use in xlib, since xlib has its own xkb api that we can't break; but it could happen
+< whot> acronyms galore
+<@ajax> xcb has no xkb support yet, this could help.
+<@ajax> and, of course, if you happen to be writing your own display server for some reason, you could use this to import X's keyboard layout support
+<@ajax> so that's also cool
+< alanc> but you'd have to be crazy to be writing your own display server
+<@ajax> so, do we actually use this or not?
+<@ajax> general consensus that we really do need to make xserver use it if we want to claim it's usable at all
+<@ajax> ~3 versions right now (daniels, krh, dbn) so we need to pick and/or unify those
+<@ajax> "i'm sure we could write a better parser, but then... we'd be writing an XKB parser"
+<@ajax> discussion about possibly keeping a binary form of the text files around to at least cut the parsing time out of the profile
+<@ajax> rough consensus: yeah, probably, and it might as well be the wire protocol format if we do that since we know it's sufficient
+<@ajax> daniels does have an xserver branch up that's ported to xkbcommon
+"""]]
+
+### Input threads impromptu
+
+
+[[!format txt """
+< oga_> friends don't let friends call ioctl from sigio
+<@ajax> aside on input threads
+<@ajax> basically we want "threads or classic" instead of the current "sigio or classic"
+<@ajax> no one seems to have a problem with _that_, but there's some doubt that non-classic is actually a win
+<@ajax> to the doubters, go find X11R1 and build the plaid demo, and you'll be convinced
+< oga_> sure, i'm game
+< oga_> don't suppose you have a url to save me the search engine latency?
+< alanc> http://www.x.org/archive/
+< oga_> found a copy. imake isn't behaving though
+< alanc> we could probably autotool it in about 10 minutes if we cared
+< oga_> feh,
+< oga_> oga@melanie/p4:/tmp/X.V11R1/demos/plaid$ ./plaid
+< oga_> Cannot open display
+< oga_> : Undefined error: 0
+< oga_> EGIVEUP
+< oga_> oh, no fixed it
+<@ajax> also, CLOCK_MONOTONIC_COARSE is way way cheap, so we should use that for the tick source when it's available (and HZ is high enough)
+<@ajax> anyone still using a HZ of 100, seriously fix your kernel.
+< leio> 250 or 300 good enough? :P
+< oga_> may play with that soon
+< RAOF> Hm. Ubuntu kernel seems to be set at 100Hz.
+< oga_> i wonder how many hardcoded bugs I find
+<@ajax> threads won't be universally deployed since they're not a win if you have userspace threads (openbsd eg)
+<@ajax> or if you don't have threads (mingw we think)
+<@ajax> also general consensus that the current main loop is lame and libevent would be better
+< oga_> as mentioned a couple of days ago, if no one else gets to it before me then it is on my to-do\
+< oga_> but my hacking latency right now is worse than my machine running plaid
+"""]]
+
+### Intel DRM for OpenBSD
+
+
+[[!format txt """
+<@ajax> gem is like the buffer cache but for gpu instead of disk
+< mbalmer> nice slides he has...
+<@ajax> despite the drm code being MIT-licensed, it's not directly portable
+<@ajax> mostly because the vm's are different among OSes
+< alanc> that matches the experience of the folks porting DRM to the Solaris kernel as well, having yet another VM system
+<@ajax> obsd does gart mapping directly on the object instead of being under the drm fd
+<@ajax> cache coherency and tiling are handled differently, tiling is handled entirely by kernel instead
+<@ajax> netbsd could probably c/p the drm code since the vm is relatively similar, freebsd would have more issues
+<@ajax> kms is a ways off still
+<@ajax> (discussion of how kms and fbdev interact under linux and what the parallel would be under bsd)
+<@ajax> only want one DRI implementation in the kernel so need to get radeon converted to DRI2 before looking at KMS for real
+"""]]
+
+### Mesa feature requirement/removal
+
+
+[[!format txt """
+<@ajax> possible things to mandate:
+<@ajax> ARB_copy_buffer - trivial addition after ARB_vertex_buffer_object which is always enabled
+<@ajax> ARB_map_buffer_range - ditto
+<@ajax> APPLE_object_purgeable - maybe ditto? needs another look at the spec.
+< alanc> screen is showing http://www.x.org/wiki/Events/XDS2010/Program#line-93
+<@ajax> bah, i thought it was still just a preview.
+< alanc> oh, I guess it does say #preview up there, wonder what they've edited since the last save
+<@ajax> object_purgeable might be tricky since apps might be aggressive with it present and conservative without? who knows. possible drirc if it's a problem.
+<@ajax> ARB_vertex_array_object is also easy
+< oga_> oh, with purgable if you worry about that just always purge
+<@ajax> ARB_draw_elements_base_vertex is well fakeable on hardware that can't support it; do we care?
+< oga_> the idea is that stuf can be recalculated anyway, but you cache it while you have memory free
+<@ajax> SGIS_generate_mipmaps too
+<@ajax> don't know if we have sufficient tests in piglit ot glean for these?
+<@ajax> earlier discussion (about gl support) mostly concluded "better communication for app developers"
+<@ajax> easy baseline seems to be "the stuff in gles2" which is basically 915 and r300 level shading
+<@ajax> new version of GL has an extension for es2 compat so that's pretty sensible too
+<@ajax> do we want to start requiring new tests for any new feature addition? well, we should, yeah.
+<@ajax> and we've been better about that over the last year or so, so, sure.
+<@ajax> (needs confirmation with brianp etc, but)
+<@ajax> (still just going down the list on the page alanc linked)
+< alanc> now on the fbdev driver discussion on http://www.x.org/wiki/CorbinSimpson/KillItWithFire
+< alanc> nominated for burning at the stake: 2 of the 3 sw rasterizers in Mesa: swrast, softpipe or llvmpipe
+<@ajax> ended up with no real time to talk about the glsl compiler; sorry
+<@ajax> mostly loud agreement about what to kill and bits of historical trivia
+"""]]
+
+### xserver 1.10 planning
+
+
+[[!format txt """
+<@ajax> per-crtc pixmaps, libxkbcommon, atomic modesetting for randr
+<@ajax> schedule posted to the list a bit ago, seems okay (mid february)
+<@ajax> input abi to break again
+<@ajax> openbsd patch merge
+<@ajax> input threads, libx86 out for real
+<@ajax> coarse monotonic timer for scheduler
+<@ajax> vgahw abi updates
+<@ajax> privilege reduction work: signal to parent, io port access, input devices etc.
+<@ajax> driver merging: yes? no?
+<@ajax> benefits are bisectability and immediate feedback
+< leio> arguable
+<@ajax> (and argued, yes)
+< dottedmag> ajax: Q: is libv's proposal considered? The one presented on last FOSDEM
+<@ajax> more frequent rcs may be valuable; but probably don't need to be actual tarballs, just git tags is fine
+<@ajax> dottedmag: remind me what the primary artifact of that proposal was? as i remember it was just "hey i can make an sdk, we should do that"
+< libv> ajax: no, that would be the dri sdk that i did in response to what some people were telling me at fosdem.
+<@ajax> proposal to unify the kms common code
+<@ajax> should probably merge dummy (video) and void (input)
+<@ajax> sdksyms.sh needs to be shot; ajax volulnteers, the sucker
+<@ajax> input drivers possibly more interesting to merge since that abi changes more (and yet, people care less)
+< alanc> input drivers mainly change due to input ABI changes - for most of them the actual device support is either static (the ancient PS/2 & serial mouse protocols in mouse_drv haven't changed in years) or not in the X driver but down in the kernel (evdev on linux, vuid on Solaris, etc.)
+< alanc> wacom & synaptics being exceptions
+< dottedmag> ajax: IIRC, it was moving X driver, DRI, DRM and kernel module for each driver to the single place, so drivers need to rely only to more or less stable interfaces.
+< dottedmag> libv: am I right?
+<@ajax> also vesa and fbdev proposed for merging (mostly as build canaries)
+< leio> again, have not heard any real benefits, even for those (vesa/fbdev). I can cite the known drawbacks.
+<@ajax> go for it.
+< dottedmag> ajax: merging vesa and fbdev does not make sense from embedded standpoint.
+< libv> dottedmag: yeah, for a single sentence (which i won't manage anyway), definitely
+< alanc> embedded can --disable-vesa --disable-fbdev
+<@ajax> dottedmag: your package system knows how to not install things.
+< libv> i hate the vesa idea though... if my vesa is broken, i cannot update my driver anymore :((
+<@ajax> libv: i don't follow.
+< leio> or embedded can not install xf86-video-vesa, which is much more friendly from a packaging standpoint - still have the same packages for whether to have or not have the driver.
+< libv> ajax: read that again, and then remember what i put most of my work on, and where the actual vesa bugs really happen :)
+< libv> or, that was a joke.
+< leio> read: You can give workarounds for packaging problems, but still haven't heard any benefits.
+< dottedmag> ajax: not a drivers merging, but just repositories merging? Not a problem then.
+<@ajax> dottedmag: right, you'd still get separate objects. vesa_drv.so would still be a loadable.
+< leio> dottedmag: because you make debian do separate packages?
+< libv> dottedmag: libv.livejournal.com
+< mbalmer> complete operating systems ship like this... kernel, userland, drivers, even compilers in one single module....
+< oga_> ``oh no, my 2kb of disk space! whatever shall I do''.
+< dottedmag> libv: I referred to vesa/fbdev
+< mbalmer> install to /dev/null?
+< dottedmag> leio: because I can continue avoiding to load VESA-related stuff on device without any sign of VESA and with quite limited memory.
+ * mbalmer wonders if this discussion is a sign of admitting that going modular was a mistake in the first place...
+<@ajax> mbalmer: no, just that it's hard to find where to slice.
+< dottedmag> no
+< oga_> going *so* modular quite probably was
+< oga_> splitting in general was mostly a good thing
+< mbalmer> server, drivers, protos
+< dottedmag> oga_: amount of modules is not a problem, but interfaces are.
+< Kayden> also, things were quite different back then.
+< oga_> dottedmag: it is a pain in the arse.
+< Kayden> xfree86 was a long time ago.
+< oga_> 32 protocols packagezs with more build system than actual code
+< dottedmag> who cares?
+ * mbalmer does
+< drago01> what about this ... try it out in case it sucks split them again
+< drago01> people pretend as if there is no way back
+<@ajax> it's not really "pretending". we just like to argue.
+< libv> drago01: i just hope that vcs history does manage to get preserved over such changes.
+<@ajax> everyone's seen a makefile so everyone thinks their opinion on buildsystems matters.
+<@ajax> libv: that's pretty straightforward in git, but yes, valid concern.
+< tilman> the merged proto package _will_ happen, right? or is that still argued about, too?
+< alanc> it happened, we called it xcb-proto, we just need to port everything to use it instead of the old ones
+< alanc> of course, that isn't likely to happen before 1.10
+< tilman> okay
+< alanc> no one came up with a strong argument against merging the old proto drivers during the 1.10 cycle, so it seems to be more a matter of if someone puts in the work
+<@ajax> competent argument for gpu objects, for once
+< leio> if the mid-term plan is killing them in favor of xcb-proto, the question becomes whether it's worth it to have distributions and other build systems need to adapt to these changes now
+<@ajax> (gpu size limits, crtc collections)
+<@ajax> and xineramifying randr to actually work across gpus
+<@ajax> ... and not much else!
+<@ajax> "if we do this in brazil, we should really start an hour later"
+<@ajax> mad props to mherrb for hosting and organizing
+<@ajax> see you on the other side of the planet next year
+"""]] \ No newline at end of file
diff --git a/Events/XDS2010/Program.mdwn b/Events/XDS2010/Program.mdwn
new file mode 100644
index 00000000..037e4b4e
--- /dev/null
+++ b/Events/XDS2010/Program.mdwn
@@ -0,0 +1,106 @@
+
+
+# XDS2010 Program
+
+This is the rough program for [[XDS2010|Events/XDS2010]].
+
+Recordings of the presentations can be found at [[Videos|http://www.x.org/videos/XDS2010]] or at [[youtube|http://www.youtube.com/results?search_query=XDS2010&aq=f]]. Search for XDS2010
+[[!table header="no" class="mointable" data="""
+ **Thursday September 16** |||
+ 9:00 | Welcome coffee - registration ||
+ 10:00 | [[Introduction|intro.pdf]] | [[MatthieuHerrb|MatthieuHerrb]] + University staff
+ 10:30 | [[X.Org Foundation|XorgFoundation]] session | [[AlanCoopersmith|AlanCoopersmith]] &amp; other [[Board members|BoardOfDirectors]]
+ 11:30 | Review of latest DRI2 protocol additions | [[JesseBarnes|JesseBarnes]]
+ 12:30 | Lunch break ||
+ 14:00 | Documentation or: how a newbie got involved | [[MattDew|MattDew]]
+ 15:00 | Development process recap [[Video|http://www.phoronix.com/scan.php?page=news_item&px=ODYzMQ]] | [[PeterHutterer|PeterHutterer]] & [[KeithPackard|KeithPackard]] ?
+ 16:00 | Coffee break ||
+ 16:30 | Transportation to ENAC/CENA ||
+ 17:00 | Visit and demos at CENA - X11 based UIs for air trafic control | CENA Team
+ **Friday September 17** |||
+ 9:00 | Multitouch session |
+ 10:30 | Coffee break ||
+ 11:00 | Gestures session | [[ChaseDouglas|ChaseDouglas]]
+ 12:30 | Lunch break ||
+ 14:00 | XCB session | [[JoshTriplett|JoshTriplett]], [[JameySharp|JameySharp]]
+ 15:00 | Xephyr future | [[DanielStone|DanielStone]] ?
+ 16:00 | Coffee break ||
+ 16:30 | EGL in Mesa [[Video|http://www.phoronix.com/scan.php?page=news_item&px=ODYyMA]] | [[KristianHøgsberg|KristianHøgsberg]]
+ 17:30 | Board meeting |
+ 20:30 | Social event: dinner at _le Patio de la Table Ronde_ ||
+ **Saturday September 18** |||
+ 9:00 | Wacom input driver* | [[PeterHutterer|PeterHutterer]]
+ 9:45 | OpenGL - which functions can developers rely on ? | [[JohnBridgman|JohnBridgman]]
+ 10:30 | Coffee break ||
+ 11:00 | libxkbcommon | [[KristianHøgsberg|KristianHøgsberg]]
+ 11:45 | Handling input events: threads or not ? | [[TiagoVignatti|TiagoVignatti]]
+ 12:30 | Lunch break ||
+ 14:00 | Non Linux DRI/KMS support | [[OwainAinsworth|OwainAinsworth]]
+ 15:00 | Kill it with fire | [[IanRomanick|IanRomanick]]
+ 15:30 | Mesa GLSL compiler internals | [[IanRomanick|IanRomanick]]
+ 16:00 | Coffee break ||
+ 16:30 | Xserver 1.10 planning | [[KeithPackard|KeithPackard]]
+ 17:30 | Closing session ||
+"""]]
+
+* This session will be just be a discussion for those involved with the driver. There won't be a presentation and it will likely be of limited use for others.
+
+
+## Ideas
+
+* X server 1.10 planning session
+ * merge drivers back?
+ * old PCI support (non-libpciaccess) on **driver** side (or why keep a 1:n for driver:server)
+ * and the close-source ones?
+ * and what about the big proto module?
+* Non-Linux support BoF
+ * DRM/KMS on *BSD
+* Review of latest DRI2 protocol additions ([[JesseBarnes|JesseBarnes]])
+ * DRI2SwapBuffers
+ * DRI2 events (swap, invalidate)
+ * DRI2Wait*
+ * discussion of triple/n-buffering
+* Development process recap
+ * what is working, what isn't?
+ * master vs. stable vs. -next
+* Multi-touch session
+* Gestures session
+* Xephyr BoF
+ * last one out the room is the maintainer
+* XCB BoF
+ * What still needs doing to support widespread porting efforts?
+* Handling Input events: [[assume threads or not?|http://cgit.freedesktop.org/~vignatti/xserver/commit/?h=inputthread-diff&id=126b89196122162515d8d5e9c4603d6cd7829f94]] ([[TiagoVignatti|TiagoVignatti]])
+* [[BoardOfDirectors|BoardOfDirectors]] chat
+ * XDC 2011 (in Brazil?)
+* Documentation or: how a newbie got involved
+* EGL in mesa
+ * what is EGL
+ * what's in mesa
+ * how does it work
+ * what do dri/gallium drivers need to provide.
+* libxkbcommon - who's the maintainer, where's it going?
+* Wacom roadmap BoF
+* Which functions can app developers rely on ?
+ * used to be that apps using ~GL 1.2 or 1.3 worked, anything higher was iffy
+ * most drivers now either support GLSL / GL 2.x or are getting close
+ * implementation is sufficient to make many apps work but not "perfect" yet
+ * app devs are starting to rely on GL 2.x but need per-platform testing to succeed
+ * can we identify a "new recommended level" that should work across all major HW platforms ?
+ * something like "GL 2.x minus <list> plus <low hanging fruit from GL 3/4 eg sRGB> ?
+ * What extensions should we force to be enabled in all drivers?
+ * GL_ARB_copy_buffer - GL_ARB_vertex_buffer_object is always enabled, and this is a trivial addition. **Done in Mesa master.**
+ * GL_ARB_map_buffer_range - This extension requires additional driver hooks that not all drivers implement. This may still be doable in the future.
+ * GL_APPLE_object_purgeable - Same as GL_ARB_copy_buffer, right? Some concern was expressed at XDS that apps might make (false) assumptions based on the availability of this extension.
+ * GL_ARB_vertex_array_object
+ * GL_ARB_draw_elements_base_vertex - We can (mostly?) fake this on hardware that doesn't have real support. Do we care that much?
+ * GL_SGIS_generate_mipmaps **Done in Mesa master.**
+ * Are there sufficient tests for these in piglit or glean?
+* Kill it with fire
+ * What can we remove from X, Mesa, etc?
+ * GL_ARB_imaging - [[EricAnholt|EricAnholt]] has a branch. Nobody uses convolution or histograms. **Removed in Mesa master.**
+ * GL_EXT_cull_vertex - This is only enabled in swrast and the Intel drivers. Do any applications use this? **Removed in Mesa master.**
+ * GL_EXT_paletted_texture and GL_EXT_shared_texture_palette - This is only enabled by swrast and tdfx drivers
+ * GL_EXT_clip_volume_hint - No hardware driver supports this. The support in swrast appears to be fake. [[JakobBornecrantz|JakobBornecrantz]] expressed some concern that this can enable some extra fast paths in llvmpipe and softpipe. The question remains whether or not applications actually use this extension.
+ * GL_APPLE_client_storage - This is only enabled in swrast and the Intel drivers. Do any applications use this? The support appears to be fake.
+ * GL_MESA_packed_depth_stencil - No hardware driver supports this. It's not enabled in swrast either. This is a **superset** of GL_EXT_packed_depth_stencil that also has a 15.1 depth/stencil format. **Removed in Mesa master.**
+ * [[Corbin's list|CorbinSimpson/KillItWithFire]] \ No newline at end of file
diff --git a/Events/XDS2010/Program/intro.pdf b/Events/XDS2010/Program/intro.pdf
new file mode 100644
index 00000000..5c9baa96
--- /dev/null
+++ b/Events/XDS2010/Program/intro.pdf
Binary files differ
diff --git a/Events/XDS2010/xds2010-color-small.png b/Events/XDS2010/xds2010-color-small.png
new file mode 100644
index 00000000..4a28b924
--- /dev/null
+++ b/Events/XDS2010/xds2010-color-small.png
Binary files differ
diff --git a/Events/XDS2010/xds2010-color.svg b/Events/XDS2010/xds2010-color.svg
new file mode 100644
index 00000000..b7dcc628
--- /dev/null
+++ b/Events/XDS2010/xds2010-color.svg
@@ -0,0 +1,350 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="588.58331"
+ height="557.48865"
+ id="svg2547"
+ sodipodi:version="0.32"
+ inkscape:version="0.47pre4 r22446"
+ sodipodi:docname="xds2010-color.svg"
+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
+ version="1.1">
+ <defs
+ id="defs2549">
+ <linearGradient
+ id="linearGradient3676">
+ <stop
+ style="stop-color:#e0e0e2;stop-opacity:1;"
+ offset="0"
+ id="stop3678" />
+ <stop
+ style="stop-color:#e00000;stop-opacity:0;"
+ offset="1"
+ id="stop3680" />
+ </linearGradient>
+ <linearGradient
+ inkscape:collect="always"
+ id="linearGradient3662">
+ <stop
+ style="stop-color:#e00000;stop-opacity:1;"
+ offset="0"
+ id="stop3664" />
+ <stop
+ style="stop-color:#e00000;stop-opacity:0;"
+ offset="1"
+ id="stop3666" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient3654">
+ <stop
+ style="stop-color:#000000;stop-opacity:1;"
+ offset="0"
+ id="stop3656" />
+ <stop
+ style="stop-color:#000000;stop-opacity:0;"
+ offset="1"
+ id="stop3658" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4130">
+ <stop
+ id="stop4132"
+ offset="0"
+ style="stop-color:#ffff4f;stop-opacity:0.86274511;" />
+ <stop
+ id="stop4134"
+ offset="1"
+ style="stop-color:#fff600;stop-opacity:0;" />
+ </linearGradient>
+ <linearGradient
+ id="linearGradient4122">
+ <stop
+ style="stop-color:#ff0000;stop-opacity:1;"
+ offset="0"
+ id="stop4124" />
+ <stop
+ style="stop-color:#e6af00;stop-opacity:0;"
+ offset="1"
+ id="stop4126" />
+ </linearGradient>
+ <inkscape:perspective
+ sodipodi:type="inkscape:persp3d"
+ inkscape:vp_x="0 : 372.04724 : 1"
+ inkscape:vp_y="0 : 1000 : 0"
+ inkscape:vp_z="1052.3622 : 372.04724 : 1"
+ inkscape:persp3d-origin="526.18109 : 248.03149 : 1"
+ id="perspective2556" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient4130"
+ id="radialGradient3634"
+ cx="453.75146"
+ cy="355.98727"
+ fx="453.75146"
+ fy="355.98727"
+ r="266.65195"
+ gradientTransform="matrix(1,0,0,1.0086379,0,-3.074984)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient4130"
+ id="radialGradient3642"
+ cx="452.02399"
+ cy="354.8356"
+ fx="452.02399"
+ fy="354.8356"
+ r="274.1377"
+ gradientTransform="matrix(1,0,0,1.0021004,0,-0.74530549)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3654"
+ id="radialGradient3660"
+ cx="419.20187"
+ cy="347.34985"
+ fx="419.20187"
+ fy="347.34985"
+ r="279.32016"
+ gradientTransform="matrix(1,0,0,0.91135425,0,30.791089)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3662"
+ id="radialGradient3668"
+ cx="419.20187"
+ cy="347.34985"
+ fx="419.20187"
+ fy="347.34985"
+ r="279.32016"
+ gradientTransform="matrix(1,0,0,0.91135425,0,30.791089)"
+ gradientUnits="userSpaceOnUse" />
+ <radialGradient
+ inkscape:collect="always"
+ xlink:href="#linearGradient3676"
+ id="radialGradient3682"
+ cx="382.9248"
+ cy="344.4707"
+ fx="382.9248"
+ fy="344.4707"
+ r="286.80588"
+ gradientTransform="matrix(1,0,0,0.94579145,-4.6066138,-31.999495)"
+ gradientUnits="userSpaceOnUse" />
+ </defs>
+ <sodipodi:namedview
+ inkscape:document-units="mm"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.86831673"
+ inkscape:cx="623.62297"
+ inkscape:cy="299.26351"
+ inkscape:current-layer="layer2"
+ id="namedview2551"
+ showgrid="false"
+ inkscape:window-width="1280"
+ inkscape:window-height="778"
+ inkscape:window-x="-1"
+ inkscape:window-y="0"
+ inkscape:window-maximized="0" />
+ <metadata
+ id="metadata2553">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:groupmode="layer"
+ id="layer2"
+ inkscape:label="Fond"
+ transform="translate(-152.54991,-76.667113)">
+ <rect
+ style="opacity:0.77777782;fill:#e00000;fill-opacity:1;stroke:#000000;stroke-width:3.54330707;stroke-miterlimit:4;stroke-opacity:0.21076235;stroke-dasharray:none"
+ id="rect3672"
+ width="585.03998"
+ height="553.94531"
+ x="154.32156"
+ y="78.438766" />
+ <rect
+ style="opacity:0.77777782;fill:url(#radialGradient3682);fill-opacity:1;stroke:none"
+ id="rect3674"
+ width="570.06848"
+ height="538.97382"
+ x="93.283936"
+ y="24.311049" />
+ </g>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1"
+ style="display:inline"
+ transform="translate(-152.54991,-76.667113)">
+ <path
+ d="m 451.96875,343.90625 0,-71.21875 L 340.375,106.75 230.59375,106.65625 392.0625,349.9375 l 55.65625,0 4.25,-6.03125 z"
+ id="path2737" />
+ <path
+ d="m 450.34375,359.875 0,73.625 109.84375,164.71875 109.78125,0 -159.90625,-241.75 -57.3125,0 -2.40625,3.40625 z"
+ id="path4040" />
+ <g
+ style="fill:#fcef3c;fill-opacity:1;stroke:#000000;stroke-width:1.88821995;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;display:inline"
+ transform="matrix(1.588788,0,0,1.588808,-3046.2811,-670.20233)"
+ id="g16252">
+ <path
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.88821995;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ d="m 2201.4845,500.70333 c -4.7445,0 -9.4057,0.2639 -14.0313,0.71875 -0.2868,12.97986 -10.9206,23.43752 -23.9687,23.4375 -5.1093,-8e-5 -9.8347,-1.63974 -13.7188,-4.375 -2.2056,-2.45229 -4.4786,-4.85284 -6.8125,-7.1875 -5.4822,2.48316 -10.7899,5.30529 -15.875,8.4375 1.8116,1.69271 3.5803,3.41917 5.3125,5.1875 0.9351,1.11745 1.9518,2.14558 3,3.15625 0.068,0.0658 0.1188,0.15342 0.1875,0.21875 22.38,24.1556 37.657,54.94886 42.5,89.125 -38.3346,-5.42977 -72.4383,-23.98976 -97.6562,-50.96875 -3.1307,5.08128 -5.9862,10.36584 -8.4688,15.84375 2.0007,1.9988 4.0376,3.96832 6.125,5.875 3.3757,4.13081 5.4062,9.41583 5.4063,15.15625 -1e-4,13.06932 -10.491,23.68449 -23.5,23.9375 -0.425,4.47328 -0.6251,9.00982 -0.625,13.59375 0,4.89355 0.2352,9.73331 0.7187,14.5 12.9652,0.30349 23.4062,10.93119 23.4063,23.96875 -1e-4,4.66188 -1.3433,9.01161 -3.6563,12.6875 -2.694,2.39906 -5.3195,4.86243 -7.875,7.4063 2.5682,5.6668 5.5205,11.1335 8.7813,16.375 25.1633,-26.77177 59.0893,-45.19557 97.2187,-50.62505 -5.5898,37.99185 -24.0768,71.78525 -50.875,96.81255 5.093,3.1371 10.4149,5.9515 15.9063,8.4375 2.038,-2.0283 4.0306,-4.0928 5.9687,-6.2188 4.1126,-3.3169 9.3155,-5.3124 15,-5.3125 13.0587,10e-5 23.6679,10.4742 23.9375,23.4688 4.4835,0.4269 8.999,0.6562 13.5938,0.6562 4.8935,0 9.7333,-0.2665 14.5,-0.75 0,-3e-4 0.031,3e-4 0.031,0 0.3203,-12.9502 10.9108,-23.375 23.9375,-23.375 4.6794,10e-5 9.0341,1.3899 12.7188,3.7188 2.3852,2.6766 4.844,5.2811 7.375,7.8125 5.6759,-2.571 11.1569,-5.5156 16.4062,-8.7813 -26.5665,-24.9688 -44.9135,-58.5778 -50.5,-96.34375 37.7562,5.58971 71.3818,23.91034 96.3438,50.46875 3.2615,-5.2462 6.1822,-10.7342 8.75,-16.4062 -2.3226,-2.32558 -4.7095,-4.58075 -7.1563,-6.7813 -2.7264,-3.88977 -4.3437,-8.61826 -4.3437,-13.71875 10e-5,-13.03745 10.441,-23.63489 23.4062,-23.9375 0.4548,-4.62558 0.6875,-9.31801 0.6875,-14.0625 0,-4.73391 -0.2347,-9.4157 -0.6875,-14.03125 -12.9653,-0.30344 -23.4062,-10.93116 -23.4062,-23.96875 10e-5,-5.12497 1.6243,-9.8592 4.375,-13.75 2.4304,-2.18711 4.8158,-4.43881 7.125,-6.75 -2.486,-5.49134 -5.3004,-10.81321 -8.4375,-15.90625 -1.7668,1.89537 -3.5818,3.7532 -5.4375,5.5625 -1.0978,0.93785 -2.1643,1.92066 -3.1563,2.96875 -23.9289,22.14845 -54.3982,37.33603 -88.1875,42.3125 5.4331,-38.12885 23.8756,-72.06549 50.6563,-97.21875 -5.2482,-3.26636 -10.7314,-6.20943 -16.4063,-8.78125 -2.3091,2.31661 -4.5599,4.69301 -6.75,7.125 -3.9111,2.77508 -8.6935,4.43741 -13.8437,4.4375 -13.0481,-1.7e-4 -23.6514,-10.45766 -23.9375,-23.4375 -4.6256,-0.45485 -9.3181,-0.71875 -14.0625,-0.71875 z m 0,14.40625 c 5.4852,14.65345 19.2193,25.25893 35.5312,26.25 -18.591,27.8166 -29.7948,60.96631 -30.7187,96.6875 35.7195,-0.91794 68.9048,-12.07803 96.7187,-30.65625 1.0096,16.28659 11.6475,29.97823 26.2813,35.46875 -14.6483,5.48332 -25.2839,19.1956 -26.2813,35.5 -27.8138,-18.5782 -60.9991,-29.76931 -96.7187,-30.6875 0.9235,35.7122 12.1362,68.87535 30.7187,96.68755 -16.1071,1.1604 -29.6178,11.7696 -35.0625,26.2812 -5.5304,-14.7738 -19.4178,-25.4737 -35.9062,-26.3125 18.5586,-27.8036 29.7016,-60.9561 30.625,-96.65625 -35.7135,0.92401 -68.8445,12.13636 -96.6563,30.71875 -1.1604,-16.10716 -11.7698,-29.6178 -26.2812,-35.0625 14.7805,-5.53279 25.4823,-19.43906 26.3125,-35.9375 27.8043,18.56783 60.9271,29.73277 96.625,30.65625 -0.9242,-35.72327 -12.0746,-68.8717 -30.6563,-96.6875 16.2943,-1.00304 29.9763,-11.61102 35.4688,-26.25 z"
+ id="path14367" />
+ <g
+ style="fill:#fcef3c;fill-opacity:1;stroke:#000000;stroke-width:1.88821995;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="g16238">
+ <path
+ transform="matrix(0.775253,0,0,0.81501,1089.4,186.8612)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14388"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546897;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ transform="matrix(0.671389,-0.387627,0.407505,0.705818,1010.393,804.0035)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14390"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ transform="matrix(-0.671389,-0.387627,0.407505,-0.705818,2936.607,1593.817)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14392"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ transform="matrix(-0.775254,-4.402797e-7,4.628583e-7,-0.815011,3313.6,1098.86)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14394"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546611;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ transform="matrix(-0.671389,0.387627,-0.407505,-0.705819,3392.606,481.716)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14396"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546873;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546802;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14398"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(-0.387628,0.671389,-0.705819,-0.407505,3152.458,-92.24858)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546611;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14400"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(-4.402797e-7,0.775254,-0.815011,-4.628583e-7,2657.502,-469.2423)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546873;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14402"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(0.387627,0.671389,-0.705819,0.407505,2040.357,-548.2492)" />
+ <path
+ transform="matrix(0.671389,0.387628,-0.407505,0.705819,1466.393,-308.0995)"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ sodipodi:ry="19.5"
+ sodipodi:rx="20.5"
+ sodipodi:cy="387.86218"
+ sodipodi:cx="1434.5"
+ id="path14404"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546802;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ sodipodi:type="arc" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14406"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(0.387627,-0.671389,0.705818,0.407505,1250.543,1377.968)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546897;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14408"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(1.565175e-7,-0.775253,0.81501,1.645442e-7,1745.499,1754.96)" />
+ <path
+ sodipodi:type="arc"
+ style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
+ id="path14410"
+ sodipodi:cx="1434.5"
+ sodipodi:cy="387.86218"
+ sodipodi:rx="20.5"
+ sodipodi:ry="19.5"
+ d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z"
+ transform="matrix(-0.387627,-0.671389,0.705818,-0.407505,2362.644,1833.966)" />
+ </g>
+ </g>
+ <path
+ d="m 450.34375,359.875 -25.3125,35.65625 25.3125,37.96875 0,-73.625 z"
+ id="path4071" />
+ <path
+ d="m 451.96875,343.90625 24.5,-34.78125 -24.5,-36.4375 0,71.21875 z"
+ id="path4065" />
+ <path
+ d="M 630.21875,106.4375 452.75,356.46875 l 57.3125,0 -9.84375,-14.875 166.5625,-235.15625 -36.5625,0 z"
+ id="path2644" />
+ <path
+ d="m 447.71875,349.9375 -55.65625,0 L 401.40625,364 235.5,598.0625 l 37.5,0 174.71875,-248.125 z"
+ id="path4034" />
+ </g>
+</svg>
diff --git a/Events/XDS2012.mdwn b/Events/XDS2012.mdwn
new file mode 100644
index 00000000..11926796
--- /dev/null
+++ b/Events/XDS2012.mdwn
@@ -0,0 +1,8 @@
+
+
+# XDC2012: Nürnberg, Germany
+[[!table header="no" class="mointable" data="""
+ [[<< XDC 2011|Events/XDC2011]] | [[XDC 2012|Events/XDC2012]]** | XDS 2013
+"""]]
+
+**Please refer to [[XDC2012|Events/XDC2012]]**