|
|
http://freedesktop.org/~ajax/xdevconf-2005-notes.txt
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
Mesa Solo
- Jon Smirl
Merging fbdev and DRM
- Jon Smirl
Open Source Legal Issues, Patents and Copyrights
- Scott Peterson and Greg Jones
X.org Update
- Audience |
|
IP卡
狗仔卡
发表于 2005-2-16 22:26:07
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
偶看了两个多小时。