IRC transcript of the notes from XDS2010.

Thursday, September 16

Board (Alan Coopersmith, Matthieu Herrb)

<@ajax> right, intro over, board presentation time
<@ajax> board is alanc, mherrb, dberkholz, agd5f, anholt, keithp, bart massey
<@ajax> the foundation exists to make life easier for X developers (conference travel and sponsorship, nda documentation, etc)
<@ajax> vote in the next board election!  become a member to do that if you're not already.
<@ajax> currently mostly working on the 501(c)3 paperwork
<@ajax> also working on trademark issues.  apparently some brazilian company has a logo that looks very similar to the current X logo?
< daniels> yeah, it's in the meeting minutes
<@ajax> general opinion is the current logo is too ugly to be worth fighting for, so, looking for new designs
<@ajax> (mhopf is also on the board, apologies for leaving him out)
<@ajax> SoC student and anybody else: if you have things you want to work on that require funding for equipment, let the board know!  that's what they're there for.
<@ajax> question from (i believe) libv: how's the paperwork situation?
<@ajax> background is that we need ~5 years of paper trail for the bank account for the 501(c)3 switch
<@ajax> paperwork was still going to leon's house and getting thrown away; only last 11 months easily available from the bank, so stukreit harassing the bank to get that filled in
<@ajax> egbert says he has the records through 2006ish
<@ajax> board also looking into xts5 licensing, it's under non-clarified artistic which is non-dfsg and non-osi
<@ajax> http://wiki.x.org/wiki/BoardOfDirectors/MeetingSummaries/2010/08-17
<@ajax> questions for the board: board@foundation.x.org
<@ajax> watch for election announcements soon, four seats up for election every year.  run if you have the time, vote if you don't.
< alanc> http://www.nettv.tv.br/images/stories/logo.gif is the brazilian tv logo in question, rendered much shinier than ours

DRI2 updates (Jesse Barnes)

<@ajax> dri2 landed about 18 months ago
<@ajax> pretty reasonable but lacked support for some of the common glx extensions (page flipping and other swap control stuff)
<@ajax> DIR2SwapBuffers through DRI2SwapInterval in dri2proto.h are new
<@ajax> also, two new events
<@ajax> SwapBuffers was originally a round trip, is now just a normal async request
<@ajax> has (protocol) support for scheduling future swaps, either as msc frame number or divisor/remainder like in the sgi glx extensions
<@ajax> DRI2GetMSC (media sync counter) to get the current frame number
<@ajax> DRI2WaitMSC to wait for a particular frame
<@ajax> DRI2WaitSBC to wait for a particular swap (SBC == Swap Buffer Counter)
<@ajax> DRI2SwapInterval to (obviously) set the swap interval for throttling
<@ajax> events: BufferSwapComplete and InvalidateBuffers
<@ajax> apps never really see any of these, these are all just to support the GLX extensions
<@ajax> lots of new hooks for the drivers to support these, see hw/xfree86/dri2/dri2.h for details
<@ajax> (wow, documented function pointer hooks!  mad props to jbarnes)
<@ajax> drivers have some leeway to optimize flips (eg if src and dst are both screen-sized)
<@ajax> intel implementation: drm file descriptor can give you events on swap events and etc, so just select() on it
<@ajax> intel impl will also block if it tries to do any further GL after a swap
<@ajax> question from keithp: how much parallelism does that actually allow?
<@ajax> well, we don't have any real data, but that tends to be what the toolkits and games do: swap, compute the new scene, then resume more GL commands
< airlied> tap tap is this thing on?
< airlied> ajax: q from down under, what about triple buffering?
<@ajax> (some discussion about where blocking actually happens and etc.)
<@ajax> dileks: not that i'm aware of
<@ajax> triple buffering: "all the code is there for that..."
<@ajax> still some issues in implementation, so, not actually done.
<@ajax> qquestion from the room (wish i could remember this person's name): why don't you want vblank events on every frame?
<@ajax> well, because it's expensive, you keep the CPU awake so you can't stay in deep sleep states.  but you will get every frame event you ask for, so if you're rendering continuously it's the same as getting them all the time.
<@ajax> another room question: no events for render completion?
<@ajax> not in DRI2, but GL sync events do give you that.
<@ajax> but that is planned, since you do want it for a) async main loop type toolkits, b) ordering between rendering APIs.  (gl sync only gives you query and block, not events)
<@ajax> ("GL sync events" above are not events in the X protocol sense)
<@ajax> some discussion about details of how you actually put the swap to the hardware: in the command ring, or through an mmio write
<@ajax> ie, does the hardware accept the mmio write immediately or does it effectively get queued anyway
<@ajax> (all in the context of fairness among clients)
<@ajax> (audience participators: tapani paelli, mario kleiner)
<@ajax> (also owain ainsworth, i believe)
<@ajax> relevant wiki page: http://dri.freedesktop.org/wiki/CompositeSwap
<@ajax> hint to app writers: OML_swap_method is part of the fbconfig, which means we basically have to report "unknown" since swap method can change at runtime
<@ajax> all the above is about BufferSwapComplete
<@ajax> InvalidateBuffers: glViewport used to be the trigger for getting buffer coords and clip
<@ajax> but that can change multiple times per frame, and it's roundtrips, and it's not really correct anyway since Viewport isn't a clip and rendering outside it should show up
<@ajax> so InvalidateBuffers is a new event to tell the clients about buffer changes as they happen instead
<@ajax> SwapBuffers _is_ a round trip right now, though it could be request/event, because you need the sync point with the server; otherwise client doesn't know what buffer to render into
<@ajax> yet more discussion about particular bits of hardware and optimising

Documentation (Matt Dew)

<@ajax> speaker background: linux geek, electrical engineer by trade, recently back to school
<@ajax> started working on documentation as a break from studies, emailed bart asking how to help, got a response! oh my.
<@ajax> X seemed to be really understaffed, wanted to help grow the developer pool, and be a part of something important
<@ajax> was it hard to get involved?  yes!  
<@ajax> why?  intimidating, seems complicated (crowd: yeah, it kind of is!), no idea what to do or who to ask or where to look
<@ajax> bart and gaetan kept replying to emails and giving encouragement
<@ajax> mostly working on organizing information.  gathering what already exists, and making it findable and searchable. not really working on new content except for TOCs etc.
<@ajax> from thinkwiki: "As usual with X, good documentation is hard to find" 
<@ajax> why not me? spend lots of time reading specs and white papers, so appreciate good docs. also spent some time writing it, realize it takes effort.
<@ajax> why documentation? because it really really matters.
<@ajax> http://stashbox.org/122385/xorg%20architecture2.pdf
<@ajax> (and then we all check out that pdf and say "yeah that's too simple")
< vignatti> jbarnes: for sure is manually done, this diagram
<@ajax> question (jay cotton i think): what are you trying to document?
<@ajax> "anything that's useful", but that's also not an easy question
< alanc> yes, thats jay
<@ajax> alanc: the ferrari mouse was a giveaway
<@ajax> (presenter's focus possibly more about "how to write an app to use this stuff" rather than "how do you implement it")
<@ajax> so, mostly working on rounding up existing documenttion rather than writing new stuff; the docs _are_ findable, but only if you find it can you use it
<@ajax> then, searchability, toc/index, structure, de-duplication.
<@ajax> after that, start filling in the holes.
<@ajax> also trying to convert things to a consistent file format; still not complete consensus on what the right format is, but framemaker is not it
<@ajax> aside: hey developers, use doxygen comments
<@ajax> docbook conversion: changing from/to and why, what's involved, what's done, what's left
<@ajax> major formats: troff, tex, docbook, framemaker, asciidoc
<@ajax> moving to docbook/xml, at lrast just to have one instead of five.
<@ajax> (aside from whot earlier: authoring tools for db/xml would be nice)
< dottedmag> ajax: Q: does it include protocol specs?
<@ajax> status: troff done, tex done, db/sgml in progress, framemaker needs someone to export, others unfinished
<@ajax> dottedmag: "it"?
< dottedmag> ajax: conversion
<@ajax> yes.
<@ajax> by mid-january aiming for finishing the conversions, proofreading, crosslinking, and css-ization
<@ajax> after that: diagrams, picking a docbook tag subset, style, what goes in book vs wiki
<@ajax> BFTBX: Big [mutter] Turquoise Book of X
<@ajax> complete book of everything you could want to know (that doesn't change that much).  note: project, not a real artifact yet.
<@ajax> more future: wiki organization
<@ajax> open questions: what's missing? (man, if only we knew) what's going to be documented? eventually, everything, but wants some prioritization
<@ajax> timeline: summer of 2012 docs should be good if not great.  "great" is a not sure.
<@ajax> http://www.osource.org/xorg - temporary wiki
<@ajax> _temporary_.  going away.
<@ajax> but the stylesheet sure is nicer
<@ajax> question from jay: how do you purge everything else from the web that's wrong?
<@ajax> well, you don't, but you just make sure everything on the X wiki is authoritative
< alanc> helps if ours is less wrong than everyone elses
<@ajax> tapali comment: currently writing some docs on dri2 development, need review for whether it's actually correct enough
<@ajax> if anybody wants to help with this, talk to matt!  no, really, we will love you forever.
<@ajax> matt@osource.org 
<@ajax> and there's plenty of work to do
<@ajax> use xorg-devel@ for the moment, will split off list later if necessary, but for now probably best to keep it in one place
<@ajax> remarkable number of newbies at the conference, ~1/5 or so.  what was useful to those people?
<@ajax> blog more!  example of agd5f's radeon get-started blogs.
<@ajax> ideally would like to have content _in_ the wiki, not just a collection of links; but do send links to source documents

Development process (Peter Hutterer, Keith Packard)

<@ajax> mostly motivated by various failings in releases; bad schedule follow-through, quality issues, content definition, etc.
<@ajax> wasn't satisfying either distro maintainers or driver developers
<@ajax> whot put together release process document; no real surprises in it nor any major discussion
<@ajax> as projects become more central to the OS they seem to naturally develop a formal release process, so, it was time. 
<@ajax> keithp as release manager is really trying to be just quality control not content control
<@ajax> first phase is pretty wide open, change whatever, as long as there's rough consensus.
<@ajax> second phase is more bugfix oriented, abi changes and such are still acceptable but needs to be bug focused.
<@ajax> third phase is stabilization
<@ajax> aaronp now actually monitoring ABI and asking when/if we're ABI stable.  woo!  
<@ajax> third phase is where we're really saying distros should start testing; regressions at that point _will_ get looked at
<@ajax> "blocker" is sort of a misnomer, more of a tracker
<@ajax> really only security regressions would be a serious release blocker
<@ajax> comment from libv: we still see a pretty large vendor merge window, wasn't that the promise of m12n? 
<@ajax> ajax and mherrb: we try to merge down but there's portability issues that prevent a lot of those.
<@ajax> so you oscillate
<@ajax> jamey says "patchwork was a huge win for me, once i filter down to just my patches, but it seems underused"
<@ajax> request for keith to reply to anything that gets merged
<@ajax> stable branch maintainers (jeremy and ajax for 1.9) need your help, cc them on stable-worthy candidate
<@ajax> (s)

Friday, September 17

Multitouch session

<@ajax> got to the multitouch talk late, sorry about that
<@ajax> let's see if i can't backfill from what i heard since coming in
<@ajax> unlike mpx, you have to glue all the touch points together as one device, since otherwise you have to do device create/destroy notifies for every touchpoint, which will wake up every client and that's lame
<@ajax> multitouch and gestures are actually separate things, there are plenty of use cases that want multiple touches without gestures
<@ajax> touch and pointer events are probably separate things; pointer and touch grabs would ignore each other, if A has a pointer grab B would still recieve touch events
<@ajax> event replay makes for many weird issues, events can get delivered out of order 
<@ajax> some devices can report events as bitmaps (actually rgb images); ouch, imagine queueing all that up in the server until the events replay
<@ajax> "everyone wants multitouch, but nobody wants multitouch"
<@ajax> experience with app development is that they end up 99% singletouch with a sprinkling of pinch/zoom or similar
<@ajax> mt probably not going to happen for 1.10
<@ajax> multitouch workshop earlier in the week was mostly violent agreement for the short term and then fuzzier after 
<@ajax> timeline is hard to predict; chase should have more time for it after maverick, daniels working on it, so, _something_ will happen.
<@ajax> ms surface has a ui principle of "no touch left behind", every touch has visual feedback. otherwise people think the app is broken and poke the screen harder and harder
<@ajax> only ~5 gestures are intuitive (swipe, pinch/zoom, etc); after that the UI needs to give feedback to show what's happening
<@ajax> (some technical discussion about how to draw that feedback, hardware cursors or ...)
<@ajax> how do we help?  test!  write an actual app and find out how it doesn't work. 
<@ajax> peter's not an app guy or a toolkit guy, so he's kind of driving blind without that kind of feedback

Gestures session

<@ajax> "gestures" here means intuitive gestures only (again, as above, pinch zoom swipe rotate etc), not "magic" gestures like draw a star to close an app
<@ajax> general consensus that gestures need to be client-side for the most part, X just demuxing events
<@ajax> which isn't how it works now, but, getting there
<@ajax> mtdev: multitouch tracking translation library.  eats raw multitouch data (tracked or not), emits tracked data and filtered coordinates
< whot> http://bitmath.org/code/mtdev/
<@ajax> utouch-grail: gesture recognition and instantiation library.  eats tracked touches, emits gestures if they're recognized or passes through if not
<@ajax> gestures only emitted if the client has expressed interest in _that_ gesture (if you don't care about rotates, you won't get them)
<@ajax> utouch-geis (pronounced like "geist" without the t): gesture engine interface support. input is platform-specific gesture events, output is common gesture event interface.
<@ajax> geis is api for apps to register for gestures
<@ajax> (architecture diagram)
< remi|work> could someone in the room point out that Metisse has infrastructure for that? it already supports gestures (done with the mouse) which you can "cancel" if you've messed up, in which case metisse replays the mouse events for the underlying windows
 * whot waits for ajax asciiart skills
< remi|work> not that I'm pushing for Metisse directly, the code is a mess and I wouldn't force it on anyone other than me :D
<@ajax> xcb-gesture is private implementation-detail protocol to get this out of xserver up to geis and unity
<@ajax> another architecture diagram, this one moves stuff out to client side
< whot> remi|work: discussion on what is mettise ensues :)
<@ajax> motivation is about pluggable gesture recognizers and keeping complexity out of the server
< remi|work> whot, may I assume you've described what it does? :)
< whot> ajax did, roughly, yes
< whot> metisse is not something easily explained in 30 sec :)
< remi|work> haha, right :P 
< remi|work> well the 2 core features are window compositing and per-window input redirection
< remi|work> the rest is just fluff :)
<@ajax> unity has a use model where 3 and 4 finger gestures are window and environment controls, so want to make those things that you "unlock"; how do you design that well?  not really clear.
<@ajax> whot points out that direct (touchscreen) and indirect (touchpad) multitouch are pretty different usage models, not clear that you want to conflate them.
<@ajax> list of hardware with interface style and number of touches
<@ajax> big categories are touchscreen, trackpad, and apple magic mouse.
<@ajax> (demo)
<@ajax> question: have you seen any blob devices?  (shrug, no)
<@ajax> usual licensing discussion

XCB session

< JoshTriplett> So, notes from the XCB BoF...
< JoshTriplett> "Apparently XTS uses some interface in Xlib which allows direct use of the X protocol, and this doesn't exist in Xlib/XCB."
<@ajax> hey xcb people, have you looked at this: https://bugs.freedesktop.org/show_bug.cgi?id=29657
< JoshTriplett> Discussion attempting to find out what interface...
< krh> ebassi: right 
< JoshTriplett> "Perhaps someone should port XTS to XCB natively?"
< JoshTriplett> ajax: Yes, we have, and we're in the process of giving that some thought.
< remi|work> JoshTriplett, you're filling in for ajax ?
< JoshTriplett> remi|work: Yes, it seemed appropriate for a BoF to note discussion and show it on the projector.
< JoshTriplett> So if you have questions for the BoF or the room, pretend you're here and ask. :)
< JoshTriplett> The room will see it.
<@ajax> i like the sherrif's star next to my nick.  that might be the only thing i like about xchat.
<@ajax> wait, that's not xchat, is it.
< JoshTriplett> ajax: Pidgin.
< alanc> it was already mentioned that Xlib 1.4 (RC1 out now, final release out RSN) will always have the XCB integration and no longer support building without it
< JoshTriplett> alanc: Thanks for making sure that didn't get missed.
< alanc> ajax: xchat gives you green balls, not sheriff's stars 
< remi|work> JoshTriplett, Q: "plans for API/ABI stability in xcb and various other libs (eg, never ever change like libX11? or perhaps majors breaks every now and then?)
< remi|work> "
< JoshTriplett> Current discussion: Handling of events in Qt and GTK+, and non-incremental porting of the event handling from Xlib to XCB.
< JoshTriplett> remi|work: queued.
< remi|work> thanks
< mbalmer> Bonjour from row 3, seat 6729. 
< JoshTriplett> Q from ajax: "What about XIfEvent, why can't we look ahead in the XCB event queue?"
< remi|work> JoshTriplett, (not sure if this is the right BoF for this question) "Is anyone working or planning to work on cairo xcb/xlib-xcb ?"
< JoshTriplett> A: "You should process events in order, and if you really want a queue, you can build one on top of XCB." 
< JoshTriplett> remi|work: sure. 
< JoshTriplett> Followup: "You can't always process input events in order, you might need to look ahead."
< JoshTriplett> "You can just handle that via the callbacks after the event receipt..."
< JoshTriplett> "...just queue a callback later, don't forward the event into the application"
< JoshTriplett> "Effectively you can get motion compression"
< alanc> this is the sort of thing we need to document as recommendations/best practices
< JoshTriplett> Followup from ajax: "Having to port all of the event handling at once seems painful"
< JoshTriplett> A: "Not trivial to demux events to Xlib and XCB simultaneously, you have to pick one"
< JoshTriplett> Much discussion about Xlib and XCB's event queue.
< JoshTriplett> "The main problem: Xlib's event queue is a data structure in the Display structure"
< JoshTriplett> "keithp: Don't move events out of XCB, copy them out of XCB"
< JoshTriplett> remi|work: Discussion in the room about the answer to your question: "yes, we intend to guarantee API/ABI stability for libxcb since the 1.0 release; we might add new functions but we won't break existing ones" 
< JoshTriplett> remi|work: Currently discussing cairo.
< remi|work> JoshTriplett, many thanks :)
< JoshTriplett> note from ajax: "You have a bajillion libraries"
< Kayden> remi|work: (however, it was noted that xcb-util is still very much an experimental playground, and is not API/ABI stable)
< JoshTriplett> Kayden: Thanks.  Yes, though things split *out* of xcb-util should provide API/ABI stability.
< remi|work> indeed, that's the one I had in mind
< JoshTriplett> "ajax: ~31 libxcb-* libraries, each one wastes 3 fragments of pages due to shared libraries"
< JoshTriplett> "ajax: We should be using ELF filters, which let us expose the same API/ABI of various libxcb-*.so libraries but have them live in a single libxcb-ext.so"
< JoshTriplett> General consensus that that seems like a *great* idea. 
< JoshTriplett> Question for the IRC channel: who did the SoC work on XKB?  Was that mceier?
< remi|work> ajax, care to tell how that works when you have a minute? I'm curious
< vignatti> ELF filters sounds so hacky 
< whot> mceier: you did xcb input GSOC, right?
< mceier> mceier: yes, I've done the XML part. 
< mceier> :p
< JoshTriplett> "keithp: Keep libxcb and the extensions in the same library, don't bother with a separate libxcb-ext either"
< whot> mceier: well, you're on TV now :) what's the current state of XI and XKB in XCB?
< JoshTriplett> mceier: IRC is on the projector at XDS right now. :)
< whot> your 15 minutes of fame
<@ajax> vignatti: hey man, you're the anti-size queen.
<@ajax> i'm on your side here.
< vignatti> ajax: I' am. And I don't want a couple of unused extensions for my system though in one single library
< vignatti> :)
<@ajax> so build them out.
< mbalmer> tiago++
< oga_> oh no, you might have a couple of K disk space wasted.
< oga_> or just don't build them, indeed
< vignatti> okay, we'll need a configurable way to do so then
< JoshTriplett> vignatti: We have that.
< vignatti> sweet
< JoshTriplett> vignatti: configure options
< vignatti> JoshTriplett: I hope we don't get in the same state as xserver configure options disaster though :)
< JoshTriplett> :)
< mceier> well the XML part is complete, although it's not tested - it needs an implementation of some new tags in XML->C generator.
< mceier> like <switch> :)
< JoshTriplett> "ajax: I can try to find out how long ELF filters have been supported in binutils"
< JoshTriplett> (In response to the note that some embedded systems use antique binutils and such that might not support ELF filters.)
< JoshTriplett> mceier: Thanks!
< JoshTriplett> Sounds like XI has similar need for <switch>, though somewhat less insane than XKB (not hard to do).
< JoshTriplett> Discussion about API/ABI of extension libraries when the extension revs the protocol.
< JoshTriplett> Question of whether anyone cares about supporting multiple extension versions simultaneously.  "ajax: mmmm, no"
< JoshTriplett> "ajax: but some library systems make it possible to support multiple library versions"
< JoshTriplett> General consensus from the room: protocol extensions should not break backward compatibility, whether it bumps the major or minor number.  Always change the name of the extension; e.g. DRI2, XI2...
< krh> but never DRIng
< JoshTriplett> This certainly makes XCB's job easier; libxcb-xi2 versus libxcb-xi
< krh> "next generation" is verboten
<@ajax> IGDNG!
< oga_> IGD was just worse
< oga_> you mean like.... ALL OF YOUR GRAPHICS DEVICES?
< JoshTriplett> Wave goodbye to the room. :)
< ickle> but IGDNG^W sandybridge!
< alanc> Further consensus from the room: "rootless" sucks as feature name, call it "unprivileged" or "hosted"
< Kayden> clearly IGDNG5...like R5RS :)
< mbalmer> or non-root...
< tilman> alanc: yay
< Kayden> (revised revised revised revised revised report on Scheme...)
< alanc> mbalmer: non-root-user or non-root-window ?
< mbalmer> yeah, that's confusing...

Unprivileged X

<@ajax> apropos of which, next talk is on unprivileged X
<@ajax> major question is input.  you have to trust whatever opens the input device.
<@ajax> (you have to trust the X server to close input devices on the way off the vt)
< alanc> Keith's requirements: 1. No display server should be privileged - should not have control of which server gets input events from devices
< mbalmer> Hmm, I think this input switching problem could be solved in a rather elegant way, at least I knew how I would approach it in the BSD kernel (and I assume in Linux it's not hard either)
<@ajax> details about where we put that mechanism: cgroups or whatever
< oga_> mbalmer: how?\ 
< oga_> krh: btw, your flink_to idea a while back was sound, what happened to that? 
< krh> oga_: the linux kernel got released earlier than expected so I stopped working on it for a bit 
< JoshTriplett> flink_to sounds like an interesting call; link file descriptor to new filename?
< mjg59> krh: Yeah, shipping in 1991 was kind of unexpeted
< oga_> JoshTriplett: no, this is gem filehandle stuff 
< JoshTriplett> ah.
< oga_> krh: I was thinking of something similar about a year ago, we should move forward on that
< krh> JoshTriplett: yeah, flink_to for fds makes sense too
< JoshTriplett> "ajax: My model assumes code injection attacks don't happen" (between processes running as the same user) 
< JoshTriplett> "keithp: So you want security theatre?"
<@ajax> someone else keep writing notes 
< alanc> 3 issues: 1) switching input devices between servers 2) switching front buffer control 3) RunFromSmartParent
< alanc> Wayland is the answer to everything, as long as you can afford another 1000 context switches/second
< mbalmer> for every byte send from a mouse, oh my....
< oga_> it is wayland all the way down
< whot> mhmmm, turtles... *drool*

EGL in Mesa

<@ajax> gl is just a rendering api, you also need window system bindings (wgl, agl, glx, etc0
<@ajax> egl is "embedded" gl, useful for when there's no window system, but is also used to be agnostic of your window system.
<@ajax> since all the binding apis are fairly similar, it's easy to implement egl interms of say glx
< bobo1on1> egl is to gles what glx is to gl right?
<@ajax> ennh. 
<@ajax> egl can encapsulate lots of rendering apis.  vg, gles, gl proper...
<@ajax> gles (embedded subset) comes in fixed-function gles1 and programmable gles2 
<@ajax> mesa can implement the gles api in terms of dri drivers
<@ajax> egl has an image extension for sharing pixels across APIs
<@ajax> which works in mesa! yay. gallium drivers can even do vg (well, they have a state tracker for it anyway)
<@ajax> mesa extension to image extension to create your own image objects (normally you have to pull them out of a rendering api), with hints like "am i scanout" or "am i shared between processes"
<@ajax> these map pretty directly to gem objects
<@ajax> working on official khronos extension for image sharing across processes
<@ajax> useful for accelerated compositing in separate processes
<@ajax> mesa can create contexts for a particular api (gles or full gl, etc)
<@ajax> demo: es2gears under X
<@ajax> (tsk, only 360fps)
< whot> ajax: those are metric seconds though ;)
< MrCooper> FWIW the Mesa VG demos have worked for me with r300g, should be easy to get it working with any other Gallium driver
< RAOF> The Mesa VG demos have worked for me with nvfx and r600g, also. 

Board meeting

<@ajax> people have started sending submissions for new logos?  weird,.
<@ajax> minor legal issues around signing over rights etc.
<@ajax> so if someone wants to help organize that, please do talk to the board (contest etc)
<@ajax> $3000 in checking, $120k-ish in stash, paid out $13500 ish in sponsorships and travel
<@ajax> did agree to sponsor an xcb workshop, though  there's no date for that
<@ajax> again, willing to sponsor special-topic workshops, if you have ideas talk to the bord
<@ajax> board@foundation.x.org
<@ajax> checks for xds sponsorships are in keithp's bag, so, bother him if that applies to you
<@ajax> possibility to hold next xdc in brazil? difficult for travel reasons, but possible.
<@ajax> possible colocation/contemporary with bossa or fisl
<@ajax> really needs local organizer though
<@ajax> tiago says there are brazilian nokians that could probably do organization
<@ajax> some discussion about costs 
<@ajax> other suggestion to colocate with desktop conference in (berlin? germany anyway)
< vignatti> actually Bossa been happening lately in March 
<@ajax> no real decision yet; send suggestions to the board, either in email or at the irc board meeting

Saturday September 18

OpenGL baseline

< alanc> inspired by blog from KDE developer about what OpenGL calls work in various open source drivers
< alanc> need to better to communicate what we expect to work
< alanc> can we just fix bugs to get closer to actually having full OpenGL 3.0 support?   we're maybe 90% there
< airlied> alanc: question from outside, if AMD/Nvidia have any interesting contributing to piglit
< airlied> from the closed source side of the companies
< alanc> not sure anyone came from those groups
< airlied> well ask if the guys there can make the closed guys more aware of it 
< alanc> agd5f says that asking them to contribute to piglit would be a good idea
< alanc> (this is a discussion session, not a presentation, so it's hard to keep up with IRC notes, especially as it broke into sub-conversations)
< alanc> there is a discussion thread that getting more people in general contributing to piglit would be good

libxkbcommon

< alanc> "it's all daniels' fault"
<@ajax> xkbcomp as a library, more or less
<@ajax> which takes your xkb configuration and turns it into the big map from keycode to keysym
<@ajax> krh working on giving it an actual api instead of being just a pile of structus
<@ajax> we're not using it at the moment in the X server, but boy we really should be
<@ajax> (right now there's a popen() adventure that's quite disgusting, go read it if you're into schadenfreude)
<@ajax> not completely straightforward to use in xlib, since xlib has its own xkb api that we can't break; but it could happen
< whot> acronyms galore
<@ajax> xcb has no xkb support yet, this could help. 
<@ajax> and, of course, if you happen to be writing your own display server for some reason, you could use this to import X's keyboard layout support
<@ajax> so that's also cool
< alanc> but you'd have to be crazy to be writing your own display server
<@ajax> so, do we actually use this or not?
<@ajax> general consensus that we really do need to make xserver use it if we want to claim it's usable at all
<@ajax> ~3 versions right now (daniels, krh, dbn) so we need to pick and/or unify those 
<@ajax> "i'm sure we could write a better parser, but then... we'd be writing an XKB parser"
<@ajax> discussion about possibly keeping a binary form of the text files around to at least cut the parsing time out of the profile
<@ajax> rough consensus: yeah, probably, and it might as well be the wire protocol format if we do that since we know it's sufficient
<@ajax> daniels does have an xserver branch up that's ported to xkbcommon

Input threads impromptu

< oga_> friends don't let friends call ioctl from sigio 
<@ajax> aside on input threads
<@ajax> basically we want "threads or classic" instead of the current "sigio or classic"
<@ajax> no one seems to have a problem with _that_, but there's some doubt that non-classic is actually a win 
<@ajax> to the doubters, go find X11R1 and build the plaid demo, and you'll be convinced
< oga_> sure, i'm game
< oga_> don't suppose you have a url to save me the search engine latency?
< alanc> http://www.x.org/archive/
< oga_> found a copy. imake isn't behaving though
< alanc> we could probably autotool it in about 10 minutes if we cared 
< oga_> feh,  
< oga_> oga@melanie/p4:/tmp/X.V11R1/demos/plaid$ ./plaid
< oga_> Cannot open display
< oga_> : Undefined error: 0
< oga_> EGIVEUP
< oga_> oh, no fixed it
<@ajax> also, CLOCK_MONOTONIC_COARSE is way way cheap, so we should use that for the tick source when it's available (and HZ is high enough)
<@ajax> anyone still using a HZ of 100, seriously fix your kernel.
< leio> 250 or 300 good enough? :P
< oga_> may play with that soon
< RAOF> Hm.  Ubuntu kernel seems to be set at 100Hz.
< oga_> i wonder how many  hardcoded bugs I find
<@ajax> threads won't be universally deployed since they're not a win if you have userspace threads (openbsd eg)
<@ajax> or if you don't have threads (mingw we think)
<@ajax> also general consensus that the current main loop is lame and libevent would be better
< oga_> as mentioned a couple of days ago, if no one else gets to it before me then it is on my to-do\
< oga_> but my hacking latency right now is worse than my machine running plaid 

Intel DRM for OpenBSD

<@ajax> gem is like the buffer cache but for gpu instead of disk
< mbalmer> nice slides he has...
<@ajax> despite the drm code being MIT-licensed, it's not directly portable
<@ajax> mostly because the vm's are different among OSes
< alanc> that matches the experience of the folks porting DRM to the Solaris kernel as well, having yet another VM system
<@ajax> obsd does gart mapping directly on the object instead of being under the drm fd
<@ajax> cache coherency and tiling are handled differently, tiling is handled entirely by kernel instead
<@ajax> netbsd could probably c/p the drm code since the vm is relatively similar, freebsd would have more issues
<@ajax> kms is a ways off still 
<@ajax> (discussion of how kms and fbdev interact under linux and what the parallel would be under bsd)
<@ajax> only want one DRI implementation in the kernel so need to get radeon converted to DRI2 before looking at KMS for real

Mesa feature requirement/removal

<@ajax> possible things to mandate:
<@ajax> ARB_copy_buffer - trivial addition after ARB_vertex_buffer_object which is always enabled
<@ajax> ARB_map_buffer_range - ditto 
<@ajax> APPLE_object_purgeable - maybe ditto? needs another look at the spec.
< alanc> screen is showing http://www.x.org/wiki/Events/XDS2010/Program#line-93
<@ajax> bah, i thought it was still just a preview.
< alanc> oh, I guess it does say #preview up there, wonder what they've edited since the last save
<@ajax> object_purgeable might be tricky since apps might be aggressive with it present and conservative without?  who knows.  possible drirc if it's a problem.
<@ajax> ARB_vertex_array_object is also easy
< oga_> oh, with purgable if you worry about that just always purge 
<@ajax> ARB_draw_elements_base_vertex is well fakeable on hardware that can't support it; do we care? 
< oga_> the idea is that stuf can be recalculated anyway, but you cache it while you have memory free
<@ajax> SGIS_generate_mipmaps too
<@ajax> don't know if we have sufficient tests in piglit ot glean for these?
<@ajax> earlier discussion (about gl support) mostly concluded "better communication for app developers"
<@ajax> easy baseline seems to be "the stuff in gles2" which is basically 915 and r300 level shading
<@ajax> new version of GL has an extension for es2 compat so that's pretty sensible too
<@ajax> do we want to start requiring new tests for any new feature addition?  well, we should, yeah. 
<@ajax> and we've been better about that over the last year or so, so, sure. 
<@ajax> (needs confirmation with brianp etc, but)
<@ajax> (still just going down the list on the page alanc linked)
< alanc> now on the fbdev driver discussion on http://www.x.org/wiki/CorbinSimpson/KillItWithFire
< alanc> nominated for burning at the stake: 2 of the 3 sw rasterizers in Mesa: swrast, softpipe or llvmpipe
<@ajax> ended up with no real time to talk about the glsl compiler; sorry 
<@ajax> mostly loud agreement about what to kill and bits of historical trivia

xserver 1.10 planning

<@ajax> per-crtc pixmaps, libxkbcommon, atomic modesetting for randr
<@ajax> schedule posted to the list a bit ago, seems okay (mid february)
<@ajax> input abi to break again
<@ajax> openbsd patch merge
<@ajax> input threads, libx86 out for real
<@ajax> coarse monotonic timer for scheduler
<@ajax> vgahw abi updates
<@ajax> privilege reduction work: signal to parent, io port access, input devices etc.
<@ajax> driver merging: yes?  no?
<@ajax> benefits are bisectability and immediate feedback
< leio> arguable
<@ajax> (and argued, yes)
< dottedmag> ajax: Q: is libv's proposal considered? The one presented on last FOSDEM
<@ajax> more frequent rcs may be valuable; but probably don't need to be actual tarballs, just git tags is fine
<@ajax> dottedmag: remind me what the primary artifact of that proposal was?  as i remember it was just "hey i can make an sdk, we should do that"
< libv> ajax: no, that would be the dri sdk that i did in response to what some people were telling me at fosdem. 
<@ajax> proposal to unify the kms common code
<@ajax> should probably merge dummy (video) and void (input)
<@ajax> sdksyms.sh needs to be shot; ajax volulnteers, the sucker
<@ajax> input drivers possibly more interesting to merge since that abi changes more (and yet, people care less)
< alanc> input drivers mainly change due to input ABI changes - for most of them the actual device support is either static (the ancient PS/2 & serial mouse protocols in mouse_drv haven't changed in years) or not in the X driver but down in the kernel (evdev on linux, vuid on Solaris, etc.)
< alanc> wacom & synaptics being exceptions
< dottedmag> ajax: IIRC, it was moving X driver, DRI, DRM and kernel module for each driver to the single place, so drivers need to rely only to more or less stable interfaces.
< dottedmag> libv: am I right?
<@ajax> also vesa and fbdev proposed for merging (mostly as build canaries)
< leio> again, have not heard any real benefits, even for those (vesa/fbdev). I can cite the known drawbacks.
<@ajax> go for it.
< dottedmag> ajax: merging vesa and fbdev does not make sense from embedded standpoint.
< libv> dottedmag: yeah, for a single sentence (which i won't manage anyway), definitely
< alanc> embedded can --disable-vesa --disable-fbdev
<@ajax> dottedmag: your package system knows how to not install things.
< libv> i hate the vesa idea though... if my vesa is broken, i cannot update my driver anymore :((
<@ajax> libv: i don't follow.
< leio> or embedded can not install xf86-video-vesa, which is much more friendly from a packaging standpoint - still have the same packages for whether to have or not have the driver.
< libv> ajax: read that again, and then remember what i put most of my work on, and where the actual vesa bugs really happen :)
< libv> or, that was a joke.
< leio> read: You can give workarounds for packaging problems, but still haven't heard any benefits.
< dottedmag> ajax: not a drivers merging, but just repositories merging? Not a problem then.
<@ajax> dottedmag: right, you'd still get separate objects.  vesa_drv.so would still be a loadable.
< leio> dottedmag: because you make debian do separate packages?
< libv> dottedmag: libv.livejournal.com
< mbalmer> complete operating systems ship like this...  kernel, userland, drivers, even compilers in one single module....
< oga_> ``oh no, my 2kb of disk space! whatever shall I do''. 
< dottedmag> libv: I referred to vesa/fbdev 
< mbalmer> install to /dev/null?
< dottedmag> leio: because I can continue avoiding to load VESA-related stuff on device without any sign of VESA and with quite limited memory.
 * mbalmer wonders if this discussion is a sign of admitting that going modular was a mistake in the first place...
<@ajax> mbalmer: no, just that it's hard to find where to slice.
< dottedmag> no
< oga_> going *so* modular quite probably was
< oga_> splitting in general was mostly a good thing
< mbalmer> server, drivers, protos
< dottedmag> oga_: amount of modules is not a problem, but interfaces are.
< Kayden> also, things were quite different back then.
< oga_> dottedmag: it is a pain in the arse.
< Kayden> xfree86 was a long time ago.
< oga_> 32 protocols packagezs with more build system than actual code
< dottedmag> who cares?
 * mbalmer does
< drago01> what about this ... try it out  in case it sucks split them again 
< drago01> people pretend as if there is no way back
<@ajax> it's not really "pretending".  we just like to argue.
< libv> drago01: i just hope that vcs history does manage to get preserved over such changes.
<@ajax> everyone's seen a makefile so everyone thinks their opinion on buildsystems matters.
<@ajax> libv: that's pretty straightforward in git, but yes, valid concern.
< tilman> the merged proto package _will_ happen, right? or is that still argued about, too?
< alanc> it happened, we called it xcb-proto, we just need to port everything to use it instead of the old ones
< alanc> of course, that isn't likely to happen before 1.10
< tilman> okay
< alanc> no one came up with a strong argument against merging the old proto drivers during the 1.10 cycle, so it seems to be more a matter of if someone puts in the work
<@ajax> competent argument for gpu objects, for once
< leio> if the mid-term plan is killing them in favor of xcb-proto, the question becomes whether it's worth it to have distributions and other build systems need to adapt to these changes now
<@ajax> (gpu size limits, crtc collections)
<@ajax> and xineramifying randr to actually work across gpus
<@ajax> ... and not much else! 
<@ajax> "if we do this in brazil, we should really start an hour later"
<@ajax> mad props to mherrb for hosting and organizing
<@ajax> see you on the other side of the planet next year