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 jg intro: X needs to work in the context of a larger project software will not restrict itself to unix what's the larger context we need to work in, how do we get there standards page is huge no idea what's "official", many of these specs are just bad some are actively deprecated do we need to formalize the process? (maybe) do we need to expand the scope? (probably) do we need real doc writers, or at least professional editing (yes) problem with some of these specs is a very small audience, so size of community isn't necessarily an indicator of activity or relevance need to triage these a bit need to split the standards page up to be relevant per audience - this is what toolkit authors need to know versus what app authors need to know idea: bugzilla component for interop problems very few toolkits we (anyone) cares about: qt, gtk, mozilla, ooo, motif don't really want to block on motif in terms of forward progress, much higher BC constraint requirement there. keeping motif working is valuable. adopted needs work: basedir, menu, mime, icon xsettings isn't really adopted outside of gtk XDS is rox-only systray - adopted but sucks icon theme - no standard for icon names, so not as useful as it could be recent file - semi-adopted, clee says due for a rewrite startup-notification well adopted, too bad gnome doesn't do it yet... file uri spec - there is an RFC, but it's useless, needs a bit of work clipboard specs are all kind of hazy suggestion from jg: matrix for each toolkit showing support status again mostly just needs manpower suggestion from lars: need to switch input method and keyboard map as one jg response: you want to switch keyboard maps and have it work? owen mentions case of irc client wanting different methods per tab so might need to expose that to the app somehow comment from zack: we're trying to implement all of these external to gtk/qt, this kinda sucks because it's hard to do and doesn't necessarily integrate owen response: yeah, but when we don't do them external to the toolkit they don't get adopted now on to projects some of the software are just sample implementations without much adoption - uim, startup-notification many of these don't even have proper release schedules big projects: fontconfig, gstreamer, dbus, hal, cairo - cairo plans to hit 1.0 before the next gtk release (before august) - small package set works as a base fdo platform release keep it small translation is an issue, hard to work on due to project setup management want east coast hosting / mirrors clee is on the job admin process is difficult possibility raised of unified IT for multiple projects, maybe through pooled funding from the various projects DND Specification Issues - Owen Taylor and George Staikos george: dnd issues DND Warts page current spec prevents some use cases also some systray spec issues - breakout to gamera for discussion resulting notes: - http://freedesktop.org/wiki/Standards_2fSystrayAndAppletsMeeting - http://freedesktop.org/wiki/Standards_2fXDNDRevision xrestop, xephyr, and X on handhelds - Mathew Allum xrestop: top for X pretty good for finding offenders lies a little (but that's okay) xephyr: like Xnest, only paints to an XImage kdrive based, supports nice features like lower bit depths, randr, visual paint debugging, damage/fixes/composite, even if the host server doesn't x on handhelds: arm or similar CPU at ~200MHz+ small flash (32M or more), similar amounts of RAM, small display generally if you can get a framebuffer it'll work tend to use kdrive Xfbdev tslib for touchscreen input with some calibration support from the server 2-3M footprint when trimmed down performance pretty much linear with fb speed xlib can be built wihtout xlocal, xkb, xcms cuts size in half, mostly works, could use some polish will generally run any X app some apps specifically for handhelds: matchbox, GPE, minimo matchbox: tiny wm specifically designed for non-desktop platforms not just for handhelds but kiosks and appliances too minimal window management policy, compile-time flags for features eg Pango desktop apps mostly work (dialogs etc. are tricky) supports most of ewmh/xsettings/systray demo at http://projects.o-hand.com/matchbox/demos.html xoo: gtk wrapper around xnest/xephyr allows buttons and such for input http://projects.o-hand.com/xoo/ what's next? - embedded GL would be cool - general tools work for embedded competition: opie, qt/embedded on framebuffer plusses and minuses to each, opie has better sync but x is more like x Testing Strategies - Stuart Anderson, Free Standards Group and X.org X has a serious need for improved testing VSW4 has been nice but we can always use more Useful both for correctness and for identifying regressions Rules for commit to test suites need to be more restrictive - need to be sure whether the test or the implementation is at fault Need for a working group on testing http://xorg.freedesktop.org/wiki/TestGroup/CodeManagement for the proposal Should integrate this with tinderbox the way mozilla does tinderbox and automated testing (Xvfb eg) saves a lot of stress makes it very easy to narrow search for commits that caused problems Short Topics - All output only windows - recent keithp commit in kdrive - the input shape for the window is really cool, lets you pass clicks through - useful for translucent windows color management - needed for mac-like usage of X (print media, etc) - Xcms is fairly broken and largely unused - might need to be more general than just X (scanners, printers) - lots of patent noise - we're bigger than the mac, but that won't get us in the door non-suid server - traditionally a problem on suck hardware (x86) - drivers can tell the server if they need i/o ports (do by default) - console init now works right without root - privsep from openbsd might be relevant xim cache - xim startup takes forever, there's a better fix out there in suse - question as to whether it's worth staying on XIM (probably not?) commit process dmx - can use composite to automate calibrating and balancing these - very configurable killing xorg.conf open nv driver security (missed the rest of these, if anyone else has notes let me know) Sunday, February 13 Starting at 9:00 X Proxy and Multicast Demo - David Flynn, Realm Systems http://www.stampede.org/~daflynn/ proxy is basically a full server in C++ mirrors real server state, so can do predictive responses looks like a single client to the real server three new extensions: nest, share, view not xlib based at all, good batching, very low overhead basically makes X stateless, proxy can migrate across servers passes more of vsw5 than Xvnc nest extension works around app assumptions about visibility share extension binds XIDs to a share object view extension is used by viewing apps to look at shares A Unified View of Improving X Desktop Rendering (Fedora Rendering Project) - The Owen Taylor, Søren Sandmann, Kristian Høgsberg and Diana Fong sh owen intro goals: dynamic graphics, animations, general flash old components: gtk, pango, gnome desktop new components: Cairo, OpenGL cairo: uniform rendering layer kristian on printing uniform API for all output backends, so identical output on all devices cairo/gtk integration pango as text api compositing managers usually same app as window manager spiffifity - compmgr in metacity luminocity - opengl based compmgr with the compmgr, moving is fast, resizes... not so much, but could be why GL? good match for a compmgr: textures, filtering, scaling, shadows industry standard, currently faster than Render accelerated indirect GL needed for remote luminocity, and good for local luminocity direct rendering has more bandwidth, but needs more sync need unclipped GL to the root window, redirection of GL and Xv, accelerated indirect GL, some cairo and libpixman optimization, and server Render accel Cairo Status - Carl Worth, Red Hat what we've done - new backends, devs, apps, bindings, license (LGPL/MPL) - performance improvements - backends in 04-2004: glitz, render, core X, memory, postscript - now also have pdf, quartz, win32 new devs: - alexander larrson: xpdf in cairo, profiling, performance improvements - krh: pdf backend, general backend interface work - calum r: osx new apps: dia, gtk/pango, scribus, swfdec, squeak, xpdf, etc. goals: cairo 1.0 before gtk 2.6, hopefully may or june 2005 todo: - api stabilization - test suite: have infrastructure, need backends, need tests - performance: profiling with real apps API issues: rendering equation, clipping, mask support, destroy notifiers, transparent datatypes, group rendering questions: - why no lock? clients are responsible for telling cairo when the image is damaged by external draws. X Input Redirection - Deron Johnson, Keith Packard if the compmgr moves the window, you need to translate pointer screen position to window coordinates. this works when the mouse is within the window when it's not, you need to translate again this solves problems for for multiple systems - PLG, luminocity, croquet XME - X Modular Event system runs either in the server or in an evmgr client based on dix/{events,grabs}.c modular, clear inputs and outputs, uses server for grabs and events alternative approaches: - scene graph in the server: multithreaded design, single-threaded server - Z model: needs two picks, not fast - share memory scene graph: timing problems, big code changes, blocks server proof of concept runs moz and gnome, good start todo: integrate into looking glass, xinput support, unified codebase far future: input drivers and xkb into the evmgr plg update: open project, http://lg3d-core.dev.java.net/ release 0.61 shipped, most X apps work, livecd version in progress next major release june 2005, focus on X performance and 3d apps A New Input System - Kristian Hogsberg, Jim Gettys x currently assumes a limited set of input devices no way to associate axes with events no way to discover which driver corresponds to a device no way to do hotplug need a way to ask the driver for its button and axis names xinput extension is mostly good needs hotplug, device controls and valuators static config sucks implementation is mostly about ancient serial devices, which is not reality evdev driver is a good start dbus/hal can provide for plugging and configuration X SI lacks callbacks for socket state change - applies to more than just input interesting security problems need user and session concepts, and expose the policy to apps somehow wire protocol issues Polling And Scheduling in the X Main Loop - Kristian Høgsberg, Red Hat Reworking the X server main loop, with proposed changes. X server needs to learn how to be a client for hal/dbus current main loop has no mechanism for callbacks when fds are readable X and Media Support - Leon Shiman Media Application Server - www.mediaapplicationserver.net developed under the auspices of the Open Group starting in about 1999 designed to be separable but tightly integrable, scalable peer-to-peer design works on everything - solaris, linux, aix, win32 3D Graphics Pipelines - Nick Triantos, NVidia overview of the pipeline, nvidia software overview, strengths and challenges point, lines and triangles, vertices, texture mapping, gouraud shading per fragment color, all of which gets alpha-blended to the framebuffer the life of a triangle: vertex fetch, vertex processing, prim assembly, rasterize and z cull, pixel shader pre-texture, texture, pixel shader post-texture, framebuffer blend vertex processing: vertices go one at a time - color and interpolants in the vp all inputs treated as float4 within the vp instruction set: mul, add, mas, sin, cos, rsq, tex, etc. 512 instructions long, 64k instructions per vertex output values interpolated by hw, fed to fragment processor MIMD execution units fragment processing: programs go per-fragment, to 1-4 buffers. float precision. similar instruction set as vp. up to 16 textures bound anisotropic filtering, min/mag, rotation, etc. up to 8192 instructions per fragprog. simd execution across many units. raster ops: z buffer, stencil buffer, alpha blending, downsampling for antialiasing engine optimized to distribute work across memory units interesting note: 32GB/s on card, 2.4GBs to and from card driver architecture: kernel bits do chip init, interrupts, resource management client driver optimizes state changes, compiles vp/fp, queue commands command submission is generally "fire and forget" GLX: interface with the window system, allocate surfaces, manage clipping strengths of the 3d pipeline: min/mag of textures (if you have mipmaps) rotating textures at full speed blending and compositing can usually do YUV textures too very flexible weakness of the pipeline: state changes can be very expensive high quality font rasterization best done in software 3d programs can take arbitrary time functional variance between vendors: interpolation, precision, sampling loss of the video overlay no 8bpp pseudocolor (oh darn) driver model allows one app to be a pig driver complexity grows 3d rasterisation doesn't match X rules challenges: memory management many threads can use GL at once any one thread can allocate surfaces/textures/... how do you ensure fairness among programs? - pre-allocate for compositor? - page out for fullscreen? - other ideas? how do you do video? cards can convert or do it natively but performance and quality can suffer low latency is a pain, decode -> compositor -> scanout overlay engine is finite-time, GL may not be might need lots of memory, audio sync needs consideration challenge: keep the desktop responsive big triangles and lots of vp/fp ops can take huge amounts of time Monday, February 14 Starting at 9:00 X on GL - David Reveman, Novell structure: what's between X and GL? X{glx,agl,wgl} / Xgl / glitz / OpenGL Xglx is window system interface layer Xgl handles input stuff glitz for high level API OpenGL for actual drawing glitz provides a Render-like API on top of GL hides extensions / contexts / special cases from the server layer difficulties: visuals are not visuals and picture formats are not picture formats lack of direct framebuffer access means you have to guess what the front really is; as long as you don't lose data you're okay - would be nice to define texture format at use rather than allocation software fallback path: X wants plane masks and logic rops these are hard to do in GL EXT_framebuffer_object benefits: - no buffer to texture copying - window system independent - efficient memory management - avoids context switches will still be a few months before it's deployed though Xgl is really targeted at the Render/Composite case, core X isn't accelable hardware is used for filters, transforms, textures hardware antialiasing would be nice but isn't yet future: implement this on WGL/AGL/EGL add GLX and Xv extensions test test test Mesa Solo - Jon Smirl XGL, GL compositing manager, Cairo/glitz, standalone GL Merging fbdev and DRM - Jon Smirl Open Source Legal Issues, Patents and Copyrights - Scott Peterson and Greg Jones (Novell), Linda Hamel (MA IT division) patents are a difficult issue companies exist for whom open source is an active threat danger of using patents to attack open source - sidebars: incentives for each license, definition of community gpl has a mechanism for terminating rights where mit/bsd doesn't difficult for a company to both distribute gpl code and use a patent against it mit has more of an implied patent grant how do you cope as an OSS developer with patents you don't know about? patent litigation is not a new phenomenon nor is it restricted to the usa need to logically separate fixing the patent system with using the system argument presented for OSS devs filing defensive patents while there is a procedural barrier to getting this started, if the community decides it's worth doing, the money will appear major bootstrapping issues complementary to filing patents is good records of prior art X.org Update - Audience Xorg board news bylaws need revision architectural review decisions shouldn't go through the board because most of them are not actively involved in development. rough consensus and working code proposal is to turn the arch board into the arch working group discussion on what the process should be do process experiment with deron's PLG changes