= XDC2009 Notes = Live from sunny Portland, it's the X Developer's Conference 2009! <> == 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 * 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?