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 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 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
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).
NVIDIA: Can clock-down core and memory frequencies (Note: 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 - 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: constructor, _operator, 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.