Live from sunny Portland, it's the X Developer's Conference 2009!
- Monday, September 28
- Tuesday, September 29
- Wednesday, September 30
Monday, September 28
Bart Massey: Welcome, Introductions
- 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.
- 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
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.
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
- 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
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
- 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
- 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?