path: root/Events/XDC2009/Notes.mdwn

# XDC2009 Notes

Live from sunny Portland, it's the [[X Developer's Conference 2009|/Events/XDC2009]]!

[[!toc startlevel=2 levels=2]]


## 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`, hook `CreateWindow`, redirect root window in CW hook
* Hook `RealizeWindow` and make GEM handles for the window pixmap, tear it down in `UnrealizeWindow`
* Update it in `SetWindowPixmap` (resize, reparent, etc)
* Hook `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>

### 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>
* 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>

### 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 on DRI wiki|http://dri.freedesktop.org/wiki/MissingFunctionality/]]
* Kernel 2.6.31: dynamic clock control, self-refresh support, error detection, FIFO watermark support, misc output fixes, vbios parsing fixes, 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!  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`
* 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?