diff options
597 files changed, 40130 insertions, 0 deletions
diff --git a/ATIProprietaryDriver.mdwn b/ATIProprietaryDriver.mdwn new file mode 100644 index 00000000..4e5c0854 --- /dev/null +++ b/ATIProprietaryDriver.mdwn @@ -0,0 +1,39 @@ + + +## ATI/AMD Closed Source "fglrx" Drivers + +Since the Radeon R200 chipset series ATI/AMD is providing its own set of closed source binary only drivers for their hardware. The drivers were originally designed for the FireGL professional graphics adapters but got extended soon for supporting any comparable mainstream board design from ATI Inc. and from third party board vendors. + +See also the [[VideoDrivers|VideoDrivers]] page for a list of other drivers for ATI hardware. + + +### Driver Package + +The rpm packaged drivers from ATI/AMD do provide those main components: + +* readme file or a set of documentation pages +* DRI compatible driver module for 2D support +* DRI compatible driver module for OpenGL support +* kernel module (precompiled binaries plus source/lib for self building) +Other than that there are those minor components: + +* a set of install/uninstall scripts for usage by the rpm packaging +* a customized x11 configuration tool +* a binary control panel based upon QT toolkit and its sources +* sample source for the gamma correction interface +* sample application for OpenGL pbuffer rendering extension +The driver is hosted at [[http://www.ati.com|http://www.ati.com]] - go to download, select your board and then the Linux operating system for getting to the matching page. If Linux is not listed for your specific board then that might just be a web update error - you should then try out the drivers for a similar board as there is really only one single driver for all boards. + + +### Status + +The driver is relatively mature and does perform quite well for professional OpenGL applications. Some gaming applications do work reasonably nice, some others might still expose some minor or major problems. 2D performance is below of what the open source DRI drivers do provide, but is still acceptable fast for everyday work. The set of drivers still is bound to XFree86 4.0.0 and X.Org 6.7.0, but might get updated to be compatible with the latest X.Org release. Further updates and inclusion of GLSL are expected for one of the very next releases. + +The current drivers are for Linux/i386 and Linux/x86_64 (AMD 64bit or Intel EM64T) platforms only, but there were some Linux/ia64 drivers available from the download page of some big OEM vendor. + +For more information and discussion on the current driver releases a visit of the [[http://www.rage3d.com|http://www.rage3d.com]] forums is recommended. + + +### Support + +Please note that Xorg developers are mostly unable to help with any issues with this driver. For discussions with other users, please use the #ati IRC channel on irc.freenode.net. diff --git a/AdamJackson.mdwn b/AdamJackson.mdwn new file mode 100644 index 00000000..4c67e77c --- /dev/null +++ b/AdamJackson.mdwn @@ -0,0 +1,111 @@ + +X hacker, for Red Hat and recreationally. [[See elsewhere.|http://freedesktop.org/wiki/AdamJackson]] + + +# Old school 3D hardware + +I have something of a rare hardware fetish. The following list of cards I'd like to have at some point is as much for my own benefit as anyone else's. If you have one of these and are willing to part with it, please let me know! Contact info can be found through the link at the top. + +Even better, if you have programming information for this hardware, or contact information for the defunct companies, let me know. Even if it's just a definitive "sorry, this never taped out", that's better than nothing. + + +## 3dfx + +* Voodoo 5 6000. Sure, why not. +* Also, just about any sufficiently interesting Quantum3D card is fair game. + +## 3dlabs + +* Anything newer than what's supported by the gamma(4) driver. I've got a Wildcat VP760. I'm sure there's more than one generation of Wildcat though. + +## Ark Logic + +* 8100 (Tiger3D) and 8300 (Cougar3D). If they exist. + +## ArtX + +* Anything! They look like they were in business just long enough to sell some of their own kit before being bought by ATI (ATI paying to have ArtX take over really). I already have a Game``Cube, thanks though. + +## ATI + +* Rage Fury Maxx. Dual rage128. I have one but I don't think it POSTs anymore. + +## Barco + +* Did some medical imaging cards, among other things. Some were Number Nine chips with extra output cleverness, but there seem to have been some custom ASICs too. +* Update, 2008-05-01: I have two now. One's a pair of Cirrus chips behind a PCI bridge. The other is a custom ASIC. The PCI ID is for "Metheus Corporation", who Barco definitely bought. Despite having a ROM, it's not VBE-compliant. And, terrifyingly, the string "Tseng" appears in it. The ASIC name appears to be "Aura", according to the ROM. + +## Chromatic Research + +* mPact. Actually I have one, don't remember which one though (there's two, according to pci.ids). These were early shader-like hardware, so I would dearly love to find programming information or a competent driver disassembly. + +## Diamond + +* Various FireGLs. This is a bit misleading since Diamond never did silicon, but wikipedia [[lists|http://en.wikipedia.org/wiki/FireGL#List_of_Cards]] basically four varieties: FireGL 1 - 4 with IBM chips, 1000 through 3000 just boring old Permedias, 4000 is some wacky Mitsubishi chip and 5000 is something totally alien. I'd love to lay hands on a 4000 or 5000, I have examples of the other two varieties. + +## Dome + +* Same story as Barco, really. Later sold to Planar but still sold under the Dome marque. Not sure any of these were non-#9 chips, to be honest. + +## Evans and Sutherland + +* Pretty much any REALimage chip. I have a Lightning 1200 and a Tornado 3000. The E&S chips look like they also made their way into Accel``Graphics' Accel``Galaxy and other boards. See also Real``Vision below. + +## Intel + +* Intel 752 or 754 cards. These are rumored to exist but I've never seen one in the wild. Should be more or less i810 graphics on a card? + +## Intergraph + +* Don't really know the genealogy here. I have a few cards, need to document them better. These are probably predecessors of the post-glint 3dlabs kit. + +## iXMicro + +* Anything. I had a Twin Turbo ages ago but gave it away to daniels. + +## Matrox + +* QID. Pretty sure this is just a Parhelia with two extra output pipes. Almost certainly, pci.ids lists QIDs as variants of other P-series chips. I have a Parhelia and a P650, but it's a little unclear where the register banks for the other two CRTCs on a QID live. + +## Neomagic + +* Magic``Media 256XL+. The only one with a 3D engine. Almost certainly only to be found in laptops. The OQO model 01 possibly? + +## Number Nine + +* Imagine 2 (PCI ID 105D:2339) +* Ticket 2 Ride (PCI ID 105D:493D) +* Anything done by [[Silicon Spectrum|http://siliconspectrum.com/]]. + +## NVIDIA + +* NV2. Assuming any ever made it outside NVIDIA campus. + +## Oak Technology + +* Warp 5. If it exists. Wikipedia has a picture of a prototype board. + +## RealVision + +* Anything. Corporate takeover history leads me to believe they inherited the gfx group from E&S, so these might be related kit. I don't speak Japanese though. + +## S3 + +* Delta``Chrome and Gamma``Chrome. I have a Chrome S27. + +## Tech Source + +* Raptor 2100T. Yet more ATC hardware. + +## Tritech + +* Pyramid3D. Eval hardware definitely produced, definitely never shipped to retail. + +## Tseng Labs + +* ET6300. Again, not sure this ever reached market. + +## XGI + +* Volari V8 Duo. If it shipped. +* XP10.
\ No newline at end of file diff --git a/AdvancedTopicsFAQ.mdwn b/AdvancedTopicsFAQ.mdwn new file mode 100644 index 00000000..d4790c01 --- /dev/null +++ b/AdvancedTopicsFAQ.mdwn @@ -0,0 +1,50 @@ + + +# Advanced Topics + +[[!toc ]] + + +## I want to make the mouse cursor invisible + +X always must have a cursor. Its appearance depends on the window the cursor is over. You can change the appearance of the root window cursor and make it invisible that way. To make the root window mouse cursor invisible create an empty bitmap file. To do so you can either create a file [[emptyCursor.xbm|emptyCursor.xbm]] with the content: +[[!format txt """ +#define emptyCursor_width 1 +#define emptyCursor_height 1 +#define emptyCursor_x_hot 0 +#define emptyCursor_y_hot 0 +static unsigned char emptyCursor_bits[] = { +0x00}; +"""]] +or you can use the application `bitmap`. Start bitmap, create a new bitmap file with the `File->New` menue, and save it with `File->Save`. Assuming you called the empty bitmap file `emptyCursor.xbm` you can now change the root window cursor with: +[[!format txt """ + xsetroot -cursor emptyCursor.xbm emptyCursor.xbm +"""]] +NOTE: As mentioned this *only affects the root window cursor*. Modern window managers create their own root window. Its cursor is not affected by this. Also most applications define their own cursors. Moving a cursor over an application will cause its cursor to be displayed if it defines its own cursor. If it doesn't it will inherit the cursor of its parent window. + + +## I want to run the Xserver without a mouse attached, however the Xserver doesn't start without a core input device + + +### Server 1.4 (X11R7.3) and later + +The server will start without any devices connected. No core input device is needed anymore, it is automatically allocated. If your server crashes or shows other signs, this is a bug. Please file a bug report. + +You may also want to add the following line to the [[ServerFlags|ServerFlags]] section of your xorg.conf file: +[[!format txt """ + Option "AllowEmptyInput" "True" +"""]] + +### Earlier versions + +X refuses to start if the initialization of the core pointer input driver fails. You can add the line: +[[!format txt """ + Option "AllowMouseOpenFail" +"""]] +to the `"ServerFlags"` section to prevent this. However the better solution is to use the `void` driver as driver for the mouse input device. + + + +--- + + IDEA: Dual head setup and configuration issues diff --git a/AdvancedTopicsFAQ/emptyCursor.xpm b/AdvancedTopicsFAQ/emptyCursor.xpm new file mode 100644 index 00000000..9b330a37 --- /dev/null +++ b/AdvancedTopicsFAQ/emptyCursor.xpm @@ -0,0 +1,6 @@ +#define emptyCursor.xpm_width 1 +#define emptyCursor.xpm_height 1 +#define emptyCursor.xpm''x''hot 0 +#define emptyCursor.xpm''y''hot 0 +static unsigned char emptyCursor.xpm_bits[] = { +0x00}; diff --git a/AlanCoopersmith.mdwn b/AlanCoopersmith.mdwn new file mode 100644 index 00000000..57526871 --- /dev/null +++ b/AlanCoopersmith.mdwn @@ -0,0 +1,16 @@ + + +## Alan Coopersmith +[[!table header="no" class="mointable" data=""" +[[!img http://planet.freedesktop.org/faces/alanc.png] | Release Manager: X11``R6.9, [[7.5|Releases/7.5]], [[7.6|Releases/7.6]], [[7.7|Releases/7.7]] +X.Org Modular Maintainer: Solaris port, app/xdm, lib/libX11 +Co-lead (with [[MatthieuHerrb|MatthieuHerrb]]) of X.Org [[Security|Development/Security]] Team +Member, [[X.Org Foundation Board of Directors|BoardOfDirectors]]: 2009 - present +See also: [[http://people.freedesktop.org/~alanc|http://people.freedesktop.org/~alanc]], [[http://blogs.oracle.com/alanc/|http://blogs.oracle.com/alanc/]] +"""]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/ArchitectureToDo.mdwn b/ArchitectureToDo.mdwn new file mode 100644 index 00000000..c005ba0e --- /dev/null +++ b/ArchitectureToDo.mdwn @@ -0,0 +1,87 @@ + + +# The Grand ToDo List + +[[!toc ]] + + +## What is this? + +This is a list of fundamental problems standing in the way of a better implementation of the desktop. On-topic items include graphics and input problems and needed features. + +To anyone working on these problems, or working on a large problem not listed here: please update this page with comments. It is intended to be a kind of road map, so feel free to comment on what you believe is the preferred solution to a problem. + +Non-coding mailing list lurkers are encouraged to update this page if they see a mistake or something that looks out of date. If unsure about a change, put it in italics and put a question mark after it. _(Got that?)_ Someone else will come along and confirm/deny the question. + + +## XAA + +_"<ajax> - XAA is totally unsuitable for accelerating modern desktop usage"_ + +XAA is designed around accelerating the wrong primitives. + +Solutions include: + +* implementing KAA in Xorg +* using the Kdrive X server _(has something other than XAA, right?)_ +* using Xgl _(requires [[MesaSolo|MesaSolo]] and friends to be ready)_ + +## Render Acceleration + +_"<ajax> - Render is largely unaccelerated"_ + +This depends on the XAA problem above. XAA isn't suitable for accelerating render. + +Solutions include: + +* replacing XAA +* using Xgl _(see above)_ +_Does/did the proprietary nvidia driver accelerate render? How?_ + + +## DRI FBO/pbuffer + +_"<ajax> - DRI really needs pbuffers and fbo's"_ + +Self evident? + +_There's interest in getting DRI to transfer textures from one process to another for a "glcompmgr." Related?_ + + +## DRI needs a memory manager + +_... assume video memory only large enough to store one texture ... _ + +_<ajax> the first client in general can't assume that its textures are still where it left them. thus we have an sarea. "shared area". when DRI clients dirty some bit of state, they leave a note of what state they touched in the sarea. so our second client would have dirtied the texture state, so the first client knows it needs to push its texture again. now remember we're wanting to share textures between clients. so introduce a third client. 1 and 3 want to share their texture. 1 owns it. 2 runs, evicting the shared texture. 3 goes next, and the texture it wants isn't there anymore. except 3 can't push it, because 3 is trying to pull it from 1. see the problem? 3 never had a copy of this texture. _ + +_<tjk> sounds like a proper dri memory manager would solve that._ + +Right now DRI uses some kind of "peer to peer" memory management technique. DRI really needs to start managing video and agp memory for the clients. This would enable passing textures from one client to another without copying and without the possibility of deadlocking. + +Additionally this would reduce the complexity of clients. + +Presumably, DRIMM would be responsible for moving data between video memory, agp memory, and it's own storage in main memory tying all of the information to the process it belongs to. + +_Would this eliminate the need to map video memory into the client's address space? or Would it make it easier to implement memory protection so that one client can't start scribbling on another client's video data just for fun?_ + + +## Multiple cursors + +_Shared projector systems have serious need for multiple simultaneous streams of input. _ + +_I recently had a chance to play with the projector table at MERL, and we can expect similar such devices as commercial products over the next couple years; it provides a compelling demonstration of the need. _ + +* _- Jim_ +Do we handle this with multiple cursors? Or do with handle with by making applications explicitly request input from many cursors? + + +## Configuration format + +There has been noise about an elektrified x server and machine vs human readable configuration file format. The x server itself does need a configuration makeover, but by a more general mechanism. [[XHotplugProposal|XHotplugProposal]] would like to do with with some sort of external configuration client. This would enable a legacy X![[OrgConfig|OrgConfig]] client, an elektrified client, a HAL-based client using dbus, etc without introducing dependancies for the X server itself. The other advantage to using a client is hotplug. See the dynamic reconfiguration section above. + + +## X on GL + +DRI is being reworked and merged with the linux framebuffer code. [[MesaSolo|MesaSolo]] is being prepared and mode selection code is being rewritten. _(right?)_ + +Xgl is a proof of concept server, but without the above, it cannot run except inside an ordinary X server. As soon as the above are ready, we will have a legitimate possibility for moving all rendering onto the GL API as a standalone GL X server. diff --git a/ArchitectureWorkingGroup.mdwn b/ArchitectureWorkingGroup.mdwn new file mode 100644 index 00000000..0b63eecd --- /dev/null +++ b/ArchitectureWorkingGroup.mdwn @@ -0,0 +1,58 @@ + + +# X.Org Foundation Architecture Working Group + +The X.Org Foundation Board of Directors recently voted to create an Architecture Working Group to serve as a forum to discuss the technical direction of the X Window System. + +The Architecture Working Group intends to represent a variety of interests in X Window System technologies, including traditional Xserver and protocol library developers, toolkit developers, application developers, as well as end-users. As a result, this working group hopes to serve as a forum for a wide variety of discussions related to the X Window System, including (but not limited to) architectural discussions, general technical directions, as well as development processes and procedures. + +The goal of the Architecture Working Group is to facilitate discussion and provide a forum to help build consensus in the areas mentioned above. To further this goal, membership is open to all interested participants. In this way, the Architecture Working Group can chart the technical direction of the X Window System, as well as advance its use, maintainability, and improve the scalability of the X.Org Foundation's development efforts. + +For those areas that have a more focused scope in influence and/or duration, as well as a critical mass of interested participants, a sub-working group may be created. The Release Wranglers, the [[Testing Working Group|TestGroup]], and the [[Modularization Working Group|ModularizationWorkingGroup]] are examples of existing sub-working groups. + +As already noted, membership is open to all interested participants. In an effort to encourage participation from as many of the growing list of X.Org contributors as possible, a new mailing list has been created for this working group. To subscribe, please visit: + + * [[http://lists.x.org/mailman/listinfo/xorg-arch|http://lists.x.org/mailman/listinfo/xorg-arch]] + +## Current Projects: + +The X Developer's Meeting held in Cambridge in February, 2005, concluded with a discussion of topics of current interest to the X.Org community. In addition, some issues were raised that people felt were good developer-oriented issues for the Architecture Working Group to address via the creation of processes and guidelines to facilitate developers. Some of those areas include: + + +### Development and release + + * Create processes that explain how new code/features get to HEAD + * Draft guidelines for committing changes + * Understand possible ABI changes and implicit dependencies + * Reference bugzilla ID in the commit message + * More information in the comments and commit message is better + * More atomic commits - don't check 15-20 different things in at one time + * Need for an on-going code czar - someone who's authority to remove controversial code (until further discussion) is unquestioned + * Which licenses are acceptable for contributions to X.Org projects + +### Creation of a documentation project (or even a sub-working group) + + * Convert existing documents to Doc``Book + * Get APIs and specifications in one, easy-to-find place + * Can vendors contribute internally-generated documentation that has general information + * Translate documentation to other languages? + +### Other related pages + + * [[ArchitectureToDo|ArchitectureToDo]] contains an initial list of projects + * [[http://www.freedesktop.org/wiki/FreedesktopProjects|http://www.freedesktop.org/wiki/FreedesktopProjects]] contains a list of Freedesktop projects + * [[XDevConf|http://www.freedesktop.org/wiki/Software_2fXDevConf]] includes the projects discussed at given at the February, 2005, X Developers Meeting in Cambridge. + * [[XInputHotplug|XInputHotplug]] is Kristian Hogsberg's project for hotplug of input devices + * [[LookingGlassIntegration|LookingGlassIntegration]] describes the Looking Glass functionality and an effort to integrate the Xserver changes into the tree for a future release. + +### Sub-working groups + + * Processes/guidelines describing what is needed to create a sub-working group +If you have ideas for other projects in any of these categories, or if you know of other projects not already listed here, please add them. + + +## FAQ: + +A list of some possible questions and answers you may have about the Architecture Working Group can be found at: + + * [[ArchitectureWorkingGroupFAQ|ArchitectureWorkingGroupFAQ]]
\ No newline at end of file diff --git a/ArchitectureWorkingGroupFAQ.mdwn b/ArchitectureWorkingGroupFAQ.mdwn new file mode 100644 index 00000000..640dd0f6 --- /dev/null +++ b/ArchitectureWorkingGroupFAQ.mdwn @@ -0,0 +1,23 @@ + + +# Architecture Working Group FAQ + +Q: I read the announcement about the creation of the Architecture Working Group within X.Org, but what does this really mean? + +A: This change will allow the technical discussions to take place in an open community forum, and it will free the board of directors to concentrate on other organizational and infrastructural issues. + +Q: What does this mean for the existing working groups? + +A: Three other previously established working groups -- the Release Wranglers, Testing Working Group and Modularization Working Group -- which previously made progress reports to the board of directors will now make their reports directly to the Architecture Working Group. + +Q: How is this list/group different from [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] discussions? + +A: The content on [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] discusses, to a large extent, defects and questions about the X.Org releases. The Architecture Working Group mailing list intends to discuss a wider range of longer-term technical and development issues. + +Q: I have a question, but I'm not sure if I should post it to [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] or to [[xorg-arch@lists.x.org|mailto:xorg-arch@lists.x.org]]. Which list should I use? + +A: If in doubt, it is acceptable to start discussions on [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]]. If people feel the topic is better suited for discussion in the Architecture Working Group, the discussion can migrate to [[xorg-arch@lists.x.org|mailto:xorg-arch@lists.x.org]]. + +Q: What happened to the Architecture Board elected by the members last year? + +A: One of the primary reasons for the formation of the X.Org Foundation was to lower barriers to participation in and increase contribution to X Window System technologies. After careful consideration, the X.Org Foundation's Board of Directions determined that the best way to foster open participation in the development of this technology was to move architectural responsibilities away from a small, albeit elected, group to a larger group where all can participate. diff --git a/ArvindUmrao.mdwn b/ArvindUmrao.mdwn new file mode 100644 index 00000000..496ee6d9 --- /dev/null +++ b/ArvindUmrao.mdwn @@ -0,0 +1,13 @@ + + +## Arvind Umrao + +Email: [[arvind.umrao@sun.com]] + +Helping in fixing Xsun, Xorg and Xnewt for Sparc and Sunray. Devoted good amount of time in graphics domain. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/BarryScott.mdwn b/BarryScott.mdwn new file mode 100644 index 00000000..f8b2e53d --- /dev/null +++ b/BarryScott.mdwn @@ -0,0 +1,7 @@ + + +## Barry Scott + +email: barry.scott atspamfree onelan co uk + +I work for [[ONELAN Limited|www.onelan.com]] where we make Digital Signage Players using Linux and Xorg X11. diff --git a/BartMassey.mdwn b/BartMassey.mdwn new file mode 100644 index 00000000..0fab557f --- /dev/null +++ b/BartMassey.mdwn @@ -0,0 +1,13 @@ + + +## Bart Massey + +Email: bart AT SPAMFREE cs DOT pdx DOT edu + +Bart Massey is an [[Associate Professor of Computer Science|http://www.cs.pdx.edu/~bart]] at [[Portland State University|http://pdx.edu]] in Portland, Oregon USA, where his research focus is on open source software engineering and open hardware technologies. Bart is the founder and proprietor of [[bart-massey.com LLC|http://bart-massey.com]], and Technologist in Residence at the Oregon [[Open Technology Business Center|http://opentechcenter.com]]. He has been involved with X development and education in various ways since around X11 release 2, and is the lead architect of the [[XCB|http://xcb.freedesktop.org]] library. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/BernieThompson.mdwn b/BernieThompson.mdwn new file mode 100644 index 00000000..559de1ac --- /dev/null +++ b/BernieThompson.mdwn @@ -0,0 +1,15 @@ + + +## Bernie Thompson + +Email: bernie AT SPAMFREE plugable DOT com + +* Wrote article for the 1st issue of Linux Journal in 1994 ([[http://www.linuxjournal.com/article/2734|http://www.linuxjournal.com/article/2734]]) +* Worked at Microsoft in the Windows team on Bluetooth, USB, and graphics drivers. +* Worked at [[DisplayLink|DisplayLink]] on USB graphics adapters +* Now getting Plugable started - a company producing plug and play devices with open source drivers + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/BoardOfDirectors.mdwn b/BoardOfDirectors.mdwn new file mode 100644 index 00000000..4e8a2c43 --- /dev/null +++ b/BoardOfDirectors.mdwn @@ -0,0 +1,43 @@ + + +# The X.Org Foundation Board of Directors + +Also see the [[XorgFoundation|XorgFoundation]] page. + +* Contact: board AT foundation DOT x DOT org + +### Current Members +[[!table header="no" class="mointable" data=""" +**Name** | **Affiliation** | **Contact** | **End of term** | **Office** + [[Alan Coopersmith|AlanCoopersmith]] | Oracle Corp. | alan.coopersmith AT oracle.com | Q1 2015 | + [[Alex Deucher|AlexDeucher]] | AMD | alexdeucher AT gmail DOT com | Q1 2014 | + [[Martin Peres|MartinPeres]] | University of Bordeaux - LaBRI | martin.peres AT free DOT fr | Q1 2015 | + [[Matt Dew|MattDew]] | Micron | marcoz AT osource DOT org | Q1 2014 | + [[Matthias Hopf|MatthiasHopf]] | Georg-Simon-Ohm University | mat AT mshopf DOT de | Q1 2014 | + [[Peter Hutterer|PeterHutterer]] | Red Hat | peter.hutterer AT who-t DOT net | Q1 2015 | **Secretary** + [[Stuart Kreitman|StuartKreitman]] | Oracle Corp. | stuart.kreitman AT oracle.com | Q1 2015 | **Treasurer** + [[Keith Packard|http://keithp.com/]] | Intel | keithp AT keithp DOT com | Q1 2014 | +"""]] + +End of term based on an [[election|BoardOfDirectors/Elections/]] date in the first quarter of each year. + + +### Recent Members + +* [[Eric Anholt|EricAnholt]] (Intel) eric AT anholt DOT net (term ended: 2012) +* [[Bart Massey|BartMassey]] (Portland State University) bart AT cs DOT pdx DOT edu (term ended: 2012) +* [[Matthieu Herrb|MatthieuHerrb]] (CNRS/LAAS) matthieu DOT herrb AT laas DOT fr (term ended: 2011) +* [[Donnie Berkholz|DonnieBerkholz]] (Gentoo Linux) dberkholz AT gentoo DOT org (term ended: 2010) +* [[Adam Jackson|AdamJackson]] (Red Hat, Inc.) ajax AT redhat DOT com (term ended: 2009) +* [[Daniel Stone|DanielStone]] (Collabora Ltd.) daniel AT fooishbar DOT org (resigned: 2009) +* [[Carl Worth|CarlWorth]] (Intel) cworth AT cworth DOT org (term ended:2009) +* [[Egbert Eich|EgbertEich]] (SUSE Linux Products GmbH) eich AT freedesktop DOT org (term ended: 2008) +The company affiliations are given only for reference. The X.Org Foundation has only personal membership; the Board Members do not represent their employers or affiliations. + +Originally, the Board had regular phonemeetings, now the meetings are held on irc. Summaries of these meetings are published at [[MeetingSummaries|BoardOfDirectors/MeetingSummaries]]. These meetings take place fortnightly, on Thursdays at 2pm Pacific Time (22:00 UTC depending on daylight savings time) in the #xf-bod channel on the OFTC network (irc.oftc.net #xf-bod). Please refer to the [[X.Org calendar|https://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80@group.calendar.google.com&ctz=Australia/Brisbane]] for the next meeting time (remember to set the TZ). Some logs from these meetings can be found at [[IrcLogs|BoardOfDirectors/IrcLogs]]. + +The Foundation is operated according to its [[Bylaws|BylawReview]]. + +--- + + [[CategoryCategory|CategoryCategory]] diff --git a/BoardOfDirectors/Elections.mdwn b/BoardOfDirectors/Elections.mdwn new file mode 100644 index 00000000..179431c6 --- /dev/null +++ b/BoardOfDirectors/Elections.mdwn @@ -0,0 +1,27 @@ + +The [[X.Org Foundation|XorgFoundation]] holds annual elections for its [[Board of Directors|BoardOfDirectors]]. The full set of election rules is laid out in the [[Bylaws|http://www.x.org/wiki/BylawReview]]. What follows is a brief unofficial summary. + +Normally half of the board, 4 of the 8 members, are up for election each year for a two year term. If additional vacancies are present in the board, additional members will be elected to fill the remaining portion of vacated terms. + +The [[Members|http://members.x.org/]] of the X.Org Foundation are eligible to vote in elections. [[Membership|Membership]] is open to individuals who have contributed to the X Window System in some way, typically code, documentation or substantive public service. + +Votes are collected via a web application on [[http://members.x.org/|http://members.x.org/]] during an announced period. Each voter provides a ranked list of their preferences among the nominated candidates. The results are then tallied using the [[simple Borda Count method|http://en.wikipedia.org/wiki/Borda_count]]. + +For example, in an election with 6 candidates, the rankings are scored as follows: + +* [[!table header="no" class="mointable" data=""" +**rank** | **points** + 1 | 6 + 2 | 5 + 3 | 4 + 4 | 3 + 5 | 2 + 6 | 1 + none | 0 +"""]] + +Thus, refusing to rank someone denies them any points at all. Of course each rank can be assigned to at most one candidate. + +Candidates with the highest point total are elected to the board until all available seats for two-year terms are taken. If any remaining seats are open to fill vacancies, the next highest scoring candidates are elected to those until they are all filled. + +There is a limit of no more than two directors affiliated with the same company or institution. Once two seats are filled with affiliates of a given entity, all further candidates from that entity are skipped over in the ranked results list. diff --git a/BoardOfDirectors/Elections/2010.mdwn b/BoardOfDirectors/Elections/2010.mdwn new file mode 100644 index 00000000..dd0a1abf --- /dev/null +++ b/BoardOfDirectors/Elections/2010.mdwn @@ -0,0 +1,112 @@ + +The [[X.Org Foundation|XorgFoundation]] is holding elections for the [[BoardOfDirectors|BoardOfDirectors]]. The [[Elections|BoardOfDirectors/Elections]] overview page describes the voting methods and process. [[Members|Membership]] may vote by logging in to the web app on [[https://members.x.org/|https://members.x.org/]] + +For the 2010 elections, the regular 4 seats are open for 2 year terms, and one additional seat is open for a 1 year term to finish the term vacated by Daniel Stone's resignation. + +[[!toc ]] + + +## Election Dates + +* **Voting opens:** [[Friday, 5 Feb. 2010, 1 am UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=5&year=2010&hour=1&min=0&sec=0&p1=0]] +* **Voting closes:** [[Thursday, 18 Feb. 2010, 11pm UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=18&year=2010&hour=23&min=0&sec=0&p1=0]] + +## Candidates + + +### Eric Anholt +Current Affiliation +: Intel + +Statement of Contribution +: My role in X.Org has largely been as a developer, including contributions to the EXA acceleration architecture, RandR 1.2 development, and developing native Intel modesetting. + +Personal Statement +: I got my start in X working on Mesa and 2D drivers back in the early days of DRI, and later moved on to working in the X Server on acceleration architectures. I've since been working at Intel on the X Server, the 2D driver, and the 3D driver and Mesa. On the board this past term, I've primarily contributed by working on minor administration tasks. In particular, I made touchups on the members system (failing at my plan to replace it), and was the point person approving new members as they applied. + + + +### Alex Deucher +Current Affiliation +: AMD + +Statement of Contribution +: I've been working on Xorg video drivers for many years. I now work at AMD supporting the open source driver stack and helping provide chipset documentation for AMD hardware. + +Personal Statement +: The X Window System has interested me since I first saw screen shots of X window managers back in 1997. I got actively involved in X around 2000 and my interest and participation has grown from there. I now work for AMD supporting open source software on AMD graphics hardware. Prior to starting at AMD, I worked in telecom engineering and intellectual property risk management. My current focus has been on 2D and 3D driver support and documentation for AMD hardware. I have previously contributed to a number of other X drivers including drivers for hardware from S3 and Siliconmotion and mentored several Google and Xorg summer of code projects. Sitting on the X.Org Foundation Board of Directors would give me a chance to lend my unique expertise and skill set to the future direction of the X Window System and related technologies. I would like to focus on increasing new user participation and finding solutions to legal obstacles to handling new technologies in the open source X graphics stack. + + + +### Matthieu Herrb +Current Affiliation +: Centre National de la Recherche Scientifique (CNRS) + +Statement of Contribution +: Long time X contributor. Current focus: Security, *BSD support + +Personal Statement +: I'm 46 years old and work for a French research lab in Toulouse, in the south-west of France. I've been contributing to X since the XFree86 2.x era. I'm maintaining the OpenBSD port of X.Org and trying to help other BSD projects to get the support they need too. I've also been handling security issues in X.Org since The X.Org foundation has a very important role to play in education and animation of the community around X.Org, in particular by organizing X developer conferences and providing support for people to participate to these events. As a member of the board I will continue to support these efforts to promote the X technology. I strongly believe that the multi-platform nature of X is one of its key strength and will continue to work with the board to support portability towards a wide range of operating systems, as well as the MIT style licensing of the core X.Org server and libraries. + + + +### Matthias Hopf +Current Affiliation +: SuSE GmbH + +Statement of Contribution +: Working on radeonhd (one of the principal authors), R[67]xx bringup, RandR (1.3, specifically), general Xserver fixes. + +Personal Statement +: I'm active in X development for over 5 years now. For SUSE I'm working on stabilizing the Xserver and drivers to get enterprise quality in our products, upstream I'm trying hard to foster new and fancy developments that do not conflict with backwards compatibility too much. I'm a strong advocate of Google SoC and X.org's participation therein. + + + +### Stuart Kreitman +Current Affiliation +: Sun Microsystems + +Statement of Contribution +: +Xorg promoter to the Open``Solaris community, hacker, Dev``Conf organizer, board member for several terms. + + +Personal Statement +: I am current co-treasurer, former board member, early co-architect of the Xorg Foundation and dis-architect of the late X Consortium. My contributions to the Foundation and the Xorg community include Conference organization, donations of funds and equipment from Sun, and education within Sun to promote alignment and transition to a pure-Xorg based product set. My technical interests are in the areas of input handling, thin clients, and large scale multiuser deployments. As of Feb 15, 2010, I will be an employee of Oracle Corporation, advocating for Xorg desktop to a wider but less *nix-centric user community, an uphill task that really needs the support of this Xorg community. + + + +### David Nicol +Current Affiliation +: tipjar LLC + +Statement of Contribution +: Coding since 1980, dot-com since 1996. + +Personal Statement +: If elected to the X.Org foundation Board of Directors, David Nicol will participate in the bi-weekly meetings on IRC and attend the annual face-to-face. David Nicol brings decades of experience as a software consultant, and recent credentials from a top entrepreneurship program, to add value to the organization by verifying that our activities continue to further our mission in an ever-improving way. + + + +### Keith Packard +Current Affiliation +: Intel + +Statement of Contribution +: Have written a bit of X server code over the years, designed and wrote a few extensions that add nice features to the window system. + +Personal Statement +: The X.org board continues to perform an important role in the X community. Over the last couple of years, the primary activities of the board have involved organizing technical conferences and providing funding for developers to attend both those conferences and other important free software conferences around the world. I've been involved in the board since the reformation of the X.org foundation, as treasurer for the whole time and as an intermittent board member. If elected, I will offer my services as treasurer again and work to continue offering opportunities for X developers to meet around the world. + + + +### Carl Worth +Current Affiliation +: Intel + +Statement of Contribution +: I was lured into the world of X by an invitation to implement trapezoid rasterization for the software implementation of Render in the server. From there I moved up the stack implementing the cairo graphics library so there would be an easier way to get interesting graphics in X without coding XRender directly. More recently, I've come back down the stack working to improve the xf86-video-intel drivers so that cairo will be reasonably accelerated. + +Personal statement +: The X Window System has an essential role in an increasing number of mobile and desktop platforms built with Free Software. Of course, the X.Org Foundation has no technical role in the development of the system. But the Foundation does have a unique position to be able to facilitate the workings of the community. Examples of Foundation activities include hosting developers' summits and attracting new developers by funding students. I have contributed time and effort by serving on the X.Org Foundation Board over the past two years and would be happy to contribute similarly in the future. + diff --git a/BoardOfDirectors/Elections/2011.mdwn b/BoardOfDirectors/Elections/2011.mdwn new file mode 100644 index 00000000..b2f7261b --- /dev/null +++ b/BoardOfDirectors/Elections/2011.mdwn @@ -0,0 +1,123 @@ + +The [[X.Org Foundation|XorgFoundation]] is holding elections for the [[BoardOfDirectors|BoardOfDirectors]]. The [[Elections|BoardOfDirectors/Elections]] overview page describes the voting methods and process. [[Members|Membership]] may vote by logging in to the web app on [[https://members.x.org/|https://members.x.org/]] + +For the 2011 elections, the regular 4 seats are open for 2 year terms. + +Results of the Candidate Q&A can be found on [[BoardOfDirectors/Elections/2011/qa|BoardOfDirectors/Elections/2011/qa]]. + +[[!toc ]] + + +## Election Dates + +* **Nomination period opens:** [[Tuesday, Jan. 18, 2011, 00:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=1&day=18&year=2011&hour=1&min=0&sec=0&p1=0]] +* **Nomination period closes:** [[Monday, Feb. 07, 2011, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=7&year=2011&hour=23&min=59&sec=0&p1=0]] +* **Publication of candidates:** [[Monday, Feb. 14, 2011|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=14&year=2011&hour=12&min=0&sec=0&p1=0]] +* **Deadline for X.org membership application and renewals:** [[Friday, Feb. 11, 2011, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=11&year=2011&hour=23&min=59&sec=0&p1=0]] +* **Candidate Q&A begins:** [[Monday, Feb. 14, 2011|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=14&year=2011&hour=12&min=0&sec=0&p1=0]] +* **Candidate Q&A ends:** [[Monday, Feb. 21, 2011, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=21&year=2011&hour=23&min=59&sec=0&p1=0]] +* **Election period opens:** [[Monday, Feb. 21, 2011, 00:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=21&year=2011&hour=0&min=0&sec=0&p1=0]] +* **Election period closes:** [[Monday, Feb. 28, 2011, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=28&year=2011&hour=23&min=59&sec=0&p1=0]] + +## Candidates + + +### Eric Anholt +Current Affiliation +: Intel + +Statement of Contribution +: My role in X.Org has largely been as a developer, including contributions to the EXA acceleration architecture, RandR 1.2 development, and developing native Intel modesetting. + +Personal Statement +: Eric Anholt has been active in the X community for the last 5 years as an Intel graphics driver developer, and before that as a general DRI driver and FreeBSD DRM hacker. As an X.Org board member, Eric has managed the member application process, done minor system administration on the X.Org server, and passed messages on to the freedesktop.org sysadmin when it has been out of his scope. + + + +### Alan Coopersmith +Current Affiliation +: Oracle + +Statement of Contribution +: X11 R6.9, 7.5, + 7.6 Release Manager, Modularization Task Force + Security Coordination Team, Maintainer of xdm + Solaris/OpenSolaris port of Xorg + +Personal Statement +: I am running for re-election to the X.Org Foundation Board, having served as a member for the past two years, and the Secretary for the past year. + + +: The role of the X.Org Board is to manage the resources of the foundation and use them to support the developers, both current and new. Travel sponsorships for developers and Summer of Code students to come to X.Org conferences have worked well, and the board has also funded some targeted hackfests, and have accepted proposals for a couple more still in the planning stages. The Board should encourage more proposals for other ways to make use of the foundations resources. + + +: When I last ran, I said that members should have greater visibility into the workings of the X.Org Board, including more frequent reports from the board of the tasks it is working on. This has happened over the past two years, with information on board meetings now regularly provided to the members, and should continue. + + +: I am glad to have been able to serve the X.Org membership over these past two years, and appreciate the opportunity to continue to serve. + + + +### Stuart Kreitman +Current Affiliation +: Oracle + +Statement of Contribution +: +Xorg promoter to the Open Solaris community, hacker, [[DevConf|DevConf]] organizer, board member for several terms + + +Personal Statement +: As current treasurer and former board member of X.org, I am thankful to be considered for re-election to the board. I generally attend the bimonthly board meetings already, so this added role would allow us to reach a quorum more often, which would expedite business. + + +: My technical life has included Xorg maintenance and advocacy within my organization and user community (Sun, now Oracle), and occasionally committing resources from that organization for the benefit of the Xorg community. + + + +### Bart Massey +Current Affiliation +: Portland State University + +Statement of Contribution +: I am a member of the X.Org Foundation Board, an Associate Professor of Computer Science at Portland State University, and an X geek with 20 years experience. I'm the architect, advisor, and sometimes implementor to the XCB project, which provides a modern replacement to Xlib. I've also tried to help out with design and algorithms for Xft, Render, Cairo, and various other projects. PSU hosts freedesktop.org's infrastructure, and PSU students have contributed to X in substantial ways. I am currently investigating X in Haskell and GUI toolkit design. + +Personal Statement +: I've had the privilege of serving the X.Org Foundation Board as a Board Member over the last four years, as Secretary for three. + + +: In the last two years, the X.Org Foundation has consolidated many of the gains that we made previously. The Foundation was successful in supporting and encouraging communication in the X community, and in deploying our resources to support X technical development. + + +: We have been working harder to recruit new developers. I recently helped to initiate an effort to collect, reorganize and rationalize X developer documentation. We plan to push forward in the coming year with new developer documents, for which I am organizing a book sprint. I have continued to be involved with the Google / X.Org Summer of Code, and have continued to contribute to various X projects such as XCB that are new-developer friendly. + + +: There's still a lot to do. The end of our interminable corporate and financial reorganization is in sight. We need to understand how the Foundation should support transitions to "post-X.Org" technologies such as Wayland. I'd like to continue with the Board and help with these activities. I humbly ask for your support in doing so. + + + +### Tiago Vignatti +Current Affiliation +: Nokia + +Statement of Contribution +: Following Linux graphics open communities since 2006. My interests are on X Window System development and implementation, processes of open source development, and any other graphics technologies that enable embedded system development. + +Personal Statement +: As a university student, back in 2006, I got involved with X.Org when I started my contribution with X development; the time was great, I was doing it as a hobby and for fun, and I had the pleasure to attend a couple of X conferences. + + +: Nowadays I do the same, but working for Nokia; besides being paid (which is good), the difference now is that I try push the resources of the company to keep the open source implementation of X, in which I believe and think it can be shaped in a beneficial way for everyone, technically and politically speaking. + + +: Also, I believe I can give a step further, using my experience and knowledge to help the Foundation in all the possible ways, attracting more developers and contributors for the development of X. I would be quite happy to do my best for X.Org. + + + +### Carl Worth +Current Affiliation +: Intel + +Statement of Contribution +: I was lured into the world of X by an invitation to implement trapezoid rasterization for the software implementation of Render in the server. From there I moved up the stack implementing the cairo graphics library so there would be an easier way to get interesting graphics in X without coding XRender directly. More recently, I've come back down the stack working to improve the xf86-video-intel drivers so that cairo will be reasonably accelerated. + +Personal Statement +: The X Window System has an essential role in an increasing number of mobile and desktop platforms built with Free Software. Of course, the X.Org Foundation has no technical role in the development of the system. But the foundation does have a unique position to be able to facilitate the workings of the community. Examples of foundation activities include hosting developers' summits and attracting new developers by funding students. I would be happy to contribute of my time and effort to help with these and other appropriate foundation activities. + diff --git a/BoardOfDirectors/Elections/2011/qa.mdwn b/BoardOfDirectors/Elections/2011/qa.mdwn new file mode 100644 index 00000000..3044dc70 --- /dev/null +++ b/BoardOfDirectors/Elections/2011/qa.mdwn @@ -0,0 +1,25 @@ +[[!table header="no" class="mointable" data=""" + | **Eric Anholt** | **Alan Coopersmith** | **Stuart Kreitman** | **Bart Massey** | **Tiago Vignatti** | **Carl Worth** + ** 1) In the last year, the membership gained a lot more insight in the activities of the board. What is your opinion on this new-gained transparency? Do you see options for improvement? ** | I'm glad to finally have the transparency we'd agreed we all wanted. In particular, the open IRC meetings have been going well. | Well, it's more work for me, but I think it's been worth it so that members can see what's happening (or in many cases, how little is happening). | | | What happened in the recent past when people started to demand logs and open meetings from X.Org was great and should be always supported. The board reacted relatively quickly which was nice also. As a open organization, the Foundation has to work to improve more this, specially regarding the financial aspects which is being subject of discussions lately. | + ** 2) In the past, X.org financials have been dealt with in a less than optimal way, but in the last year a lot of effort has been put into creating solid financial records for the last 5 years, so that incorporation can happen. This work is still underway. What is your opinion about this, where do you see room for improvement? ** | More transparency is good. Everything to do with financials is pain, thuogh, and that's not an reflection of the board as much as the banking system we have. | The work is needed, and good progress is being made. | | | As I elaborated before a bit, this is a must. I believe the current directors made already the necessary effort to dig the past records. At the same time, and obviously, mistaken happened there due not finding all of those, so there is room for improvement. Therefore, all we can do now is to focus on the current and next financial logs and for that not only the directors but also members can help guaranteeing everything is going well. | + ** 3) As stated in the X.org Foundation bylaws, only a maximum of 2 of the 8 board seats can be taken by employees of the same company. In the past there was a situation where there were more than two of the same company on the board, after some board member changed affiliation. What is your opinion about this, how would you prefer to resolve such a situation? ** | Just the same as before when it happened: We take the top-ranked candidate for the seat. Alan suggested that we up the number from 2 to 3, so as not to eliminate candidates that care enough to contribute to the board just because they're employed by one of the larger X.Org contributors. I'm neutral on this -- it seems like a good thing to do for the X.Org board, since it doesn't involve itself in technical direction at all, but it means that I would have less excuse for not running at some point. | There's only one way we can resolve such a situation - getting the three members in question together to discuss it, with the simple directive that "Three members enter, two members leave." The bylaws don't allow us to just ignore it. | | | Although is entirely board’s fault, all members must help when the bylaw is not being followed correctly and some aspects are interpreted wrongly. | + ** 3b) As a follow-up, do you still think this restriction is relevant, and would you change/remove it in any way?? ** | - | We've been fortunate to never have any serious problems caused here, and the board members have historically done a good job of representing the best interests of the community over their employers, but clauses like this are designed to prevent the worst case, not deal with the normal case. I think it's still useful to have some limit, to avoid the appearance of becoming a non-independent organization (see for instance the recent blogs and stories around the proposed OpenJDK governance). It does unfortunately limit the board membership, which as others have noted, is always a challenge to get enough qualified candidates each election. I do think we should continue the discussion from the last board meeting of re-examining it - possibly raising the limit to 3, which still prevents any one company from stacking the board with enough members to have a majority vote. | | | - | + ** 4) What is your opinion about the past and the current X.org board elections. Do you have any suggestions for improvement? ** | The elections system is fine. | They're a pain to organize, which is why the schedule is often missed. | | | Lately the elections have chose candidates with a known background in X.Org community. This is enough to say that the election process works. | + ** 5) This years X.org conference was held in Toulouse, France. Did you have the chance to visit this, or any previous conferences? For 2011 one proposal was already made to hold the conference in Chicago. Opinions/Suggestions/Proposals? ** | Couldn't do the last one due to a conflicting event. XDS/XDC have been useful conferences for setting technical direction and improving communication. | Yes, I've been fortunate enough to have my employer send me to all but one of the X.Org conferences. (I missed Cambridge, UK due to schedule clashes.) What city the conference is held in is the least important part of a conference proposal. The far more crucial and much harder part is getting the people to organize it and run it. | | | Conferences have to be hold in countries where is affordable to fly, the bureaucracy with foreigns visiting is okay and where we have a good host setting up the organization. Fortunately I never experienced anyone failing in this last point, but I saw already people not going for conferences because of lack of visa. Although USA is not a visa friendly country, I honestly believe that Michael Larabel can influence this, expediting invitation letters for instance in an eventual Chicago’s conference. Oh, of course that all attendees want also to have fun, which is very important! | + ** 6) A big chunk of spending goes to travel sponsorship. When he learned about the practices of the more recent years, the current treasurer voiced that, when the X.org foundation was formed, travel was usually not sponsored for those gainfully employed to work on X.org related topics. What is your opinion on this? ** | It's more important to get our contributors together to talk than to point fingers at their current employers for being cheap. | The economy was better when the X.Org Foundation was formed - as it worsened, we adjusted to deal with it for the benefit of the community. The majority of travel funding still goes to those for whom X is not their full time jobs, especially to students like our GSoC mentorees. | | | Anyone doing any work related with and surrounding X should be eligible. For a conference for instance, we define a given budget based on the donations we get and current available money, and then set priorities to see who deserves it given the involvement of such the person. | + ** 7) Now, a topic quite close to the heart of the author of this questionnaire: FOSDEM. 4-5000 free software users and developers over a weekend in winter, join up in the center of Europe. X.org used to have a hugely popular Developers Room there. But the interest from the X.org community has dwindled now. Why do you think this is so? Should this be different? Do you have any suggestions? ** | I was made unwelcome by the organizer of the FOSDEM dev room, and would probably not bother with it again. FOSDEM is an excellent conference, though, which I would attend again. | I believe FOSDEM greatly suffers from being too close in time to linuxconf.au, and that X.Org developers have generally been attending the conference more directly relevant to them, not the one with much wider scope of all open source, and with more limited travel budgets, have an easier time getting funding for LCA than FOSDEM. | | | The interest for X was never that big. Just a few geeks are interested in hacking on drivers or spending hours debugging a complex code of a compositor manager interacting with a X server and its non-trivial window stack. The past experience shown that is not easy to attract developers for X development and very likely a newbie will rather go learn a SDK high level before. X conferences have been very small, with deep and long technical discussions in which several times hardly more than 3 persons in the room can talk about. Although these discussions are good and productive, they also tend to be boring for someone not involved in the subject. One alternative to improve this is to bring the annual conference of X.Org co-located with big events such as FOSDEM. | + ** 8) The topics of an X.org trademark and a new X.org logo have been talked about since the formation of the current X.org foundation. Are these really important topics for the X.org board? What is your opinion, do you have any suggestions? ** | No, they are not important topics for the board in my opinion. | Not really. | | | To promote X.Org trademark is for sure very desired by the board. This topic is considered “important” but not “really important”, I would say, so that is the reason why the current directors are not paying much attention at this moment. But then again, this is something that with just a little kick from the board, the members and the community could do the rest of the work. A more proactive director could do this. | + ** 9) Coordinating Google Summer of Code is another initiative supported by the X.org board. There have also been follow-up initiatives started by the board. What is your opinion about these initiatives and their results? Any suggestions? ** | They have successfully brought new people into the community. Huge success. | They're working well. | | | I guess it is not fair to myself talk about this because I was one that got leveraged by Summer of Code within X community :) So obviously it is important to ramp up newcomers and the Foundation’s Vacation of Code, although without not being that popular still, was a brilliant initiative from the board. We should advertise it better though. | + ** 10) X.org hosting infrastructure has had its hiccups over the past few years. The loss of all users home directories on freedesktop.org and the breach of trust through defamation of a driver repository by former board members come to mind. What is your opinion about the current situation, how would you want to improve it? ** | Things are running fine for a volunteer organization. | I've expressed my opinion clearly on the mailing list many times. | | | The situation is not good. There are room for improvements throughout the whole infrastructure: management of machines, creation and handling of repositories, administration of accounts and all other activities. For the repositories, one problem I noticed is that freedesktopers are not seeing us with good eyes, sometimes even abandoning and going instead for gitorious, linaro.org, google, github and many others. These services mostly have the same interests in open-source and I am sure we could centralize the efforts in one single place, thus reducing the overall maintenance costs. | + ** 11) The membership of the X.org foundation is not completely representative with respect to its contributing audience, and it is hard to motivate people to become a member of the X.org foundation. Some people suggest linking commit access with membership. What is your opinion, and do you have any further suggestions? ** | Having been the person approving members since the first elections process I went through as a board member, I feel that representation in the members list is in fine shape. I like the current system because it allows non-developers involvement in the foundation. | I think linking commit access to membership is useful only in that it ties it to the legal agreement in the membership application. I see no benefit to increasing the membership solely for the point of increasing the membership. We get no real benefits from just having a larger number of members on the books. | | | We are doing good already. We are trying to create a culture of development process where the “commit access” is irrelevant. There is one or a few numbers of people only responsible to the final commit; this final commit is based on the reviews that got from the mailing list by any other hacker. It’s truly open and focusing in stability. So, in short, everyone should be able to create repositories at freedesktop, but patches are pushed to repositories upon review only. Membership is a bit different. | + ** 12) Are there any topics that were overlooked in this questionnaire? Is there something else that you would like to talk about now and/or work on during your term on the board? ** | - | No. | | | Pretty much covered good points. Thank you for elaborating. | + ** 13) What do you think about this questionnaire? Should this initiative be repeated, and do you have any suggestions for such future repeats? ** | - | Way too long. | | | My suggestion is that it should get opened and announced before the elections to all members discuss a bit the best questions. Also, to limit the number of questions would be better. | + ** 14) How do you feel about the size of the Xorg board? Should it be changed? ** | 8 is fine. | Seems to work. | | | I don’t have the experience inside the board to tell this, but it seems to be working okay from outside. | + ** 15) Some have argued that the current election process is flawed. Do you agree? What do you think is flawed and how can it be improved in the future? ** | Disagree. | Seems to work. | | | It is not flawed. | + ** 16) The Xorg Foundation has been working on getting 501(c)3 non-profit status for a while now. Would you be interested in getting involved with this work? ** | It is almost done from my understanding. | All board members already are involved at some level. | | | I am pretty sure there are other directors or even members with more expertize in this kind of paper work, specially the ones living in USA. If needed, I could help of course. | + ** 17) It has been brought up in several board meetings that we should donate some money to the SFLC (Software Freedom Law Center) for their help various legal matters. Do you agree with this? ** | We voted on this, it was near consensus including me. | I voted yes. | | | I honestly don’t see much difficulties lately happening where lawyers should be involved. But of course, both X.Org and SFLC are sister organizations and they should help each other anyway. It all depends of the current cash of Foundation. | + ** 18) Non-profit corporations have certain requirements with respect to where their funding comes from depending on the type of non-profit they are. Should the Xorg Foundation actively solicit donations from the community to fund it's activities (developer conferences, travel expenses, infrastructure expenses, etc.)? ** | Unless there are legal requirements otherwise, we have had no issues with getting sufficient funding from corporate sponsors and I don't see a reason to change that. | I don't see a need right now. The Foundation still has more money than things to fund with it. | | | Other open-source organizations are doing this repeatedly. We should invest some time on it also. | + ** 19) If you agree with the soliciting funding from the community, would you be interested in taking on a role to help reach that end? If so, what ideas do you have for soliciting these donations? If you don't agree, where should the Xorg foundation look to get it's funding? ** | - | The X.Org Foundation seems to be sufficiently funded by corporate donations at this time. | | | Yes, definitely I’m willing to help. Last year, when I was trying to raise up funds from my company, I asked the Board for a formal letter that I could emit asking for budget contribution. There was none. We could start from this idea for instance. | + ** 20) With new platforms such as android and programs like wayland, some would say X is becoming less relevant. Do you agree with that statement? Where do you see X going in the future? ** | X is certainly becoming less relevant in terms of linux window system marketshare. I do see X remaining relevant as a linux desktop windowing system for a long time, because it will take a long time for any competitor to catch up to the relevant features X supports. | I see Wayland, like Xgl and similar programs in the past, as being an interesting experiment in future desktop design, and one from which we should be able to learn some things. It's too soon to tell whether it joins Xgl in the experiments that don't work out (but from which we gained valuable insights into what to do instead), or whether it turns into "X12". The X.Org Foundation is not here to promote X11 and the exact current model & implementation at the expense of all other solutions, but to research, develop, and support the window system, and that must include evolving it as necessary. This is why I asked to include Wayland in the projects eligible for the X.Org mentoring in the Google Summer of Code this year. | | | X evolved a lot through the years already with its protocol extensions. Everyone is amazed to see a protocol completing one fourth of century of birthday, where initially was designed for a much simpler environment with different hardware requirements. At the same time, we haven’t been deprecating unused parts of the protocol and this led us to a very big open source implementation that we have nowadays. The productization of it is not practical and the development happens quite slowly. So we have to move on and I guess that is the big technical challenge the board will have to face next. Although the Foundation states explicitly the support for X, it also supports all siblings technologies such as DRI, Mesa, Linux kernel, now Wayland and a dozen of others. So it is important to emphasize that the community remains the same, i.e., of hackers shaping the core of graphics towards a free and open-source desktop experience. | + | **Eric Anholt** | **Alan Coopersmith** | **Stuart Kreitman** | **Bart Massey** | **Tiago Vignatti** | **Carl Worth** +"""]] diff --git a/BoardOfDirectors/Elections/2012.mdwn b/BoardOfDirectors/Elections/2012.mdwn new file mode 100644 index 00000000..0e9beb81 --- /dev/null +++ b/BoardOfDirectors/Elections/2012.mdwn @@ -0,0 +1,133 @@ + +The [[X.Org Foundation|XorgFoundation]] is holding elections for the [[Board of Directors|BoardOfDirectors]]. The [[Elections|BoardOfDirectors/Elections]] overview page describes the voting methods and process. [[Members|Membership]] may vote by logging in to the web app on [[https://members.x.org/|https://members.x.org/]] + +For the 2012 elections, the regular 4 seats are open for 2 year terms. + +[[!toc ]] + + +## Election Dates + +* **Nomination period opens:** [[Monday, Jan. 30, 2012, 00:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=1&day=30&year=2012&hour=1&min=0&sec=0&p1=0]] +* **Nomination period closes:** [[Monday, Feb. 13, 2012, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=13&year=2012&hour=30&min=59&sec=0&p1=0]] +* **Deadline for X.org membership application and renewals:** [[Friday, Feb. 24, 2012, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=24&year=2012&hour=23&min=59&sec=0&p1=0]] +* **Publication of candidates, Candidate Q&A begins:** [[Monday, Feb. 27, 2012|http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=27&year=2012&hour=12&min=0&sec=0&p1=0]] +* **Election period opens:** [[Monday, Mar. 5, 2012, 00:00 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=5&year=2012&hour=0&min=0&sec=0&p1=0]] +* **Election period closes:** [[Monday, Mar. 12, 2012, 23:59 UTC|http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=12&year=2012&hour=23&min=59&sec=0&p1=0]] + +## Candidates + + +### Marc Balmer +Current Affiliation +: Micro Systems + +Statement of Contribution +: Entrepreneur, Consultant, Software Developer, Teacher; xf86-input-elographics maintainer + +Personal Statement +: First of all, I want to express that I am surprised that I was nominated, it was not myself who nominated me, but the fact alone that someone nominated me means that someone wants me to serve on X.Org's board and I am willing and capable to take the challenge, provided, of course, that enough X.Org members see me as a valuable member of the X.Org board of directors. + + +: I am a Swiss citizen, 44 years old, living in the canton Aargau. I am an entrepreneur, running the software development and consulting firm micro systems, www.msys.ch, successfully for more than twenty years. + + +: +I am a former lecturor and member of the board of the Hyper``Werk Institute of the Basel University of Applied Science, where I tought general informatics and man/machine interaction. + + + +: Since many years I give a lecture about "Open Source Software as a Reality in Commercial Software Development" at the University of Basel, which invites me as a long-standing open source defender/user/developer. + + +: In my commercial life I do point of sale systems, for which use X11 on touchscreen systems to interact with the cashier. I am an IBM business partner and my work with X.Org and touchscreens yielded me an IBM 2010 "Newcomer Award". IBM is seeing the potential in X.Org and Open Source, obviously. + + +: I am an active BSD Unix developer, focusing on NetBSD, but with having lots of code in OpenBSD and some in FreeBSD, and with very tight connections to the *BSD development teams in general. + + +: I helped with with making X.Org drivers available and working on various BSD platforms, most notable the AMD Geode on OpenBSD, but also support for various touchscreen drivers. + + +: If I am to be elected to the X.Org board of directors, I will first and of all help my colleagues to get the tasks at hand to be handled. But I will also see my role as a janitor reminding the X.Org community that the world is not only i386 and Linux, but that systems like the *BSD Unixes use and need X11 as well. And that some coordination between X.Org and the BSD's is needed. + + +: As a personal reference I would like to mention Matthieu Herrb, who is currently serving on board, and who knows my past in BSD and X.Org quite well. + + + +### Alex Deucher +Current Affiliation +: AMD + +Statement of Contribution +: I've been working on Xorg video drivers for many years. I now work at AMD supporting the open source driver stack and helping provide chipset documentation for AMD hardware. + +Personal Statement +: The X Window System has interested me since I first saw screen shots of X window managers back in 1997. I got actively involved in X around 2000 and my interest and participation has grown from there. I now work for AMD supporting open source software on AMD graphics hardware. Prior to starting at AMD, I worked in telecom engineering and intellectual property risk management. My current focus has been on 2D and 3D driver support and documentation for AMD hardware. I have previously contributed to a number of other X drivers including drivers for hardware from S3 and Siliconmotion and mentored several Google and Xorg summer of code projects. + + +: I joined the X.Org Foundation Board of Directors in 2009. During my time on the board, I spearheaded the 501(c)3 non-profit application, handled our Delaware tax filings, and was the election chair for the 2010 Board election. I would like to continue my work on the board: see the 501(c)3 process finished, encourage more projects like the Xorg Endless Vacation of Code, and perhaps even organize an Xorg Developers conference. + + + +### Matt Dew +Current Affiliation +: Micron + +Statement of Contribution +: I do the work that noone else wants to do, like cleaning up documentation. I care about the project and want to see it become better, not just go into a holding pattern until Wayland takes over. + + +: I also am involved with GSoC and EVoC trying to bring in new, young blood into X.org. + +Personal Statement +: +Although I have followed X.org activity for almost 10 yrs now, I have only been contributing to X.org for 2 years. However I really want to help the project overall. As my coding skills are rudimentary compared to fulltime coders and I'm not lucky enough to be employed to work on X, I contribute the best way I feel I can; by working on the not-so-sexy aspects of X.org, like documentation, whenever I can. For the past 2 years I've been working on cleaning up the in-tree documentation, starting with converting 40 documents (>2000 pgs) from various formats like Framemaker and groff into one common format, docbook. Last summer I started getting involved with GSoc and EVoC trying to get students involved in X.org. + + + +: I've recently taken over the EVoC duties from Bart Massey. In doing so, I've started pinging the local Unis to drum up interest among the bright students. I would very much like to see more public noise around the project and to generate interest amongst the bright recent college grads. If I were elected to the board, I would try to help move the project in that direction. + + +: Humble thanks for your consideration. + + + +### Matthias Hopf +Current Affiliation +: Georg-Simon-Ohm-University + +Statement of Contribution +: Working on radeonhd (one of the principal authors), R[67]xx bringup, RandR (1.3, specifically), general Xserver fixes. + +Personal Statement +: I'm active in X development since 2005. Being one of the principal authors of radeonhd, I helped jump-starting development for modern ATI (now AMD) graphics chips, and did major work for the 3D bringup of this chipset family. For SUSE I was mainly working on stabilizing the Xserver and drivers to get enterprise quality in our products, upstream I'm trying hard to foster new and fancy developments that do not conflict with backwards compatibility too much. I strongly believe that the notion of Open Source software does not only have to be reflected by licenses, but also by communication structures. The board irc logs, published on the freedesktop wiki, are one fine example for open communication. I'm also a strong advocate of Google SoC and X.org's participation therein. + + +: In September 2011 I changed my profession and I'm now lecturing and researching at the Georg-Simon-Ohm University of Applied Science in Nuremberg, Germany. My lectures will have a strong focus on Open Source technologies, and of course I'm promoting the use of Linux or Un*x-alike operating systems including the X11 technologies amongst our students. + + + +### Jeremy Huddleston +Current Affiliation +: Apple Inc + +Statement of Contribution +: My role within X.org has primarily been that of developer and release manager. I am the principle maintainer of the XQuartz Project, and by extension the XQuartz DDX within xorg-server, the AppleWM protocol, and quartz-wm. In recent cycles, I have been the release manager for the stable branches of xorg-server. + +Personal Statement +: I am honored to be nominated for a position on the X.org Board of Directors. I have enjoyed working with the community as a developer and maintainer of the stable branch of the X.org server and would be delighted to serve on the board. As a board member, I would love to be more involved with Summer of Code. SoC offers us a great opportunity to bring in new talent and support students in their own personal development. Our involvement with SoC has been quite beneficial, but we have room to improve. We can do a better job at matching students with mentors/support, and we need to improve the publication of results for the SoC projects. As a board member, I would like to address these concerns and work with the community to make our SoC involvement even better than it currently is. Thank you for your consideration. + + + +### Keith Packard +Current Affiliation +: Intel + +Statement of Contribution +: Have written a bit of X server code over the years, designed and wrote a few extensions that add nice features to the window system. + +Personal Statement +: The X.org board continues to perform an important role in the X community. Over the last couple of years, the primary activities of the board have involved organizing technical conferences and providing funding for developers to attend both those conferences and other important free software conferences around the world. I've been involved in the board since the reformation of the X.org foundation as treasurer or as a board member. If elected, I will work to continue offering opportunities for X developers to meet around the world. + diff --git a/BoardOfDirectors/IrcLogs.mdwn b/BoardOfDirectors/IrcLogs.mdwn new file mode 100644 index 00000000..7f07fa2e --- /dev/null +++ b/BoardOfDirectors/IrcLogs.mdwn @@ -0,0 +1,106 @@ + +IRC logs of [[BoardOfDirectors|BoardOfDirectors]] Meetings on channel #xf-bod on the oftc irc network. + +Meetings are held every second Tuesday. + + +## 2010 + +* [[Feb. 16|BoardOfDirectors/IrcLogs/2010/02-16]] +* [[Mar. 2|BoardOfDirectors/IrcLogs/2010/03-02]] +* [[Mar. 16|BoardOfDirectors/IrcLogs/2010/03-16]] +* [[Mar. 30|BoardOfDirectors/IrcLogs/2010/03-30]] +* [[Apr. 13|BoardOfDirectors/IrcLogs/2010/04-13]] +* [[Apr. 27|BoardOfDirectors/IrcLogs/2010/04-27]] +* [[May. 11|BoardOfDirectors/IrcLogs/2010/05-11]] +* [[May. 25|BoardOfDirectors/IrcLogs/2010/05-25]] +* [[Jun. 8|BoardOfDirectors/IrcLogs/2010/06-08]] +* [[Jun. 22|BoardOfDirectors/IrcLogs/2010/06-22]] +* [[Jul. 6|BoardOfDirectors/IrcLogs/2010/07-06]] +* [[Jul. 20|BoardOfDirectors/IrcLogs/2010/07-20]] +* Aug. 3 - Meeting was canceled +* [[Aug. 17|BoardOfDirectors/IrcLogs/2010/08-17]] +* [[Aug. 31|BoardOfDirectors/IrcLogs/2010/08-31]] +* Sep. 17 - Meeting was held live during [[XDS 2010|Events/XDS2010]] +* [[Sep. 28|BoardOfDirectors/IrcLogs/2010/09-28]] +* [[Oct. 11|BoardOfDirectors/IrcLogs/2010/10-11]] - Meeting moved to Monday from now on, same time +* [[Oct. 25|BoardOfDirectors/IrcLogs/2010/10-25]] +* [[Nov. 8|BoardOfDirectors/IrcLogs/2010/11-08]] +* [[Nov. 22|BoardOfDirectors/IrcLogs/2010/11-22]] +* [[Dec. 6|BoardOfDirectors/IrcLogs/2010/12-06]] +* [[Dec. 20|BoardOfDirectors/IrcLogs/2010/12-20]] + +## 2011 + +* [[Jan. 3|BoardOfDirectors/IrcLogs/2011/01-03]] +* Jan. 17 - Meeting was canceled (Martin Luther King, Jr. day) +* [[Jan. 31|BoardOfDirectors/IrcLogs/2011/01-31]] +* [[Feb. 14|BoardOfDirectors/IrcLogs/2011/02-14]] +* [[Feb. 28|BoardOfDirectors/IrcLogs/2011/02-28]] +* [[Mar. 14|BoardOfDirectors/IrcLogs/2011/03-14]] +* [[Mar. 28|BoardOfDirectors/IrcLogs/2011/03-28]] +* [[Apr. 11|BoardOfDirectors/IrcLogs/2011/04-11]] +* [[Apr. 28|BoardOfDirectors/IrcLogs/2011/04-28]] - Meeting moved to Thursday from now on, same time +* [[May. 12|BoardOfDirectors/IrcLogs/2011/05-12]] +* [[May. 26|BoardOfDirectors/IrcLogs/2011/05-26]] +* [[Jun. 09|BoardOfDirectors/IrcLogs/2011/06-09]] +* [[Jun. 23|BoardOfDirectors/IrcLogs/2011/06-23]] +* [[Jul. 7|BoardOfDirectors/IrcLogs/2011/07-07]] +* [[Jul. 21|BoardOfDirectors/IrcLogs/2011/07-21]] +* [[Aug. 4|BoardOfDirectors/IrcLogs/2011/08-04]] +* [[Aug. 18|BoardOfDirectors/IrcLogs/2011/08-18]] +* [[Sep. 1|BoardOfDirectors/IrcLogs/2011/09-01]] +* Sep. 14 - Meeting was held live during [[XDC 2011|Events/XDC2011]] +* Sep. 29 - Meeting was canceled +* [[Oct. 13|BoardOfDirectors/IrcLogs/2011/10-13]] +* [[Oct. 27|BoardOfDirectors/IrcLogs/2011/10-27]] +* [[Nov. 10|BoardOfDirectors/IrcLogs/2011/11-10]] +* Nov. 24 - Meeting was canceled (Thanksgiving) +* [[Dec. 8|BoardOfDirectors/IrcLogs/2011/12-08]] +* Dec. 22 - Meeting was canceled (X-mas) + +## 2012 + +* [[Jan. 5|BoardOfDirectors/IrcLogs/2012/01-05]] +* [[Jan. 19|BoardOfDirectors/IrcLogs/2012/01-19]] +* [[Feb. 2|BoardOfDirectors/IrcLogs/2012/02-02]] +* [[Feb. 16|BoardOfDirectors/IrcLogs/2012/02-16]] +* [[Mar. 1|BoardOfDirectors/IrcLogs/2012/03-01]] +* [[Mar. 15|BoardOfDirectors/IrcLogs/2012/03-15]] +* [[Mar. 29|BoardOfDirectors/IrcLogs/2012/03-29]] +* [[Apr. 12|BoardOfDirectors/IrcLogs/2012/04-12]] +* [[Apr. 26|BoardOfDirectors/IrcLogs/2012/04-26]] +* [[May. 10|BoardOfDirectors/IrcLogs/2012/05-10]] +* [[May. 24|BoardOfDirectors/IrcLogs/2012/05-24]] +* [[Jun. 07|BoardOfDirectors/IrcLogs/2012/06-07]] +* [[Jun. 21|BoardOfDirectors/IrcLogs/2012/06-21]] +* [[Jul. 05|BoardOfDirectors/IrcLogs/2012/07-05]] +* [[Jul. 19|BoardOfDirectors/IrcLogs/2012/07-19]] +* [[Aug. 02|BoardOfDirectors/IrcLogs/2012/08-02]] +* [[Aug. 16|BoardOfDirectors/IrcLogs/2012/08-16]] +* [[Aug. 30|BoardOfDirectors/IrcLogs/2012/08-30]] +* Sep. 13 - Meeting was canceled (XDC) +* Sep. 19 - Meeting was held live during [[XDC 2012|Events/XDC2012]] +* [[Oct. 4|BoardOfDirectors/IrcLogs/2012/10-04]] +* [[Oct. 18|BoardOfDirectors/IrcLogs/2012/10-18]] +* [[Nov. 1|BoardOfDirectors/IrcLogs/2012/11-01]] +* [[Nov. 15|BoardOfDirectors/IrcLogs/2012/11-15]] +* [[Nov. 29|BoardOfDirectors/IrcLogs/2012/11-29]] +* [[Dec. 13|BoardOfDirectors/IrcLogs/2012/12-13]] +* Dec. 27 - Meeting was canceled (X-mas holidays) + +## 2013 + +* [[Jan. 10|BoardOfDirectors/IrcLogs/2013/01-10]] +* [[Jan. 24|BoardOfDirectors/IrcLogs/2013/01-24]] +* [[Feb. 7|BoardOfDirectors/IrcLogs/2013/02-07]] +* [[Feb. 21|BoardOfDirectors/IrcLogs/2013/02-21]] +* [[Mar. 7|BoardOfDirectors/IrcLogs/2013/03-07]] +* [[Mar. 21|BoardOfDirectors/IrcLogs/2013/03-21]] +* [[Apr. 4|BoardOfDirectors/IrcLogs/2013/04-04]] +* [[Apr. 18|BoardOfDirectors/IrcLogs/2013/04-18]] +* [[May. 2|BoardOfDirectors/IrcLogs/2013/05-02]] +* [[May. 16|BoardOfDirectors/IrcLogs/2013/05-16]] +* [[May. 30|BoardOfDirectors/IrcLogs/2013/05-30]] +* [[Jun. 13|BoardOfDirectors/IrcLogs/2013/06-13]] +* [[Jun. 27|BoardOfDirectors/IrcLogs/2013/06-27]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/02-16.mdwn b/BoardOfDirectors/IrcLogs/2010/02-16.mdwn new file mode 100644 index 00000000..938f999d --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/02-16.mdwn @@ -0,0 +1,53 @@ + + +[[!format txt """ +<alanc> wow, an audience today +<Bart_Massey> Greetings all! Yeah, visitors. Welcome! +<mherrb> hi +<anholt> (here) +<ajax> hello +<Bart_Massey> So, this is the last meeting before we change out part of the Board. To any of you who turn out to be outgoing, let me once again say thanks hugely for your service. Greatly appreciated. +<Bart_Massey> I think there's not too much meeting to be had today, actually. My only agenda items for this meeting are a couple of election-related ones. +<Bart_Massey> First off, I am about halfway through preparing the minutes from the last year or more for posting. I should finish tonight. +<hankswap> hi i'm the audience +<Bart_Massey> Hi hankswap! +<Bart_Massey> I am hoping to post to members.x.org; after reviewing the minutes so far I think there are legal details and other things that I would be uncomfortable sharing with random scammers and spammers. :-) +<Bart_Massey> So two questions: is the rest of the Board good with this, and can someone take care of the technical details? +<ajax> sounds fine to me. what technical details are you thinking of? +<Bart_Massey> Figuring out how to get the stuff onto members.x.org :-) +<Bart_Massey> I was hoping I could just email someone a tarball... +<anholt> Bart_Massey: is it just a pile of text or html? +<mherrb> I'm ok with that, but can't help with the technical stuff. +<Bart_Massey> anholt: just textfiles +<Bart_Massey> anholt: probably about 35 of them. +<Bart_Massey> actually, more. close to 50 +<anholt> Bart_Massey: I can drop them on the server easily +<Bart_Massey> anholt: thanks much +<Bart_Massey> mherrb: Thanks much for posting the XDS announcement! Is all good on that front? +<anholt> hmm. but integrating them into the login system would require writing php +<mherrb> yes, although I don't have much to do for now. room is booked and I'm getting in touch with local people to help... +<Bart_Massey> anholt: this is what i feared +<Bart_Massey> mherrb: Great. Let us know what we can do. +<Bart_Massey> anholt: Is the members.x.org auth system just Apache basic or digest auth with an htpasswd file? +<anholt> Bart_Massey: hahaha +<anholt> (it's worse) +<mherrb> Get Peter Hutterer to come. The people at ENAC working on multitouch really hope to meet him... +<Bart_Massey> anholt: A man can dream, can't he? :-) +<anholt> maybe we should review on board@ and see how much would be questionable for openly publishing. +<Bart_Massey> mherrb: We can bug Peter for you. :-) Send him an email and Cc the Board and we'll chime in. +<Bart_Massey> anholt: That's what I was hoping to avoid. I can do expurgated minutes, but I'm hoping we can give members the unexpurgated ones in any case. +<anholt> I fear that if it comes down to "wait for anholt to write php for viewing minutes", nobody will ever get to view minutes. +<Bart_Massey> anholt: Understood. We'll think of something else. +<Bart_Massey> I guess we could just post the password for viewing the minutes on members without any new PHP. :-) +<anholt> Bart_Massey: oh, that's way easier. +<anholt> yes. +<Bart_Massey> OK, we'll do that for now. +<anholt> I can sign up for getting that going. +<Bart_Massey> OK, I think I'm good. Anyone have anything else? +<ajax> not i +<Bart_Massey> Move to adjourn +<mherrb> nor do i +<alanc> not me +<mherrb> bye +<Bart_Massey> Bye all! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/03-02.mdwn b/BoardOfDirectors/IrcLogs/2010/03-02.mdwn new file mode 100644 index 00000000..cff8bc36 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/03-02.mdwn @@ -0,0 +1,219 @@ + +Date is 2010-03-02, times are UTC+01. +[[!format txt """ +22:56 <alanc> good afternoon +22:57 <+mherrb> a bit later in the afternoon here, but yes, good afternoon. +22:57 <+Bart_Massey> Greetings! +22:57 <+daniels> 'evening all +22:58 <+daniels> just hanging the washing up, brb +22:58 -!- Bart_Massey changed the topic of #xf-bod to: X.Org Foundation Board: just hanging the washing up +22:59 <@daniels> just missing mhopf +22:59 <+alanc> speaking of operator status: Bart_Massey - did you ever file the freenode registration form for the xorg channels, or should I go ahead and do that, since I'd volunteered to be their contact anyway? +22:59 <+agd5f_> hi +23:00 <libv> daniels: you mean emmes i guess :) +23:00 <+Bart_Massey> alanc: I was assuming you were doing it. :-) +23:00 <+emmes> yep, I'm here +23:00 <+Bart_Massey> Please do, my apologies. +23:00 <+alanc> okay, somehow I thought you were doing it as secretary, must have misremembered - I'll take care of it then +23:01 <+Bart_Massey> alanc: More likely my bad, but moot now. Maybe especially moot in a few minutes. :-) +23:01 <+Bart_Massey> OK, shall we get started? +23:01 <+agd5f_> sure +23:01 <+emmes> ga +23:02 <+Bart_Massey> OK, I think the first order of business is to (1) thank the outgoing Board members profusely for their service, and (2) to welcome the incoming Board members. +23:02 <+Bart_Massey> In particular, let me remind the outgoing folks that they cannot escape that easily. :-) +23:03 <+Bart_Massey> We will continue to call on you for service, and sincerely hope each and every one of you will return to the Board in the future. +23:04 <+Bart_Massey> Do any of the outgoing Board have anything that should be on the agenda? In particular, is there stuff we need to know or think about that I likely have forgotten? +23:04 <@daniels> libv: oh, hah. dberkholz, then. +23:04 <+emmes> Bart_Massey: Maybe minutes. I would volunteer for that. +23:05 <+Bart_Massey> emmes: Is this Matthias? +23:05 <@daniels> Bart_Massey: not that i can think of, but just ftr, if you guys need anything done with expo or whatever, give myself or tollef a shout. i've set him with root on expo as discussed on the list. +23:05 <+emmes> yep :) +23:05 <+Bart_Massey> daniels: Thanks huge! +23:05 <+daniels> no wuckers +23:05 <+Bart_Massey> emmes: Then we'll take that up in a bit. +23:05 <+Bart_Massey> Anyone else? +23:06 <+Bart_Massey> OK. Then I think that the next order of business is for the Board to elect a Secretary and Treasurer. +23:06 <+Bart_Massey> As you may know, I'm stepping down as Secretary after this meeting, so I won't be nominable. +23:06 <+Bart_Massey> I'd like to nominate Alan Coopersmith as the new Secretary. +23:07 <+agd5f_> seconded +23:07 <+alanc> I'm willing to accept the nomination +23:07 <+Bart_Massey> alanc: Thanks huge. +23:07 <+anholt> excellent +23:07 <+daniels> :) +23:07 <+emmes> very fine with me. thanks Alan! +23:07 <+Bart_Massey> Discussion? +23:07 <+mherrb> +1 for alan +23:08 <+Bart_Massey> In accordance with the Board tradition, can I get a +1 0 or -1 from each non-outgoing Board member? +23:08 <+agd5f_> +1 +23:08 * Bart_Massey notes that mherrb saw it coming +23:08 <+emmes> +1 +23:08 <+daniels> while i'm entirely non-voting here, just as long as whoever does it has enough time to get minutes out in a timely fashion and is prepared to organise the wiki etc +23:09 <+anholt> +1 +23:09 <+Bart_Massey> daniels: Or is willing to make sure that someone else does. For example, Alan may want to ask Matthias for help with the minutes, since he was foolish enough to volunteer :-) +23:10 <+Bart_Massey> I'm +1. +23:10 <+Bart_Massey> I think we need a roll call, sadly. +23:10 <+alanc> time is fungible and can be acquired as needed +23:10 <+Bart_Massey> keithp: you there? +23:10 <+daniels> Bart_Massey: indeed +23:10 <+alanc> I guess I need to +1 then +23:10 <+Bart_Massey> anholt:? +23:10 <+anholt> Bart_Massey: replied above +23:11 <+Bart_Massey> oops +23:11 <+emmes> we're +6 now +23:11 <+Bart_Massey> OK, then the motion is carried. +23:12 <+Bart_Massey> Next, I'd like to nominate Stuart Kreitman for Treasurer. +23:12 <+Bart_Massey> Stuart has been helping manage the banking and finances for some time now. +23:12 <+Bart_Massey> Both Stuart and Keith have expressed themselves comfortable with this arrangement. +23:12 <+keithp> I'm here, just late as usual +23:13 <+Bart_Massey> keithp: cool +23:13 <+Bart_Massey> As you may recall, there's a tradition of not necessarily having the Treasurer be a Board member. +23:13 <+emmes> I just wanted to ask ;) +23:13 <+daniels> (noting that keithp was the treasurer last year while not being on the board) +23:14 <+Bart_Massey> In any case, Stuart was 1 Borda Point short of being elected this time around. :-) +23:14 <+Bart_Massey> Any second? +23:14 <+mherrb> +1 +23:14 <+emmes> +1 +23:14 <+agd5f_> +1 +23:14 <+Bart_Massey> I'll take mherrb as second. +23:14 <+Bart_Massey> +1 +23:14 <+Bart_Massey> keithp: ? +23:14 <+alanc> +1 +23:14 <+anholt> +1 +23:15 <+Bart_Massey> The motion is carried. +23:15 <+keithp> +1 +23:15 <+Bart_Massey> Good. +23:15 * keithp is not used to voting anymore +23:15 * Bart_Massey grins +23:16 <+Bart_Massey> We also have a tradition of keeping these meetings as short as feasible. I have just a couple of agenda items and we'll call it good. +23:16 <+emmes> +1 ;) +23:16 <+Bart_Massey> First, I wanted to recap a little bit of where we are as a Board for the new members. +23:16 <+Bart_Massey> Perhaps the most pressing item this year is to complete the never-ending "bank transition" and "corporate transition" bullet items. +23:17 <+Bart_Massey> If somebody wants to take the lead on this, that would be really good. +23:17 <+daniels> lolz +23:17 <+daniels> i believe it'll be completed shortly after xkb2 ;) +23:17 <+keithp> daniels: we should race +23:17 <+Bart_Massey> daniels: But we have some vague idea of how to do xkb2. I think it will take longer. +23:17 <+agd5f_> I'm willing to help +23:18 <+daniels> keithp: loser buys dinner. +23:18 <+keithp> daniels: ok, you're on +23:18 <+Bart_Massey> We also have some concerns we've been discussing around trademarks and logos and stuff that need to get resolved. +23:18 <+agd5f_> on the corporate transition that is. not touching xkb2 ;) +23:19 <+Bart_Massey> There has been some talk of trying to review and potentially revise the Bylaws; it's been a while, and there are some places where they have diverged a bit from practice. +23:19 <+Bart_Massey> I don't think it's urgent, and it might best wait another year. +23:19 <+mherrb> As an european I'm mostly out of this bank/corporate things. I can't do much unless we want to set up some legal entity in .eu too. +23:19 <+daniels> agd5f_: hah. best of luck. +23:19 <+keithp> daniels: unisa actually found the first check in may and cashed it +23:19 <+daniels> mherrb: i think that'd be more trouble than it's worth +23:19 <+Bart_Massey> mherrb: Yeah, this is basically an American job, I'm afraid. +23:19 <+keithp> daniels: so, while they were asking for a second check, they found and cashed the first one +23:19 <+Bart_Massey> keithp: Awesome. +23:20 <+keithp> Bart_Massey: lolz all round +23:20 <+daniels> Bart_Massey: is there anything in the bylaws in particualr? +23:20 <whot> unisa at its best +23:20 <+Bart_Massey> daniels: Yes, but I'd hate to try it off the top of my head. Things about timing and membership, mostly, IIRC. +23:21 <+Bart_Massey> Infrastructure and system administration is an ongoing concern. We've made some progress but there's still a lot to think about. +23:22 <+keithp> daniels: for the record, the unisa check was posted 2009-5-28 for $1920.00 +23:22 <+daniels> as for infrastructure, as i said, we'll try to actually get things sorted. do you guys have any requirements beyond an actually functioning (sorry) board wiki? +23:22 <+Bart_Massey> That brings me to a piece of new business: there's been some discussion this week of X.Org mirrors, and how they might be handled going forward. +23:22 <+Bart_Massey> daniels: I think we just want to make sure there's adequate sysadmin and related people, and to rationalize our machine infrastructure as much as possible. +23:23 <+keithp> oh, can't post the actual bank statements as someone could easily construct a check from that and extract all of our money +23:23 <+emmes> keithp: what was the unisa about (i probably only don't remember the abbrev)? +23:23 <+keithp> emmes: whot came to an event while he was a student; the university of south australia paid for his travel and X.org re-imbursed them for it +23:24 <+anholt> Bart_Massey: adequate sysadmin is covered now I think. +23:24 <+Bart_Massey> anholt: awesome +23:24 <+anholt> we do need a new members system still +23:24 * Bart_Massey thanks anholt for the reminder +23:24 <+keithp> emmes: unisa 'lost' the check for five months and started asking anyone they could find in Australia about it, including Daniels and whot +23:24 <+alanc> I'd still like to see the Sun-donated machines someday used for something, even if it's just running a couple tinderboxes +23:24 <+daniels> Bart_Massey: nod. tollef is handling fd.o entirely adeptly, partly due to being paid to do it by the wonderful people at collabora ltd, and x.org is a doddle in comparison. +23:24 <+daniels> anholt: want us to get that sorted? +23:24 <+emmes> keithp: thnx +23:24 <+daniels> alanc: indeed +23:25 <+anholt> daniels: if tollef has time? yes. a thousand times yes. +23:25 <+keithp> alanc: I'd love to find a way to get those machines moved to someplace cheaper +23:25 <+Bart_Massey> Yes, I think we all would like to see a replacement for members.x.org. And if we're going to do it, it needs to be sooner rather than later, so that it can be solidified before the next Board election +23:25 <+daniels> ok, i'll chat to tollef about it. feel free to kick me if i appear to have forgotten about it within the next couple of weeks. +23:26 <+Bart_Massey> Does anybody want to talk about mirrors today, or shall we save it for next meeting? It's arguably not pressing. +23:26 <+anholt> Bart_Massey: as far as I can tell, the mirrors task is "update the wiki to say that you can feel free to mirror and it's a wiki so you don't need to bother us." +23:27 <+Bart_Massey> anholt: Yes. I and I think others have some minor concerns about this. +23:27 <+daniels> for those not on the board list ... someone pointed out that we still have xf_mirrors@x.org or something ridiculous where people have to ask for permission to mirror. +23:27 <+daniels> so we'd like to make it clear that it's a free-for-all, but also maintain a list of reputable sites we know aren't messing around with the tarballs. +23:27 <+emmes> i don't think the mit license +23:27 <+mherrb> I just think that we should check the listed mirrors from time to time and remove stale ones. +23:27 <+daniels> which would presumably include polling to make sure they're still alive, still carrying the latest content, and that it's unadulterated. +23:28 <+Bart_Massey> Besides which, we're in a situation for the following scenario, which we may or may not care about: someone deliberately sticks a mirror with malware in it up on the "official" wiki. +23:28 <+emmes> i don't think the mit license "allows" us to require people to ask us for mirroring +23:28 <+emmes> so this should be moot +23:28 <+Bart_Massey> emmes: absolutely not, but we can require them to ask to be put on some official web page. +23:28 <+Bart_Massey> I'm not saying we want to, but we could. +23:28 <+daniels> emmes: it's not about restricting redistribution at all -- which would obviously be beyond stupid -- but about the list of mirrors we maintain. +23:28 <+alanc> they don't have to ask permission to mirror, just to be listed with our recommended mirrors +23:29 <+keithp> heh. at least everyone agrees about that :-) +23:29 <+daniels> \o/ +23:29 <+Bart_Massey> So do folks think we should do anything about this, or just back away slowly? +23:29 <+emmes> about malware: we could disallow mirroring of .md5 files. just a thought, would need more brainstorming. +23:29 <+Bart_Massey> I guess I mildly think we ought to do something about it. +23:30 <+Bart_Massey> emmes: I don't think most people check md5 files. I know I should but don't. +23:30 <+anholt> I'd suggest that distributions tracking our set of source mirrors and doing verification of tarballs fetched from them (i.e. freebsd) are probably doing a better job of checking for adulteration of tarballs than we would do. +23:30 <+mherrb> emmes: I think the pgp signed announcement with md5 are good enough to prevent tempering. +23:30 <+daniels> we could have a list of md5 + sha1 + sha256 sums, gpg-signed, and say 'if you really want to be paranoid, verify this'. +23:30 <+daniels> mherrb: tbh it's mildly pointless given that all the keys are untrusted anyway +23:31 <+emmes> mherrb: hm. agreed. this is at least as good as my thinking. +23:31 <+Bart_Massey> I guess all I'd really want to verify on an "official" mirror list is that the entity mirroring actually exists and will take responsibility for their mirror. This latter is hard, though. +23:32 <+daniels> Bart_Massey: i guess just ping now and then to check that they're carrying the latest bits, which can be automated. +23:32 <+Bart_Massey> The alternative is to stick a nice solid disclaimer on the wiki mirror list that can't be erased, saying "don't believe this". +23:32 <+Bart_Massey> daniels: it would help some, but if they get broken into between audits... +23:32 <+daniels> Bart_Massey: in that case, why the list ... +23:32 <+daniels> Bart_Massey: meh. what can you do. +23:32 <+Bart_Massey> daniels: just informational at that point. +23:33 <+Bart_Massey> anyway, we don't have to solve this today. please think about what you'd like, and email the board list if you have some great insight. +23:33 <+Bart_Massey> Any other business? +23:33 <+alanc> fd.org & x.org seem to have enough bandwidth that mirrors are just to reduce latency for people on far parts of the globe, not to reduce our network load +23:33 <+Bart_Massey> alanc: I agree +23:34 <+Bart_Massey> In some ways, public mirrors are an anachronism. +23:34 <+Bart_Massey> Oh, I remember one more piece of business. +23:34 <+Bart_Massey> Meeting time. When do we want to meet next? +23:34 <+alanc> they are very useful for users behind national firewalls, like the PRC though +23:34 <+Bart_Massey> alanc: agreed +23:35 <+Bart_Massey> I think there's some sentiment toward moving the meeting earlier in the day. +23:35 <+Bart_Massey> Does moving it four hours earlier, to 10:00 Pacific, work for everyone? +23:35 <+emmes> i'm perfectly fine with the current time. +23:36 <+alanc> the board seems to be less geographically spread this year, which should allow more flexibility +23:36 <+Bart_Massey> emmes: Well, you're the one most negatively affected by it :-) +23:36 <+emmes> no, it fits me fine. +23:36 <+agd5f_> either time is fine with me +23:36 <+Bart_Massey> So if no one has any objection, we'll avoid confusion by not changing it. +23:36 <+emmes> allows me to go to the cinema before ;-) +23:36 <+mherrb> In practice me too. moving 4 hours earlier would be 19:00 here, +23:36 <+daniels> alanc: .au ftl +23:36 <+Bart_Massey> mherrb: oops, sorry +23:36 <+mherrb> and I'm more likely to be busy at 19:00 than at 23:00 +23:37 <+Bart_Massey> OK, let's leave it right where it is, then. I'll see all y'all in two weeks? +23:37 <+emmes> right +23:37 <+agd5f_> sounds good +23:37 <+mherrb> ok +23:37 <+alanc> works for me +23:37 <+emmes> alanc: how about minutes? should we take this offline? +23:37 <+keithp> as long as bart wakes me up each week, it works for me +23:38 <+alanc> Bart_Massey: you doing minutes for today as outgoing secretary? or should emmes & I work this out? +23:38 <+Bart_Massey> Thanks all! Alan, I'll let you worry about logging and minutes from here on out (with emmes help). Thanks huge once again! +23:38 <+Bart_Massey> alanc: I've got a log if you want it. You folks can do minutes. +23:38 <+emmes> i'm loggin anyways +23:38 <+Bart_Massey> OK, then. +23:38 <+alanc> it's all in my scrollback log too, thanks - we'll make sure they get done +23:39 <+Bart_Massey> keithp: You can notify Stuart. +23:39 <+Bart_Massey> Thanks much all! +23:39 <+daniels> alanc: don't get it out too quickly, principle of least surprise and all that +23:39 <+emmes> ok, thanks, Bart, for being the secretary so long +23:39 <+daniels> indeed! +23:39 <+Bart_Massey> Quite happy to do it. Thanks for putting up with me for so long! +23:40 <+daniels> thanks bart & comiserations alanc +23:40 <+alanc> yes, thanks Bart +23:40 <+emmes> thanks, Ajax, Daniel, and Carl for working in the board. Much appreciated! +23:40 <+Bart_Massey> +100 +23:40 <+ajax> kein problem +23:40 <+mherrb> yes. Thanks to all, sincerly. +23:41 <+Bart_Massey> Bye! +23:41 <+agd5f_> yeah, thanks! +23:43 <+daniels> best of luck kids :) +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/03-16.mdwn b/BoardOfDirectors/IrcLogs/2010/03-16.mdwn new file mode 100644 index 00000000..95a44c72 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/03-16.mdwn @@ -0,0 +1,183 @@ + +Date is 2010-03-16, times are UTC+01. + +Due to some antispam rules the word g*old has not been allowed to be posted, and has been changed in the log accordingly. +[[!format txt """ +21:59 <+alanc> good afternoon (or evening as the case may be) +21:59 <dberkholz> hi +22:00 <agd5f> hi +22:00 <+mherrb> hi +22:00 <stukreit> hi +22:01 <+Bart_Massey> keithp: ping? +22:01 <+alanc> so it looks like we're just short keithp (who is in channel but quiet) and anholt (who connected & dropped a few minutes ago) +22:01 <+Bart_Massey> I'll bug them by phone now and see what's up, I guess. +22:02 <dberkholz> keith was active 10-15 minutes ago +22:03 <+Bart_Massey> Can't raise either; they're probably in the same Intel mtg. :-) +22:04 <+alanc> well, 6 of us seems good enough to get started then +22:04 <+Bart_Massey> OK! +22:04 <+emmes> alanc: I gues agd5f should have +v as well ;) +22:05 <+alanc> I tried to do that, but can't since I'm not an op - need to figure out how to do that +22:05 <+Bart_Massey> Just got a text from Keith; they are indeed in a meeting. +22:05 <+emmes> right... +22:06 <+alanc> I guess we can't ask keith how he's doing on the action of transferring the treasurer docs to stukreit then +22:06 <dberkholz> hmm, i can probably fix the irc issues, i'm one of the channel masters +22:06 <+Bart_Massey> Only by email, I guess. :-( He may show up in a bit. +22:06 <stukreit> all I can say is its not complete. +22:06 <+alanc> the other action I had noted from the last meeting was the #xorg* freenode registration - I've submitted that, it's in their queue now, which they warn may take weeks to process +22:07 <+keithp> I'm here, but the network at this hotel is 'suboptimal' +22:07 <+Bart_Massey> Thanks alanc! +22:07 <agd5f> what's the status on the 501 transition? is there anything I can do to help? +22:07 <+Bart_Massey> keithp: Oh yeah, you're in Skandahoovia this week. +22:07 <+keithp> Bart_Massey: no, actually pdx, norway next week +22:07 <+Bart_Massey> keithp: Yeah, but Skamania, no? +22:08 <+Bart_Massey> I've notified SFLC that Alan is now the Secretary, and so they're changing the legal contact to him, I think. +22:08 <+keithp> Bart_Massey: skamania last week +22:08 <+Bart_Massey> (re Board transition) +22:08 <+Bart_Massey> keithp: Ah +22:08 <+keithp> Bart_Massey: hilton towers today and tomorrow :-) +22:08 <+Bart_Massey> (er 501 transition) +22:09 <dberkholz> any chanop can voice people via 'query chanserv voice #xf-bod nick' +22:09 <+agd5f> llc to non-profit +22:10 <+Bart_Massey> I don't even know what voicing does +22:10 <+Bart_Massey> agd5f: Yes. alanc is now in charge. :-) +22:10 <+emmes> nothing, as long as this is not moderated +22:10 <+alanc> in xchat it gives us little g*old markers by our names 8-) +22:10 <+emmes> aaaah :-))) +22:10 <+alanc> Bart_Massey: we'll have to talk sometime about what I need to do for that then +22:10 <+Bart_Massey> Ah, *that's* what my little g*old marker means :-) +22:11 <+agd5f> :) +22:11 <+Bart_Massey> alanc: Yeah, give me a call on my cellphone or drop me some email whenever. +22:11 <+Bart_Massey> I think the main holdup at this point is getting the treasurer transfer complete and getting some financial documents together that SFLC needs. +22:12 <+alanc> keithp: any word on the treasurer handoff? +22:12 <+Bart_Massey> We've already dissolved the LLC and registered the 501 in Delaware. +22:12 <+agd5f> alanc: if you need a hand with anything let me know. I'm happy to help +22:12 <+Bart_Massey> We just need to finish our IRS nonprofit status paperwork. +22:13 <+Bart_Massey> query chanserv voice #xf-bod stukreit +22:14 <+Bart_Massey> Oops +22:14 <+keithp> alanc: Stuart is up in Tahoe this week, but I think we're in good shape there +22:14 <+keithp> he's got a checkbook, I think the only requirement is that he have access to our monthly statements until we find a new bank +22:14 <+mherrb> ~. +22:15 <stukreit> I'm here. And I have pdf's of the statements going back aways +22:15 <+mherrb> oops. sorry +22:15 <+alanc> okay - and one of you will work out the paperwork needed for the 501(c) transition? +22:15 <+dberkholz> Bart_Massey: you need a / in front of that. =) +22:16 <stukreit> I have no view into this 501(c) action +22:16 <+Bart_Massey> dberkholz: inferred. of course i couldn't make that work either. what a klutz. :-) +22:17 <+Bart_Massey> stukreit: SFLC has helped us through the whole 501(c)3 process, except they need some sort of records from I think the last two years of our finances, and a projection going forward. Keithp knows the details. +22:18 <+Bart_Massey> Once they have this, they can do the final filing so that we are officially 501(c)3 +22:19 <+alanc> so under new business, we need to form our election committee - congratulations to agd5f, mherrb, emmes, keithp - you've got a bit under a year to organize next years election! +22:19 <+mherrb> heh :) +22:19 <+agd5f> :) +22:19 <+alanc> there's a page in the board private wiki with the details of what you need to do +22:20 <+stukreit> keithp: are you interested in handing this off sooner or later? (compound question) +22:20 <+agd5f> how to you access the board wiki? +22:20 <+emmes> omg ;) +22:21 <+alanc> I think I mailed the link to board mailing list last week - you do need the .htaccess stuff set up on expo - daniels or anholt should be able to help with that +22:22 <+agd5f> I've got the link, but I wasn't sure where the htaccess stuff needed to be changed +22:22 <+agd5f> and no one replied to me :/ +22:23 <+alanc> yeah, I was hoping someone else would remember better than I did +22:24 <+anholt> afaik all info needed is on the wiki, but it's 500ing on me. +22:25 <+alanc> yeah, it's giving me "Internal Server Error" too - have to poke at the admins I guess +22:25 <+agd5f> er... I need access to actually see the wiki +22:25 <+anholt> but browsing around expo suggests /srv/bod.x.org/moin/htpasswd +22:26 <+keithp> stukreit: I'd love some help if you're up for it +22:26 <+agd5f> anholt: thanks +22:27 <+anholt> so dump bits in your homedir and I'll drop them in I guess? +22:28 <+stukreit> keithp: I can follow instructions (but I prefer guessing away) +22:29 <+keithp> stukreit: I'm not sure how precise the directions are, but I'll see what I've got +22:29 <+stukreit> keithp: sounds like a start +22:30 <+agd5f> anholt: it's in my ~/.htpasswd +22:30 <+anholt> done +22:30 <+agd5f> sweet +22:30 <+agd5f> thanks +22:32 <+keithp> stukreit: the note from Karen that I have is that we're responsible for filling out form 1023 +22:32 <+keithp> I fear any form identified with four digits +22:33 <+stukreit> keithp: then fear must an everpresent part of your life +22:34 <+alanc> sorry, got interrupted, the other two items I had noted for today's agenda were Google Summer of Code and whot's XDS 2010 travel request +22:34 <+keithp> nah; I've got an accountant for most of those forms +22:34 <+stukreit> I guess its off to forms.irs.gov then +22:34 <+alanc> not sure there's anything we need to do for GSoC other than to heartily thank marcheu for taking the reigns from Bart to drive our application this year +22:35 <+keithp> +1 +22:35 <+Bart_Massey> alanc: indeed +22:35 <+agd5f> yes +22:35 <+mherrb> +1 +22:35 <+emmes> yep, thanks Marcheu +22:35 <+keithp> I'd like to move to fund whot's travel to XDS +22:35 <+agd5f> +1 +22:35 <+agd5f> er seconded +22:35 <+dberkholz> +1 +22:35 <+mherrb> + +22:35 <+Bart_Massey> +1 +22:35 <+emmes> +1 +22:35 <+alanc> +1 +22:35 <+anholt> +1 +22:36 <+Bart_Massey> Proviso that he has to give a talk, though +22:36 <+Bart_Massey> (I think he would anyhow. :-) +22:36 <+keithp> we can hardly stop him at most conferences +22:36 <+mherrb> The people in TLS working on multitouch are really looking forward to meet him +22:36 <+alanc> for the record we should probably state that we're approving funding at the level he quoted for airfare, plus a reasonable lodging stipend +22:37 <+Bart_Massey> +1 +22:38 <+mherrb> agreed. +22:38 <+keithp> alanc: agreed +22:38 <+emmes> +1 +22:38 * keithp also needs multitouch +22:38 <+Bart_Massey> I +22:38 <+alanc> looks like the airfare should be around $2300 USD, and whatever mherrb said rooms near the venue go for +22:39 <+Bart_Massey> er, I've got to go give an exam. Need me for anything else? +22:39 <+emmes> phew. pretty hefty. but so be it. +22:39 <+alanc> I'm out of agenda items for today +22:39 <+mherrb> the rates are between 60 and 100 EUR (90-150 USD) +22:39 <+alanc> it is pretty much the opposite side of the world +22:39 <+Bart_Massey> emmes: I looked. Intl airfare right now is insane. +22:39 <+emmes> right... +22:40 <+agd5f> seems reasonable +22:40 <+Bart_Massey> Bye all! +22:40 <+alanc> so assume $3000 would cover airfare plus 4 nights ? +22:41 <+stukreit> um, ground transport and food? +22:41 <+agd5f> alanc: yeah, I think so +22:41 <+emmes> i think local transport and food should be personal expenses +22:42 <+agd5f> emmes: me too +22:42 <+emmes> except for that we probably have a social event ;-) +22:43 <+mherrb> I'm trying to find local sponsors for a social event. If it fails I'll either ask here or find something cheap:) +22:43 <+alanc> okay, I'll record we approved a budget of $3000, and can adjust later if necessary, but at least he can reserve his plane tickets now before prices climb higher +22:43 <+stukreit> well, if on a payroll I would expect it, but I'm in favor of rules to protect our budget +22:43 <+dberkholz> might be worth asking various attendees companies to sponsor a meal each. +22:44 <+alanc> there's often people at these conferences traveling on corporate expense willing to pick up a few less fortunate attendees on their expense accounts +22:44 <+mherrb> to protect our budget I can also ask the people from ENAC if they'd have some money to contribute to Peter's travel. +22:44 <+stukreit> I wish I could offer rides on Larry's trimeran, but I don't see it happening +22:45 <+alanc> previous management never blinked when I had a couple guests on my dinner bills, have to find out about new management +22:46 <+keithp> mherrb: I'm also looking for sponsorship at Intel, will let the board know when I get a firm answer +22:46 <+mherrb> ENAC is the school and lab for air trafic controllers in .fr. They should have some money. +22:46 <+agd5f> yeah, I think AMD would probably sponsor something. won't hurt to ask anyway +22:46 <+emmes> mherrb: same for me. given that France is cheaper for us, I'll probably be able to convince SuSE. But you never know. +22:48 <+mherrb> hmm I'll have to send an email to stephane chatty early tomorrow about this, before he learns that from posted irc logs :) +22:48 <+alanc> mherrb: you'll work that out with whot? I don't mind if we're flying him in to have him spend an extra day in town talking to them if he wants to, since it helps evangelize our technology +22:48 <+alanc> anything else before we call the meeting to a close? +22:49 <+emmes> BTW - I haven't really noticed whot's request (have a large mail backlog ATM) - I thought he is working for RedHat now. So they're tight with travel budget as well? +22:49 <+anholt> emmes: always have been +22:49 <+mherrb> yes I'll figure out somthing. +22:49 <+emmes> sigh :-( +22:50 <+mherrb> (sorry crossing an area with weak 3G signal) +22:50 <+stukreit> so now we're paying travel for people with real(tm) jobs? +22:50 <+alanc> most corporations are a bit tighter on travel budget right now - we picked up at least one corporate developer for Portland in 2009 +22:51 <+anholt> stukreit: yes, and we have done so in the past. +22:52 <+emmes> Maybe that should be part of our sponsorship scheme, when we restart that - asking companies for travel budget +22:52 <+emmes> I mean, travel budget for their own people... +22:52 -!- whot [~phuttere@66.187.239.10] has joined #xf-bod +22:53 <+alanc> sure, now he shows up, after we spend 10 minutes using his name in vain... +22:53 <+alanc> 8-) +22:54 <+emmes> whot: you probably want to read http://www.x.org/wiki/BoardOfDirectors/IrcLogs/2010/03-16 as soon as it's filled with content :) +22:54 <whot> oh, crud. I'm too late. thanks +22:54 <+mherrb> US DST is playing games with meeting times +22:54 <+emmes> whot, daylight saving time in US now. +22:54 <+alanc> whot: we agreed to pay for your trip, in exchange for selling you as an indentured servant to the French Air Traffic Control people mherrb knows there +22:55 <whot> hehe. sounds good. thank you +22:55 <+emmes> alanc: I think we're finally done now. +22:55 <+stukreit> I want the people to travel, but I also want to know the managemenet has received a request, and knows that they are benefiting from our nonprofit +22:56 <+stukreit> you can close now if you ant to +22:57 <+keithp> I move to adjourn +22:57 <+anholt> second +22:57 <+agd5f> +1 +22:57 <+keithp> ttyl +22:57 <+alanc> meeting adjourned - thanks all +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/03-30.mdwn b/BoardOfDirectors/IrcLogs/2010/03-30.mdwn new file mode 100644 index 00000000..33ddf781 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/03-30.mdwn @@ -0,0 +1,126 @@ + +Date is 2010-03-30, times are UTC+02. +[[!format txt """ +22:59 <alanc> good afternoon/evening +23:00 <+agd5f> hey alanc +23:00 <+agd5f> motion to change the bod meetings to freenode? +23:00 <+mherrb> hi +23:01 <alanc> maybe once bart or keithp are around we can ask why oftc +23:01 <+keithp> agd5f: oftc and freenode are fairly equivalent? +23:02 <+agd5f> keithp: yeah. just another server to log into for one thing. and considering all the other xorg stuff is on freenode... +23:03 <+keithp> agd5f: we've got the channel all configured here; moving would be a bit of work +23:03 * keithp ends up on five irc networks... +23:08 <+agd5f> no biggie. mostly just curious as to why it was on oftc +23:08 <+mherrb> user certificate auth is nice here. dunno if freenode provides this. +23:09 -!- Bart_Massey [bart@barton.cs.pdx.edu] has joined #xf-bod +23:09 <alanc> so we're just short anholt and bart? +23:09 <+Bart_Massey> Apologies for my lateness; got sidetracked +23:09 <libv> if emmes didn't excuse himself, i can give him a quick call +23:10 <+Bart_Massey> Did I miss anything important? +23:11 <alanc> Bart_Massey: not yet, just a question about why oftc when the other Xorg channels are on freenode +23:11 <libv> did emmes excuse himself? +23:11 <+Bart_Massey> alanc: What was the answer? :-) +23:11 <alanc> libv: I did not see one +23:11 <libv> ok, calling, he's undoubtedly behind his pc anyway +23:11 <alanc> "Ask Bart, maybe he remembers" +23:12 <+Bart_Massey> :-) +23:12 <+Bart_Massey> I didn't set it up; my vague recollection is just that we were concerned about the reliability and privacy of freenode, and th +ought oftc might do better. +23:12 <alanc> I tried sending out minutes & agenda to board & members mailing list yesterday, but never saw it go through - but my mail is a bit we +ird given the transition right now +23:13 <libv> hrm, he's not answering his cell... well, i am not going to go over and throw a brick through his window. +23:13 <+Bart_Massey> Haven't seen it, but my email often gets delayed substantially. Wouldn't think moving a little text over the Internets would +be that hard, but apparently it's awful difficult. :-) +23:13 <alanc> (my sun.com mail server was deactivated over the weekend and all my mail is forwarded to the oracle.com server now, so I'm working th +rough updating mailing list subscriptions & such to avoid getting caught in moderation) +23:13 <+mherrb> I didn't receive anything from you. +23:14 <alanc> I didn't see it in the members archives either +23:14 <alanc> oh well - it basically said today was meeting day, but I didn't have anything specific for the agenda +23:14 <+Bart_Massey> I've got a couple of items. +23:15 <alanc> I think the official GSoC acceptance notice came after last Board meeting - we're in, developers who can help mentor should contact m +archeu, students should read the wiki page on applications & ideas +23:15 <alanc> okay Bart, you have the floor... +23:15 <+Bart_Massey> I've been working with a new volunteer named Matt Dew who's been really helpful looking into a couple of long-standing issues +already... +23:16 <alanc> oh, and the summary of last meeting is posted to http://www.x.org/wiki/BoardOfDirectors/MeetingSummaries/2010/03-16 +23:16 <+Bart_Massey> First, it looks like it will be something like $750 to register the name X.Org as a US Trademark. I would recommend that we d +o this, just to prevent some idiot doing it instead and us having to deal with it. But it's a lot of money. +23:16 -!- stukreit [~skk@brm-ea-fw-nat.Sun.COM] has joined #xf-bod +23:17 -!- dberkholz|mob [~dberkholz@64.134.173.139] has joined #xf-bod +23:18 <+Bart_Massey> Thoughts? +23:18 <alanc> $750 doesn't sound that huge - 1/4 of what we approved last time for one person to go to XDS2010 +23:18 <dberkholz|mob> Sorry I'm late +23:18 <+agd5f> seems fine to me. I figured it would be more than that +23:18 <alanc> presumably the $750 is one time, not annual, right? +23:18 <+Bart_Massey> So Matt isn't willing to do the application---it must be done online. We may want to get an attorney to do it. +23:18 <+Bart_Massey> alanc: Yes, one-time fee. +23:19 <alanc> is that something SLFC would help with? +23:19 <+Bart_Massey> I would think so. +23:19 <+Bart_Massey> You should ask them; they will want to talk to you anyhow, as the new Secretary. +23:19 <+Bart_Massey> I ratted you out and told them you were the new legal contact recently. :-) +23:19 * alanc writes a note to get the SLFC contact information from Bart... +23:19 <+Bart_Massey> Just drop me some email and I'll reply with the right contact. +23:20 <+Bart_Massey> Second, Matt looked into getting our x.org domain name technical and admin contacts reassigned. +23:20 <+Bart_Massey> He's sent a bunch of email to Internic with little luck. +23:21 <+Bart_Massey> Right now he's waiting for a response from Leon Shiman, the current tech / admin contact. +23:21 <+Bart_Massey> If he doesn't get one soon, someone on the Board is probably going to have to step in. +23:21 <+Bart_Massey> Internic wants all kinds of hard-to-get stuff, such as "previous and current month's utility bill with org name on it" :-) +23:22 <+Bart_Massey> Anybody want to work with Matt on this? +23:22 <alanc> "We don't pay for power, we just siphon it from MIT & PSU" +23:22 <+Bart_Massey> alanc: indeed :-) +23:23 <+keithp> We do have bills from MIT +23:23 <+keithp> lots of those :-) +23:23 <+Bart_Massey> keithp: They might be sufficient. I don't know. :-) +23:23 <+agd5f> I can work on it +23:23 <+Bart_Massey> agd5f: Thanks huge. +23:24 <+Bart_Massey> Third, Matt has been poking at the amorphous issue of librarianing X documents. +23:24 <+Bart_Massey> He (and I) would like to see a central, managed document repo of some kind in the X.Org space (beyond the fine wiki). +23:24 <alanc> always a huge task +23:24 <+Bart_Massey> alanc: Indeed. Anyone have thoughts or suggestions that might be helpful? +23:25 <dberkholz|mob> What are the requirement? +23:25 <alanc> I know the job I did on the 7.5 release docs was incomplete, but it was more than we'd done since 7.2 or so - we've got way too many +different formats of specification documents +23:26 <+Bart_Massey> We have a lot of formats, and a lot of documents aren't really exactly officially X.Org, or are not stashed with the X.Org stu +ff +23:26 <alanc> and making the top-level index for them was mostly manual +23:26 <+Bart_Massey> The thing that brought this up was the Gettys "deprecation" document, which is why Matt contacted me in the first place. +23:26 <alanc> I did see someone started wikifying that one +23:27 <+Bart_Massey> Which is good. I guess one question is whether the long term strategy should be to get everything onto the wiki? +23:27 <+agd5f> is the wiki backed up? +23:27 <+mherrb> spec documents cannot get wikified, unless you mark them readonly +23:27 <+Bart_Massey> As well as anything is, I think. :-( +23:28 <+mherrb> but then you've problems to update them again. +23:28 <+Bart_Massey> mherrb: If they are available from a well-known place, an abstract and link on the wiki should be sufficient, I think. +23:28 <+Bart_Massey> agd5f: As well backed-up as anything, I think. We should check that the backups are working right now by asking for a restore +. +23:28 <+mherrb> yes the wiki is useful to create the indexes for documents stored elsewhere. +23:29 <+mherrb> if there are not too many of this I think it's enough. +23:29 <+mherrb> otherwise a more sophisticated software may be needed. +23:29 <+Bart_Massey> Someone should bug someone at sitewranglers to work with the PSU CAT on checking the bakcup state. +23:29 <alanc> job for tollef? +23:30 <+keithp> I haven't heard anything for a while; I should see if things are OK +23:30 <+keithp> alanc: I should probably introduce them +23:32 <+Bart_Massey> Fourth, we've talked a little about doing some kind of alternative to EVoC for non-students. +23:33 <+Bart_Massey> Basically a volunteer mentoring thing, unpaid, in the style of the stuff the Linux kernel does sometimes. +23:33 <+Bart_Massey> Anybody got any thoughts on that? +23:33 <+Bart_Massey> The idea, of course, is to try to help some developers over the horrible awful X learning curve... +23:35 <dberkholz|mob> essentially pairing new contributors with mentors? Don't think it needs to be very formal, but a good idea +23:35 <+mherrb> do we have volunteers for this? +23:35 <+Bart_Massey> Fifth, I've talked with Matt about coming to XDS. It's not clear he's available, but I'm assuming we could help with travel i +f he did. +23:35 <+Bart_Massey> Yes, lining up volunteers would be the key. Only needs to be formal to the extent that there's a well-defined way for people +to get started / paired up. +23:36 <+Bart_Massey> I think Matt could give a "getting started with X.Org" talk that would be +1 insightful. +23:36 <+mherrb> I got a request from someone needing help last friday. his company is even willing to pay consultancy fees +23:36 <+mherrb> but I didn't really know who to forward the request to. +23:37 <+mherrb> Some of you got it... +23:39 <+Bart_Massey> So I think that's my stuff. I yield the floor. :-) +23:41 <alanc> anyone have anything else, or are we ready to call it a day? +23:42 <+Bart_Massey> I'm good +23:42 <+mherrb> nothing else here. +23:42 <dberkholz|mob> nope +23:42 <+agd5f> nothing here +23:43 <alanc> okay, I move to adjourn +23:43 <+Bart_Massey> seconded +23:43 <alanc> see you in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/04-13.mdwn b/BoardOfDirectors/IrcLogs/2010/04-13.mdwn new file mode 100644 index 00000000..30f56857 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/04-13.mdwn @@ -0,0 +1,110 @@ + +Date is 2010-04-13, times are UTC+02. +[[!format txt """ +22:55 <alanc> Good afternoon. Meeting should begin in about 5 minutes +22:56 <+mherrb> Hi +23:01 <+emmes> heho +23:01 <marcheu> hmm, we have 3 Soc slots :( +23:02 <alanc> seems to be around the typical number - I think we usually have 3-4 slots for 10-12 applicants +23:03 <marcheu> alanc: usually 4-5 +23:03 <+Bart_Massey> Minute or two late; sorry. +23:03 <alanc> okay, was about to say Bart might remember better how many GSoC slots we had in the past +23:03 <+Bart_Massey> It has varied widely. +23:03 <+Bart_Massey> Sometimes just two or three. Sometimes as many as 7? +23:04 <+Bart_Massey> Do we know what we've got this year yet? +23:04 <marcheu> nope, we had 4/5/2/4 +23:04 <marcheu> this year we're at 3 +23:04 <+Bart_Massey> OK, you knew the answer :-) +23:04 <dberkholz> hi there +23:04 <marcheu> hopefully we get a 4th in the process +23:05 <alanc> did anyone get the mail I sent yesterday to board & members with the pointer to the summary of last meeting and reminder for today? +23:05 <dberkholz> gentoo may or may not have some extra slottage it could slide toward xorg +23:05 <+mherrb> alanc: no I didn't get it afaict. +23:05 <dberkholz> let me know how many projects xorg can't live without +23:05 <dberkholz> alanc: no, i didn't get it. i just saw you link it on irc +23:05 <alanc> I seem to be unable to send to those lists or receive mail from it since my address changed - haven't been getting notices that they' +re stuck in the moderation queues either +23:06 <agd5f> alanc: I don't recall seeing it +23:06 <alanc> guess I'll poke the sitewranglers later +23:07 <alanc> I didn't make any progress on my action of talking to the lawyers (or talking to Bart to get their contact info) - I don't see any ot +her outstanding actions from the last meeting +23:08 <agd5f> well, we can always do evoc for good applicants beyond 3 +23:08 <marcheu> agd5f: yup, but I'll ask for additional slots first. you can ask to be put on the waiting line so I'll do that +23:09 <agd5f> I'd like to finalize who we want as our new tech and admin contacts for x.org +23:09 <agd5f> domain stuff +23:10 <+Bart_Massey> Sorry, AFK. Yes, EVoC is a fine backup. PSU may have slots for you too; it looks like we may get more than we really need if + all goes well. +23:10 <marcheu> Bart_Massey: you cannot transfer from an org to another directly though +23:10 <+Bart_Massey> agd5f I *think* we want SFLC for admin. Technical matters less, because the admin can change it, I think. +23:11 <dberkholz> marcheu: in my experience, you can tell google where you want extra slots to go and they will respect it +23:11 <+Bart_Massey> marcheu: No, but if we ask nicely in the past they've always said yes. :-) +23:11 <agd5f> Matt suggested SFLC for the admin contact. is there a person we want or a generic address? as for the tech contact, is sitewrangers +@freedesktop.org appropriate or do we want a specific person? +23:11 <+Bart_Massey> agd5f: Generic would be best. I think they'll want a tech contact physical address, so I don't know how to do sitewranglers. +23:12 <agd5f> Bart_Massey: maybe the hosting address? +23:12 <alanc> do we still have a PO Box in portland? +23:12 <+Bart_Massey> agd5f: If they will surely forward our physical mail. +23:12 <+Bart_Massey> alanc: I don't think so. keithp? +23:13 <alanc> hrm, http://www.x.org/wiki/XorgFoundation lists one as our contact address +23:13 * Bart_Massey s/surely/reliably/ :-( +23:13 <+mherrb> afaict the dns stuff is hosted on expo. someone with root on expo should be tech c. +23:13 <+keithp> alanc: our PO box expired; we hadn't received any mail there for over a year +23:13 <+keithp> so I didn't renew it. I didn't realize it was listed as a contact address +23:13 <+Bart_Massey> mherrb: For sure. It would be nice to have a role rather than an individual, though. +23:13 <alanc> I think the root on expo has a high overlap with sitewranglers +23:13 <+Bart_Massey> keithp: I don't think it is right now. +23:14 <alanc> we can remove it from the wiki page easily +23:14 <+keithp> alanc: probably a good idea +23:14 <alanc> Done +23:14 <+Bart_Massey> I forget why we don't just hire a mail-forwarding agent? +23:14 <alanc> http://www.x.org/wiki/XorgFoundation?action=diff +23:15 <+Bart_Massey> It seems ideal for us... +23:16 <dberkholz> there's a startup headquartered in portland that will open and scan all your mail +23:16 <dberkholz> or forward it, if desired +23:17 <+Bart_Massey> Yes, Earth-Class Mail +23:17 <+Bart_Massey> I know the owner pretty well... +23:17 <+Bart_Massey> Their plan is to use robots, but I think right now they just hire people. :-) +23:18 <+Bart_Massey> But I was thinking just a Mailboxes-etc type place that would give us a PO Box and throw everything in a big mailing envelope +once in a while and mail it to Alan's house. +23:20 <alanc> if we actually got mail, that would seem reasonable, and better able to cope with the secretary changing every year or two +23:21 <agd5f> seems like a good plan +23:21 <alanc> so going back to the original question: did we decide on who the domain contacts should be? sitewranglers@fd.o for admin? +23:21 <+Bart_Massey> No, sflc for admin +23:21 <+Bart_Massey> sitewranglers for tech +23:22 <+mherrb> if you look at fd.o they have generic fd.o LLC for both admin and thec +23:22 <+Bart_Massey> Get a PO box to give as a physical addr f +23:22 <+Bart_Massey> or sitewranglers +23:22 <agd5f> so for sflc, what email should we use? +23:22 <alanc> right, I was thinking sysadmin, meant tech +23:22 <+Bart_Massey> agd5f: Their office, presumably +23:22 <+Bart_Massey> Ask them. +23:23 <alanc> freedesktop.org whois gives a paper mail address for them of 7615 SW 59th Ave, Portland, OR - wonder who that actually is +23:23 <+Bart_Massey> :-) +23:23 <agd5f> ok. will do. I just wanted to make sure there wasn't someone there that we are currently working with that we wanted to use +23:23 <+Bart_Massey> Talk to Karen Sandler +23:24 <+Bart_Massey> She's our contact person at SFLC. +23:24 <+Bart_Massey> She will tell you what to do, I think. +23:24 <agd5f> Bart_Massey: Can you email me her contact info? +23:24 <+Bart_Massey> Working. +23:25 <+Bart_Massey> agd5f: Now I just need *your* contact info and I'm set. :-) +23:25 <+Bart_Massey> Just a sec. +23:27 <+Bart_Massey> OK. Anything else today? +23:27 <alanc> The one piece of news I have to report is that I've been informed Hideki Hiura passed away last week. Most of you probably don't re +member him, but he was one of the original Xlib Input Method framework authors for X11R6, and one of the founders/chairs of openi18n.org/li18nux.or +g with the FSG. +23:28 <+Bart_Massey> How sad. Can you send condolences someplace appropriate on behalf of the Board? +23:28 <alanc> I have e-mail for his wife I can send a note to +23:29 <+emmes> Yes, I think that would be appropriate. +23:29 <+mherrb> sure. +23:29 <agd5f> yes +23:29 <dberkholz> it would be really nice to send a physical card +23:29 <+Bart_Massey> Thanks! +23:30 <+Bart_Massey> Move to adjourn +23:30 <agd5f> seconded +23:30 <+keithp> ta ta +23:30 <+Bart_Massey> alanc: ? +23:31 <alanc> sounds like we're adjourned to me +23:31 <+Bart_Massey> Thanks all! +23:31 <+emmes> nothing from my side +23:31 <alanc> I've got that all the members except anholt were in attendance +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/04-27.mdwn b/BoardOfDirectors/IrcLogs/2010/04-27.mdwn new file mode 100644 index 00000000..c1f0dab9 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/04-27.mdwn @@ -0,0 +1,76 @@ + +Date is 2010-04-27, times are UTC+02. +[[!format txt """ +23:00 <alanc> good afternoon +23:00 <+Bart_Massey> Greetings! +23:00 <alanc> sorry for not sending out a reminder this week +23:01 <+emmes_> np +23:01 <+Bart_Massey> np; calendars work +23:02 <+dberkholz> hi +23:02 <alanc> heh - my phone, oracle & google calendars have now all beeped at me to remind me it's meeting time - 3 reminders is usually enough to get my attention, but not always... +23:03 <agd5f> my google calender only reminds me when it feels like it... +23:04 <+Bart_Massey> calendar is not google's finest hour. what's the agenda for today? +23:04 <alanc> umm, I didn't have much - hopefully by now everyone saw marcheu's announcement of our 5 Summer of Code students +23:04 <+Bart_Massey> great news. i'm sure they'll all do well. +23:05 <agd5f> yeah, it's a good set of projects I think +23:05 <+dberkholz> everything worked out pretty well there. i think that's about as many that were really good +23:05 <alanc> and as I just did on #xorg-devel, hopefully you all will be reminding any students who didn't make Google's cut but you think still have good proposals about http://www.x.org/wiki/XorgEVoC +23:06 <+emmes> any news from the students so far already? except for the one that contacted xorg in advance? +23:06 <alanc> (I didn't see the other proposals this year, so don't know about the ones that weren't selected) +23:06 <+dberkholz> the others would probably need to spend some time reworking their proposals to be good enough +23:07 <+emmes> a few were pretty bad, but the 5 students selected were all well above par. +23:07 <+dberkholz> i haven't really checked to see whether they're all posting to the mailing lists yet +23:08 <alanc> I certainly recognized Matt Turner's name from many xorg-devel patch threads already +23:08 <agd5f> and tom has been asking a lot of questions as well +23:08 <+emmes> right +23:08 <marcheu> emmes: I'm not sure about all of them, I plan to touch base with them when google publishes their email addresses... +23:08 <marcheu> or through their mentors +23:09 <alanc> though it seems not all of the projects are in the typical xorg-devel coverage, but dri-devel or mesa-dev instead +23:09 <+emmes> marcheu: thanks a lot for your work there! +23:09 <+Bart_Massey> indeed! +23:09 <alanc> oh, and xcb of course +23:09 <marcheu> sure np +23:09 <alanc> yes, thanks much marcheu +23:09 <marcheu> alanc: yes there is a serious mesa/dri bias this year indeed +23:09 <+emmes> ;) +23:10 <+dberkholz> marcheu: all of them have posted to the xorg lists except igor, who's already got repos on fd.o +23:10 <marcheu> we had 7 proposals on mesa/dri out of 10 +23:10 <+dberkholz> so we should definitely be able to contact them at any point +23:11 <marcheu> dberkholz: yes, but I still want to touch base to make sure mentor/students connexions exist :) +23:11 <alanc> which is fine - the layers of our stack are certainly well-intermingled, and since Google prefers dealing with one umbrella organization over having to deal with separate entries from X.Org proper, Mesa, DRI, & XCB, anything that helps them help us seems like a win +23:11 <marcheu> connections even +23:11 <+dberkholz> marcheu: sure. my points were that 1) we have their email addresses, because they're on the lists; and 2) they're already participating in the community to some extent +23:12 <marcheu> yes, personnally that's why I ranked these guys higher... +23:13 <+dberkholz> anything else gsoc-related we need to talk about? +23:14 <+emmes> marcheu: given the experience with my last student this is *the* most important attribute :-/ +23:14 <alanc> it's a bit soon now, but mentors should remember that we'd pay for successful GSoC students to come join us in Toulouse in September to present on how they spent their Summer of Code +23:15 <alanc> which also reminds me I saw mherrb added hotel information to the XDS wiki page +23:15 <+dberkholz> probably means they should start applying for passports about the time the summer starts. +23:15 <marcheu> alanc: should we mention this to students already? +23:15 <marcheu> i.e. is that a firm commitment +23:16 <alanc> we've traditionally done it, but I don't think it's a firm commitment until we get and vote on each individual request +23:16 <marcheu> right +23:16 <marcheu> let me know when you can say for sure :) +23:16 <+Bart_Massey> we have a firm commitment to consider their request :-) +23:17 <+Bart_Massey> as dberkholz said, they might want to do some preliminary planning now +23:17 <marcheu> okay I will use maybes +23:17 <+dberkholz> if they want to come, have them put in a funding request to the board, and we can vote on it pretty much anytime +23:18 <+Bart_Massey> I'd suggest not until after midterms +23:18 <+Bart_Massey> We want to see that they'll have something to contribute +23:18 <marcheu> yes I agree here +23:18 <+dberkholz> sure, that's reasonable +23:19 <+dberkholz> marcheu: all of them will get accounts on fd.o to put up personal repos, right? +23:19 <marcheu> dberkholz: yeah I'll ask that + blog on planet.fd.o +23:19 <+Bart_Massey> Cool. We good for today? +23:20 <alanc> they should just have to file the account request bug, and their mentors should be able to give the required +1 from an existing project member +23:20 <alanc> I've got nothing else - does anyone else? +23:20 <marcheu> alanc: well with git they can have personal repos even, they don't need project access +23:20 <alanc> (btw, thanks to Tollef for getting foundation.x.org mail unstuck) +23:21 <alanc> marcheu: right, but I thought to even get an account they had to have an existing project member vouch for them +23:21 <marcheu> ah. I suppose they can be all nouveau devs if need be :p +23:21 <agd5f> update on the x.org domain stuff. no response yet from leon or karen. that's it +23:21 <alanc> though we could just tell sitewranglers that we pre-approve accounts for anyone on the SoC list, though maybe not write access to any repos +23:22 <alanc> to any master/non-personal repos that is +23:22 <marcheu> alanc: that's the default situation, when you're not in any group. doesn't sound like an issue to me +23:29 <alanc> I think we're adjuourned for the day - thanks for coming all +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/05-11.mdwn b/BoardOfDirectors/IrcLogs/2010/05-11.mdwn new file mode 100644 index 00000000..dd10a190 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/05-11.mdwn @@ -0,0 +1,48 @@ + +Date is 2010-05-11, times are UTC+02. +[[!format txt """ +23:06 <alanc> so I don't have anything noted for today's agenda - there's probably some things we need to get back to that were caught in the e-mail backlog on foundation.x.org that finally cleared a couple weeks ago, but the only recent e-mail I saw was the student asking about EVoC, which Alex answered +23:07 <+Bart_Massey> OK. We probably need to push on the Never-Ending Corporate Transition again at some point soon. +23:07 <+Bart_Massey> Did we finally sort out what we wanted to do about trademarks? +23:08 <alanc> yeah, I need to get the paperwork/details I need to deal with on the transition one of these days +23:08 <+Bart_Massey> Yes, I think I have some of it, cworth has some, and keith has some. Sigh. +23:08 <+Bart_Massey> Maybe Karen Sandler has all of it, though. +23:09 <+Bart_Massey> I'd suggest you start by just contacting Karen and finding out where we are and what still needs to be done. +23:09 <+Bart_Massey> She would probably like to meet you anyway. +23:10 <alanc> okay, can you send me her contact info? +23:10 <+Bart_Massey> How do I work this IRC thing anyhow? Is there a better way to get a prviate channel than DCC chat? +23:11 <+emmes> Bart_Massey: /q or /msg +23:11 * Bart_Massey s/prviate/private/ +23:11 <alanc> the last notes I have on trademarks were that someone (Matt Dew maybe?) was going to ask SFLC for advice, but that we were in favor of spending $750 to register in the US at least +23:11 <alanc> http://www.x.org/wiki/BoardOfDirectors/MeetingSummaries/2010/03-30 +23:11 <+Bart_Massey> emmes: thanks +23:11 <agd5f> sorry I'm late +23:11 <+Bart_Massey> alanc: ok; I think you are in touch with Matt on this one +23:12 <alanc> am I? I thought you were +23:12 <+Bart_Massey> alanc: I am also, but I thought you and he were working on it now. :-) +23:12 <+Bart_Massey> Anyway, let's the three of us get some email going on this. It can't be that hard. +23:14 <agd5f> karen emailed keith and I last week. We need to get out 1023 form in. I volunteered to fill out the 1023 irs form, but I may need some help with some of the info. Also we need an address. +23:14 <agd5f> s/out/our/ +23:15 <+Bart_Massey> agd5f Is it OK with Karen if we use SFLC as our address for this for now? +23:15 <agd5f> Bart_Massey: I'll ask her +23:18 <+Bart_Massey> move to adjourn +23:18 <agd5f> also, one more item on my list. We had a evoc request +23:19 <+Bart_Massey> i'm way behind on my email from being out of town for a week +23:19 <+Bart_Massey> what was the request? +23:19 <agd5f> joshua clayton, one of the gsoc applicants that didn't make it +23:20 <agd5f> prime (multi-gpu power saving stuff) +23:20 <+Bart_Massey> I think we should probably discuss this privately? +23:20 <agd5f> I told him to submit his request to the board +23:20 <agd5f> sure +23:20 <alanc> I hadn't seen a formal proposal from him yet, just the request for info +23:21 <+Bart_Massey> maybe there's nothing to discuss until we have a formal request? +23:21 <+Bart_Massey> or application or whatever we're calling it? +23:21 <agd5f> yeah +23:21 <+Bart_Massey> OK, that's easy :-) +23:22 <+emmes> i would say so. if he won't file a formal request i'd rather think it's doubtfull that he would finish his work... +23:22 <+Bart_Massey> :-) +23:22 <agd5f> sounds good +23:22 <+emmes> also: less work for us :-P +23:23 <+Bart_Massey> renew motion to adjourn +23:23 <alanc> seconded +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/05-25.mdwn b/BoardOfDirectors/IrcLogs/2010/05-25.mdwn new file mode 100644 index 00000000..f00e5f18 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/05-25.mdwn @@ -0,0 +1,80 @@ + +Date is 2010-05-25, times are UTC+02. +[[!format txt """ +23:04 <+mherrb> hi +23:04 <alanc> hello +23:04 <alanc> sorry, forgot to mail out meeting reminder +23:05 <+Bart_Massey> Greetings all; sorry I'm late +23:06 <+Bart_Massey> Apparently not the latest :-) +23:06 <agd5f> hello +23:06 <alanc> that's 4 +23:07 <alanc> does anyone have any items for today's agenda? +23:08 <alanc> I got the information from Matt on his trademark research, still need to contact SFLC for the next steps +23:08 <+mherrb> I'd like to talk a bit about xds2010 budget. +23:08 <agd5f> I'm attempting to fill out the 1023 form, but may need a hand +23:09 <agd5f> should I just email the board ml? +23:10 <+Bart_Massey> agd5f: Here would be fine. What do you need? +23:10 <agd5f> hold on. let me open up the form +23:11 <+Bart_Massey> mherrb: what's up with XDS2010 budget? +23:11 <agd5f> who do we want as the authorized representative? +23:11 <+Bart_Massey> agd5f: Ideally SFLC, IMHO +23:12 <+Bart_Massey> That way we have some continuity +23:12 <agd5f> ok +23:12 <+mherrb> I got only negative replies from my attempts to find local funding for the social event. +23:12 <+mherrb> so I'd like to know how much we're prepared to spend on this. +23:12 <+Bart_Massey> mherrb: Contact keithp re Intel +23:12 <agd5f> what's our Employee Identification number and the official org name +23:12 <+Bart_Massey> If that falls through, there's other orgs we can bug +23:13 <+mherrb> since the Euro is sinking down, it's getting cheaper every day, but still.. +23:13 <+Bart_Massey> agd5f: I have the document with all that information...somewhere. Drop me some email and I'll send you a scan. +23:13 <agd5f> Bart_Massey: cool +23:13 <keithp> yoiks! +23:13 <+Bart_Massey> keithp! +23:13 <keithp> agd5f: X.Org EIN: 98-0436689 +23:14 <keithp> and the official name is X.Org Foundation LLC +23:14 <agd5f> mherrb: AMD can probably cover a social event. at least last time I asked +23:14 <agd5f> keithp: thanks +23:14 <+Bart_Massey> I'm not sure there's a "." in the official name; IIRC the paperwork we filed wouldn't allow it +23:14 <alanc> is the LLC name still valid? +23:14 <keithp> alanc: sadly, yes +23:14 <+Bart_Massey> No, I don't think so +23:15 <+Bart_Massey> I mean, you may know better than me, but... +23:15 <keithp> Bart_Massey: we don't have another name yet +23:15 <+Bart_Massey> IIRC when we filed the paperwork with IRS we changed it +23:15 <+Bart_Massey> keithp: Now I'm quite confused. :-) +23:16 * Bart_Massey thinks X.Org needs a more complicated legal status +23:16 <+mherrb> agd5f: do you need some cost estimates to ask again? +23:16 * Bart_Massey is sure we haven't made it to 11 yet +23:16 <agd5f> mherrb: I got tentative approval for sponsoring a happy hour. what did you have in mind? +23:16 <+Bart_Massey> We do have a Delaware Corp now, I'm pretty sure. +23:17 <alanc> must be getting near the 11th incarnation, there's been what, the MIT Consortium, the X Consoritium, the Open Group, the old X.Org... +23:17 * Bart_Massey can't remember them all +23:17 <+Bart_Massey> XFree86... +23:17 <agd5f> what month does our accounting end and what was the date xorg was formed? +23:18 <+mherrb> I had a dinner in a restaurant in mind. That would be around EUR 30 /pers including drinks. +23:18 <+Bart_Massey> agd5f: The Delaware Corp or something else? +23:18 <alanc> didn't we form the 501(c) in Portland at XDS last fall? +23:18 <agd5f> mherrb: if you can get me rough numbers, I'll ask +23:19 <alanc> we had the ritual reading of the arcane scrolls of incorporation and all that there at least +23:19 <agd5f> Bart_Massey: the organization applying for 501(c)(3) +23:19 <+Bart_Massey> agd5f: Like I say, I have all the documents we filed; drop me some email and I'll reply with a giant attachment +23:19 <+mherrb> the rough number is that EUR 30/pers we currently have 22 person registered. I hope we get up to 40 or so. +23:19 <agd5f> Bart_Massey: cool. will do +23:20 <+Bart_Massey> I'll cc alanc so that he has them too +23:20 <alanc> thanks +23:20 <+mherrb> I also plan to send a reminder with a call for talks; the program is still empty. +23:21 <+Bart_Massey> Of course it is---it's more than a week before the event :-) +23:22 <+mherrb> and if people already have setup travel plans (flights numbers an so on) tell me when you arrive / leave. +23:22 <agd5f> mherrb: I'll ask. do you think we can get a fixed rate at a restaurant? costs can get out of control very easily with food and drink +23:23 <+mherrb> yes if we go as a 40 or so group I'll negiate something with a pre-arranged price. +23:24 <+mherrb> negociate even. +23:24 <+mherrb> otherwise it's a nightmare. +23:24 <agd5f> mherrb: ok, cool +23:24 * Bart_Massey realizes negotiate is a good spelling word +23:26 <+Bart_Massey> move to adjourn +23:27 <alanc> seconded +23:28 <agd5f> +1 +23:28 <agd5f> mherrb: if you can send me some estimates, I'll see what I can come up with +23:28 <+Bart_Massey> Talk to y'all in a couple of weeks! +23:28 <+mherrb> ok. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/06-08.mdwn b/BoardOfDirectors/IrcLogs/2010/06-08.mdwn new file mode 100644 index 00000000..409ac064 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/06-08.mdwn @@ -0,0 +1,137 @@ + +Date is 2010-06-08, times are UTC+02. +[[!format txt """ +23:02 <alanc> good afternoon +23:03 <+Bart_Massey> Greetings. +23:03 <+Bart_Massey> Apologies for my lateness; previous meeting ran a bit long. +23:03 <alanc> the only thing I have for today's agenda is offering congratulations to dberkholz if he's around +23:04 <alanc> though I suspect there's XDS business to discuss, and maybe Form 1023/501(c)(3) progress? +23:04 <+Bart_Massey> Regardless, and for the minutes, congratulations! On... ? +23:05 <alanc> the release of his latest medical experiment... +23:05 <+Bart_Massey> Oh. Nice! +23:05 <alanc> "Max William, born May 25, 8 lbs 11 oz and 22" long" +23:05 <alanc> 8-) +23:05 <+Bart_Massey> Wow. Yes, big congratulations. +23:06 <alanc> http://dev.gentoo.org/~dberkholz/personal/pics/max.jpg +23:06 <+Bart_Massey> Is Stewart and/or Keithp here? +23:06 <+Bart_Massey> Pretty, pretty baby. +23:06 <+dberkholz> i'm here +23:06 <+Bart_Massey> Er, Stuart +23:06 <+dberkholz> thanks +23:06 <+Bart_Massey> dberkholz: Holding up OK? +23:07 <agd5f> hey, sorry I'm late +23:07 <+dberkholz> things are settling down enough that i can think straight again, although i'll probably be sleep-deprived for at least another couple months +23:07 <+mherrb> dberkholz: congratulations. +23:08 <+dberkholz> alanc: may 24 actually; just took me a while to get to twitter =) +23:08 <+Bart_Massey> dberkholz: oh well, at least we geeks are no strangers to low-sleep. :-) +23:08 <+anholt> keithp is off at a conference today, unlikely to be here I'd guess. +23:08 <agd5f> alanc: I'll send you what I have so far for the 1023 irs forms if you want to see it. maybe you have some ideas +23:09 <alanc> dberkholz: what? you had something better to do? 8-) +23:09 <stukreit> bart: a question for me? +23:10 <+Bart_Massey> stukreit: Yeah, wondering how the financial records are doing; are you getting everything from Keithp that you need? +23:10 <+Bart_Massey> I ask because presumably this is part of what is needed to complete the other stuff. +23:11 <+Bart_Massey> IIRC we need a financial report and financial projection; nothing fancy, but at least a modest one. +23:11 <stukreit> I do have a pile of data from keith +23:12 <agd5f> I wrote a list of the remaining things I need for the 1023 form in addition to the financial records +23:12 <agd5f> 1. month our accounting period ends +23:12 <agd5f> 2. phone number? SFLC's number? +23:12 <agd5f> 3. Are we an LLC or a corporation? +23:12 <agd5f> 4. copy of the bylaws +23:12 <agd5f> 5. names, titles, mailing addresses of officers, directors, trustees +23:12 <agd5f> -- Does this include the board? +23:12 <agd5f> 6. conflict of interest policy? +23:12 <agd5f> 7. Successor to another org? +23:12 <agd5f> 8. list of fund-raising activities +23:12 <agd5f> 9. list of xorg copyrights, trademarks, patents, etc. +23:12 <agd5f> 10. types of contributions we accept (land, IP, etc.) +23:12 <agd5f> 11. do we plan to fund organizations in addition to individuals +23:12 <agd5f> 12. financial info +23:13 <stukreit> I do not have a defined deliverable. Is there an old example of these things from this or another small organization? +23:14 <agd5f> stukreit: http://www.irs.gov/pub/irs-pdf/f1023.pdf +23:14 <agd5f> although I don't know of an example +23:14 <+Bart_Massey> No, I think we've never done them before. Karen at SFLC described it as something simple; just a half-page accounting of how we've spent our money in the past n years (3, I think?) and a plan for how we will spend it in the next m years (2, I think?) +23:14 <+Bart_Massey> You should talk to Karen and/or agd5f to figure out the details. +23:15 <stukreit> Is Karen approachable for this basic kind of question? +23:15 <+Bart_Massey> AFAIK +23:15 <stukreit> So I guess you're saying I should meet with agd5f offline.. +23:16 <agd5f> stukreit: I'll forward you what I have so far +23:17 <+Bart_Massey> Our Bylaws require an annual Treasurer Report in any case. :-) +23:17 <stukreit> ok. as a status report, its "nothing to report". as an action item, I have: "talk with agd5f, then with Karen" +23:17 <+Bart_Massey> Perfect. +23:17 <agd5f> Bart_Massey: where can I find a copy of the bylaws? +23:18 <agd5f> all I could find on the x.org wiki was proposed changes +23:18 <stukreit> bart: would you set a delivery date for this? +23:18 <alanc> http://www.x.org/wiki/BoardOfDirectors has a link to the Bylaws +23:18 <+Bart_Massey> stukreit: I'd be more comfortable with alanc doing it as Secretary. +23:18 <+Bart_Massey> Ultimately, he's the lead on this, I think. +23:19 <stukreit> yeah, but he can do me direct bodily harm. I'd rather it was someone far away ;-) +23:19 <agd5f> we have to file some sort of tax thing in delaware +23:19 <+Bart_Massey> :-) +23:19 <alanc> locking you in your office until it's done is indirect bodily harm, not direct... +23:20 <+Bart_Massey> Somebody needs to update the Bylaws page on the wiki to reflect that we've been operating under those Bylaws for several years now. +23:20 <stukreit> I see you've read the new employee handbook carefully +23:20 <+Bart_Massey> agd5f: what do we need for that? +23:20 <agd5f> if we don't pay by march 1, 2011, we lose our corporation +23:20 <agd5f> pay whatever taxes we owe I guess +23:20 <+Bart_Massey> agd5f: Well then. Let's pay. +23:21 <alanc> Bart_Massey: I guess I should do that as Secretary - I'll add it to my todo list +23:21 <+Bart_Massey> agd5f: AFAIK, as a 501(c)3 we don't owe any, but it would be good to know. +23:21 <+Bart_Massey> alanc: Thanks +23:22 <agd5f> Bart_Massey: we aren't a 5013c yet until we finish the 1023 right? +23:22 <alanc> I noticed it before, but didn't make a note of it and forgot +23:22 <+Bart_Massey> agd5f: It beats me. Talk to Karen. +23:22 <+Bart_Massey> In any case, our total income is tiny, so I doubt we would owe much. +23:23 <agd5f> If you guys want to look over the stuff I just forwarded and fill in any info you may have, I can talk to Karen and organize a call or something +23:24 <agd5f> stukreit: we should talk first I guess to sort out the financials +23:24 <stukreit> ok. any chance you can get a better scan of the delaware notice you just sent us? +23:25 <agd5f> stukreit: I got that from bart +23:25 <agd5f> Bart_Massey: do you have an original? +23:25 <+Bart_Massey> Somewhere +23:25 <agd5f> or just that scan? +23:26 <stukreit> and who is Ian Sullivan? +23:26 <+Bart_Massey> Beats me +23:26 <agd5f> someone at SFLC apparently +23:26 <stukreit> Let's put that on the list to ask Karen. He might be knowledgable +23:26 <+Bart_Massey> What's the problem with the scan? +23:27 <stukreit> just whining about it. I'll blow it up a bit +23:27 <marcheu> Ian Sullivan is one of the SFLC guys, he was one of the guys I talked to about nouveau I think +23:28 <stukreit> Well, we need a definition or boilerplate of a "delaware annual franchise tax report". Was one ever made before? +23:29 <agd5f> don't know +23:29 <+Bart_Massey> I doubt it +23:29 <+mherrb> the bod wiki on expo is giving me an internal server error. There's definatly something wrong with this machine. +23:30 <stukreit> would it be crazy to ask Ian Sullivan what the heck that is? +23:31 <+Bart_Massey> Not at all +23:31 <agd5f> stukreit: I guess we should email Karen and Ian with what we have and try and get this sorted out +23:31 <alanc> expo's disk is 96% full, but I have no idea what we'd clear +23:31 <+Bart_Massey> agd5f: Agree completely +23:31 <stukreit> I think i've asked enough dumb questions for today. I'll catch up with agd later, you guys can move on with your agenda +23:31 <+Bart_Massey> alanc: We can buy more disk for it if we need to +23:32 <+mherrb> alanc: don't clean the previous years financial reports :) +23:32 <alanc> looks like it's running with something like 2 8gb disks +23:32 <+Bart_Massey> lol that would be easy to not do +23:33 <+Bart_Massey> Cool. 16GB!!! That's *huge*! +23:33 <+Bart_Massey> We should retire the box, I guess; I think keithp has the plan for replacing it, no? +23:33 <alanc> my phone has twice that 8-) +23:34 <agd5f> weren't there some v40z's floating around unused for a while? +23:34 <stukreit> at mit +23:34 <agd5f> althugh those are pretty old at this point +23:34 <+mherrb> about xds: I tried to mail out the english version of the short presentation of the event with sponsoring opportunities I originally did in french to seek local sponsors. it bounced at agd5f@gmail.com and got stuck on expo. +23:34 <agd5f> ah +23:34 <agd5f> mherrb: it's alexdeucher @ gmail +23:35 <+mherrb> yes. it bounced because of the pdf attachment apparently. +23:36 <+anholt> Bart_Massey: keithp and tollef have been poking around for $ for new machines, I know, but not succeeding so far. +23:36 <stukreit> agd: they're old if you have something better, but I don't anticipate more hardware from oracle in the forseeable future +23:37 <alanc> last plan I remember discussing for the v40z's was using them as tinderbox clients +23:37 <agd5f> stukreit: they are probably more than enough for what we need +23:37 <stukreit> how about the plan being to get someone nearby to commit to going over there and racking them? +23:38 <alanc> ajax is the closest to them +23:39 <alanc> I can get mail through to alanc@foundation.x.org but haven't seen board mail go through +23:42 <alanc> so does anyone have anything else to discuss today, or are we ready to adjourn? +23:43 <+Bart_Massey> move to adjourn +23:43 <+emmes> +1 +23:44 <agd5f> +1 +23:44 <+mherrb> adjourn. I'm tring to get my data sent by pigeons. +23:44 <alanc> thanks everyone +23:44 <+Bart_Massey> ! +23:44 <alanc> meeting adjourned +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/06-22.mdwn b/BoardOfDirectors/IrcLogs/2010/06-22.mdwn new file mode 100644 index 00000000..4e9f146e --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/06-22.mdwn @@ -0,0 +1,48 @@ + +Date is 2010-06-22, times are UTC+02. +[[!format txt """ +23:03 <alanc> I'm trying to remember what we have for today's agenda +23:03 <alanc> any updates on the 501(3)c paperwork progress? +23:04 <agd5f> alanc: not yet +23:05 <alanc> and I saw the review on the list of mherrb's request for XDS corporate sponsorships +23:07 <+mherrb> I sent an updated version. did you guys get it? +23:07 <alanc> anything else people have to bring up today? +23:07 <+emmes> mherrb: if it was on the same day, yes. +23:07 <+mherrb> yes it was the same day or the day after, depending on time zones. +23:08 <alanc> I saw the one with the updates after dberkholz's review +23:08 <+mherrb> there was only one update from me so its the one :) +23:09 <alanc> looked fine to me +23:10 <+emmes> looked pretty good after the review. it was definitely a good change to embedd the main purpose in the title area +23:10 <+mherrb> feel free to send to your management or other potential sponsors then :) +23:10 <+emmes> i'll see Markus Rex on the weekend, i'll check how the financial situation is then. Don't have too high hopes, though. +23:11 <+mherrb> I don't, seen the poor (==0) result I got so far locally. +23:11 * alanc will pass it up the chain here +23:12 <agd5f> mherrb: I'll run in by the amd folks +23:12 <+emmes> i'll first have to check whether there's funding for me going to xds. In that kind of situation we are :-/ +23:16 <alanc> sorry for being completely out of it today, and not having minutes of last meeting to feed into this meeting's agenda +23:16 <+Bart_Massey> 'scool +23:17 <+emmes> agd5f: what is currently halting us in the 501(3)c? Just being curious... +23:19 <agd5f> emmes: finding the info needed to fill out the form. I'll be sending a list of questions to the board this week +23:19 <alanc> if you need more help from Stuart, his office is about twenty yards down the hall from mine, so I can go ping him anytime +23:20 <+emmes> np, as I said, just being curious. And I'll probably won't be much help here (don't know much about American laws, and too little about board history as well :-] ) +23:20 <agd5f> alanc: cool. we talked last week and filled in a lot of the details. we also need to organize the financial info for the form +23:21 <+Bart_Massey> I'll help how I can, but we really need to involve Karen / SFC; have we got the tax stuff we need for this year done yet? +23:23 <agd5f> not yet as far as I know. stuart and keith were going to look into the financial stuff. I've got a list that should cover what we need, I'll sent it out today or tomorrow. Once I've filled in what I can I'll send everything to Karen +23:24 <+Bart_Massey> Cool. Karen sounded a little frustrated in her last email. :-) +23:25 <agd5f> Bart_Massey, keithp: is Karen ok with lots of questions? I've been trying to gather as much info as I can before going to her. I don't really have a sense of how much they do vs. us +23:25 <+Bart_Massey> If it were me, I'd send her questions until she asked me to stop. :-) +23:26 <+Bart_Massey> She's really friendly, and I think her big concern is that we're ignoring our responsibilities; more questions would be helpful there. +23:26 <+Bart_Massey> As far as distribution of responsibilities, we need to do the actual paperwork and stuff, but they need to tell us what to do. +23:27 <+Bart_Massey> They help lots of folks like us, so I'd think they are used to these questions. +23:28 <+Bart_Massey> Are we good for now? +23:29 <+emmes> nothing from my side +23:29 <alanc> anything else for today or are we ready to adjourn? +23:29 <agd5f> I think so. I'm sending the questions to the board. if you know any answers, please reply +23:29 <+Bart_Massey> Thanks all! +23:29 -!- Bart_Massey [bart@barton.cs.pdx.edu] has quit Quit: Leaving +23:29 <+emmes> alanc: adjourn +1 +23:30 <alanc> and I think Bart just voted the same +23:30 <+emmes> :-P +23:30 <alanc> see you all in two weeks! +23:30 <+mherrb> +1 good bye. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/07-06.mdwn b/BoardOfDirectors/IrcLogs/2010/07-06.mdwn new file mode 100644 index 00000000..42e02318 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/07-06.mdwn @@ -0,0 +1,66 @@ + +Date is 2010-07-06, times are UTC+02. +[[!format txt """ +23:01 <jammcq> I'd just like to find out the status of the xorg corp status. as far as I know, my name "James McQuillan" is listed on the registration of the corporation +23:01 <jammcq> dberkholz|mob: howdie +23:02 <dberkholz|mob> hi there +23:03 <alanc> hello +23:03 <+Bart_Massey> Hi all! +23:03 <agd5f> As far as I know we are a delaware corp already. I'm in the process of completing the 501(c)3 irs forms +23:03 <jammcq> Bart_Massey: hey, long time,no see +23:03 <alanc> but jammcq is probably on the registration of the previous LLC incarnation +23:03 <+Bart_Massey> jammcq: Good to talk to you again! +23:03 <+anholt> agd5f: excellent! +23:04 <jammcq> Bart_Massey: yeah, just checking on the corp status +23:04 <+Bart_Massey> sigh +23:04 <jammcq> wondering if i'm still listed as the sole member of the corporation +23:05 <+Bart_Massey> beats me +23:05 <jammcq> heh +23:05 <+Bart_Massey> I never really understood the old corp at all; I thought we finally dissolved it? +23:06 <jammcq> I dunno. there was some paperwork that I sent in many months ago, that was supposed to help transfer the old corp to the new corp. I just never heard if that happened +23:06 <agd5f> jammcq: you're listed as the incorporator and the directors shall be picked by bylaws. no idea on pre-delaware stuff +23:06 <+Bart_Massey> I remember going to some trouble to get everybody's sigs +23:06 <+Bart_Massey> Yeah, I think we're good; being the "incorporator" doesn't really matter to anything, and there's been elections +23:07 <jammcq> agd5f: so me being the "incorporator", just wonder if that leaves me liable for anything that the corporation does +23:07 <agd5f> jammcq: no idea. I'll ask Karen tomorrow +23:07 <jammcq> ah, thanks +23:07 <+Bart_Massey> I don't believe so. You can email Karen Sandler and ask her if you are concerned. +23:07 <+Bart_Massey> agd5f: Thanks! +23:07 <agd5f> I've set up a call with karen tomorrow if anyone has anything they want me to ask about +23:08 <jammcq> agd5f: if you could let me know at jam@Ltsp.org, that'd be great +23:08 <agd5f> jammcq: will do. +23:08 <alanc> anything else to mention on the 501(3)c status while we're on the topic? +23:09 <+Bart_Massey> Is our honored Treasurer here? +23:09 <agd5f> keithp: any news on the financial info from you or stuart? +23:09 <alanc> doesn't seem to be, I can walk down the hall and poke him +23:10 <+Bart_Massey> I think that Stuart needs to produce (w/ keithp's help) the reports needed for 501(3)c ASAP; Karen seemed to be getting unhappy about this. +23:10 <+Bart_Massey> I feel bad that I let it sit for so long... +23:10 <+Bart_Massey> We need to figure out whether we need to pay taxes this year, so make sure to ask Karen about that +23:11 <alanc> Stuart can't come to the meeting right now, said he had no update to pass along +23:11 <+Bart_Massey> 'k +23:11 <agd5f> Bart_Massey: already on the list +23:13 <alanc> our other main topic of discussion recently has been XDS, but I guess if mherrb isn't coming today, there won't be much to say thre +23:15 <ajax> if anyone's looking for a windmill to tilt at, it would be kind of pleasant if someone could talk to The Open Group about the license on XTS5 +23:15 <ajax> right now it's classic Artistic, which is a little murky, enough so that Fedora won't distribute code under it +23:15 <+Bart_Massey> ajax: Do tell... +23:16 <alanc> I've actually been meaning to ask them about cleaning up the license on all the old code they own to the current MIT template, to reduce a bunch of crud +23:16 <+Bart_Massey> Makes sense +23:16 <ajax> Clarified Artistic or Artistic 2.0 would be much improved +23:16 <+Bart_Massey> But MIT would be best, no? +23:16 <ajax> *shrug* +23:16 <alanc> (not at all motivated of course by my need to gather all the license info for our packages for Oracle's lawyers to review) +23:16 <ajax> OSI-approved is all the higher of a bar i care about +23:17 <+Bart_Massey> Fair enough +23:17 <alanc> do we have a contact at TOG? I remember Howard coming to XDC in Boston, but he was leaving them +23:17 <alanc> Andrew Josey is the only other person there I remember dealing with +23:17 <ajax> i don't know how much of it they can actually relicense, i think i saw several other companies' copyrights on the code +23:18 <ajax> and it's certainly not the end of the world if it can't be fixed +23:18 <alanc> I guess I can sign up for asking them about both at once +23:18 <+Bart_Massey> I think they contracted for XTS, so that copyright should be owned by TOG unless they transferred it to us? +23:19 <ajax> i don't think they transferred it to us. +23:20 <+Bart_Massey> 'k +23:23 <alanc> so anything else to discuss today? +23:24 <+Bart_Massey> I'm good +23:24 <agd5f> nothing else here +23:25 <+Bart_Massey> move to adjourn +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/07-20.mdwn b/BoardOfDirectors/IrcLogs/2010/07-20.mdwn new file mode 100644 index 00000000..24873623 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/07-20.mdwn @@ -0,0 +1,111 @@ + +Date is 2010-07-20, times are UTC+02. +[[!format txt """ +22:59 <alanc> good afternoon +23:00 <alanc> hopefully people's calendars reminded them of the meeting since I failed to +23:00 <+mherrb> I'm there. Hi. +23:00 <+emmes> heho. +23:01 <agd5f> hello +23:02 <dberkholz|mob> Hi +23:02 <+anholt> hi +23:02 <agd5f> thanks everyone for getting me your bios and addresses. +23:04 <+emmes> np. thanks for compiling everything into the documents for the transition. +23:04 <alanc> so you're making progress on the 501(c)3 stuff with Karen? +23:04 <agd5f> the 1023 is just about done. Karen sent me a draft on Friday. She's at OSCON this week, but we are meeting again next week to finish it +23:05 <agd5f> the delaware franchise this is also done, I just need to clarify one last thing and find out where to send the check +23:06 <dberkholz|mob> very cool +23:07 <agd5f> and finally, I think we may owe a lot of back taxes on the old xorg llc. SLFC is looking into it +23:08 <alanc> ouch +23:09 <agd5f> that's about it on my end +23:10 <+mherrb> about xds. any news wrt sponsors? +23:10 <agd5f> mherrb: I'm waiting to hear back +23:11 <alanc> I need to poke now that the people I need to ask are back from vacation +23:11 <+mherrb> And if there are no sponsors, should we cancel the social event, ask participants to pay, or have the foundation pay for it? +23:11 <+emmes> no chance from our side, at least ATM. This might have to be discussed in higher places, though. +23:12 <+emmes> i wouldn +23:12 <+emmes> i wouldn't cancel it. how much are we talking about? +23:13 <+mherrb> about EUR 1500 for 50 persons. +23:13 <+mherrb> but currently only 33 registrations (including 19 'tentatives') +23:13 <alanc> we should ask SFLC if there's any restrictions we have to be careful about on paying for stuff like that once we get 501(3)c status +23:13 <+mherrb> so it may be less. +23:13 <+emmes> maybe we should think supporting students or others who cannot afford it. but the exact qualifications would remain fuzzy. which isn't good. +23:14 <agd5f> keithp: btw, one last thing on the 1023, for the financial stuff let me know if you want to schedule a call with Karen. Stuart wasn't sure what he needed to provide when I talked to him last. +23:14 <agd5f> Karen can probably walk you through it +23:14 <dberkholz|mob> can just trust people to be honest about needing help... +23:16 <keithp> agd5f: yeah, I should have time this week and next to get to that +23:16 <agd5f> BTW, don't tell people their donations are tax deductible yet until we are a 501c3. I changed the verbiage on the wiki already +23:16 <alanc> donations? people make those? +23:16 <agd5f> alanc: not that I know of, but we were saying they were on the wiki +23:16 <+emmes> dberkholz|mob: for amounts like this it's probably ok. i would have headaches if it's about larger sums, but we're already sponsoring travel. so it seems ok. +23:21 <alanc> so is there anything else to discuss? you should have seen in e-mail my progress on the license investigations, and it sounded like we all agreed in e-mail to support jg's request for space to store the old Consortium archives +23:23 <agd5f> yes, I think we should provide the space for jg, backed up if possible +23:23 <+anholt> I assume expo is backed up? +23:23 <+mherrb> agreed +23:23 <+emmes> I think backup is a must for these data. +23:23 <alanc> not sure if it is backed up +23:23 <agd5f> I would guess not +23:24 <+anholt> I see ~jg/Archive/ on it, 500MB, looks like he got started. +23:24 <alanc> is mithrandir admin'ing expo now as well as the fd.o machines? Would he know the backup status? +23:24 <+anholt> pinging +23:25 <alanc> I know he's helped with the x.org mailing lists, but not sure if that's all on expo or fd.o +23:25 <agd5f> John Jendro said it wasn't on his list +23:26 <+anholt> says he's admin, thinks it's backed up, and keithp would have restore-fu. +23:26 <keithp> news to me +23:27 <+emmes> that sounds a bit... too scary for me. +23:28 <+mherrb> if possible get details on the procedure, and try to restore something... +23:28 <alanc> yeah, it's not on the PSU list since it's at MIT +23:29 <alanc> it sounded like we could pay MIT to back it up, which would be a reasonable use of our funds +23:29 * dberkholz|mob agreed +23:30 <agd5f> agreed +23:30 <+mherrb> +1 +23:30 <+emmes> +1 +23:31 <+emmes> assuming that backup at MIT is not unreasonably expensive +23:31 <alanc> do we have anyone who is still in contact with MIT folks for the hosting? I assume someone like Leon originally set that up +23:32 <alanc> or do we just volunteer ajax since he's closest, even though he's not on the board anymore? +23:33 <+mherrb> didn't ajax have physical access there? +23:34 <alanc> I thought so +23:34 <agd5f> does anyone know the deal with MIT? Do we pay them for ping, power, and pipe? +23:35 <alanc> keithp should know if we've been sending them checks +23:35 <keithp> yes, we pay them every year +23:35 <keithp> quite a bit too, $2500 iirc +23:37 <+mherrb> hopefully there are invoices somewhere, with some details. Who has them? +23:39 <agd5f> maybe ajax knows someone there who knows about the services offered +23:39 <keithp> I have the invoices and have paid the checks +23:39 <keithp> just not right at hand +23:39 <alanc> do the invoices mention backup services? +23:39 <keithp> no +23:39 <keithp> just space, power and bandwidth +23:42 <alanc> so does someone want to volunteer for the AI to chase this down and find out what it takes/costs to get backups done if they're not being done? +23:44 <agd5f> I'll do it if someone can provide with a contact of some sort +23:46 <+mherrb> "someone" should be keithp or ajax no? +23:47 <agd5f> yeah, unless someone else knows +23:47 <keithp> One fears what it will cost though; we're paying a mint for rack space +23:48 <agd5f> we could ask if the rates have dropped as well +23:48 <agd5f> renegotiate our contract +23:48 <alanc> or if it's still worth maintaining two sites - I understand historical ties to MIT, but we've really not utilized that well +23:49 <agd5f> consolidating to pdx is fine with me +23:50 <keithp> alanc: the issue is that the machines at MIT were not donated to X.org, but rather to MIT +23:50 <keithp> although, I expect we could ask for them back and expect to receive them +23:51 <alanc> at this point, I doubt they have much value to anyone - all the machines there are 5-6 years old now aren't they? +23:52 <keithp> indeed +23:52 <keithp> I'm working to replace a similar aged stack at PSU +23:53 <+emmes> i think having a single site is ok nowadays. with git there is not a chance of catastrophic data loss. except for the wiki, i guess. +23:53 <alanc> for software distribution we have more than enough mirrors run by other people +23:54 <agd5f> or copy the data to fdo and let MIT have them. less machines to maintain +23:55 <alanc> I don't think we're doing any actual replication between the PSU & MIT machines - more of running different services with different account sets +23:56 <+emmes> then it's actually worse to have two sites - increases the number of single points of failure. +23:59 <+mherrb> so back to original point, have fd.o machines enough space to host jg's data? +[...] 2 security related comments deleted +00:01 <alanc> ... +00:04 <+mherrb> ... +00:05 <alanc> I don't think we need to worry about exact implementation now, and we've gone past our hour +00:05 <alanc> shall we think about this some more and discuss further in two weeks? +00:07 <+mherrb> sounds reasonable, since we miss some precise information to conclude now. +00:07 <agd5f> sounds good +00:07 <+emmes> as this is important that's a good idea. +00:07 <alanc> anything else for today, or shall we adjourn? +00:07 <+emmes> adjourn, from my side +00:07 <agd5f> +1 +00:07 <+mherrb> +1 +00:09 <alanc> thanks for coming all - I'll try to send out minutes sooner this time to remind us about this tabled topic +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/08-17.mdwn b/BoardOfDirectors/IrcLogs/2010/08-17.mdwn new file mode 100644 index 00000000..40af4bf5 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/08-17.mdwn @@ -0,0 +1,179 @@ + +Date is 2010-08-17, times are UTC+02. +[[!format txt """ +23:03 <mattst88> (someone ping me when it's an appropriate time to pose a question to the board) +23:03 <+dberkholz> hi +23:04 <+emmes> mattst88: ping +23:04 <agd5f> mattst88: go ahead +23:04 <+mherrb> jokes apart, if you tell me when you arrive and feel you need a bit of assistance on arrival, I'm planning to be available all of the day before. +23:04 <+emmes> I would say, time is appropriate as it gets +23:04 <mattst88> I wanted to ask this after I'd completed my GSoC, else it would be a bit inappropriate: +23:04 <+emmes> mherrb: noted :-) and appriciated :-) +23:05 <mattst88> I boughht 60~65 dollars worth of video cards for the project, and Ian suggested that the Foundation might reimburse me for this. +23:05 <mattst88> IIRC he mentioned it to Keith and Bart, but I haven't pursued this any further in a few months. +23:06 <+emmes> mattst88: what was your GSoC again? Sorry, Alzheimer... +23:06 <mattst88> KMS for glint, and documenting the process for writing a KMS driver. +23:07 <+emmes> yep, I think I remember now. +23:07 <alanc> $65 sounds well within the foundation's budget, especially if someone filled out the paperwork to get our $500 mentoring fee from GSoC +23:08 <mattst88> OK, great. I think I should send documentation of all this to board@. +23:08 <mattst88> Is there anything else I should do? +23:08 <alanc> do the board members want to vote now or wait until he sends the details? +23:09 <alanc> (I don't see bart in channel - are keithp & anholt actually here?) +23:09 <+anholt> yeah +23:09 <+emmes> if he passed GSoC I'm fine with it anyhow :-) +23:09 <mattst88> emmes, yep, I'm in good shape. :) +23:09 <+anholt> agreed on "sounds like a good idea", just a bit of notes on what you purchased in an email would probably be good. +23:10 <+dberkholz> i'm fine with approving it now. if you have receipts, those might be useful to have +23:10 <+mherrb> I'm ok on the principle. Just check the details to make sure it's really video cards :) +23:10 <mattst88> dberkholz, yes, of course. I'll send those along. +23:10 <alanc> I vote +1 for reimbursing approx. $65 worth of video cards +23:10 <+dberkholz> we may eventually need that kind of documentation for audits +23:10 <+anholt> +1 +23:10 <agd5f> +1 +23:10 <+dberkholz> +1 +23:10 <+emmes> +1, agreeing on docs +23:10 <+mherrb> +1 +23:11 <+Bart_Massey> Apologies for my extreme lateness. +23:11 <alanc> so mattst88 please send details to board@foundation and cc stuart.kreitman@oracle.com (our treasurer) to get the reimbursement +23:12 <mattst88> OK, will do so. Thanks! +23:12 <alanc> and we'll work out via e-mail what sort of reciepts are needed for our records +23:12 <+dberkholz> Bart_Massey: we just voted to reimburse mattst88 for $65 of video cards he bought for gsoc. +23:12 <+Bart_Massey> Excellent +23:12 <+Bart_Massey> +1 +23:13 <agd5f> not much new on the 501c3 side. apparently mail was broken for ~2 weeks, so if the board could review my email and give me their opinions on the questions, I'll take that back to Karen. thanks to those who already replied +23:13 <+dberkholz> i'm in agreement on accepting copyright/TM. not sure on the tradeoffs of public vs private. +23:14 <alanc> so as long as we're spending money, I think we have 4 requests for XDS travel sponsorship +23:14 <+mherrb> (plus the one of Peter that we already accepted) +23:15 <agd5f> dberkholz: you generally want to be public, but that has some requirements you have to meet over the following 5 years +23:16 <+mherrb> and Jeremy Huddlestone (sp?) from apple asked me details, saying Apple won't pay for him. But I saw him remove his name from the attendees wiki today. I don't know what's up. +23:16 <alanc> plus one offer from Intel to provide funding for travel +23:16 <+dberkholz> agd5f: yeah, i recall one of the bsd's having serious issues with too much money coming from a small number of sources +23:17 <+dberkholz> not sure whether we would be affected by that too +23:17 <agd5f> some kind of 30/10 rule with regard to donations over the next 5 years. If we don't meet the requirements we become a private charity, so no big deal +23:17 <+dberkholz> does that mean we lose tax deductibility? +23:17 <agd5f> no +23:17 <agd5f> just slightly stricter regulation in some regards. I don't remember all the details +23:18 <+emmes> regarding travel sponsorship I guess we should fund anyone who's willing to do a talk. Opinions? +23:18 <+Bart_Massey> Up to the limits of our funding I think that's right +23:18 <agd5f> sounds good to me +23:18 <+Bart_Massey> Assuming we'd have any interest in the talk +23:18 <+emmes> that goes without saying :-) +23:18 <+Bart_Massey> I mean, vendor commercials don't count, for example +23:19 <+Bart_Massey> BTW, I'm planning to apply for some funding as well in the next day or two. +23:19 <alanc> or people we think should be present for some of the discussions/BoFs +23:19 <+emmes> right +23:19 <+Bart_Massey> Better to handle me via email, though, I think. +23:19 <+Bart_Massey> I've got a talk. :-) +23:20 <alanc> for instance, the OpenBSD DRI developer would be good for the proposed BoF on DRI/KMS for non-Linux platforms +23:20 <+Bart_Massey> Sure. +23:21 <alanc> all 3 requests/4 people I saw come in during yesterday's resumption of email delivery seemed reasonable to me +23:21 <+Bart_Massey> Me too. +23:21 <agd5f> me too +23:21 <+mherrb> and mee too. +23:22 <alanc> now if we could only get mail delivery to be reliable +23:22 <+Bart_Massey> Tolef thinks he has that under control now. Hope he's right. +23:22 <+Bart_Massey> Mailman wedges all the time for everyone; just need a plan for noticing and/or unwedging it +23:23 <alanc> does anyone want to discuss more or vote on the requests separately, or just go ahead and vote now on approving the travel funding for Matt, Jamey, Josh & Owain? +23:23 <+Bart_Massey> I move we approve all the requests +23:24 <+mherrb> agreed +23:24 <+emmes> +1 +23:24 <agd5f> +1 +23:24 <alanc> +1 +23:25 <+mherrb> +1 +23:25 <alanc> looks like that's about $3k USD for the 3 that gave estimates, plus an unknown amount for Matt to travel from the US +23:25 <+anholt> +1 +23:25 <+Bart_Massey> Matt may actually still be in China; don't know yet. +23:25 <+Bart_Massey> Can't remember +23:26 <alanc> ah, well, then about the same distance the other way around +23:26 <+mherrb> alanc a bit more for owain: he only gave me an estimate for the train. have to add 2 or 3 hotel nights. +23:27 <+Bart_Massey> Anyway, call it $5K for the lot; that still leaves plenty of headroom on Intel's generous donation. +23:27 <alanc> still, leaves most of Intel's offer left to cover additional requests (Jeremy?) or the social event +23:27 <+Bart_Massey> Don't y'all wish we were still doing two of these per year? :-) +23:28 <alanc> sure, approving spending other people's money is no sweat at all +23:28 <alanc> the organizing bits, well, we all owe mherrb much gratitude since that's the hard work +23:29 <+Bart_Massey> Indeed. thank you mherrb! +23:29 <+Bart_Massey> And yes, the organizing and planning was what I was commenting on. :-) +23:30 <alanc> anything else for XDS we need to discuss today? we should all be there in a month +23:30 <+emmes> any time table yet? +23:30 <+Bart_Massey> Want to talk about X.Org logo copyright? +23:30 <+Bart_Massey> Oh, sorry, XDS. +23:30 <+emmes> saturday could prove difficult for me, if we plan any bod meeting... +23:31 <alanc> last I looked at the schedule it was very light - need to encourage more people to put down topics/talks +23:31 <+emmes> so chances are we do the bod meeting thu or fri evening, correct? +23:32 <alanc> I will be in transit during our normally scheduled board meeting on 9/14 - I assumed that would be replaced with an in person "Chat with the Board" session during one of the conference days +23:32 <+emmes> sounds reasonable +23:32 <alanc> or maybe I'll already be in Toulouse by then, the time zones are confusing me +23:33 <+emmes> it's 11pm-12pm. if that helps :P +23:33 <+mherrb> emmes: one evening for the social event, the other for a board meeting. +23:34 <+mherrb> alanc: generally travelling from us->europe you loose one day. +23:34 <+emmes> mherrb: sounds good! +23:35 <+mherrb> I will probably set the day of the social event next week (the people are on vacation now) +23:36 <alanc> ah right, I will be airborne over the US at 2pm Tuesday, arrive in Toulouse at 14:30 Wed +23:38 <agd5f> I'll be on a plane as well tuesday +23:38 <agd5f> arriving at 8:15 wed +23:38 <agd5f> er 11:30 rather +23:39 <+emmes> I'll arrive pretty damn late in the evening on wed. 11pm. +23:40 <+emmes> mherrb: any ideas whether the bus to midtown is still running that late? +23:40 <+mherrb> yes, it runs up to the last plane +23:41 <+mherrb> the last one leaves at 0:15am. so you have some margin for plane delays +23:41 <agd5f> what hotels are people staying at? +23:41 <agd5f> still need to book mine +23:42 <+Bart_Massey> Not to derail the meeting, but I've got grades due in a couple of hours. Any chance we could get the other stuff done first? +23:42 <agd5f> Bart_Massey: sure. what else on the agenda? +23:42 <+emmes> rt_Massey: do you know the status of our logo? appart from that we have the copyright? +23:42 <alanc> okay - X.Org logo copyright/trademark? +23:42 <+mherrb> Irecommend the Albert 1er hotel if possible. +23:43 <+Bart_Massey> I think even the copyright is mildly dicey given the bad records we have from TOG. +23:43 <+Bart_Massey> Our best plan, far and away, is probably to get a new logo that is less ugly and that we unarguably own, and trademark it. +23:43 <alanc> and would it cover the original logo with just the X or the version we have on the website now with the added loop? +23:44 <+Bart_Massey> If we run a contest, we can do the logo for less than $500 +23:44 <+Bart_Massey> The old MIT X logo is probably hopeless at this point; I don't think we have any control over it +23:44 <alanc> http://www.nettv.tv.br/images/stories/logo.gif is a nicer rendering of it than ours though +23:44 <+Bart_Massey> It will probably be another $300-$500 to get all the trademark reg stuff done, unless SFLC will do it for free. +23:44 <+Bart_Massey> alanc: Indeed :-) +23:44 <+Bart_Massey> It's still an ugly logo +23:45 <agd5f> there's still the trademark application and maintenance fees +23:45 <+Bart_Massey> Yes, the fees are a couple of hundred dollars IIRC, plus something like $50 / year. +23:46 <+Bart_Massey> The principal barrier here is finding someone to run all this, I think. I am *not* volunteering. :-) +23:47 <+Bart_Massey> BTW, that brings up an old, old agenda item. We had voted a long time ago to donate some money to SFLC based on their help to date. We should revisit that and actually do it this time. :-) +23:47 <agd5f> indeed. I very much agree with that +23:48 <+emmes> that must have been before my time. not that I'm against it ;) +23:48 <alanc> it doesn't necessarily need to be a board member, we could put out to the community to ask for volunteers for organizing a logo replacement +23:48 <+Bart_Massey> alanc: excellent point. someone put a note to the xorg list. +23:49 <alanc> yeah, I don't remember discussing an SFLC donation, but would approve of one +23:49 <+Bart_Massey> i don't think many of you were on the Board at that time. :-) +23:49 <alanc> I can send a note to the list to ask for volunteers when I do the minutes +23:50 <+Bart_Massey> I was thinking O($7500), but some other Members thought O($5000) was sufficient. What do other folks think of amounts? +23:50 <+Bart_Massey> alanc: thanks +23:51 <alanc> agd5f is probably in the best position to know how much time they've put in to helping on the 501(c)3 stuff for us +23:51 <+emmes> I can't tell until there is *some* list of things they helped us with. I understand they help Alex with the 501 stuff. +23:51 <+Bart_Massey> Remember, it's been 3+ years. :-0 +23:51 <agd5f> they were also involved in the switch from llc to non-profit +23:52 <+Bart_Massey> Indeed +23:53 <+emmes> Right. Just asking because $5000 and up isn't exactly nothing. I know lawers can be expensive, though. +23:54 <+Bart_Massey> Conservatively they've put in 30-40 hours on us. At a typical $400/hour, that's 12-16K. So we're really just doing a courtesy donation here in any case. +23:55 <alanc> $7500 seems reasonable to me +23:55 <+Bart_Massey> From talking to Karen, I think $5K-$10K would be in line with what other organizations that have used their services have donated. +23:55 <alanc> though we probably ought to get a treasurer's report soon (maybe by XDS?) to find out how much money we still have to spend +23:56 <+Bart_Massey> That would be the awesome +23:56 <+emmes> as this isn't exactly pressing, that sounds like a good idea to have first. +23:56 * Bart_Massey notes that xchat won't let him type t e h as one word +23:56 <+emmes> (first this means the donation) +23:56 <+Bart_Massey> emmes: i suppose. but I'd hate to drop it for two years again. let's make sure to deal with it at XDS +23:57 <+dberkholz> fwiw, we don't need to register a trademark to own it +23:57 <+emmes> :-] +23:57 <+dberkholz> trademarks are "earned" by simply using them +23:57 <+anholt> Bart_Massey: settings -> advanced -> auto replace to fix that. +23:57 <agd5f> we also have the $25 delaware franchise fee and ~$2000 in old llc taxes and fees +23:57 <alanc> okay, so we'll table the SFLC donation for now +23:57 <+Bart_Massey> dberkholz: it's complicated. much more complicated than copyright law. you are unlikely to want to bring legal action without a registered mark +23:57 <+Bart_Massey> anholt: thanks! +23:58 <alanc> and given our hour is up, I guess we'll wait until next time to discuss more about the MIT-hosted machines and if they're still worth the expense of hosting there +23:58 * Bart_Massey is bemused that teh->the is the sole auto-replacement +23:58 <+Bart_Massey> alanc: fair enough +23:58 <+Bart_Massey> Thanks all! Move to adjourn +23:59 <+emmes> +1 +23:59 <agd5f> +1 +23:59 <alanc> +1 +23:59 <alanc> thanks for coming everyone +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/08-31.mdwn b/BoardOfDirectors/IrcLogs/2010/08-31.mdwn new file mode 100644 index 00000000..a8160fef --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/08-31.mdwn @@ -0,0 +1,46 @@ + +Date is 2010-08-31, times are UTC+02 +[[!format txt """ +23:01 <alanc> good afternoon +23:01 <agd5f> hello +23:01 <+mherrb> hi +23:01 <+keithp> hello +23:03 <+keithp> bart is away today; anyone else have an agenda? +23:04 <alanc> I thought mherrb had sent some mail about XDS +23:04 <agd5f> nothing new here +23:04 <+mherrb> yes about the program +23:05 <agd5f> keithp: did you get my email about the delaware franchise tax? +23:05 <+keithp> agd5f: yes +23:05 <agd5f> ok. cool +23:05 <alanc> not sure when Stuart's meeting with Karen is this week, haven't heard any updates from him on the 501(3)c stuff +23:05 <alanc> but then, he's in New York +23:05 <+keithp> alanc: also hoping to hear that Stuart has gotten an invoice to intel for the XDS funding +23:06 <+keithp> mherrb: I've secured US$15k for the event for travel sponsorship; it sounds like we'll have enough left from that for the social event too? +23:06 <alanc> I'll ask him when he get's back +23:07 <+keithp> alanc: needs to be in by Friday or we don't get any... +23:07 <+keithp> welcome to end-of-the-quarter finances +23:07 <alanc> I think he's back before then - was in NY to drop off a kid at college +23:07 <+keithp> what fun +23:08 <+mherrb> yes I havent counted exactly but I thing there should be some money left for the dinner. +23:08 <alanc> I think we allocated around $4-5k for the 4 travel sponsorships we approved last week +23:09 <alanc> last meeting rather +23:09 <agd5f> mherrb: I asked about funding the dinner too, but doesn't look like it's gonna happen +23:09 <+mherrb> If I'm not mistaken Mikhail Gusarov was the only one to ask after what we approved, and he cancelled his request (unfortunatly) +23:09 <+keithp> no time to get a visa, it seems +23:10 <+dberkholz> just wanted to pop my head in ... +23:10 <+mherrb> it's partly my fault he sent me a personal e-mail while I was on vacation to get an invitation letter, but I didn't see it until last week, drawned in the middle of spam. +23:10 <+mherrb> so I sent him the letter too late. +23:12 <+mherrb> I'm a bit scared by the number of last minute registrations. As soon as I know more about the replacement room, I'll close the registration I think. +23:13 <alanc> now if we could only get as many last minute offers of content for the program +23:13 <+mherrb> I asked the people at Enac (benjamin tissoire and his boss stephane chatty) to present what they do in flight control UI with Xorg. +23:14 <+mherrb> they agreed. But it's still undecided if they bring a demo or if we take the metro to go visit their lab. +23:17 <+mherrb> if the latter, we can go there by the end of the afternoon on thursday (after the break) for example. +23:18 <alanc> a mid-conference field trip could be fun +23:19 <alanc> is there anything else the board needs to decide before the conference begins? (this is our last meeting until then) +23:19 <+mherrb> No I think that's all for now. +23:20 <alanc> anything else for the agenda, or are we done? +23:20 <+anholt> nothing here. enjoy the vacation^Wmeeting. +23:21 <agd5f> nothing else from me +23:23 <alanc> I move to adjourn then +23:23 <alanc> and hope to see most of you in Toulouse in 2 weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/09-28.mdwn b/BoardOfDirectors/IrcLogs/2010/09-28.mdwn new file mode 100644 index 00000000..5921a615 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/09-28.mdwn @@ -0,0 +1,54 @@ + +Date is 2010-09-28, times are UTC+02 +[[!format txt """ +23:08 <alanc> so first we have meeting times - will same time on Monday work for everyone? +23:08 <agd5f> works for me +23:08 <+dberkholz> yep, as mentioned +23:08 <+mherrb> for me too +23:09 <+anholt> wfm +23:09 <alanc> mhopf said on list it would work for him after this week +23:10 <alanc> okay, so next meeting will be Monday, Oct 11 @ 2pm Pacific +23:11 <alanc> it also looked like everyone who responded on list agreed with the proposal to remove the instructions on the wiki telling mirrors to contact us - any objections? +23:11 <+mherrb> can you also update the google cal? +23:11 <+anholt> looks like the mirrors question is resolved and the wiki just says "it's a wiki, add your mirror if you want." +23:11 <alanc> mherrb: sure +23:11 <agd5f> alanc: no objections here +23:11 <+mherrb> none here +23:12 <alanc> great, we'll check that off as done then +23:13 <alanc> from my agenda that leaves elections - its getting near the time when the election committee should be starting to draw up the calendar for the end of year elections +23:14 <alanc> since the election committee automatically consists of the members who just got elected and thus can't be running again, that would be agd5f, mherrb, mhopf, & keithp +23:14 <+anholt> is the private bod website 500ing for everyone else? it's got the info an election committee needs. +23:16 <+mherrb> i can't test right now. +23:17 <+mherrb> not the right laptop with stored ids :( +23:20 <alanc> I'm still trying to find the mail where I have the info for it stored, since I only go there twice a year +23:20 <+dberkholz> same +23:21 <+anholt> https://members.x.org/bod/ and I'm pinging mithrandir +23:21 <+anholt> some moin hilarity. +23:21 <alanc> Internal Server Error +23:21 <+dberkholz> yep, error here +23:22 <alanc> https://foundation.x.org/bod/ElectionCommittee is the link I had +23:24 <alanc> okay, well, we've reminded the election committee and hopefully the site will be fixed soon so they can see the instructions for the next steps +23:24 <alanc> anything else to discuss today? any news on 501(c)3 status? +23:25 <agd5f> no. I need to follow up with stuart and karen +23:25 <alanc> I trust all the people who needed to be paid for XDS have been, or will start complaining to us soon (I have seen mail about getting the check to Matt for his travel, but Stuart & Keith are working that out) +23:26 <+mherrb> I sent my check to my bank yeststerday +23:27 <alanc> and of course, once again, much thanks to mherrb for a conference well organized +23:28 <alanc> oh, now that stukreit is here - what was the bill we discussed during XDS? something like $25 for Delaware annual corporation fee? +23:29 <agd5f> yeah +23:29 <alanc> everyone present at XDS was in favor of paying it +23:29 <agd5f> karen still needs the financial info as well for the 501c3 forms +23:30 <alanc> unless anyone here wishes to object, I'll record that we approved the Delaware fee and let agd5f send the details to stukreit to get a check written +23:31 <stukreit> ok. just so you know. I write a check, send it to Keith, then he signs it and we send it on +23:31 <stukreit> I have the ptr from agd5f on the delaware details +23:33 <agd5f> stukreit: if the form has timed out, I have the info saved and can fill it out again +23:33 <stukreit> I want to update the financial info with the checks from xds2010 before sending it to Karen +23:33 <agd5f> makes sense +23:33 <stukreit> a*f: it's staying put +23:34 <stukreit> keith: do you think I have to resend you a check for Matt Dew? +23:38 <alanc> keithp hasn't been responding - seems to be away from his keyboard +23:39 <alanc> stukreit: thanks for the report you provided for us to give at XDS btw, helped with the discussion about the board & spending money +23:39 <stukreit> sure, I should do more of that +23:44 <alanc> anything else for today's agenda, or shall we call it done? +23:45 <agd5f> nothing else from me +23:46 <alanc> I move to adjourn then +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/10-11.mdwn b/BoardOfDirectors/IrcLogs/2010/10-11.mdwn new file mode 100644 index 00000000..4c91e679 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/10-11.mdwn @@ -0,0 +1,62 @@ + +Date is 2010-10-11, times are UTC+02 +[[!format txt """ +23:00 <alanc> Good afternoon/evening +23:00 <agd5f> hello +23:00 <+dberkholz> yep +23:05 <+dberkholz> Bart_Massey: did you get stephane's email about gsoc vendor info? +23:05 <+Bart_Massey> Yes, albeit later than I should have. I responded. +23:05 <alanc> hmm, looks like https://foundation.x.org/bod/ElectionCommittee is still broken +23:06 <+dberkholz> ah, must've been in the past couple of days. +23:06 <+Bart_Massey> indeed +23:09 <alanc> so we still seem to be missing anholt, keithp, emmes, and mherrb +23:10 <+anholt> here +23:11 <keithp> I'm here as well +23:11 <alanc> since the board wiki is still down, I assume the election committee hasn't been able to do much since last meeting +23:12 <agd5f> yup +23:13 <alanc> Stuart says he has nothing to report from treasurer status beyond what he already sent in e-mail (new check for Matt sent to Keith for co-signing) - did anyone want to discuss the mail he forwarded about a donation policy? +23:13 <alanc> do we need to explicitly state that money doesn't buy any promises before we start accepting donations to the 501(c)3? +23:13 <+dberkholz> i agree with the impression alanc got from them +23:14 <+Bart_Massey> I just got a phone call and have a family emergency. Have to go now---sorry. +23:14 <+dberkholz> yeah, i'm pretty sure you are right about that. otherwise it doesn't count as donation anymore but as other income +23:14 <alanc> we have linked to donors before, but I think that was out of gratitude, not a condition of the donation +23:15 <+anholt> while we try to get expo up again, I can fwd the 2009 process text to the committee if that would help. +23:15 <agd5f> anholt: yes please +23:16 <alanc> if I remember right, this should be around the time they're thinking about the schedule and making sure the membership process stuff is working for new members to sign up before the elections +23:16 <+anholt> we have 0 apps in the queue at the moment, last app was a month ago or so. +23:17 <+anholt> who was the committee this year? +23:17 <+anholt> meh, I'll just forward to board@ +23:17 <alanc> agd5f, mherrb, mhopf, & keithp should be this years committee, since they're most recently elected +23:17 <alanc> but board works too +23:18 <keithp> no reason to not use the board list; the only interesting piece is who gets the 'write enable' bits +23:18 * keithp has been hacking on SIMD hardware a bit too much +23:21 <+anholt> done. +23:21 <alanc> agd5f: any 501(c)3 news? +23:22 <agd5f> alanc: just waitig for stuart to update the financial numbers post-XDS +23:23 <alanc> okay, I'll remind him +23:23 <agd5f> thanks +23:24 <alanc> just saw dberkholz's comment about professional designers not liking the "do work for a small chance of getting paid" systems, which I can understand +23:25 <alanc> (and actually saw a well written blog on over the weekend from a designer responding to GAP's logo design "contest" that expressed similar feelings) +23:26 <alanc> so if we go forward with the contest, we'll probably get more students & amateurs than professionals +23:26 <+dberkholz> my guess is that we'd get better quality from free vs small amount of money +23:27 <+dberkholz> people are willing to give away things they wouldn't sell for a pittance +23:27 <agd5f> yeah, I agree. it's the "fame" reward +23:34 <alanc> so do we want to keep up the idea of a contest but without a cash prize? +23:34 <+dberkholz> the only trick will be reaching the right audience. +23:35 * anholt feels entirely neutral about the logo change plan. +23:35 <+dberkholz> we'll just have to re-submit the original logo as an option, so if none of them beat it, they don't get adopted +23:36 <agd5f> sounds fine to me. +23:38 <+dberkholz> i'm not deeply passionate about getting a new logo but i'm ok with it +23:40 <keithp> yeah, the existing logo is lame, but I doubt we'll get anything substantially better... +23:41 <agd5f> should we just work on gettig the current one properly registered? +23:43 <alanc> doesn't seem like anyone is all that passionate about a new logo - marcoz (aka Matt Dew) was the only one interested in figuring out how we move forward with organizing a replacement +23:44 <marcoz> i'm just volunteering to do the grunt work. either way (keep the existing or look for new) is fine by me. +23:45 <+dberkholz> sounds like we should just stick with what we've got, until people feel more enthusiastic about changing it +23:45 <marcoz> it would be nice to have some colors in the logo that we could use in the rest of the site. color coordination as it were. +23:47 <+dberkholz> i need to run in a few minutes. is there anything besides this we need to get through today? +23:48 <alanc> I don't have anything else for the agenda -does anyone else? +23:48 <agd5f> nothing here +23:50 <alanc> I move to adjourn then +23:50 <keithp> second +23:51 <alanc> see you all in two weeks then +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/10-25.mdwn b/BoardOfDirectors/IrcLogs/2010/10-25.mdwn new file mode 100644 index 00000000..b6a60e98 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/10-25.mdwn @@ -0,0 +1,151 @@ + +Date is 2010-10-25, times are UTC+02 +[[!format txt """ +23:07 <alanc> so I didn't have a whole lot for today's agenda - I mailed out about the google winter program for high school kids, and there's the usual status updates on 501(c)3 & election committee +23:07 <alanc> did anyone have thoughts on the Google Code-In? desire to volunteer to organize us for it? +23:08 <+emmes> I'd also like to ask whether anybody has reviewed Michael's proposal for XDC 2011 +23:08 <+Bart_Massey> Code-In? +23:08 <+emmes> SoC in small ;-) +23:09 <+Bart_Massey> Haven't seen it yet. Michael? Where? +23:09 <alanc> Bart_Massey: Google's "junior summer of code" program for 13-18 year olds running November-January +23:09 <alanc> instead of 3-month long projects, they do a bunch of short tasks, like write a man page or fix a bug +23:09 <+Bart_Massey> Huge thanks to Stephane for running GSoC 2010. Very nice job. +23:09 <+Bart_Massey> Right, this is the former ghop +23:10 <+emmes> "fix a bug" is probably too hefty in Xorg for most bugs that are still open... +23:10 <dberkholz|mob> They can be different difficulty levels... +23:10 <+Bart_Massey> "write a test" would be nice +23:10 <alanc> http://foundation.x.org/pipermail/members/2010-October/000600.html is the mail I sent to board & members last night with links +23:11 <agd5f> it seems like a good idea, but I won't have time to run it. I'm happy to help mentor though +23:11 <alanc> there's probably some easy bugs in the client side that students could fix - certainly a lot of the deep server bugs would be too hard +23:11 <dberkholz|mob> I could run it if others could come up with tasks and mentor +23:12 <alanc> I can help come up with some tasks +23:12 <alanc> I think Friday is the deadline to apply to google though +23:13 <+emmes> i would help mentoring, but ATM I don't have many ideas about tasks. Though I'll be nowhere near any computer for nov 30 to dec 14. +23:13 <dberkholz|mob> Yep +23:14 <dberkholz|mob> I don't have the dates handy... +23:14 <+Bart_Massey> Sorry +23:14 <alanc> I would think mentoring for this is different than summer of code, since it' +23:14 <alanc> s not a single project the whole time +23:15 <agd5f> I have a few ideas that wouldn't be too hard +23:15 <alanc> and given the holidays at that time of year, we'd probably want people who are around at different times - I can help with that too +23:15 <agd5f> exposing kms connector attributes via sysfs +23:15 <agd5f> not exactly xorg though +23:15 <+emmes> +1 +1 +23:16 <alanc> we've always considered Mesa, DRI & xcb to be part of the X.Org family for Summer of Code +23:16 <+emmes> i guess drm related stuff is xorg-ish enough to be supported +23:16 <alanc> Google prefers a larger umbrella project over having 4 different organizations to manage +23:18 <alanc> so it sounds like we're generally agreed it's a good thing to do, and dberkholz will submit our application for it +23:18 <alanc> should we submit project ideas to the thread I sent to xorg-devel? +23:19 <agd5f> maybe a wiki page and email out the wiki link +23:20 <+Bart_Massey> ...\ +23:21 <alanc> I can start a wiki page and send it out +23:22 <agd5f> alanc: thanks! +23:22 <+Bart_Massey> I'd like to do a Book Sprint before XDC 2011 to produce an X.Org New Developer Guide. +23:22 <+Bart_Massey> It would probably require a bit of funding from X.Org, and definitely participation from some clueful people. +23:23 <alanc> before as in same place, just the previous days? +23:23 <+Bart_Massey> Yes +23:23 <dberkholz|mob> sounds great to me +23:23 <+Bart_Massey> 2 or 3 days +23:23 <+Bart_Massey> depending on how much time people can spare +23:24 <agd5f> Bart_Massey: sounds like a good idea +23:24 <alanc> yeah, sounds good to me too +23:24 <+Bart_Massey> 7 of us wrote 18K words at Google last week in two 8-hour days. +23:24 <+Bart_Massey> So it seems to scale pretty well once you get the hang of it. :-) +23:24 <+Bart_Massey> Cool. We'll plan on it, and I'll announce it once we have XDC 2011 nailed down. +23:25 <+Bart_Massey> Elections? +23:28 <+Bart_Massey> ping? +23:28 <agd5f> I guess we gotta get them nailed down +23:28 <alanc> the wiki is up and running now, and anholt mailed out the task list as well +23:28 <agd5f> the elections that is +23:28 <agd5f> How do we want to break up the tasks? +23:29 <alanc> figuring out the schedule would be good to plan around the holidays +23:30 <+Bart_Massey> Any other business? +23:30 <+emmes> I noted that I apparently don't have access to the bod wiki - Eric has the necessary information in the meantime. +23:31 <+emmes> Thanks to him for kicking us in the right direction :-) +23:31 <agd5f> I'll send out an initial break down to those of us on the election committee and we we can discuss and divide tasks +23:31 <alanc> any update on 501(c)3? +23:31 <agd5f> alanc: still waiting on feedback from stuart +23:32 <alanc> and emmes raised the issue of the XDC 2011 proposal Michael Larabel mailed the board right after XDS2010, which probably no one read since it was a glossy pdf thingy +23:32 <alanc> http://www.michaellarabel.com/misc/xds-chicago-proposal.pdf +23:33 <+emmes> it looks actually pretty solid. +23:33 <+emmes> to me, that is. +23:34 <+emmes> question is whether we want the press organize our main event. +23:34 <+Bart_Massey> I think we'd need a concrete date and venue before we could really answer, but I think it looks promising enough. +23:34 <+emmes> as long as it's clear that Phoronix doesn't have any exlusitivity rights (not that other press organs ever showed much interest) I wouldn't have any issues with that, though. +23:34 <+Bart_Massey> Basically "organize" here means make sure that space is available +23:35 <+emmes> right. +23:35 <+Bart_Massey> We get full control over who we invite and accept, what content we have, etc +23:35 <+Bart_Massey> (We learned that lesson in Ottawa a few years back. :-) +23:35 <+emmes> you gotta tell me over a beer some day ;) +23:36 <+Bart_Massey> Definitely :-0 +23:36 <alanc> it also misses part of the point of tiago's proposal, which was the timing to coincide with the Mobile Linux conference there - both for increasing participation from people who would go to one or the other, but not make two trips, and to reduce the costs for people who would go to both +23:36 <+Bart_Massey> I've heard...erm...rumors that Tiago's proposal is not a going concern any longer? +23:36 <agd5f> true. Plus, IMHO, a XDC in south america would be cool +23:37 <alanc> (not that I know how many people other than Tiago & his compatriots in Nokia would be going to both) +23:37 <+emmes> still I'm not confident that Tiago will manage the conference too well. He didn't even made it to his own talk :-/ +23:37 <+emmes> i agree that it would be cool, though. for europeans the travel cost isn't vastly different anyway. +23:38 <alanc> organizing a conference on another continent can't be an easy task +23:38 <+emmes> so as always - we have pros and cons +23:38 <alanc> though I think he said he could get help from Nokia local people in Brazil +23:38 <+Bart_Massey> I'm good with whatever folks want to do. I'm kind of thinking Keithp should be part of the conversation; he has a lot of experience doing this kind of thing. +23:39 <+keithp> what's that? +23:39 <+emmes> I just suggest that we all at least check the pdf from Michael, after he has already put some efforts in it. It's an easy read anyway. +23:39 <+Bart_Massey> keithp: Chicago or Brazil or other for XDC 2011? +23:39 <+keithp> Unless we've got more feet on the ground than tiago, I'd say brazil is not a great plan +23:39 <+Bart_Massey> I just read Michael's proposal. He obviously put a lot of work into it. +23:39 <agd5f> I'm happy where ever we end up as long as someone wants to put in the organizing effort +23:40 <+keithp> weird having Michael organize our event, but frankly, better him than me +23:40 <+keithp> he's definitely contributing to X.org with all of his press coverage +23:40 <+Bart_Massey> I think Michael's title would be "local arrangements chair", which is pretty standard for conference organizing +23:40 <+emmes> Bart_Massey: He told me that it wasn't too bad. He wrote it in one of the XDS nights. Apparently he's pretty good at wording... +23:41 <+emmes> keithp: agreed +23:42 <+emmes> we don't have to get to a conclusion right away. but we also should think about the timing - another of Michael's proposal (which I found great!) was to invite the google SoC students to present their work on the conference. maybe even mandatory. +23:42 <+Bart_Massey> Anyway, I'd like to make a decision as soon as possible so I can start organizing the book sprint. Let's try to see how far we can get with this next meeting? +23:43 <+emmes> Bart_Massey: I think nobody was against the book sprint? +23:43 <+keithp> Have we posted sufficient requests to the list asking for hosting volunteers? +23:44 <alanc> I don't think we've posted any +23:44 <+Bart_Massey> emmes: I want to invite people ASAP so that they get it on their calendars. The people we need are busy busy. +23:45 <+emmes> right ;-) +23:45 <marcheu> book sprint? +23:46 <+Bart_Massey> We're going to write an X.Org New Developer Guide next year. :-) +23:46 <marcheu> ah, maybe I could interest you in something I've done then +23:46 <+Bart_Massey> Whatcha got? +23:47 <marcheu> a 65-something page manuscript on that I think +23:47 <+Bart_Massey> nice +23:48 <+Bart_Massey> Please email it to me at bart.massey@gmail.com, and we'll talk offline about how it fits. +23:48 <marcheu> been doing that thing for a year or so +23:48 <+Bart_Massey> Where do you find time for this? Wow. +23:48 <marcheu> yeah sure, I intend to put it online when it's done +23:48 <marcheu> but maybe we could collaborate on it instead +23:48 <+Bart_Massey> If you want collaborators we can arrange that. +23:49 <marcheu> sounds like it would be a good base to bootstrap such a project +23:49 <agd5f> sounds good +23:49 <+Bart_Massey> Awesome, actually. +23:49 <marcheu> the exact topic is "linux graphics drivers" though, not just X.Org :) +23:49 <+Bart_Massey> Perfect. +23:49 <+Bart_Massey> We will fill in the rest +23:50 <+Bart_Massey> Having a first draft of the biggest section is a terrific start +23:50 <marcheu> gimme 5 second, I'll compile a pdf and put it online +23:51 <+Bart_Massey> Thanks huge. +23:52 <alanc> marcheu: btw, if you missed the previous book sprint discussion, you might have missed the bits scrolled even further back: "Huge thanks to Stephane for running GSoC 2010. Very nice job." +23:52 <marcheu> people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf +23:52 <marcheu> alanc: nope I've got it, thanks :) +23:52 <+Bart_Massey> alanc: Thanks. +23:52 <+Bart_Massey> marcheu: Indeed! +23:53 <alanc> anything else for today, or are we ready to call it done? +23:53 <+Bart_Massey> Such a relief for me to not have to do anything. :-) +23:53 <+Bart_Massey> I'm good. +23:54 <+anholt> sorry, fell off wireless and didn't notice :/ +23:54 <+Bart_Massey> marcheu: Sweet book! +23:55 <agd5f> nothing else from me +23:55 <+Bart_Massey> I will read it carefully, and maybe even I will understand some things now. :-) +23:55 <marcheu> yeah a lot of work went into it, but it's not yet halfway there :( +23:55 <+Bart_Massey> That's the beauty of the book sprint approach; we can accelerate it enormously +23:55 <marcheu> yup +23:56 <marcheu> sorry, I have to take off now +23:56 <alanc> wasn't matttst also working on KMS docs? +23:56 <alanc> or docs on writing a KMS driver that is +23:57 <+Bart_Massey> I have to go also. Thanks all! +23:57 <alanc> I move to adjourn since everyone is leaving +00:33 <alanc> http://www.x.org/wiki/GoogleCodeInIdeas created +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/11-08.mdwn b/BoardOfDirectors/IrcLogs/2010/11-08.mdwn new file mode 100644 index 00000000..52309444 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/11-08.mdwn @@ -0,0 +1,68 @@ + +Date is 2010-11-08, times are UTC+01 +[[!format txt """ +23:00 <+Bart_Massey> Howdy all! +23:00 <alanc> Good afternoon +23:01 <alanc> sorry for not sending the reminder earlier, given the time change confusion +23:01 <+Bart_Massey> :-) +23:01 <+Bart_Massey> Think the time change will get all the Europeans? +23:01 <+Bart_Massey> Or are we meeting an hour later? +23:01 <alanc> emmes was asking an hour ago why we hadn't started yet +23:01 <+Bart_Massey> :-) +23:01 <dberkholz|mob> hi +23:03 <+Bart_Massey> dberkholz: Hi! +23:03 <+emmes> yeah, i just forgot that we've got winter time as well already ;-] +23:03 <+emmes> so it's actually 11pm as usual. +23:04 <+Bart_Massey> :-) +23:06 <+Bart_Massey> Well, looks like 5 of us? +23:06 <alanc> so if anholt, agd5f, and keithp are here (haven't seen them say anything yet), then we seem to just be missing mherrb +23:06 <+anholt> hopefully I won't crash again. +23:07 <+Bart_Massey> anholt: Hi! +23:07 <agd5f> i'm here +23:07 <alanc> hopefully everyone saw dberkholz's update by e-mail on our non-acceptance to the Google winter of high school students program +23:07 <+Bart_Massey> Yeah. Sad, given that Google was pretty excited about getting applicants. Oh well. +23:08 <+Bart_Massey> From our point of view, I suspect we dodged a lot of hard work. +23:08 <dberkholz|mob> still too bad. I would've liked to pick up a new contributor or few. +23:09 <+Bart_Massey> Indeed. +23:09 <+emmes> i also think nobody knew that only that few applicants would be accepted +23:09 <+Bart_Massey> Definitely. +23:09 <dberkholz|mob> yeah, I had no idea they were taking less than 1 for every 7 in GSoC +23:09 <alanc> it's the first time they've done this in a while, so I don't think anyone knew what to expect - hopefully like Summer of Code they'll expand once both Google and the orgs figure out what works +23:10 <+Bart_Massey> I think they've done it every year; they just renamed it this year. +23:10 <dberkholz|mob> just once before +23:10 <+Bart_Massey> It was the Google Highly Open Participation Contest last year. +23:10 <alanc> I thought that was a couple years ago +23:13 <+Bart_Massey> I think they ran it last year. +23:13 <+Bart_Massey> I talked to Carol about it. +23:13 <alanc> in any case, we did get some ideas that new contributors can start on, even if they're not high school students getting google t-shirts & money +23:14 <+Bart_Massey> Yeah, the problem with paying HS students is that you run into horrible regs. Google gets around this by making it a "contest". +23:15 <alanc> yeah, wouldn't want to have to figure out child labor laws in all the different states, much less all the countries of the world +23:16 <+Bart_Massey> So, any other business? +23:19 <alanc> any update on 501(c)3? +23:19 <alanc> or the election committee? +23:20 <stukreit> hello port 999 +23:20 <stukreit> 9 +23:20 <alanc> greetings Mr. Treasurer - any report for us? +23:21 <stukreit> yeah, I'm trying to collect a bunch of checks and found that I have a lot of nte (not to exceed's) +23:21 <stukreit> guess I have to get some mail from keith, may have it buried somewhere +23:22 <stukreit> I also got a debit mastercard from hsbc. But I thought I was getting a crypto key +23:23 <alanc> I suppose that could be handy for avoiding check cashing fees when hosting out-of-country events like the XDS dinner +23:23 <agd5f> alanc: no news on 501c3 from me. I emailed a proposed plan to the election committee after the last meeting, but no one responded +23:23 <stukreit> that's about it. I have the checkbook with me today, planning on sase'ing the tax payment +23:23 <agd5f> stukreit: any news on 501c3? +23:24 <stukreit> haven't spoken to karen +23:24 <agd5f> stukreit: how about the delaware franchise fee? +23:25 <stukreit> yeah, that one. I'm prepping it now to send to keith +23:28 <alanc> I'm out of items on my list for the agenda +23:28 <+Bart_Massey> Cool! Move to adjourn. +23:29 <agd5f> anyone from the election committee, please reply to my email about the election plan +23:30 <+emmes> ok +23:30 <agd5f> The dates will obviously slide from my original proposal, since it's past already +23:31 <agd5f> unless someone sends an updated proposal, I'll send out an updated one later in the week +23:33 <agd5f> same proposal, new dates +23:34 <agd5f> does starting in January work? +23:38 <+emmes> good for me. almost no more vacation ;) +23:39 <+Bart_Massey> Got to go, y'all. See you in a couple of weeks! +23:40 <alanc> never saw a second on the motion to adjourn, but I guess we're done now +23:42 <alanc> thanks everyone +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/11-22.mdwn b/BoardOfDirectors/IrcLogs/2010/11-22.mdwn new file mode 100644 index 00000000..8a706bff --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/11-22.mdwn @@ -0,0 +1,36 @@ + +Date is 2010-11-22, times are UTC+01 +[[!format txt """ +22:59 <alanc> good afternoon +23:00 <+emmes> agd5f: sorry for still not having looked into your election proposal mail - I was in Taipei all of last week +23:02 <+mherrb> is it the same as what you put on the wiki earlier today? +23:02 <agd5f> I updated the schedule on the wiki +23:03 <alanc> looks like bart & dberkholz are missing (as expected for bart), keithp & anholt logged in but still silent, everyone else accounted for +23:06 <alanc> anything else to discuss on elections? +23:06 <+anholt> I'm here. +23:06 <alanc> any reports from our treasurer or on the 501(c)3 status? +23:09 <stukreit> yes, alex and I were talking briefly. +23:09 <stukreit> basically, I sent the last rollup of expenditures to Keith. Would like to get a confirmation from him that its complete. +23:10 <stukreit> and I sent him the $25 check for delaware to co-sign +23:10 <stukreit> With his conf. I would then send the rollup to Karen, and he sends the check to Delaware. +23:11 <stukreit> so we're on the virge of just-do-it. +23:11 <alanc> good, sounds like progress +23:14 <alanc> anything else we need to discuss, or is this going to be a short meeting? +23:14 <alanc> I haven't seen any further discussion on XDC locations/timing for 2011 +23:15 <agd5f> I sent out another email about the election schedule to those on the election board. please let me know if the proposed schedule works +23:15 <stukreit> how about the fosdem/X event. Is that of interest? +23:16 <+mherrb> I think it's too late, we didn't get a dev room for this year. +23:16 <+mherrb> I will very probably be there if people want to have a beer though +23:17 <+mherrb> for 2012 if we want a room again we'll need to have a program ready by oct 2011. +23:17 <+mherrb> libv can correct me if I'm wrong. +23:17 <alanc> which I guess means someone willing to put in a fair bit of time to organize it +23:18 <stukreit> I see the last deadline was oct 16 '10 +23:18 <+mherrb> to harass people to give a title and a summart of possible talks. +23:18 <+mherrb> which is also the problem with XDS programs :) +23:21 <+mherrb> if the book programs goes well, one could imagine a Xserver programming course / lab at fosdem 2012 +23:24 <alanc> sounds like we've run out of things to discuss today - hopefully by next meeting we'll have an election calendar to look at +23:25 <alanc> shall we call ourselves done? +23:25 <agd5f> +1 +23:25 <+mherrb> +1 +23:26 <alanc> thanks for coming all +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/12-06.mdwn b/BoardOfDirectors/IrcLogs/2010/12-06.mdwn new file mode 100644 index 00000000..dc46ce85 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/12-06.mdwn @@ -0,0 +1,89 @@ + + +[[!format txt """ +<alanc> good afternoon +<alanc> Matthias sent mail last week saying he'd be unavailable today due to vacation +<agd5f> hello +<alanc> hmm, seem to be missing anholt, bart, and keith (assuming dberkholz is here, just quiet) +<dberkholz> here! +<dberkholz> not even mobile for once +<alanc> oh, I guess keithp is in channel too +<alanc> agd5f: any election or 501(c)3 update to get us started with? +<alanc> or any treasurer report from stukreit ? +<stukreit> I don't think I have any thing to do on that +<agd5f> alanc: the delaware franchise fee requires an ACH transfer or credit card. any objections to me paying with my card and xorg reimbursing me? +<stukreit> or.. $0 in, $0 out +<agd5f> I believe the fee is like $25 +<alanc> right, I thought stuart already sent on a check for that +<stukreit> alanc: As treasurer, I recommend this, we don't have a good way to send money out +<alanc> I have no objection to that +<stukreit> I did, but it apparently didn't get past keith +<stukreit> I would like to put an issue on the agenda: +<agd5f> alanc: they don't take checks. just ACH transfers and credit cards. At least there doesn't seem to be any easy way to pay via check +<alanc> stukreit: didn't you get a debit card on the X.Org account you could use for that? +<stukreit> let me read it- I have it here +<stukreit> well, it's a mastercard debit card. +<stukreit> Can you use that over the phone? +<agd5f> stukreit: if you have the financial data together for the 1023 form, we should ping Karen +<alanc> in any case, the board approved the $25 dollars for the Delaware fee, as long as the money leaves our bank account and gets credited to our fees due in delaware, whatever path it takes to get there is an implementation detail I'm happy to leave to you & stuart to work it +<stukreit> Was the unformatted stuff I emailed sufficient? +<alanc> work out even +<agd5f> stukreit: I don't remember seeing that. we need like 4-5 years of history for the form +<stukreit> I'll have to dig thru my email. Does anyone here remember getting these reports from me? +<agd5f> best bet would probably be to forward what you have to Karen and cc me. And she what else she thinks we need +<stukreit> alanc: Perhaps this meeting ought to have a more affirmative roll call +<alanc> stukreit: you mean besides the board members just saying some variant of "hello" at the beggining? +<stukreit> agd5k: ok, will have to search. fyi the firefox I'm running is awefull at search, I'd prefer to do it from my home mac. +<agd5f> stukreit: that's fine +<stukreit> you have a hello from mherrb, agd5f, dberkholtz, alanc, stukreit. +<alanc> yes, and no response from keithp - the other members aren't in the channel at all +<stukreit> sigh, I guess we don't have enough going on. +<agd5f> as to the elections, only mherrb replied to my proposal. Did everyone else on the election committee get it? +<mherrb> since the 2 other members aren't there, don't expect an answer now +<alanc> yeah, other 2 members would be keithp & emmes +<alanc> matthias didn't say how long he would be on vacation, just that he wasn't planning on being near a net connection today +<agd5f> yeah. it'd be nice if they could respond at some point. I've already sent two proposals over the last 2 months, but only mherrb has responded. If you are reading the minutes, the proposed changes are on the election wiki on the board site +<alanc> stukreit: you started saying earlier you wanted to add an item to the agenda - did we cover it already or did you still have something? +<stukreit> It was about the Intel donation. I've tried a few times including phone messages to the Intel person to get confirmation of the funds +<stukreit> I guess I should spend my time working on HSBC to get the security dongle/web access that they promised me months ago +<alanc> the $15k for the XDS2010? would be helpful if keithp was watching this channel +<stukreit> yes +<stukreit> that one +<stukreit> We got as far as them handing me off to their 3rd party bill paying contractor. I really need to bang on HSBC to get web access. +<alanc> okay, so now that I think we've got everything else out of the way, do we want to discuss the repository vandalism that filled the lists since our last meeting? +<mherrb> at some point we should clarify the hosting of the project x.org vs freedesktop.org and so on. but it's difficult without someone really committed to take care of this. +<dberkholz> what clarification is required? +<dberkholz> my understanding of the current status is that fd.o provides hosting for some of the x.org services, and there is some overlap between fd.o administrators and x.org contributors +<alanc> the fd.o admins have also taken over administration of the x.org machines as well I believe +<mherrb> yes. I think this could be stated on the wiki somewhere, may be with some contact information. +<agd5f> not to change the subject, but we really need a postal address for xorg. Something we need to look into at some point. getting a new PO box or some such. +<alanc> I ping tollef now when I see that my board meeting minutes/reminders haven't gone out because mailman has failed again on expo.x.org +<mherrb> there is also still the question of the cost of hosting machines at mit, at least I still don't know how much we're paying and what services we get in exchange. +<alanc> so at some level, the misuse of root on freedesktop.org to disable the commit notifications temporarily is a matter for freedesktop.org to handle, and I believe that currently, fd.o doesn't really have a well-defined governance model, just keithp as occasional ringleader when a figurehead is needed +<dberkholz> maybe it's just me but i tend to see it as an abuse in both roles, fd.o and x.org +<alanc> certainly they took actions as X.org developers that reflected badly on the project and were intended to (and succeeded at) causing turmoil with other developers +<stukreit> Re. MIT Hosting: we paid them $3000 on 3/10/2010 +<alanc> I believe we have one active machine and two gathering dust there +<stukreit> pretty steep cost for that amount of utility. +<alanc> so the question for the board then is if there's any action we should be considering taking - there were some suggestions about transparency and such, though I'm not sure if investigations into compromise/vandalism happen enough to need a formal policy +<mherrb> I was not necessarly thinking of a formal policy. Just trying to honestly describe the non-formal situation and who's doing what. +<dberkholz> that said, is the board even able to take action beyond a note of censure or recommendation? +<alanc> we could also consider something along the lines of a code of conduct (like Ubuntu & other projects have) or a statement of respect (like Jono Bacon's recent efforts) to formalize that trying to piss off other developers is not something developers should do +<alanc> in terms of the specific case, the board can't really dole out punishments - we can expel members, but the death penalty for vandalism seems extreme, and that just keeps them from voting, not participating +<alanc> as far as I know, the board has never gotten involved before in deciding who can and can't have direct git commit access, which is about the only thing we could take away now that they voluntarily gave up root +<mherrb> in this case I don't think any more punishment is needed, but we need to have something in place for the future. +<mherrb> as far as I know, anyone with xorg membership can commit to any of the repositories. Even if git makes recovery possible, brute force vandalism can make it a pita. +<mherrb> and without a minimal rule that legitimates closing the account, whoever decides to close it can be in trouble +<alanc> commit access is regulated by the xorg group on freedesktop.org - I don't think there's any connection to membership in the X.Org Foundation +<mherrb> Yes, sure. the question is more if this group needs to be more formal or not, including its relation with the foundation. +<alanc> but since our hour is almost up, and we're missing almost half the board, perhaps this is where we table this for further thought on what to do better in the future +<stukreit> Suggestion: Assign one person the Access Czar, so that if something wierd happens, that person can act without getting a chorus of who the F. are you? +<alanc> that might be useful anyway, since we also have a bunch of account requests waiting for someone to ack, and no one taking responsibility for them +<alanc> anything else before we adjourn for the day? +<agd5f> problem is not all project on fd.o are directly related to X. but it would probably make sense for X projects +<alanc> right, I was thinking of for handling access to the xorg group (in the /etc/group or LDAP sense), not access to the machines overall +<mherrb> lets continue this discussion in a next meeting. May be it can also be discussed during the election's campaign... +<alanc> okay +<alanc> thanks for coming everyone, see you all in two weeks +<mherrb> Zzz time here. bye. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2010/12-20.mdwn b/BoardOfDirectors/IrcLogs/2010/12-20.mdwn new file mode 100644 index 00000000..c7f26c9e --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2010/12-20.mdwn @@ -0,0 +1,152 @@ + +Date is 2010-12-20, times are UTC+01 +[[!format txt """ +23:03 <alanc> are we getting closer to having an election calendar? +23:03 <alanc> looks like the elections@x.org mailing list got updated today +23:03 <stukreit> hi +23:04 <+Bart_Massey> Sorry I'm late +23:04 <keithp> bart isn't proud -- chatzilla +23:04 <+emmes> yeah +23:04 <+Bart_Massey> seems to work +23:04 <+Bart_Massey> :-)\ +23:05 <+emmes> i mailed to it and daniel noted that he probably shouldn't get the mail ;-) +23:05 <keithp> heh +23:05 <alanc> but at least you got his attention to update it +23:05 <agd5f> keithp: if you are cool with the schedule I sent out, we're ready to go I think +23:07 <agd5f> election-wise +23:07 <keithp> argh. my wiki passwd appears broken +23:10 <keithp> agd5f: schedule looks fine to me +23:10 <agd5f> cool. then were set I think. +23:11 <keithp> excellent! +23:11 <alanc> apologies, I don't have much of an agenda put together today - mostly been concentrating on getting the 7.6 katamari finished (everything's posted to the website, just need long enough between meetings today to write up and send out the announcement) +23:11 <keithp> alanc: the number of commits you've done in the last week... +23:12 <+emmes> agd5f: yeah, looks good. +23:12 <+emmes> i'll try to understand the mysql setup then for dealing with the poll +23:12 <alanc> from what I remember doing it last year it wasn't that hard, but the web ui sucks +23:13 <+emmes> :] +23:13 <+emmes> i have yet to actually find it ;-) +23:13 <agd5f> emmes: cool. thanks. I volunteer to chair the committee and send out the announcements. If there is any task anyone else on the election committee wants let me know +23:15 <+mherrb> I can help proof-reading announcement and such but not much more. +23:15 <agd5f> sounds good +23:16 <+mherrb> Last time I tried to get more people become members by spamming active contributors who were not already members wasn't really successful. +23:16 <+mherrb> So I don't think it's worth to renew the effort. +23:17 <alanc> btw, since I missed even informal roll call - are anholt & dberkholz actually here? +23:17 <agd5f> mherrb: yeah, I think a reminder to xorg ML is enough +23:18 <agd5f> stukreit: any news on the financial info? If you want to forward what you have to karen and cc me, that would be a good start. IIRC, there's some time period you have to apply for 501c3 status after incorporating and if you miss it, the IRC does not look kindly upon it +23:18 <alanc> I have been wondering since our discussion last time if we want to restrict git commit access to members, so we have at least the illusion of a legal agreement in place with committers, even if it isn't much more than a best effort at not contributing encumbered/third-party IP without permission +23:18 <agd5f> s/IRC/IRS/ +23:18 <stukreit> hah +23:19 <keithp> alanc: git commit restrictions would mean having an assigned maintainer for everything +23:19 <stukreit> I'll forward you the short status. +23:20 <alanc> keithp: not necessarily - could still have just as many committers as today, just change the requirements to get commit access from provide keys + get ack to provide keys, get ack, and submit membership form +23:21 <agd5f> stukreit: thanks +23:21 <agd5f> Also, karen strongly recommends we get a postal address for xorg. A PO box would do. thoughts? +23:22 <stukreit> I have no idea. How much responsibility does this entail? +23:22 <keithp> agd5f: I tried a PO box for a while; it timed out... +23:23 <keithp> stukreit: you have to actually go to the post office on a regular basis +23:23 <keithp> some kind of forwarding service wouldn't suck +23:23 <stukreit> who does that anymore? ebay-people? +23:23 <+Bart_Massey> little mall shops +23:23 <+Bart_Massey> names like "mailboxes etc" +23:23 <stukreit> perhaps there's a non-post-office, non-PO box service that does just as nicely. +23:24 <keithp> yeah, would be worth a small amount of money for that +23:24 <agd5f> maybe fedex/kinkos/mailboxes etc has something like that +23:25 <stukreit> the idea being a very lightweight, low-traffic service +23:26 <keithp> yeah, we could pay for 1st class postage for anything delivered +23:26 <alanc> at least in the short term, I suppose having it come to the same zip code as the current treasurer & secretary both work in would make sense, but a forwarding service would allow it to change every term if needed +23:26 <agd5f> anyone want to research that? +23:26 <stukreit> i +23:26 <stukreit> I'm doing it. looking at fedex etc +23:26 <keithp> stukreit: tnx! +23:26 <stukreit> you're off the hook! +23:27 <keithp> My plan didn't work out so well anyway +23:28 <stukreit> keithp: one of these days I'm going to get a solid committment from hsbc to get me online access, I may need you to respond to them. +23:28 <stukreit> did you ever get a security device? +23:28 <keithp> stukreit: yes, I have one +23:29 <keithp> let me know if there's anything I can do to make that work for you +23:29 <stukreit> so, um, you could grab the detailed 5 years of statements that agd says Karen needs? +23:29 <keithp> nope +23:29 <stukreit> :-( +23:30 <keithp> the on-line system provides only 1 year +23:30 <keithp> and I've got all of those +23:30 <stukreit> bofa >> hsbc +23:30 <keithp> well, that should have been obvious +23:30 <agd5f> keithp, stukreit: can xorg reimburse me for the 2009 and 2010 delaware franchise fees ($25/year, $50 total)? I paid with my credit card. I can send you my address +23:30 <stukreit> I'll have to talk to a live droid then +23:30 <keithp> stukreit: good luck +23:31 <keithp> agd5f: yes, we can. stukreit: who should write a check? +23:31 <stukreit> I'll do it. +23:31 <agd5f> thanks +23:31 <stukreit> I have stuff with me today. +23:31 <keithp> sweet! +23:32 * keithp is out shopping and fedexing +23:32 <keithp> charbucks has free wifi these days, fortunately +23:32 * Bart_Massey got thrown out of Fry's for hooliganry +23:34 <+Bart_Massey> other business? +23:35 <stukreit> yas +23:35 <stukreit> yes, about the po box +23:35 <stukreit> explain again why we need a po box and not a residential address? just convenience to the volunteer? +23:36 <stukreit> 'cause I aint movin. ever. +23:36 <keithp> stukreit: yeah, that was my question :-) +23:36 <keithp> stukreit: would mean you'd be stuck getting the mail +23:36 <stukreit> until we changed the address. +23:36 <+Bart_Massey> if you'll be treasurer indefinitely that's great... +23:36 <+Bart_Massey> we hated to presume... :-) +23:37 <+Bart_Massey> if we're going to be changing the address every year or two that's not so good +23:37 <agd5f> stukreit: lots of legal forms require a postal address and SFLC doesn't want to be that address +23:37 <stukreit> even if not a perpetual committment, how is it different than a po address +23:37 <+Bart_Massey> that's why we want a forwarding service +23:37 <agd5f> since they might move or mail might get lost etc +23:37 <stukreit> well, I guess I'd be fine with a 5 year committment. Is that long enough? +23:37 <+Bart_Massey> we can re-aim that as needced\ +23:37 <+emmes> remember we had bad experience with a fixed address before. not implying that this would be the case again, of course. +23:37 <+Bart_Massey> stukreit: sure! +23:37 <agd5f> doesn't have to be a PO box, just a postal address +23:38 <stukreit> I don't recall a bad experience. Was this with Keith's home address? +23:38 <alanc> wasn't the previous fixed address Leon's? +23:38 <+Bart_Massey> emmes: not worried about it +23:38 <+emmes> afaik yes. +23:38 <marcheu> talking about bank & money, did we ever receive the SoC money? I can't access the bank statements but if the money is in there whoever has access to it needs to reimburde SoC travel expenses +23:38 <stukreit> maybe it was a Leon thing, not an address thing +23:39 <+Bart_Massey> If we can guilt stukreit for 5 years of treasurer then i say we do whatever it takes :-) +23:39 <+emmes> of course it was ;-) +23:39 <+anholt> oh, hi. here now. +23:39 <keithp> anholt: strong work +23:39 <stukreit> so, putting a number on it like 5 makes it more approachable. +23:39 <+Bart_Massey> stukreit indeed +23:39 <alanc> or at least 5 years of being the mail service for the treasurer, even if he just forwards the mail once every month or two +23:40 <+Bart_Massey> alanc: ssh! hne +23:40 <+Bart_Massey> he want s +23:40 <stukreit> guess I have to beat on hsbc again. They were so nice on the phone last time, but they sent me the mastercard instead of the dongle +23:40 <+Bart_Massey> 5 years of treasurer :-) +23:41 * Bart_Massey added a lot of accidental CRs and feels a bit silly +23:41 <stukreit> yeah, why not. I'm a good treasurer. I'm tight with money ;-) +23:41 <keithp> stukreit: a mastercard would be useful :-) +23:41 <agd5f> stukreit: are you a masochist? ;) +23:41 <stukreit> guess so +23:41 <+Bart_Massey> saint is the word you're looking for +23:41 <agd5f> right +23:43 <+Bart_Massey> Battery almost gone. Gtg. +23:43 <stukreit> ok. this thread is done. time to work, anyone? +23:43 <keithp> yeah, back to shopping for me +23:43 <+Bart_Massey> Happy Holidays all! +23:43 <agd5f> sounds good +23:43 <alanc> see you all next year +23:43 <+Bart_Massey> indeed +23:43 <keithp> ttfn +23:43 <stukreit> ok have a good one. +23:44 <alanc> our next scheduled meeting should be Jan. 3 +23:44 <marcheu> ahem*soc*ahem :) +23:44 <+emmes> ok,cu all +23:44 <+Bart_Massey> afaik im out of loop this year? +23:44 <alanc> I think that depends on stukreit getting access to check the bank statements +23:44 <stukreit> As treasurer, I have no access to the statements, will make calls now and try again to work it. +23:44 <alanc> stukreit: did you ever confirm the intel $ either? +23:44 <+Bart_Massey> bye! +23:45 <stukreit> nope! +23:45 <agd5f> I though gsoc paid students directly +23:45 <stukreit> keith? any confirmation? +23:45 <marcheu> agd5f: it's reimbursement for mentor travel to the mentor summit +23:45 <alanc> though we can afford to reimburse people first, and make sure google paid up later +23:45 <agd5f> marcheu: ah, right +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/01-03.mdwn b/BoardOfDirectors/IrcLogs/2011/01-03.mdwn new file mode 100644 index 00000000..7b79b10f --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/01-03.mdwn @@ -0,0 +1,77 @@ + +Date is 2011-01-03, times are UTC+01 +[[!format txt """ +22:59 <alanc> good afternoon +22:59 <alanc> and happy new year +22:59 <+mherrb> hi (and best wishes) +23:00 <Bart_Massey> Howdy +23:00 <+emmes> hi +23:00 <agd5f> happy new year +23:01 <+anholt> hello +23:02 <dberkholz|mob> Sorry I'm running a minute late +23:02 <alanc> looks like we're still missing keithp but have everyone else +23:03 <+anholt> keithp is on the way home, unlikely to make it. +23:03 <alanc> you didn't miss anything but hellos and happy new years +23:03 <alanc> so do we have an election calendar yet? +23:04 <+emmes> i think the timetable alex proposed is fine. +23:04 <+emmes> election setup is working. +23:04 <dberkholz|mob> In that case, happy new year =) +23:05 <alanc> so will there be an announcement to the membership soon? +23:05 <agd5f> yeah, I think we are on track for elections. everyone on the election committee signed off on the schedule +23:06 <agd5f> according to the schedule the membership annoucement should go out the 10th, but it should be fine to send it out earlier +23:06 <+emmes> asap when it comes to me ;-) +23:07 <alanc> if you've got a schedule for it next week, that's soon enough for me +23:07 <+emmes> right +23:09 <alanc> so anything else we need to discuss on the elections? +23:09 <agd5f> I think we are all set +23:09 <+anholt> member app queue is flushed. +23:10 <alanc> if not, how about 501(c)3 stuff? I saw mail from Stuart & Keith about trying to get the 5 years worth of bank records required +23:10 <stukreit1> hi, yes. Keith said he was going to traipse over to the local HSBC location +23:11 <stukreit1> He needs to visit them in-person to effect the permissions I need to do the other stuff +23:13 <Bart_Massey> ... +23:13 <stukreit1> That act is necc so he can let me take responsibility for the other requests that he wants to avoid messing with +23:14 <stukreit1> And we are re-attempting to reimburse the guy who was in Russia, now in Finland. (I'm expecting that check in the mail) +23:15 <stukreit1> that's about it. +23:16 <alanc> there was a brief mention last time of reimbursing the Google Summer of Code mentor summit attendees without waiting to see if google's check had cleared yet, since the foundation can afford to wait for google funds to arrive more than the individuals can +23:16 <alanc> are we still waiting on that or have those people (marcheau & dberkholz?) been paid yet? +23:16 <stukreit1> If you guys want to do that, someone email me the name/address/ amount/ brief explanation of work or materials involved +23:17 <dberkholz|mob> That would be nice. fwiw, gentoo does the same +23:17 <Bart_Massey> Who are the attendees? I'm good due to PSU... +23:17 <dberkholz|mob> Corbin and me +23:17 <agd5f> stukreit1: have you or keithp sent me a check yet for the delaware franchise fees? +23:17 <Bart_Massey> Check +23:18 <stukreit1> My stuff is in the mail to keith. I just sent him a ping. +23:18 <alanc> I vote to go ahead and reimburse those two for the mentor summit travel expenses in advance of google's reimbursement to the foundation clearing +23:19 <stukreit1> I hope you all understand we have this cumbersome dual-signing system. One of Keith/I writes the check, sends it to the other, signs again, then sends it to the recepiant +23:19 <Bart_Massey> +1 +23:19 <+anholt> +1 +23:19 <+mherrb> +1 +23:19 <Bart_Massey> But you're fixing that.. +23:19 <agd5f> +1 +23:19 <stukreit1> someday... +23:19 <dberkholz|mob> +1 +23:20 <+emmes> +1 +23:20 <Bart_Massey> Why not now? +23:21 <stukreit1> Keith has to make that visit to gain me internet access to the accounts. +23:21 <Bart_Massey> Right. Then we can fix it? +23:22 <Bart_Massey> I will go with Keithp this week. +23:22 <stukreit1> we've been messing with this a long time .At one point, I had a call into HSBC where the person said he would do it and send me the security dongle, then months passed +23:22 <Bart_Massey> Sigh +23:22 <stukreit1> and the last time I talked to them, in December, they said that Keith had to do it in person. +23:23 <Bart_Massey> 'K will do +23:23 <dberkholz|mob> Banking and elections, the eternal plagues of foss foundations... +23:23 <+anholt> stukreit1: so if I hear you right, a single person has to make the request to disable the double-signature system? :) +23:23 <stukreit1> I have this kind of crap going on with another personal brokerage account. They don't realize that as soon as I get it straightened out I'm gonna swoosh my funds into a moderm firm +23:23 <Bart_Massey> Gtg later all! +23:24 <stukreit1> no. I don't know how to disable the double signing yet +23:24 <+anholt> ah +23:24 <stukreit1> i'm just trying to get at the 5 year history. +23:24 <stukreit1> and then, emboldened, take it from there +23:25 <stukreit1> If I can't get internet access, I certainly can't do more ambitious stuff, like the dual signing. and Also +23:25 <stukreit1> like taking Leon's name off the account. +23:27 <alanc> anything else I've forgotten we need to talk about today? +23:30 <+mherrb> I dont see anything else +23:31 <+emmes> nothing from my side +23:31 <agd5f> nothing here +23:32 <alanc> well, then thanks to everyone for coming, and will see you all on Jan. 17 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/01-31.mdwn b/BoardOfDirectors/IrcLogs/2011/01-31.mdwn new file mode 100644 index 00000000..ad1efe72 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/01-31.mdwn @@ -0,0 +1,170 @@ + +Date is 2011-01-31, times are UTC+01. +[[!format txt """ +23:00 <+alanc> good afternoon +23:01 <+alanc> sounded like keithp might be midair today coming back from LCA - not sure if anyone else was down there +23:01 <+mherrb> hi +23:02 <agd5f> hello +23:06 <+alanc> so I see our election calendar is underway +23:06 <+alanc> nomination period ends in a few hours? +23:06 <+mherrb> less than 2 +23:07 <agd5f> yeah, probably have to extend it since we only have 2 so far +23:07 <+alanc> our current board members aren't all rushing to sign up for another two years? +23:07 <+emmes> apparently no +23:08 <+emmes> we do have more nominees, but they didn't react yet. +23:08 <+emmes> we don't have too many nominees, though (i think 6 all in all?) +23:09 <+keithp> alanc: managed to catch an earlier flight from LAX, but not very awake +23:11 <+dberkholz> i haven't been able to give the board the effort it deserves, so i don't plan on running again. although i think i only ran last time to maintain a bit more cluefulness than some other candidates. +23:12 <+alanc> bart & anholt are the other members with expiring terms +23:12 <+alanc> neither of whom are here to poke +23:14 <stukreit> um, it looks like I just got iced +23:14 <+alanc> so are you going to set a new nomination deadline now or discuss via e-mail among the election committee and let us know? +23:15 <agd5f> I guess we shoulf just extend it a week +23:15 <+emmes> i would be +1 for an additional week +23:15 <+mherrb> +1 for an additional week too. +23:15 <+emmes> Bart_Massey: don't plan to be nominated again? +23:15 <agd5f> ok, I'll send out the email and update the schedule on the internal election site +23:16 <+emmes> we're running out of candidates ;-) +23:16 <Bart_Massey> I'll run if you really need me to. +23:16 <Bart_Massey> I feel like I haven't contributed much lately, though. +23:16 <Bart_Massey> When are nominations due? +23:16 <+emmes> 1 1/2 hours +23:16 <+emmes> ;-) +23:16 <agd5f> Bart_Massey: was today, but now a week from today +23:17 <+dberkholz> has anyone considered shrinking the board instead? +23:17 <Bart_Massey> (Sorry for my extreme lateness--class ran long.) +23:17 <Bart_Massey> dberkholz: We could; I'm not sure whether it would produce more or less work, though. +23:18 <Bart_Massey> How many *qualified* candidates do we currently have? +23:18 <+emmes> dberkholz: if you want to continue to have elections split (which is good IMHO), less than 8 might be problematic. We could go with 6, but not much less. +23:18 <+emmes> currently we have Alan and Tiego. A number of additional nominees, which haven't answered yet. +23:18 <agd5f> Bart_Massey: we have two at the moment who want to run +23:19 <Bart_Massey> There are advantages and disadvantages to split elections; doing the work once every other year would sure be nice. +23:19 <Bart_Massey> Sounds like I better run. +23:19 <stukreit> 1 warm body here +23:19 <Bart_Massey> Can I officially nominate myself here? +23:19 <agd5f> Bart_Massey: sure +23:19 <Bart_Massey> OK, I nominate myself and Stuart. Stuart, do you accept? +23:20 <stukreit> sure, I got a notice a few minutes ago. +23:20 <+emmes> if you want your personal statement changed from last time, you'll have to send a mail still :-] +23:20 <agd5f> Bart_Massey: You and stuart have already been nominated +23:20 <Bart_Massey> Cool. I'll send an updated statement right after the meeting. +23:21 <+emmes> That makes 4. Still I suggest to extend the period, having 4 candidates for 4 seats is... not satisfying. +23:21 <+dberkholz> saves all the trouble of a vote +23:21 <Bart_Massey> Yes, that seems reasonable. +23:21 <Bart_Massey> dberkholz: good point +23:22 <+emmes> :-/ +23:22 <+alanc> I don't remember if the bylaws require us to still have a vote if there are only 4 nominees or not +23:22 <+emmes> i don't think this special case is handled. +23:22 <stukreit> so you could play it either way: enforce the deadline, save the vote effort, or extend the deadline, have a vote. +23:22 <Bart_Massey> lol. I don't recall that they state anything about that case, or the case of less than four nominees, which would be even more trouble. +23:22 <Bart_Massey> I'd say extend the deadline; we don't want to be accused of skulduggery by the community. +23:23 <Bart_Massey> But I'm fine either way. +23:23 <+emmes> +1 definitely +23:23 <agd5f> yeah, another week won't hurt +23:23 <+alanc> well, it looks like 3 of the 4 election committee members voted to extend a few minutes ago +23:23 <Bart_Massey> OK. Done. +23:24 <+alanc> anything else we need to discuss on the elections? +23:24 <+emmes> not from my side +23:24 <+alanc> if not, progress on the banking situation & 501(c)3 financial reports? +23:24 <agd5f> keithp, stukreit: how goes the bank stuff? +23:24 <stukreit> I got a package from keith +23:25 <stukreit> sent out most of the checks +23:25 <stukreit> (what method should I use for Gusarov?) +23:25 <stukreit> and am in process to getting the account access fixed +23:25 <+keithp> stukreit: he's in Norway now; regular post should work fine +23:26 <+dberkholz> it would be really nice if i could get my check by feb 14 or so, to avoid another interest payment.. +23:26 <stukreit> So I'll hand carry it to the post office and get their packing +23:26 <stukreit> its in the mail +23:26 <+dberkholz> good to hear +23:28 <stukreit> soo, the bank stuff is moving. I'll email the board when I make the milestone of seeing the accounts. +23:28 <+alanc> so still can't do the 5 year statements? +23:29 <stukreit> i have never seen a statement or the online data. that's the security dongle thing which needed Keith's push. +23:30 <stukreit> btw keith, nice passport pix ;-) +23:30 <+alanc> oh, I see that the two-signature thing for checks is mandated in the bylaws +23:31 <+keithp> stukreit: passport pix? +23:31 <Bart_Massey> alanc: We should amend the bylaws; that was a mistake +23:31 <Bart_Massey> Bleah +23:31 <Bart_Massey> Unfortunately, amending the bylaws requires a vote of the membership IIRC? +23:31 <stukreit> you sent me a copy of your passport with a kind of notary stamp, signed by Julie +23:32 <stukreit> (same name on bsnss card) +23:32 <stukreit> And the app form says we are electing "single control" which sounds like single signer to me. +23:33 <+alanc> Bart_Massey: yes, a vote of the members, with 2/3rds required to pass +23:33 <Bart_Massey> Yes, single signer is what we want. +23:33 <Bart_Massey> It's way past time for someone to revise the Bylaws and put the whole thing up. +23:33 <Bart_Massey> Anyone want to volunteer on a first pass? +23:34 <Bart_Massey> If we did this right, we could run the Bylaws vote at the same time as the Board vote, I think? +23:34 <+alanc> don't see any special case for skipping voting - looks like if we have more than 2 vacancies out of 8, we must hold special elections until we fill them, but if it's only one or two we have some discretion to not fill until the next election cycle +23:34 <+emmes> possible +23:34 <stukreit> Also, I'm lowering all spender limits to $25k. eg the default wire limit is $250k. I don't think we want that. If some conference bill looks huge, the board should be aware that it needs to be split into <$25k increments +23:34 <agd5f> 2/3 of the members or 2/3 of voters? +23:35 <agd5f> I'm not sure what our voter turnout normally is... +23:35 <+alanc> oh, wait, no, only 1 lets us get by: "If at any time, subject to the limits in 4.4.(i), there exists two (2) or more vacancies of Director positions on the Board, a Special Election shall be held." +23:35 <+alanc> "two-thirds majority vote of the Members" +23:35 <+emmes> stukreit: right, $250 is *way* too high +23:36 <Bart_Massey> Really ambiguous wording about majority. +23:36 <+emmes> also something to fix +23:36 <Bart_Massey> I'd prefer to interpret that as two-thirds of voters, and yes, let's clarify it. +23:36 <+alanc> the previous section says "majority of all eligible votes cast" for normal votes +23:36 <Bart_Massey> Perfect, so this interpretation makes sense. +23:37 <stukreit> I could set it to anything you want. It might be handy if the board needs a goodwill bullet someday +23:37 <+alanc> does anyone have the original editable document form of the bylaws? all I see on the wiki is the pdf +23:37 <Bart_Massey> It's possible Egbert has the only other softcopy. +23:37 <Bart_Massey> I'm pretty sure I never did. +23:37 <+emmes> i'll ask him +23:39 <+alanc> weren't there some things our SFLC lawyer said we needed to fix for 501(c)3 status in our bylaws anyway? +23:40 <agd5f> we had to fix the website to not say we are a 501c3 until we actually are +23:40 <agd5f> I don't recall any bylaw changes off hand, but I'll have to check my notes +23:42 <agd5f> I don't see anything in my notes +23:44 <Bart_Massey> It would be easy enough to bug them. +23:44 <+alanc> should probably ask if they'll review anyway, to make sure we don't screw something up - not sure if there's really time for much revision in 2 weeks if we're going to have elections then +23:44 <Bart_Massey> Have we written them a check yet? We've voted to twice now... :-) +23:44 <agd5f> Karen did recommend we get a real address at some point, but I think the bylaws are ok from the 501c3 perspective +23:45 <Bart_Massey> Revision should be quick, and mostly procedural. +23:45 <+alanc> we have a real address, as long as Stuart doesn't move +23:45 <Bart_Massey> We know of two changes we want to make, we just need to scan the Bylaws for others. +23:45 <Bart_Massey> If it's big or controversial, skip it for now. +23:45 <+alanc> stukreit: did you ever send on a check for SFLC? +23:45 <+alanc> (Software Freedom Law Center) +23:46 <stukreit> no.. I think I have to send it to agd? +23:46 <Bart_Massey> For example, I'd like to officially ratify our current practice of holding elections in February for the previous year's new Board Members. :-) +23:46 <stukreit> agd: is this the fee you paid them? +23:46 <agd5f> I paid the delaware fees +23:46 <+alanc> not the $50 he was paying to the state of Delaware - SFLC was a few thousand dollars to be paid directly +23:46 <stukreit> so I do not know this number +23:47 <agd5f> we had talked about donating to SLFC +23:47 <+alanc> I'll have to go back in the minutes to see what amount we approved +23:47 <Bart_Massey> I think the Bylaws are ambiguous about election timing... +23:47 <stukreit> i think it would be good process for someone representing the board to send me some kind of order to pay this. +23:47 <Bart_Massey> IIRC it was $7500, but we should check +23:47 <stukreit> so I can file it +23:47 <+alanc> also, was just reminded that Google announced SoC 2011 last week - is marcheu going to admin for us again this year or do we need to find another? +23:47 <Bart_Massey> stukreit: Makes sense +23:48 <+alanc> stukreit: I'll send mail once I find the minutes +23:48 <Bart_Massey> Go marcheu! +23:48 <Bart_Massey> You were great last year. +23:48 <marcheu> sure I can do it +23:48 <Bart_Massey> Thanks! +23:48 <+alanc> Sounds good +23:48 <+mherrb> yes +23:49 <agd5f> karen said we also owe like ~$2000 in back taxes for the old xorg corp +23:49 <Bart_Massey> Need to get that paid ASAP... +23:50 <+dberkholz> oh yeah, alanc -- i was going to mention the gsoc thing +23:50 <+dberkholz> people should start thinking about project ideas +23:50 <stukreit> do we have an accountant to nail that tax figure down? +23:50 <stukreit> dammit Jim, I'm a treasurer, not an accountant! +23:50 <agd5f> stukreit: karen has the exact numbers, but 501c3 is more important time-wise +23:50 <+alanc> well, it was mherrb's update to http://wiki.x.org/wiki/SummerOfCodeIdeas that had just reminded me +23:51 <+alanc> so yes, more people should go forth and update that wiki +23:53 <+alanc> so anything else to discuss today? +23:54 <agd5f> nothing here +23:54 <+alanc> I assume we'll see email soon about the extended nominations deadline from the elections committee, and from marcheu to start beating the SoC drums around project ideas/potential mentors/etc. +23:54 <+emmes> marcheu: thanks a lot in advance! +23:54 <stukreit> before you go, what is the number for sflc contrib? +23:54 <+mherrb> I'm going to fosdem next weekend even if there's no X.Org devroom. will meet at least Luc and Egbert there... +23:55 <+alanc> stukreit: I have to look that up still +23:55 <Bart_Massey> Thanks all! -oo +23:56 <+alanc> thanks everyone, see you in two weeks +23:59 <agd5f> I updated the internal calendar +23:59 <agd5f> I'll send out the email shortly +00:05 <+mherrb> bye +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/02-14.mdwn b/BoardOfDirectors/IrcLogs/2011/02-14.mdwn new file mode 100644 index 00000000..b03ccb6e --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/02-14.mdwn @@ -0,0 +1,137 @@ + +Date is 2011-02-14, times are UTC+01. +[[!format txt """ +23:02 <+alanc> good afternoon +23:02 <+mherrb> hi +23:03 <omcfadde> hello +23:04 <+anholt> hi +23:04 <+alanc> any other board members here? dberkholz ? keithp ? agd5f ? +23:04 <+anholt> keithp is off in a meeting +23:04 <+anholt> likely back soon +23:05 <agd5f> hello +23:05 <+alanc> okay, that makes 4 members present +23:06 <+alanc> and maybe a treasurer if I poke stukreit +23:07 <+alanc> so the first item on the agenda was election status - I saw the announcement this morning with 6 candidates +23:08 <+alanc> is there anything else to report or discuss? +23:08 <keithp> and now I have to head home +23:08 <keithp> change in after school schedule +23:08 <agd5f> any news on the hsbc stuff? the deadline for the 501c3 stuff is like march I think +23:11 <stukreit> hi. Last week I sent on my contact with the rep in Portland +23:11 <stukreit> .. +23:12 <stukreit> that I got her on the phone and she gave the application a nudge, so they emailed me a PIN number and still have to mail the electronic security device. +23:13 <stukreit> so, yes, "any day now", "the dongle is in the mail" +23:15 <stukreit> too bad they don't have it in a smartphone app. +23:16 <omcfadde> I'm assuming it's something like a SecurID. I guess having it as software would make it much easier to disassemble. +23:17 <+alanc> so the other thing we'd discussed last time regarding elections & the bank account was changing the bylaws to allow single-signer checks +23:17 <+dberkholz> woops. lost track of this window +23:17 <stukreit> anyway, I did nudge her that I have a deadline to make, which caused her to make a phone call, which caused an email to arrive right then. +23:17 <+alanc> I saw today we had e-mail pointing us to the .odt's for the bylaws - I know Bart had other things he wanted to change but isn't here today +23:18 <stukreit> eg the issue of allowing a single signature for the banking, which we're doing anyway +23:20 <+alanc> did anyone else want to try getting bylaw changes done in time for this election? seems like we'd be rushing to make it +23:21 <+alanc> election starts in 7 days, and runs for 7 days +23:22 <agd5f> alanc: what's involved in changing a bylaw? +23:22 <omcfadde> is voting done via these meetings, or members.x.org? +23:22 <+alanc> voting for the new board will be done on the website, via secret ballot, not irc +23:22 <omcfadde> I see. thanks for the clarification. +23:22 <+mherrb> I won't mind if we postpone this until a new proposition is really ready. no need to rush imho. +23:23 <Bart_Massey> As always, apologies for my lateness. I teach a class that comes right up to meeting time, so I tend to run over sometimes. +23:26 <+alanc> if I read the current bylaws correctly, we have to provide the amendments at least 72-hours before calling for a vote, and then need a 2/3rds majority of members to vote in favor +23:27 <+alanc> but that's assuming the online election counts as our "annual meeting" +23:28 <Bart_Massey> Sadly, I doubt the online election can count. +23:29 <+alanc> Bart_Massey: before you came in we were discussing if it was practical to have bylaw amendments ready to be voted on when the election is only 7 days away +23:29 <Bart_Massey> Probably not. Can you folks hear me at all? +23:29 <agd5f> Bart_Massey: yes +23:29 <Bart_Massey> Excellent. +23:29 <Bart_Massey> I've lost my nickserv password :-) +23:30 <+anholt> alanc: we've generally considered the xds/xdc the annual meeting +23:30 <Bart_Massey> Indeed. +23:30 <+mherrb> I don't see where article 7 says the vote has to take place during the annual meeting. +23:30 <Bart_Massey> I'd say try to get stuff ready for there. +23:30 <Bart_Massey> That's a more realistic time scale anyhow, IMHO. +23:30 <Bart_Massey> And more likely to be a reasonable crowd in some ways. :-) +23:31 <+alanc> mherrb: no it doesn't seem to, I was up on 3.9 where it talks about conduct of meetings +23:32 <+alanc> so consensus seems to be to have the new board work on bylaw amendments for a later vote, not next weeks? +23:32 <Bart_Massey> +1 +23:32 <+mherrb> +1 +23:33 <agd5f> either way works for me, as long as I don't have to draft it ;) +23:34 <omcfadde> +1 (I would say it's too short of a timeframe, with the board elections being at the same time) +23:34 <+alanc> okay, next item I had on the agenda was the SFLC donation - when I went back through our archives to find the amount for stuart, I found we'd discussed it and tabled it for later, and never came back to select a final number and vote on it +23:34 <agd5f> +1 +23:35 * alanc clearly needs to keep better track of agenda items we table +23:35 <+dberkholz> could they or did they suggest a reasonable number? +23:35 <+dberkholz> we're just picking one out of the air +23:37 <Bart_Massey> Naw, we picked a number at one point. Apparently lost. +23:37 <Bart_Massey> After some investigation, I think we recommended $7500. +23:37 <Bart_Massey> Much of the Board wanted to do $5000, which is also fine with me. +23:37 <Bart_Massey> I wanted to do $10000. :-) +23:37 <+dberkholz> perhaps that's before their people spent lots more time working on our stuff =) +23:37 <Bart_Massey> Anyway, let's just pick a number and get this thing going. +23:38 <+dberkholz> would it be reasonable to set up an annual pledge of a smaller amount instead of a one-time donation, so it's more predictable for them? +23:38 <agd5f> $7500 seems good to me +23:38 <Bart_Massey> dberkholz: we might want to do that *also*. +23:38 <Bart_Massey> Maybe $1000 +23:38 <+dberkholz> 7500 to start and then 2k/yr ongoing or so? +23:38 <Bart_Massey> Sure. +23:38 <agd5f> +1 +23:38 <Bart_Massey> +1 +23:39 <+mherrb> +1 +23:39 <+dberkholz> alanc? +23:39 <+alanc> +1 +23:39 <omcfadde> +1 +23:40 <+alanc> anholt want to vote? +23:40 <omcfadde> off topic: seem to be having some weird troubles with my connection (at least new http connections won't work); so if I drop, that's probably why. +23:41 <+alanc> I'm assuming emmes isn't actually around since he's been quiet +23:41 <+anholt> +1 +23:42 <+alanc> okay, will have stuart cut a check +23:43 <+alanc> only other thing I had on the agenda was Moving expo.x.org to PSU, ending MIT hosting +23:43 <+alanc> discussion on the board mailing list seemed to be in favor +23:43 <Bart_Massey> +1 +23:43 <agd5f> +1 +23:43 <+mherrb> +1 +23:43 <+alanc> and while I'm sad we never got much use out of the Sun-donated machines, I also don't think that 6-year old hardware is worth spending much on today +23:44 <+alanc> so +1 +23:45 <+mherrb> v20z/v40z where great machines but too loud :) +23:45 <omcfadde> I don't really have an opinion on this matter, but afaik everything else is hosted at PSU +23:45 <omcfadde> so +1 also +23:45 <Bart_Massey> We are putting a machine in at OSU for redundancy +23:45 <omcfadde> of course I don't know much about the network config e.g. backup dns servers... +23:46 <Bart_Massey> Keithp has started that negotiation already. +23:46 <+alanc> mherrb: that's why you put them in machine rooms, not on your desk +23:47 * alanc is only counting the votes from the current board members, not the general agreement from our general membership, though it's nice to know our members agree with us +23:47 <omcfadde> alanc: yes, sorry. marcheu just informed me about the voting. +23:47 <omcfadde> I'll shutup now :) +23:47 <Bart_Massey> no prob. :-) +23:48 <+alanc> it's okay, enthusiam and interest is a good thing +23:48 <+dberkholz> no need to shut up, just avoid the +1's =) +23:48 <omcfadde> ok +23:49 <+alanc> anything else we want to talk about today? our next meeting should be the day the election closes +23:49 <Bart_Massey> How many candidates did we get? +23:49 <+alanc> 6 +23:49 <agd5f> 6 +23:49 <Bart_Massey> Cool. +23:49 <+alanc> candidate statements mailed out this morning +23:49 <Bart_Massey> Nice. Thanks much to the elections cmte. +23:53 <+dberkholz> i've gotta run now +23:53 <+alanc> think it was 3 of our incumbents running for re-election, 2 former board members running to return, and 1 new candidate +23:53 <Bart_Massey> cool +23:53 <+alanc> though we may have to do the intel shuffle again +23:53 <Bart_Massey> :-( +23:54 <agd5f> http://foundation.x.org/pipermail/members/2011-February/000622.html +23:54 <Bart_Massey> Should we bump the Intel limit by 1 in the bylaws changes ? +23:54 <+alanc> (1 intel employee already on the board, 2 running for election, maximum of 2 allowed to serve) +23:54 <+anholt> I don't think we have any complaints about the limits as they are +23:54 <Bart_Massey> I'm sure. :-) +23:54 <Bart_Massey> I was thinking more of the rest of us. :-) +23:55 <+alanc> if we're keeping the board size at 8, 3 is still too small to be a majority of the membership, though it could be a majority of quorum at any given meeting +23:55 <Bart_Massey> If Intel's X developer hiring quest continues apace, most of you will be able to weasel out. :-) +23:55 <Bart_Massey> alanc: yes, that's what I was thinking. +23:56 <Bart_Massey> Anyway, if we propose the amendments separately the membership could weigh in here. +23:56 <Bart_Massey> I think it's worth at least proposing. +23:58 <Bart_Massey> motion to adjourn. +23:59 <agd5f> +1 +23:59 <+mherrb> +1 Zzz +23:59 <+anholt> +1 +23:59 <+alanc> see you all on Feb. 28 +23:59 <+alanc> which I guess will be the final meeting of the current board +00:00 <+alanc> oh, I and I need to remind Stuart & I to get to work on the annual reports of the secretary & treasurer that are due 60 days after the end of the year +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/02-28.mdwn b/BoardOfDirectors/IrcLogs/2011/02-28.mdwn new file mode 100644 index 00000000..bf044c13 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/02-28.mdwn @@ -0,0 +1,144 @@ + +Date is 2011-02-28, times are UTC+01. +[[!format txt """ +23:00 <+alanc> good afternoon +23:00 <+emmes> he +23:00 <+mherrb> hi +23:01 <+Bart_Massey> howdy +23:01 <agd5f> hello +23:01 <+dberkholz> hi +23:01 <+alanc> 2 hours left in the election +23:02 <+Bart_Massey> cool +23:02 <+dberkholz> i'm attempting to vote now. +23:02 <+dberkholz> searching for my password recovery email +23:02 <+alanc> I have to reset it every year since it won't let you choose your password, just forces a random string on you +23:03 <+dberkholz> hm. i found an old one now, but my new one still hasn't shown up. +23:03 <+alanc> seems to be going smoothly so far - anything the election committee needs to report? +23:04 * alanc saw mixed response to the candidate questionairre, and little followon discussion this year +23:04 <agd5f> alanc: all seems well +23:04 <+emmes> i have nothing (unusual) to report +23:04 <+keithp> hey, I get 30 minutes here today +23:04 <+Bart_Massey> I filled out all the responses for the questionnaire, and then didn't send them. +23:05 <+emmes> Bart_Massey: evil you!!1 +23:05 <+emmes> seriously, answers from more candidates have been missed :-( +23:05 <+Bart_Massey> It seemed like the whole thing was more intended to start an argument than to help with the process +23:06 <+Bart_Massey> I guess it was Luc publically trashing Eric for one of his answers that got me +23:06 <+emmes> so again, special thanks to Alan, Eric, and Tiago! +23:06 <+alanc> it did seem biased towards things Luc complains about and few other voters ever seem to pay attention to +23:06 <+dberkholz> sometimes i wonder if we should have a code of conduct like some other projects +23:06 <+emmes> partially, you're right, of course. still many questions were reasonable. too many, though. +23:06 <+Bart_Massey> I decided that nothing I could say was likely to (a) distinguish myself from the other candidates, or (b) change anyone's opinion +23:07 <stukreit> I felt that the questions were so coerced that answering them would only tangle things up. +23:07 <+emmes> please also consider that not *only* Luc contributed questions ;) +23:07 <+Bart_Massey> dberkholz: I don't think Luc crossed any code-of-conduct lines in that discussion, though +23:07 <+Bart_Massey> emmes: Yeah, last year when the questions went direct from the askers to the list it worked better. +23:07 <+emmes> Bart_Massey: there was one exception. /me thinks. +23:07 <+alanc> dberkholz: I thought about that after the radeonhd git incident last year - perhaps something for the next board to consider with the perspective of distance from the hot arguments there +23:08 <+emmes> Bart_Massey: we didn't have q&a last year +23:08 <+Bart_Massey> IIRC we did, it was just informal +23:08 <+Bart_Massey> Certainly did two years ago when I ran last. +23:08 <+dberkholz> is the password recovery working at the moment? +23:08 <+Bart_Massey> Some people asked the candidates questions on the list, and some of us answered them. +23:08 <+dberkholz> i'm still waiting for an email +23:09 <+emmes> I was asked by several (well, 2) people when I was voted why there wasn't a q&a... +23:09 <stukreit> keith: what State is the LLC registered in? +23:09 <+Bart_Massey> Shall I find a student to completely rewrite the webapp? +23:09 <+keithp> stukreit: delaware, of course +23:09 <+Bart_Massey> Can I pay them via VoC? +23:09 <+emmes> Bart_Massey: sounds like a good idea IMHO. it can't get much worse. +23:10 <+dberkholz> could do gsoc, since it is part of x.org and there seems to be more of a shortage of students than obtainable slots +23:10 <stukreit> I'm on the phone with them to transfer our main branch from Madison ave, nyc to University ave, palo alto +23:10 <+dberkholz> on a related note, gsoc applications opened today for organizations, and the deadline's march 11 +23:10 <+alanc> dberkholz: would it be going to an old e-mail address? I don't have admin access at the moment to check +23:10 <+Bart_Massey> I'm fine either way, but I thought that as a not-very-x-related activity it might be appropriate to fund it ourselves +23:11 <+dberkholz> alanc: doubt it, my ones from 2008 and onwards went to the same place +23:11 <+Bart_Massey> if you know what I mean +23:11 <+Bart_Massey> I'll check; sec +23:11 <+dberkholz> doesn't debian or some other org already have something? +23:11 <+alanc> I'm also not sure if it's a summer-long full-time job +23:11 <+mherrb> and aren't there already enough polling applications around? +23:12 <+Bart_Massey> Sorry; looks like I lost the admin bit when I lost the election bit +23:12 <+emmes> yeah, adapting one of them for our purposes is probably more reasonable. but somebody would have to do that... +23:12 <+alanc> yeah, seems like one of the many other membership based open source orgs like debian, gentoo, gnome, etc. would have something we could use +23:12 <+Bart_Massey> Yeah, we can probably cobble together out of existing pieces +23:13 <+Bart_Massey> Or reuse something or something +23:13 <+Bart_Massey> It doesn't need to do that much +23:13 <+Bart_Massey> I could probably do the whole thing myself in Drupal +23:13 <+Bart_Massey> Shall I put up a prototype at some point? +23:14 <+dberkholz> gentoo's app requires logging into systems and running command-line apps +23:14 <+dberkholz> i bet debian does something with gpg-signed email +23:15 <+alanc> the one opensolaris used required ssh'ing to a system with your shell set to a python based voting app +23:15 <stukreit> maybe I'm not changing the branch. They just dropped me off hold +23:16 <+Bart_Massey> There's a very nice-looking Drupal module that already does Borda Count +23:16 <+Bart_Massey> I could literally have a prototype up in a couple of hours +23:16 <+dberkholz> condorcet is where it's at. +23:16 <+Bart_Massey> We're Borda Count +23:16 <+Bart_Massey> It's better +23:16 <+Bart_Massey> for what we do +23:17 <+Bart_Massey> Regardless, I think it's in the Bylaws +23:17 <+alanc> Bart_Massey: well, if you've got a few hours, seems worth trying out in time to decide for next year's election +23:17 <+alanc> can't be too much worse than what we've got +23:17 <+Bart_Massey> 'K, I'll give it a shot at some point. Bug me if you don't hear from me on it. +23:18 <+alanc> stukreit: anything else to report treasurer-wise? +23:18 <stukreit> yes. I have the security device and have setup web access +23:19 <+alanc> does that give what you need to finish the 501(c)3 reports? +23:19 <stukreit> The main task we're sitting on is the 5 years of statements, which has to be requested to the branch +23:19 <stukreit> so, I'm changing the branch to palo alto, but if it takes a week (like everything with them) +23:19 <+alanc> ah, and that's presumably easier for you to do at the Palo Alto branch than the Manhattan branch? +23:19 <stukreit> I'll try to work with the nyc branch by phone +23:20 <stukreit> I would love to go to the manhattan branch. +23:20 <stukreit> I'd have lunch with my kid. +23:21 <stukreit> but I think walking into a local branch is better than working the 800 numbers and phone hell. That has proven to be not-effective to the extreme +23:21 <+alanc> still, flying you to New York to visit our branch in person seems rather technologically backwards +23:22 <+emmes> very +23:22 <+alanc> anything else to report on the 501(c)3? just waiting on financial records? +23:23 <stukreit> phones, email, and web access is not backwards, but they are ineffective with this company +23:23 <+Bart_Massey> stukreit, keithp: can you folks send a check to SFLC now? +23:23 <stukreit> uh, ok? what's the name and amount? +23:23 <+Bart_Massey> $7500 as per the last meeting minutes +23:24 <+Bart_Massey> Software Freedom Law Center +23:24 <stukreit> I think I can send it directly without a 2nd sig. +23:24 <+dberkholz> we agreed last meeting that we'd send a 7500 one-time check with 2000/yr follow-ups +23:24 <+keithp> stukreit: is the account all fixed now? +23:24 <stukreit> maybe. ha ha ha +23:25 <+Bart_Massey> sadly, have to run rsn. other business? +23:25 <stukreit> Its scary working with hsbc. When you type your name and address, they forcibly uppercase each field. +23:25 <+dberkholz> hmm. still waiting on a password reset. wonder if anyone else is trying to vote today. +23:25 <+keithp> JUST DON'T TRY TO HAVE A DOT IN YOUR NAME +23:25 <stukreit> I have a dot in my email address. sigh +23:26 <+Bart_Massey> Can someone with admin privs on the site check dberkholz' email address and/or reset his pw? +23:26 <+Bart_Massey> I apparently don't anymore +23:26 <+emmes> keithp: my login is matthias.hopf , so it includes a dot... +23:26 <+alanc> I don't have anything else we need to discuss today. I'm assuming the next board meeting will be on the same schedule for now, and the new board members can discuss then what ongoing schedule works best for them +23:26 <+Bart_Massey> Sounds good. Bye all! +23:27 <+emmes> right +23:27 <agd5f> oh, we have to certify the results at some point +23:27 <+dberkholz> preferably at some point after voting ends =) +23:27 <+emmes> actually, before next monday, because they are supposed to be presented to the outside world then +23:27 <agd5f> right, but does anyone know what needs to be done to "certify" them? +23:28 <+alanc> I know the members.x.org site lies to me claiming my login should be first.last, but somehow it's always been a.coopersmith +23:28 <+emmes> good question :-) +23:28 <+anholt> sorry for the delayed join, I chose the wrong wifi option on the phone and got no network :/ +23:28 <+emmes> I assume this means at least two people staring at the numbers and agreeing on seeing the same numbers :-] +23:28 <+alanc> I don't remember if we'd done anything in the past beyond that +23:28 <+dberkholz> alanc: re username, mine is definitely right. i get a different error message w/ wrong password vs wrong username +23:29 <+alanc> may also have to kick the mail daemon on expo, since it likes to die - anholt or Mithrandir may be able to help there +23:30 <+alanc> (for anholt: dberkholz isn't getting his members.x.org password reset mail so he can vote in the 1.5 hours left in this election) +23:30 <+alanc> I suppose certifying also includes verifying that the results you announce aren't going to put 3 intel people on the board +23:30 <stukreit> anholt: m.x.o doesn't know me at all. +23:31 <+anholt> I will warn *: I have no clue about mail in general, and even less about mail on expo +23:31 <+alanc> strange, I see Donnie in the members list but not Stuart +23:32 <+anholt> dberkholz: you are greylisting expo +23:33 <+dberkholz> and expo can't handle that? +23:33 <+anholt> expo is apparently waiting as it has been told to +23:33 <+anholt> I will put your info in ~dberkholz if you'd like +23:34 <+dberkholz> how long of a greylist could it be? i've been waiting more than half an hour.. +23:34 <+keithp> dberkholz: an hour is typical +23:34 <+keithp> it's the default retry time for the mailer +23:34 <+dberkholz> anholt: if you've got the info, that would be great since you're here now. +23:39 <+alanc> so unless anyone else has something, I think it's time to call the meeting adjourned +23:39 <+keithp> alanc: seconded +23:39 <agd5f> +1 +23:42 <+mherrb> +1 +23:42 <+alanc> thanks for coming everyone - see (most? all?) of you again in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/03-14.mdwn b/BoardOfDirectors/IrcLogs/2011/03-14.mdwn new file mode 100644 index 00000000..7d208836 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/03-14.mdwn @@ -0,0 +1,106 @@ + +Date is 2011-03-14, times are UTC+01. +[[!format txt """ +22:00 <alanc> good afternoon +22:00 <agd5f> hello +22:01 <alanc> stukreit sends his regrets, he's off breaking spring with his offspring +22:01 <agd5f> congrats to all the new board members +22:02 <+Bart_Massey> howdy! +22:02 <+anholt> hello +22:03 <alanc> though other than stuart, all the "new" board members are the old ones back again 8-) +22:03 <+mherrb> hi +22:04 <alanc> thanks to the election committee for steering us through the election process successfully +22:04 <alanc> may those who were just elected do as well next year, as they are now the election committee +22:05 <+Bart_Massey> let me be really clear--I will never again chair an election committee +22:05 <+dberkholz> indeed, congrats to you +22:05 <+dberkholz> feel free to get rid of my autovoice if anyone is so inclined =) +22:05 <agd5f> Bart_Massey: that makes two of us ;) +22:08 <alanc> does having voice really mean much in this channel other than an extra mark/icon by your name? +22:09 <+Bart_Massey> beats me +22:10 <+alanc> I guess this way I can easily see all 8 board members are logged into the channel, though I've not heard emmes or keithp speak up yet +22:11 <+alanc> so does the new board want to select a new secretary and/or treasurer? +22:12 <+Bart_Massey> I move we retain both alan and Stuart +22:12 <+mherrb> They're both doing a great job. +22:12 <+Bart_Massey> yep +22:12 <+Bart_Massey> +1s? +22:12 <+alanc> I'm willing to continue, and I think stuart is as well (sounded like it from his mail over the weekend about the bank status) +22:13 <+Bart_Massey> Stuart already promised us 5 years or somesuch... +22:13 <+Bart_Massey> :-) +22:14 <+alanc> I'm certainly in favor of letting him continue to deal with the banking mess +22:14 <+Bart_Massey> Would the various Board members please vote on my motions? I'll start with Stuart: +22:14 <+Bart_Massey> Move to retain Stuart as Treasurer +22:15 <+mherrb> +1 +22:15 <+alanc> +1 +22:15 <+Bart_Massey> agd5f:? +22:15 <+Bart_Massey> anholt:? +22:16 <+agd5f> +1 +22:16 <+Bart_Massey> tx! anholt? +22:17 <+Bart_Massey> 'k, looks like no quorum +22:17 <+Bart_Massey> next meeting, I guess +22:18 <+alanc> do we need to change meeting times? or is that best discussed via e-mail to get input from those who aren't here? +22:18 <+Bart_Massey> Yeah, lets ask on email. I don't remember +22:18 <+Bart_Massey> if this time works for me next school quarter +22:19 <+Bart_Massey> Kind of think so, but I'm not too picky +22:20 <+Bart_Massey> Only new business I have is to discuss the recent, probably on-hold offer by a company to directly fund some specific X development. What do people think about this in general? +22:20 <+agd5f> seems fine to me. +22:20 <+Bart_Massey> It's a bit awkward, because the Board, who presumably decides this stuff, specifically doesn't set technical direciton. +22:21 <+Bart_Massey> agd5f: My concern is that we end up funding work that helps a company but makes X worse overall. +22:21 <+alanc> do we need to get involved at all? if they have money to pay someone, can't they just do it directly, like the many other companies paying people to work on X? +22:21 <+Bart_Massey> You'd think. BUt in this case I think they didn't know how to do that, or who to do it with---and wanted to help X.Org +22:21 <+agd5f> Bart_Massey: we can't decide what gets committed per se. the company is free to do the work. the community has to decide if it goes in +22:22 <+alanc> certainly we haven't integrated all of the work students did for GSoC projects in the past +22:22 <+Bart_Massey> I guess I'm just wondering if we have any existing general principles or if we need any, or whether we should just handle it all on a case-by-case basis, at least for now. +22:23 <+Bart_Massey> You are both correct, of course. The joy of GIt is that we don't lose work entirely by leaving it off mainline. +22:23 <+alanc> I think we'd want to set the general principal up front that funding development does not guarantee integration +22:23 <+mherrb> They may prefer making a donation to the X.Org fundation rather than hiring someone directly to do the job. +22:23 <dberkholz> acting as intermediary for paid work might put the foundation in an awkward place +22:23 <+mherrb> In many .eu contries hiring people has constraints. +22:24 <dberkholz> might want to check w/ legal about possible issues +22:24 <+Bart_Massey> I think if we're looking at something like EVoC as ave +22:24 <+Bart_Massey> vehicle, that part is ok. +22:25 <+Bart_Massey> The trick is typically to set the funding as a stipend rather than a salary +22:26 <+Bart_Massey> Anyway, I promised to raise the issue here and I have. It sounds like we are all in general agreement. +22:26 <+Bart_Massey> At least we'll have some notes in the minutes for next time this comes up. +22:26 <+Bart_Massey> So do we have a date and venue for XDC 2011 yet? +22:28 <+alanc> don't think so +22:28 <+mherrb> we have Michael Larabel proposal, but we haven't heard anything new from him on this since last september +22:28 <+mherrb> or did I miss something/ +22:28 <+Bart_Massey> need to get it done now or we won;t make +22:28 <+alanc> most serious proposal so far seemed to be Michael Larabel's - I don't remember if he was actually planning to do all the organization work though, which is the hard part +22:29 <+alanc> if we wanted to piggyback on Linux Plumbers again, that appears to be "in Santa Rosa, CA, September 7-9, 2011" +22:30 <+alanc> which is unfortunately, not really local to anyone +22:30 <+alanc> though only a few hours drive for those of us at the other end of the SF Bay +22:30 <+Bart_Massey> I'm good with whatever ; +22:30 <+Bart_Massey> we mostly just need someone to step up and organize +22:30 <+Bart_Massey> like in the next week or so +22:31 <+Bart_Massey> doesn't need to be a Board member +22:31 <+alanc> do we need to put out a call for volunteers? +22:31 <+Bart_Massey> Yes +22:32 <+Bart_Massey> SInce I don't hear anyone here taking point :-0 +22:32 <+Bart_Massey> First step would be to check back in with Larabel I think +22:32 <+alanc> I guess I can write up a message to post and run it by the board for comments +22:32 <+Bart_Massey> Thanks! +22:32 <+Bart_Massey> Or just post it; I personally don't need to review it +22:33 <+agd5f> agreed +22:34 <+Bart_Massey> Anybody got other business for today? +22:35 <+mherrb> not me +22:35 <+agd5f> hopefully stukreit can get the financial info sorted. We are running out of time on the 501c3 window with the IRS +22:35 <+Bart_Massey> cool. move to adjourn +22:35 <+Bart_Massey> agd5f: when exactly? +22:36 <+agd5f> Bart_Massey: ~1 month +22:36 <+Bart_Massey> geez +22:36 <+agd5f> I'll have to ask Karen for the exact date +22:36 <+alanc> stuart should be back in a couple days, I'll poke him when I see him +22:37 <+Bart_Massey> Please make sure Stuart and Keithp are aware of this deadline. +22:37 <+Bart_Massey> It would really, really stink to miss it. +22:37 <+alanc> though I think he took his laptop to check e-mail too +22:37 <+agd5f> It's pretty bad. We had like 2 years to file... +22:37 <+Bart_Massey> s/file/flail/ :-) +22:38 <+Bart_Massey> Oh well. +22:38 <+Bart_Massey> Anything else? +22:38 <+alanc> I don't have anything else +22:39 <+Bart_Massey> cool. Move to adjourn +22:39 <+agd5f> +1 +22:39 <+Bart_Massey> opposed? +22:39 <+Bart_Massey> bye all! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/03-28.mdwn b/BoardOfDirectors/IrcLogs/2011/03-28.mdwn new file mode 100644 index 00000000..9b4dd7ff --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/03-28.mdwn @@ -0,0 +1,138 @@ + +Date is 2011-03-28, times are UTC+03. +[[!format txt """ +00:00 <+mherrb> hello +00:01 -!- mode/#xf-bod [+v alanc] by ChanServ +00:01 < agd5f> hi +00:01 -!- mode/#xf-bod [+v agd5f] by ChanServ +00:01 -!- mode/#xf-bod [+v stukreit] by ChanServ +00:01 <+alanc> hello +00:02 <+alanc> are anholt, keithp, emmes or stukreit awake? +00:03 <+stukreit> awake (hey, I just talked to you in the hall, wasn't that enough to convince you?) +00:04 <+alanc> yes, but you needed to say something in channel so I could count you here for the meeting +00:04 <+stukreit> ok. I'll say ' '. +00:04 <+alanc> want to start us off with an update on the treasurer work for the 501(c)3? +00:05 <+alanc> or any other treasurer reporting you have? +00:05 <+stukreit> ok. I got 2008 statements from hsbc and worked them up into a spreadsheet, adding later years stuff +00:05 <+stukreit> hope to send it to sflc rsn +00:05 <+stukreit> that's about it. +00:05 <+alanc> did you or adg5f find out how soon our deadline is? +00:05 <+stukreit> let me check my email +00:06 <+stukreit> "we have until april to get this in" +00:06 <+stukreit> ok, I better hustle this before cob today +00:08 <+stukreit> just gave her a heads up +00:09 <+alanc> hrm, still only 4 of the 8 board members here +00:10 <+alanc> seems we really do need a new time - so far only Keith responded to that e-mail +00:10 <+agd5f> alanc: I'm pretty flexible +00:11 <+alanc> I failed to send out a call for XDC proposals, but Michael Larabel responded that he's still willing to host +00:11 <+mherrb> earlier works for me, although I may be available less often. +00:11 <+alanc> do we want more proposals to look at? +00:11 <+mherrb> since it will be more in the middle of dinner time. +00:11 <+alanc> it sounded like an hour earlier would work for Keith +00:12 <+stukreit> did any of the people not here issue any difficulty with this time? +00:13 <+alanc> Bart needed to check his class schedule, Keith is unavailable after 2pm +00:13 <+alanc> will have to poke others via e-mail I guess +00:14 <+stukreit> We need to at least engage the board in agreeing to the meeting, perhaps if we put proposed times to a vote, we can get full participation on that. +00:16 <+alanc> so any comments on XDC? or anything else we want to discuss with only half a board? +00:17 <+stukreit> you said something about santa rosa, piggybacking another conf? +00:17 <+alanc> btw, is stukreit on the board mailing list yet? +00:17 <+mherrb> no new comments on my parts on XDC. +00:17 <+stukreit> I don't think so, I haven't gotten anything +00:17 <+alanc> Linux Plumbers is in Santa Rosa in September - but there's no one really local there to organize, just us a couple hours south +00:18 < omcfadde> is there any estimated month for XDC? +00:18 <+stukreit> oh, just got a board email from adg5f +00:18 <+agd5f> It'd be nice to have it coincide with lpc +00:18 <+alanc> omcfadde: sometime in 2011, nothing more definite yet +00:18 < omcfadde> alanc: I see +00:19 <+alanc> it's been a couple years since stukreit put together an XDC, maybe he's forgotten how much fun it was +00:19 <+stukreit> Santa Rosa's a sleepy place, shouldn't be hard/expensive to setup +00:19 <+stukreit> dunno if they have internets there. I know they have chickens +00:20 <+alanc> would have almost as much wine as France did +00:20 <+stukreit> (checking driving distance from SR to Sonoma) +00:21 <+alanc> looks like ~20 miles +00:22 < omcfadde> any info on how much budget is available for flights? I would of course ask my employer about making it a business trip, but as a backup... +00:22 < omcfadde> I'm not sure about the policy for sponsorship is nowadays. +00:22 <+stukreit> "sonoma hiway" runs thru it. +00:22 <+agd5f> omcfadde: IIRC, we should have plenty of money for sponsorships +00:22 <+stukreit> omc: Don't worry about budget, just make your request and see how it flys +00:23 < omcfadde> agd5f, stukreit: ok, cool :) +00:23 <+alanc> omcfadde: we've never really set a fixed budget for total sponsorships, just evaluated each request on a case by case basis +00:23 <+alanc> don't think we fully spent the $15k intel gave us last year for XDC2010 +00:24 <+stukreit> I did not cosign many checks at all for 10 ! +00:24 < omcfadde> well, at least now I'm old enough to drink with you guys in the U.S. +00:26 -!- Bart_Massey [bart@barton.cs.pdx.edu] has joined #xf-bod +00:26 -!- mode/#xf-bod [+v Bart_Massey] by ChanServ +00:26 <+alanc> http://www.linuxplumbersconf.org/2011/ says 7-9 September 2011 in Santa Rosa, CA, USA +00:26 <+Bart_Massey> Apologies for my lateness. Class ran long today. +00:26 <+anholt> alanc: sorry, was in a meeting. back now. +00:28 <+alanc> sounds like two more votes for continuing the discussion on the board mailing list about finding a better meeting time +00:29 <+Bart_Massey> Yeah, I normally am free at 1:50 Pacific, but I would be fine with another day. +00:30 <+alanc> so back to the XDC topic - do we want to see if anyone has another proposal or wants to offer to set something up colocated with LPC? or just tell Michael to start planning one in Chicago? +00:30 <+agd5f> I'd prefer to do something in conjunction with lpc +00:30 <+agd5f> but I'm not local to CA, so... +00:31 <+Bart_Massey> I think we should ask Michael to start planning one in Chicago. :-) I think that an offer in hand is worth a lot, and I don't see any very good reason to reject Michael's offer. +00:31 <+stukreit> I can make some comments about the current idea of lpc +00:31 <+Bart_Massey> But maybe I missed some discussion that would change my opinion? +00:32 <+alanc> I wonder if the Linux Foundation would help with organizing/finding space in Santa Rose +00:32 <+stukreit> 1. no reasonable public transportation. SFO and OAK are 40 to 100 miles away +00:33 <+stukreit> I don't think there are any big hotels. How did LF decide on it anyway? +00:33 <+Bart_Massey> I'm maybe a little concerned that between not working out Brazil with Tiago and then not working out Chicago with Michael, we start to look like we're soliciting help and then rejecting it...not good. +00:33 <+anholt> I'm fine with the chicago plan. +00:34 <+anholt> I like working with an existing proposal, instead of waiting for some other proposal to show up at this point. +00:34 <+Bart_Massey> stukreit: Maybe somebody's a Peanuts fan. :-) +00:34 <+stukreit> yeah. .. how far along is Michael with the Chicago idea? +00:35 <+alanc> waiting for us to tell him if it's worth spending any more time on it +00:36 <+stukreit> is it a proposal yet? something that can be put to a vote? +00:36 <+alanc> he sent a nice writeup a couple months ago, before you were on the board mailing list +00:36 <+stukreit> or.. is Santa Rosa a proposal with a champion? If not, then encourage M +00:36 <+alanc> http://www.michaellarabel.com/misc/xds-chicago-proposal.pdf +00:37 <+stukreit> I'll read it. I thought the way we worked is that if the idea wasn't outlandish, we indulged. +00:37 <+stukreit> for goodness sakes, we had XDS at a Zoo! +00:37 <+alanc> oh, found emmes mail that he was on vacation for this meeting, but voted in favor of larabel's proposal +00:37 <+anholt> xds at the zoo was awesome. +00:37 <+anholt> but mostly I remember the penguins. +00:37 <+stukreit> ok. maybe you'll find Chicago awesom +00:38 <+alanc> so do we want to vote on giving Michael the go ahead to start trying to arrange venue & dates? +00:38 <+Bart_Massey> I propose that we solicit a proposal of specific date and venue from Larabel, with the proviso that we will accept his proposal unless there is some extraordinary reason not to. +00:38 <+alanc> any scheduling restrictions we want to give him? Not overlapping with LPC seems like a requirement +00:39 <+stukreit> damn, he's got it together! +00:39 <+agd5f> I'd prefer santa rosa, but since we don't have anyone local to plan, chicago is fine with me. Also, not overlapping with lpc for times +00:39 <+Bart_Massey> I would be fine with August instead of September... +00:39 <+agd5f> it might still be warm in Chicago in august ;) +00:40 <+stukreit> agd5f: I'd like to express the point that Chicago is a proposal made by someone who stands behind it. I don't see that the Santa Rosa idea has an owner. +00:40 < omcfadde> fyi I'm happy with any location in the U.S. (another city to visit); but, for people traveling from Europe, it makes sense to try to colocate it with LPC +00:41 < omcfadde> colocate in either the same city, or the same timeframe... so you could fly from home-> LPC -> XDC -> home +00:41 < omcfadde> or vice versa +00:41 <+Bart_Massey> I'm not sure the overlap with LPC is that large. +00:41 <+Bart_Massey> I can think of four or five people who are probably planning to attend both. +00:41 <+agd5f> stukreit: right, that's why I'm fine with it +00:42 <+Bart_Massey> There are probably a dozen, but I'm not sure there's more. +00:42 <+Bart_Massey> Many of those are already in the US. +00:42 < omcfadde> ok. I thought there would be more overlap. in that case, I guess Chicago is fine, and already seems to be somewhat underway +00:43 < omcfadde> at least Michael would be able to organize that. +00:44 < omcfadde> from his proposal EU -> Chicago isn't too expensive. about $1000 USD (one way, I assume.) +00:45 <+alanc> so it seems like we have a consensus on going forward with Michael's proposal for Chicago? +00:45 <+Bart_Massey> +1 +00:45 <+anholt> +1 +00:45 <+stukreit> bewarned his airfares are 9/10. They are up a lot today +00:45 <+stukreit> +1 +00:46 <+Bart_Massey> Airline prices are unpredictable, but Chicago to London or Frankfurt is going to be about as cheap as it gets. +00:46 <+alanc> +1 +00:46 <+agd5f> +1 +00:46 <+Bart_Massey> I'd assume an extra couple of hundred dollars to get to Santa Rosa, however one does that. +00:46 <+mherrb> +1 +00:47 < omcfadde> stukreit: right, I'd have to check the prices again when dates are decided, then maybe my employer pays, or X foundation (if I have a presentation), or myself. +00:47 <+alanc> okay, so who will respond to Michael's e-mail? +00:48 <+Bart_Massey> The Secretary, of course. :-) +00:48 * alanc was afraid that was the answer +00:48 <+alanc> I'll try to get to it sooner this time than I did my AI's from last meeting +00:48 * Bart_Massey feels bad for how easy that was +00:49 <+Bart_Massey> You're doing great. Thanks much as always! +00:49 <+alanc> anything else we want to discuss today? +00:50 <+Bart_Massey> Move to adjourn +00:50 <+agd5f> +1 +00:51 <+Bart_Massey> Bye all! +00:51 <+alanc> thanks for coming - board members please respond to the meeting time e-mail thread so we can work that out soonish +00:51 -!- Bart_Massey [bart@barton.cs.pdx.edu] has quit [Quit: Leaving] +00:51 -!- alanc changed the topic of #xf-bod to: X.Org Foundation Board: just hanging the washing up | Next meeting: *Monday* Apr. 11, 2pm US/Pacific -- Note that US DST started Mar. 13! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/04-11.mdwn b/BoardOfDirectors/IrcLogs/2011/04-11.mdwn new file mode 100644 index 00000000..7d8dc79a --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/04-11.mdwn @@ -0,0 +1,140 @@ + +Date is 2011-04-11, times are UTC+02. +[[!format txt """ +23:01 <agd5f> hello +23:01 <+alanc> good afternoon +23:01 <stukreit> hi +23:02 <+emmes> hey +23:02 <stukreit> how's your weather in dc? +23:02 <agd5f> warm at long last +23:02 <agd5f> 82F +23:02 <stukreit> cherry blossoms and hay fever +23:04 <agd5f> indeed +23:04 <+alanc> so are anholt, keithp, mherrb actually here? +23:04 <+anholt> keithp is packing up to go home +23:05 <+alanc> we really do need to work out a new meeting time so he can make it +23:05 <+alanc> it was starting to look like an hour earlier would be good, but I think Bart's teaching class then +23:05 <stukreit> unless he wants to irc from his car. the fine's only $168 in CA. +23:06 <+emmes> known by experience? ;) +23:06 <stukreit> cellphone ticket a few months ago. but what's the difference between texting and fighting with a crappy gps interface? +23:07 <+alanc> they had the signs on the freeways last week warning about tickets for texting while driving too +23:07 <stukreit> right. "$168 ticket. Its not worth it" +23:10 <+emmes> Anything new from Michael? Sorry I couldn't make it last time (intenet was lousy in the alps). +23:11 <stukreit> Ski with me in tahoe next time. great connectivity. +23:11 <michaellarabel> Hi. It looks like it will hopefully be at IIT university... Waiting for them to respond back any time now. +23:11 <+emmes> stukreit: anytime :) +23:12 <+emmes> michaellarabel: thanks for all your work! +23:12 <michaellarabel> Pretty much what I emailed the board I think it was last week... Illinois Institute of Technology looks like it will be a great fit and just a matter of waiting on them to hear if it will be at no cost. +23:12 <stukreit> ml: What kind of room or requirements did you send them? +23:13 <michaellarabel> room for 60 people is what I've communicated so far +23:13 <stukreit> with wifi and power for laptops? +23:14 <michaellarabel> Yes those will be accommodated. +23:14 <+Bart_Massey> Sorry I'm late. +23:15 <stukreit> projector, possible locking closet? (these are ideas that were handy in previous meetings) +23:16 <michaellarabel> Yes I will bring those up too, first I'm just waiting to ensure that they can get us a room there and then will work out the finer details. +23:16 <stukreit> great. thanks for leading on this +23:16 <michaellarabel> NP. General information for the event is also up at http://www.x.org/wiki/Events/XDC2011 +23:17 <stukreit> looks good +23:18 <+Bart_Massey> quick question: is anybody working on getting x.org's dns moved to be a technical and admin contact other than Leon? We've tried on this in the past, and I forget what happened... +23:19 <michaellarabel> Hopefully I will be hearing back from the university today or tomorrow... Last week they said it should be about a week as they were checking with the ACM student chapter (acm.org I guess) to basically verify I guess that X.Org Foundation is something interesting and legitimate for getting free room. +23:19 <agd5f> Bart_Massey: we need a physical address for xorg +23:19 <agd5f> among other things +23:19 <+Bart_Massey> agd5f: I thought we finally had that sorted? +23:19 <agd5f> ideally we'd get one for the 501c3 stuff too +23:20 <+Bart_Massey> Weren't we going to use stukreit for this? +23:20 <agd5f> could be. I don't recall +23:20 <stukreit> i'm the treasurer. get the secretary to do it. +23:20 <+Bart_Massey> We could list Keithp as technical and admin contact for the dns, but give stukreit's address... +23:21 <+Bart_Massey> stukreit: But part of the reason we were happy to have a long-term commitment from you is that you agreed to lend us your address for a few years... :-) +23:21 <stukreit> minor issue: my address is changing next year. remodeling and making the entrance around the corner. +23:21 <stukreit> for everything? +23:21 <+Bart_Massey> Ideally, but obviously it's up to you. +23:21 <stukreit> Iguess its ok. hadn't thought that far. +23:22 <stukreit> I do plan to stay put +23:22 <stukreit> digging roots down deeper as we speak. foundations and footers +23:22 <+Bart_Massey> If you move (or change address) you move; nbd. But we've tried other plans in the past... +23:22 <+Bart_Massey> If you would prefer to get a maildrop near your home, X.Org would pay for it. +23:23 <stukreit> It will be ok. not a problem. probably buy a more sturdy mailbox than the current one. +23:23 <+Bart_Massey> Cool. Thanks much. +23:24 <agd5f> stukreit: btw, any news on the 1023 form? +23:25 <stukreit> I think you are cc'd to the discussions with sflc about the conversation tomorrow? +23:25 <stukreit> they sound fairly well satisfied. I'm going thru their draft and answering a few more questions. +23:26 <stukreit> I had some questions outstanding to keith about payments, no answer, but I'm thinking we have enough stuff to get it submitted +23:27 <agd5f> stukreit: I don't think I was cc'ed on that last set. but it sounds like things are moving. cool! +23:28 <stukreit> anyone who wants in on the conversation can contact me. Its at 12EST. +23:28 <+alanc> stukreit: they've been cc'ing Alan, not Alex on those +23:28 <stukreit> oh right. and I don't know why. alex: do you wish to attend? +23:29 <+alanc> which surprised me, since I thought agd5f had been involved before, and I haven't been +23:29 <agd5f> stukreit: I can't make it tomorrow, but, if you need a hand with anything let me know +23:29 <stukreit> ok, thanks +23:30 <+Bart_Massey> have we settled the meeting time question yet? +23:31 <+alanc> no +23:32 <+Bart_Massey> i would love a different time... +23:32 <+alanc> I have to go back through the e-mails to work out if there was a time that worked for everyone, since it seems like just moving an hour earlier puts it in the middle of your class +23:32 <+Bart_Massey> yep +23:32 <+emmes> also depends on the day +23:32 <+Bart_Massey> wednesday +23:34 <+Bart_Massey> ? +23:34 <+emmes> same time as ATM would be ok for me, earlier difficult +23:35 <stukreit> I'm busy alternate weds at 2pm pst +23:35 <+Bart_Massey> 'k +23:35 <+alanc> me too, but those are currently opposite the weeks the board meets, so if they stayed in sync +23:36 <+alanc> we'd be okay +23:37 <agd5f> tuesdays at 12 EDT I have a meeting, but most other times are ok. afternoons (eastern) work better for me as most meetings end up in the morning +23:41 <+keithp> stukreit: I saw Karen on Friday; I've got a bit of searching to do for old records. will let you (and SFLC) know what I find +23:42 <+Bart_Massey> I've set up one of those online poll thingies for meeting times. http://www.doodle.com/vsxzfy24mrnkzcp8 +23:43 <+alanc> thanks! I knew those were out there but couldn't remember any off hand so was going to have to search +23:43 <stukreit> keithp: great. I was thinking it would be good to scan up all the important docs from leon's box. +23:43 <+alanc> so I think we've covered the big thinks - 501(c)3, XDC, meeting times - any thing else we want to discuss? +23:44 <+alanc> did marcheu want to say anything about Google SoC now that all the student applications are in? +23:44 <+emmes> Bart_Massey: only seems to cover the day, not the time... +23:44 <agd5f> Bart_Massey: I couldn't figure out how to select times +23:44 <+Bart_Massey> Yeah, I set it up wrong, clearly +23:44 <+emmes> alanc: I think it's now for all mentors to read, comment, and vote +23:44 <+Bart_Massey> Doh +23:46 <+emmes> yes, this and next week: http://www.google-melange.com/gsoc/events/google/gsoc2011 +23:46 <+Bart_Massey> Fixed. +23:46 <+Bart_Massey> Not the best interface ever. +23:46 <+Bart_Massey> Oh well. +23:46 <+alanc> and it's not too late for new mentors to sign up, if X.Org devs want to help with one of the projects or to help rank them +23:46 <+alanc> marcheu was approving new mentors a couple hours ago +23:47 <+alanc> when I looked over the weekend there seemed to be fewer applications than I remember from past years +23:48 <+Bart_Massey> I agree +23:48 <+alanc> Bart_Massey: I'm assuming the time zone implied is US/Pacific on the poll? +23:48 <+Bart_Massey> But we're always small +23:48 <+Bart_Massey> Yeah, I put a note somewhere, but it isn't showing it +23:49 <+Bart_Massey> Next time I think I'll use a different one of these :-) +23:49 <+emmes> I think doodle is the best known one +23:50 <+Bart_Massey> Alex and Matthias, if you could redo at some point that would be awesome +23:51 <agd5f> Bart_Massey: same link? +23:51 <+Bart_Massey> http://www.doodle.com/vsxzfy24mrnkzcp8 +23:51 <+Bart_Massey> Yes +23:51 <+Bart_Massey> Somebody should email the link to the list, too. +23:52 <+alanc> done +23:53 <agd5f> done +23:53 <+Bart_Massey> Still lots of possibilities, which is good. +23:54 <+emmes> Bart_Massey: redo what? +23:54 <+emmes> filling out doodle? already done :) +23:54 <+Bart_Massey> Good. +23:54 <+Bart_Massey> With four of us down, there are still a reasonable number of prospects. +23:54 <+Bart_Massey> Hopefully the other four will grab it RSN and we can pick a time. +23:55 <+Bart_Massey> keithp: any chance you could hit the link and fill this in? +23:55 <+Bart_Massey> stukreit: same? +23:56 <+Bart_Massey> is anholt or marcheu around today? +23:56 <stukreit> done +23:56 <+anholt> yeah +23:57 <+Bart_Massey> still looking good! +23:57 <+alanc> I see 5 members now, missing keithp, anholt & mherrb +23:58 <+Bart_Massey> i think keithp may be the strongest constraint. +00:01 <+alanc> so anything else to discuss while waiting for meeting time poll votes? +00:01 <+Bart_Massey> 'k. Got to go. Somebody post the link to the list, and hopefully the remaining three will fill it out in the next day or so. +00:01 <+Bart_Massey> Bye all! +00:02 <+alanc> since the hours up, and no one has any more business, I'm ready to call this meeting adjourned -- any objections? +00:03 <agd5f> +1 +00:04 <+alanc> next meeting time/date to be worked out via e-mail once the poll results are in +00:04 <+alanc> thanks for coming all +00:05 <michaellarabel> I'll be emailing you guys soon as I have more information on XDC (again, hopefully in next day or two) +00:10 <+alanc> thanks +00:11 <+emmes> thanks as well +00:11 <agd5f> thanks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/04-28.mdwn b/BoardOfDirectors/IrcLogs/2011/04-28.mdwn new file mode 100644 index 00000000..ce3f8a14 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/04-28.mdwn @@ -0,0 +1,333 @@ + +Date is 2011-04-28, times are UTC+02. +[[!format txt """ +23:00 <agd5f> hi everyone +23:01 <+emmes> hey +23:01 <stukreit> hello +23:01 <+Bart_Massey> howdy +23:01 <+alanc> good afternoon +23:02 <+alanc> think we'll have plenty to talk about today +23:02 <stukreit> yup +23:02 <+anholt> hi +23:03 <+alanc> mherrb sent regrets in advance, so that just leaves keithp to pipe up +23:04 <+Bart_Massey> I'll send keithp a text. +23:04 <+alanc> for those who haven't seen yet, GSoC projects were announced, 4 for X.Org http://www.google-melange.com/gsoc/org/google/gsoc2011/xorg +23:04 <+keithp> afternoon +23:04 <+anholt> I pinged him +23:05 <+alanc> and EVoC got mentioned in a writeup of "where to go if GSoC rejected you" resulting in a flood of inquiries to the board, which I tried to all respond to with a form letter today since it looked like no one else had +23:05 <+Bart_Massey> Is that why I suddenly got a bunch of requests? +23:06 <marcheu> yeah Evoc was mentioned on the summer of code mailing list +23:06 <+Bart_Massey> Thanks for the form letter response; I'll try to get more personal ones to anyone who managed to contact me directly shortly. +23:06 <marcheu> Bart_Massey: there is one good project though, we can discuss it privately +23:06 <marcheu> (for evoc) +23:06 <+keithp> Bart_Massey: uh, not entirely necessary +23:06 <+emmes> I thought we had 5 slots. But I think I remember that we only had 4 really good proposals. +23:06 <stukreit> Interesting. I did not see any of these messages. Am I not on the board alias? +23:06 <+alanc> http://blog.lydiapintscher.de/2011/04/25/not-accepted-into-gsoc-heres-what-to-do/ +23:07 <+Bart_Massey> marcheu et al: Yes, if you see any that look like we should actually take them, please let me know, as I am probably not the best judge and am defaulting to no. +23:07 <marcheu> emmes: yes, but we had a good proposal which was not submitted (stayed in draft mode basically) +23:07 <+emmes> thanks for answering, Alan! +23:07 <+emmes> marcheu: ok +23:07 <+Bart_Massey> marcheu: Why was it not submitted? +23:07 <marcheu> Bart_Massey: the guy thought he had submitted it, but he hadn't +23:08 <+Bart_Massey> Carol would probably fix that for you if you asked nicely, even now. +23:08 <+Bart_Massey> Would definitely be the best plan if possible. +23:08 <marcheu> hmm good point, I'll try to use my google-fu +23:08 <+alanc> stukreit: didn't we get you added yet? mailman says agd5f is one of the admins for the board list, so he should be able to add you +23:08 <+emmes> depends. if the slot is already reallocated to some other org, it isn't. +23:08 <+emmes> trying is always a good idea, though. +23:09 <stukreit> agd: please add me to the alias +23:09 <+Bart_Massey> emmes: Carol has lots of things she can do; I'd definitely ask +23:09 <agd5f> stukreit: which one? board@foundation.x.org? +23:09 <stukreit> that one. What other ones are there? +23:10 <stukreit> (lets take this offline) +23:10 <agd5f> stukreit: ok +23:10 <+alanc> thanks to marcheu for managing the project selection process & organizing our mentors for GSOC +23:10 <+Bart_Massey> indeed! +23:11 <+alanc> so michael larabel couldn't make it today, but sent XDC updates via e-mail +23:12 <+Bart_Massey> Seems to me like he's doing great; I'd encourage anyone with concerns to contact him sooner rather than later. +23:12 <+emmes> i'll see him personally on monday +23:12 <+alanc> I think he needs us to give a thumbs up or down to the proposal to host at Illinois Institute of Technology for $1,369.80 +23:13 <+emmes> but I'll also send the excerpts of today's meeting to him (he's travelling right now) +23:13 <+emmes> yes, exactly. +23:13 <+Bart_Massey> +1 +23:13 <+alanc> which doesn't seem far off from what we've paid other venues I think +23:13 <+emmes> +1 +23:13 <+Bart_Massey> (for funding the event) +23:13 <stukreit> I'll catch up with him later, but is that the estimate for the whole event, or just a room rental? +23:13 <+alanc> that's the room rental +23:13 <+Bart_Massey> It's well within our budget, in any case. +23:14 <+alanc> 12 September to 15 September is the dates he's proposing +23:14 <+emmes> I think wifi is included as well afair. just catering is not. +23:14 <+alanc> "This includes providing seating/chairs + tables for everyone + setup of WiFi. " +23:14 <stukreit> need to work up the actual including food and any add-ons +23:14 <agd5f> seems reasonable to me. we have to start keeping records of this stuff. when we pay for things like vendors or venues, we have to have proof that we've done our due-diligence +23:14 <+alanc> right, but food can come later, need to reserve the venue first +23:15 <+alanc> +1 for the venue booking +23:15 <+Bart_Massey> alanc: Yes. If we find out something weird about the food later we can always cancel, but I find it unlikely. +23:15 <+anholt> +1 to going ahead with IIT +23:15 <stukreit> Is it a cancelable res? Is it a deposit? +23:16 <+alanc> unknown, and michael isn't here to answer +23:16 <+emmes> i'll ask him. +23:16 <+alanc> (I believe he's supposed to be approx. 30000 feet over the atlantic right now) +23:16 <+emmes> on the way to munich +23:17 <+alanc> so I have 4 votes in favor of booking the IIT venue for XDC2011 for 9/12-15 - do the other 3 members want to vote yay, nay or abstain? +23:17 <+anholt> high latency on the intel side here. (we're on some tin cans and we wish we had some string today) +23:17 <stukreit> The ready-fire-aim approach has made it um interesting to answer the 13 pages of questions that the IRS has for us +23:18 <stukreit> As requirement for the petition to become the organization we want to be. +23:18 <stukreit> I will vote against this at this time +23:18 <stukreit> -1 +23:18 <+alanc> so do we need to get more information before making these decisions? if so, can you provide that so we can get it from michael before the next meeting? +23:18 <+alanc> i.e. is that really a request to table the decision until that information is provided? +23:18 <stukreit> provide what +23:18 <stukreit> I would prefer that +23:19 <+Bart_Massey> A list of what you think we need to know. +23:19 <+alanc> provide a list of the information we need +23:19 <+Bart_Massey> I think Michael has provided a lot of information already; it's possible you've missed some of it because of email list issues. +23:19 <stukreit> Start with some planning of what is needed to host a 3 day event for the expected number of people (50? 75?) +23:19 <+keithp> sounds like we're still waiting on catering estimates +23:19 <stukreit> Yes, that's a problem. I haven't been on the alias +23:20 <stukreit> If someone wants to comfort me, please forward me Michaels most detailed email on the planning. +23:20 <+Bart_Massey> There has been a *lot* of planning. The lack of catering estimates are not a show stopper IMHO: in the worst case we don't serve food at the event. Not end of world. +23:20 <+emmes> keithp: seems michael only wanted to check catering if the venue itself is ok. +23:20 <stukreit> I'm not assuming its not planned, I'm just responding to my lack of knowledge at this point. +23:21 <stukreit> And talking to the lawyers for many hrs over the past week has sensitized me to the lack of records +23:21 <+alanc> Stuart - you responded to one of his emails to board@foundation +23:21 <+alanc> Re: XDS Location Proposal - Chicago +23:21 <+emmes> he wrote that it's not a major issue, but quite some work to get reasonable proposals +23:21 <+alanc> I'm assuming you've just lost the thread +23:21 <+emmes> for the catering I mean +23:21 <stukreit> I remember that, but there's this technical prob that I'm not seeing all the good stuff since +23:22 <stukreit> I would like to slow this process down, and move on to the more time critical issue of the 1023, which needs to be filed tomorrow +23:22 <+alanc> michael actually put together the most detailed proposal I've ever seen for an XDC +23:22 <stukreit> fine and fine. forward it to me +23:22 <+alanc> I was trying to get the quicker stuff out of the way before digging into the 1023 +23:23 <agd5f> if/when we come a 501c3, we our obligated to keeps records that prove we have made a reasonable effort to plan for and price any activities. I think michael's proposals will suffice. +23:23 <+alanc> so lets call the XDC response favorable, but the formal vote tabled until the next meeting to get the required information +23:23 <+Bart_Massey> We are +4 -1 on the motion to go forward. I'd prefer to just go ahead. +23:25 <+Bart_Massey> Could the other three board members here weigh in? +23:25 <+alanc> I didn't see votes from keithp or agd5f +23:26 <+Bart_Massey> Sorry, right, other two board members +23:27 <agd5f> +1 I guess +23:27 <+emmes> stukreit: I just bounced the three most important mails from michael to you. +23:28 <stukreit> Yes, thanks. +23:28 <+alanc> I forwarded all of the thread that I had, including the original proposal writeup +23:28 <+emmes> one has the reserveration confirmation included. i think that is the most important one (appart from the original proposal, for which an url is provided) +23:29 <+Bart_Massey> So we already have the venue reserved for these dates? +23:31 <+alanc> okay, so the vote is 5 in favor, 1 against, and keithp not voting? any more discussion or votes before we close the vote and tell michael to make the reservation? +23:31 <stukreit> I've read thru it, it looks fine +23:31 <+alanc> it didn't sound like it was already reserved in the mail I saw +23:31 <+Bart_Massey> OK. +23:32 <+alanc> stukreit: are you changing your vote to approve then? +23:32 <stukreit> I will ask M. to name a few of the other places that he contacted, for comparison. This is something we need to start making record of. +23:32 <+alanc> sounds reasonable +23:32 <+Bart_Massey> I'm sure he'll be willing to do that. He's put in a tremendous amount of work so far. +23:32 <stukreit> hmnn, be a curmudgeon or a flipflop. decisions decision. +1 +23:33 <stukreit> Yet another promise from me to followup on some thread +23:33 <+emmes> stukreit: good point +23:33 <+Bart_Massey> flipflop sounds more fun. flipflopflipflop :-) +23:34 <+alanc> okay, vote is closed with 6 in favor, 0 against. emmes, please thank michael for us when you see him +23:34 <+alanc> (I'd tell you to buy him a beer, but I don't want to spend another half hour authorizing the foundation to pay for that 8-) ) +23:34 <+Bart_Massey> indeed +23:34 <+Bart_Massey> (to the first, not the second :-) +23:34 <stukreit> I do have a point though. It is better for our outward appearance to plan things much more thoroughly than we have in the past. But we need to develop an attitude that planning is a good thing +23:35 <+alanc> agd5f & stukreit: you now have the floor to discuss the 501(c)3/1023 work +23:35 <+Bart_Massey> stukreit: planning is good, definitely +23:35 <stukreit> ok. to start +23:35 <+emmes> alanc: he'll get a beer from me in any case (or rather 2 or 3 or...) +23:35 <stukreit> Does everyone have the email "Topics of Governance that arise from the 1023 Filing" +23:36 <stukreit> Does anyone NOT have the email? +23:36 <+emmes> ... checking... +23:37 <stukreit> Does anyone need a minute more to read the first page? +23:37 <+emmes> I don't remember reading the subject, but that shouldn't say anything... +23:37 <stukreit> sent 1:34 PST +23:37 <+alanc> it was sent about a half hour before the meeting +23:37 <+keithp> I've got the mail. +23:37 <+emmes> right. sorry. I have it. +23:37 <+keithp> Bart_Massey: do you know if we have ever paid anyone for EVOC +23:38 <stukreit> excellent question. +23:38 <+Bart_Massey> My recollection is that we tried once, and it failed due to foreign funds transfer issues. +23:38 <+Bart_Massey> I have no particular records on this. +23:39 <+Bart_Massey> It seems to me like either we should close EVoC or someone besides me should take it over. +23:39 <stukreit> Would you like to retry the payment? And is there only 1 instance of attempted payment? +23:39 <+Bart_Massey> We have no records of who or when that even was. I may be misremembering it altogether. In any case, water under the bridge, I think. +23:40 <+Bart_Massey> I'm really not feeling like I have time to manage it in the way it looks like it's going to need going forward. +23:40 <stukreit> If you can find the person and make good on the promise, I think its worth doing so. +23:41 <stukreit> Separate the one instance from your plan to do this going forward. +23:41 <+Bart_Massey> If you'd like to dig through old Board minutes and try to figure out what happened, I'd be happy to talk to them. I'm pretty sure that no one's unhappy, or they would have contacted us again. +23:42 <+keithp> We had one proposal from Kristof Ralovich +23:42 <stukreit> Ok, I needed an answer to that, thanks. I would urge Bart (if you were the point person) to find the name and email of the person. Did they hold up their side of the plan? +23:42 <+alanc> didn't he withdraw partway through? +23:42 <+keithp> and one from Joshua Clayton +23:43 <stukreit> Can we hold off on new proposals for now? +23:43 <+Bart_Massey> I don't remember. I'm pretty sure Ralovich did a GSoC project at some point. +23:43 <agd5f> well, at this point, we are telling the IRS that we haven't paid out, so if we do, we have to rewrite a lot of the 1023, so we need to sort this out today if we want to +23:43 <+Bart_Massey> Joshua Clayton was not funded, IIRC. +23:43 <+Bart_Massey> I think we haven't paid anyone. +23:43 <+keithp> I don't recall ever writing any checks or doing any wire transfers, and I have no record of either as well +23:43 <stukreit> I would like to see a message or exchange that ties this loose end. +23:44 <+Bart_Massey> stukreit: I don't think it's going to happen at this point. +23:44 <stukreit> right. btw, anyone who wishes, contact me about seeing all the financial activity since 2005. +23:44 <+Bart_Massey> I'll have to admit that I'm finding it slightly ironic that our big barrier to ed nonprofit status is our one truly educational program. Sigh. +23:44 <stukreit> Its not a barrier. We're going to say that we have not done one yet. +23:45 <agd5f> we are also saying we plan to implement it going forward +23:45 <+Bart_Massey> Fair enough. +23:45 <stukreit> However, if we make the effort, we can tidy up the first attempt, and use it as a lesson for the future +23:45 <+Bart_Massey> stukreit: I don't think it's a good lesson. :-) +23:46 <stukreit> which is a lot of the tone of the 1023. and my signature goes to the IRS. (or I.R.S., I don't take this lightly) +23:46 <+alanc> the lesson is clearly that making money appear is the easiest part of organizing something like GSoC & EVoC, and the rest is much harder +23:46 <stukreit> So guys, when I hammer on you for more planning, more documentation, more comparable info on decisions, its because of this. I'll be the bad guy. +23:47 <+Bart_Massey> Someone needs to! +23:47 <+keithp> stukreit: that's why we keep you around +23:47 <stukreit> So let's look at the email and go thru the 6 questions please +23:47 <+emmes> well, it's not the only reason... +23:47 <+emmes> stukreit: do you still require my bio, or did we settle that in the past? my brain doesn't remember... +23:47 <stukreit> no I will not fix your computer +23:48 <+alanc> emmes: looks like that's #4 in the list of questions +23:48 <+emmes> yes, that's why I'm asking. +23:48 <stukreit> Yes, we need it. +23:48 <+emmes> ok. will do that. +23:49 <agd5f> emmes: specifically your job title and education +23:49 <+Bart_Massey> How do you want us to get all y'all postal addresses etc? +23:49 <stukreit> The addendum, page 7. +23:49 <+Bart_Massey> Shall we email them to you? +23:49 <+alanc> what do you need for "Double check affiliations between xorg and directors" ? looks like the list of directors & officers is correct +23:49 <stukreit> the usual way? +23:50 <+Bart_Massey> Email it is. Working... +23:50 <stukreit> ok, how about a vote that everyone who reviews it agrees +23:50 <+Bart_Massey> +1 +23:50 <+anholt> agrees what? I've lost you. +23:51 <+Bart_Massey> That the list of directors and officers is correct? +23:51 <agd5f> alanc: we want to make sure there are no outstanding agreements between xorg (the organization) and any of it's directors +23:51 <stukreit> that you have read the section and find it correct +23:51 <+alanc> the lists on pg 5-8 of the addendum? +1 for it being right +23:52 <+keithp> stukreit: looks right to me -- +1 +23:52 <+alanc> I'm not aware of any contracts or agreements other than the membership agreement, though I suppose we technically all made that agreement with the LLC +23:52 <stukreit> We were asked from several directions whether any directors have bus relationships with each other or outside of the stated affiliations. +23:52 <stukreit> my +1 +23:52 <stukreit> (4 more to go) +23:52 <+anholt> ah. +1. +23:53 <+alanc> there's certainly the whole intertwining of relationships between our employers (Oracle has agreements with Intel & AMD for instance, all 3 of which employ board members) +23:53 <agd5f> +1 +23:54 <+emmes> +1 +23:54 <+Bart_Massey> But you as an employee have not entered into any agreements you have not disclosed, which while IANAL I think is the important thing +23:54 <agd5f> alanc: that doesn't matter. Just between the Xorg foundation and it's directors +23:54 <+anholt> stukreit: does "[no longer active in the organization]" just mean "doesn't have a role in the structure", or "is not a member"? +23:54 <+anholt> page 10 +23:54 <stukreit> And in the future (further down in the email) we'll draft a conflict of interest policy. +23:55 <+alanc> right, and I believe the bylaws explictly state we serve as individuals, not corporate reps +23:55 <agd5f> anholt: everyone who ever was is still a member. It means no longer actively involved +23:55 <stukreit> These are for former directors. +23:55 <+alanc> I would expect many of those on pg. 10 is still a regular member, able to vote in elections +23:56 <+alanc> Jim & Kevin occasionally pipe in on mailing lists or irc, haven't seen them contribute code in years though +23:56 <+anholt> agd5f: we have an active/inactive distinction in the members list, and for example James McQuillan is "active". +23:56 <stukreit> I was curious about it too. I'll send a message to Justin about it, because in my mind, many of those nla's could become active at any moment. sleeper hackers +23:57 <+anholt> I hadn't looked into what sched G question 4 was about yet. +23:57 <+Bart_Massey> I think this is making things more complicated than they need to be. AFAIK all IRS cares about is whether they're still part of governance... ? +23:57 <stukreit> So, we need a written policy defining "active member"! +23:57 <+Bart_Massey> I suspect all we need is to list these folks as "no longer active in X.Org governance" and call it good. Talk to Justin. +23:58 <+anholt> Bart_Massey: thanks. +23:58 <stukreit> bart: agreed. In general, I want to fill the remaining blanks, push the doc, and then keep it high in our minds as AI's for the board +23:59 <+emmes> stukreit: I'll send you my bio and Egbert's address shortly. +23:59 <stukreit> ok, so we have 7 +1's on question 1 +23:59 <stukreit> that fills in some blanks, way to go! +00:00 <stukreit> moving on.. +00:00 <+emmes> hm, seems I don't have Egbert's address at hand :-( I'll phone him tomorrow +00:00 <stukreit> I propose we make (2) a policy +00:00 <stukreit> Please expedite. +00:00 <+alanc> that we read the IRS form? +00:00 <+Bart_Massey> Speaking of blanks, the 1023 I'm looking at in the email attachment appears to not be filled out at all. Is it just me? +00:01 <+alanc> not just you +00:01 <stukreit> damn, more trouble in pdf land +00:01 <stukreit> will work on it. +00:01 <+Bart_Massey> Will read it when I get it. +00:01 <stukreit> If someone knows the compatibility issues wrt pdf readers, please help me offline. +00:01 <agd5f> stukreit: whatever you did last time fixed it +00:02 <stukreit> So "when you get it", please read the 1023. And whoever deals with the next election, please put this in the solicitation materials. +00:02 <agd5f> but even then, the checkboxes always come up empty +00:02 <stukreit> I don't think I can fix this right now. +00:02 <stukreit> ok, Item (3), we just covered. +00:02 <stukreit> Item 4 +00:03 <stukreit> and 5 both done +00:03 <+Bart_Massey> It looks like you have a postal and email address for me. I think I'm done with 6? +00:03 <agd5f> Does someone have Egbert's address? +00:04 <+alanc> for Item 6, my paper mail address is already correct on pg. 5, and the lawyers should have my e-mail from the exchanges already +00:05 <stukreit> if you haven't ever sent a message to the lawyers, please just shoot me a line so I can collect it into one. without thinking.. I like not thinking +00:06 <+Bart_Massey> Nice. Google Contacts is down. +00:06 <+emmes> agd5f: Egbert moved. Though it could be the same address, as it was in the same building. +00:07 <agd5f> emmes: ok. you bio looks good. Thanks! +00:07 <stukreit> emmes: irc says you are ~mhopf@charybdis-ext.suse.de +00:07 <+emmes> eek +00:07 <stukreit> should I submit mhopf@suse.de? +00:08 <+emmes> yes, please. +00:08 <+anholt> stukreit: I agree on current set reading the 1023, but it doesn't look that relevant to me for new board member orientation. +00:08 <stukreit> Its a poor starting point, but the lawyers specifically suggested it. Don't call it "orientation" it isnt +00:09 <+Bart_Massey> I don't have a current address for Egbert. +00:09 <agd5f> anholt: it's more to get a idea of what we are responsible for doing as an organization and as directors +00:10 <+Bart_Massey> It's fine to ask new Board Members to read the document. They'll survive it somehow. :-) +00:10 <+Bart_Massey> Should probably also ask them to read the Bylaws. +00:10 <stukreit> +1 +00:10 <+alanc> if they did we might finally get around to updating the bylaws +00:10 <+anholt> yeah, I don't recall even reading the bylaws to start out with. +00:10 <+alanc> we fail at many of them +00:10 <stukreit> Ok, the open issues for tomorrow's filing are covered. +00:11 <+Bart_Massey> Yeah, once this current ugliness is behind us I'll start working on proposed revisions to be voted in Chicago. +00:11 <+Bart_Massey> Help appreciated as always. :-) +00:11 <stukreit> The rest of the email talks about issues that have come up. +00:12 <stukreit> This is not a file-and-forget process. We are committing to establishing written procedures and documented activites. +00:13 <agd5f> regarding reading the 1023, if we tell the IRS we keep records of X and require Y for Z, we actually have to do it +00:14 <stukreit> ok, we're past the hour, but I really insist to the point of asking a response email that.. +00:14 <stukreit> every board member read and comment on the Governance email. +00:14 <stukreit> Because now we have a lot of Governance to do. +00:14 <+Bart_Massey> I have read the email and commented on it in this meeting. Surely that suffices? +00:15 <agd5f> e.g., we said we will be using commonly accepted practices for determining the cost of vendors or venues so we have to document that we did that +00:15 <agd5f> there are a number of similar things as well +00:16 <+Bart_Massey> Either don't say that, or be much more specific, or be prepared to say that taking quotes and selecting from among them is a commonly-accepted practice (which is what we do and I think is) +00:16 <agd5f> Bart_Massey: right. but they want records that we did that +00:17 <agd5f> not just some said they did on irc +00:17 <+Bart_Massey> Which is why we're keeping minutes on IRC +00:17 <agd5f> *someone +00:17 <stukreit> We need a transcript or other record that shows the work +00:17 <+Bart_Massey> Sorry, that's how our meeting minutes are recorded. +00:17 <+Bart_Massey> It sounds like a surefire plan for making sure no one ever does anything to me. +00:18 <agd5f> Bart_Massey: blame the IRS then +00:18 <+emmes> so what would be sufficient? +00:18 <+Bart_Massey> I have worked with a lot of 501(c)3 ed nonprofits; while I'm not suggesting we be cavalier here, I will suggest that the level of documentation at these other organizations has been reasonable, and the IRS has seemed fine with that. +00:18 <+alanc> aren't the IRC logs transcripts? +00:20 <+Bart_Massey> alanc: I think the suggestion is that whoever claims to have gotten an estimate also needs to provide sufficient paper to prove it. Which is usually what we do. We just haven't been good at collecting that paper. +00:20 <stukreit> bart: I don't know if that anecdotal info proves anything. In talking to SFLC which generously gives us professional advice based on their wide view of non profit corp setup, +00:20 <stukreit> this is what we're being told +00:20 <+Bart_Massey> We can certainly do better. I'm just concerned that we realistically aren't interested in hiring a paid staff person to handle paper, and without that the level of documentation to be required may be too high. +00:21 <agd5f> Bart_Massey: we just have to try a little harder. We don't have to go overboard, but no one even knows if we paid on on evoc, or what some of our checks were for. so we need a little better accounting is all. +00:21 <stukreit> So, I will go back and ask how much documentation is needed, but it is surely more than we've been doing +00:21 <+emmes> paper as in physical paper, or are pdfs ok (like the one michael sent us)? In the later case, one additional proposal should be good enough. +00:21 <stukreit> And I'm not an accountant, which is a wee problem +00:21 <+Bart_Massey> The problem is that documentation isn't a question of volume: it isn't measured in those units. +00:21 <agd5f> emmes: digital is fine +00:22 <stukreit> I would prefer digital stuff, and have 2 people hold copies +00:22 <+emmes> ok, I'll go ask Michael. He'll surely understand. +00:22 <+Bart_Massey> It's that we have to be able to document later that we did things in a reasonable fashion. +00:22 <agd5f> right +00:22 <+alanc> he talked to multiple venues, so it sounds like just documenting the quotes he got from each +00:22 <+emmes> yep +00:23 <+Bart_Massey> That *doesn't*, AFAIK mean that for example we have to get multiple bids on everything we buy. It just means we have to be able to show that we weren't paying stupid money or colluding with somebody somehow. +00:23 <stukreit> he probably did. its just that we need to collect the info. +00:24 <stukreit> let's not worry about slippery slope issues. let's just start with the issue at hand. the next conference. I am optimistic that michael can furnish all the info we need to keep. +00:24 <+Bart_Massey> If Michael got multiple bids and has the info handy, we'd love to have it. If all he has is the investigation he reported, this should nonetheless be sufficient. We just have to make sure his emails are archived somewhere. +00:24 <stukreit> and going forward, we just have to be concious of this and ask ourselves if we're doing the right thing. +00:24 <+Bart_Massey> Yep. +00:25 <+Bart_Massey> BTW, HUGE HUGE HUGE thanks to stukreit and agd5f for finally pushing this all through. +00:25 <+Bart_Massey> Very impressive. +00:26 <stukreit> your welcome. when you finally get to read the filled-out 1023, you will get a sense of the completeness of the process. +00:26 <+emmes> yes. all this paper stuff looks awfully complex to me. +00:26 <+alanc> yes, thanks much +00:26 <agd5f> Justin just sent the updated versions of the docs. I'll foward to the board +00:26 <stukreit> Its not like the IRS has never seen an org like us before. We need to treat fair questions with due respect. +00:26 <+alanc> anything else we need to discuss today? +00:27 <stukreit> not from me. +00:27 <+emmes> i'm fine +00:27 <+alanc> thanks everyone for sticking around an extra half hour +00:27 <+Bart_Massey> Bye all! +00:27 <stukreit> bye! +00:27 <agd5f> thanks everyone! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/05-12.mdwn b/BoardOfDirectors/IrcLogs/2011/05-12.mdwn new file mode 100644 index 00000000..85f532aa --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/05-12.mdwn @@ -0,0 +1,82 @@ + +Date is 2011-05-12, times are UTC+02. + +Due to anti-spaming policies, the word insur*ance had to be crippled. +[[!format txt """ +23:01 <+mherrb> hi +23:01 <+emmes> hey all +23:01 <+alanc> good afternoon/evening +23:02 <stukreit1> hi +23:06 <agd5f> hello +23:06 <+alanc> so do we have 501(c)3 news? +23:07 <agd5f> alanc: it's in teh IRC hands now +23:07 <agd5f> IRS even +23:07 <stukreit1> one detail: I just wrote a $850 check to reimburse SFLC for the filing fee +23:08 <+alanc> sounds like a good thing to have done +23:08 <+alanc> do we need to formally vote on it for the record? +23:08 <stukreit1> and Justin (our rep at sflc) insists that we get it together with the conflict of interest and other policy statements +23:09 <agd5f> yeah. we should get that going +23:09 <stukreit1> I don't think there's anything to vote on. Its a neccessary part of the 1023 +23:09 <+alanc> Bart had some bylaw updates to propose as well, but isn't here yet +23:09 <stukreit1> I'll get a bit of boilerplate from Justin. He's here to help +23:10 <+alanc> (are keithp & anholt actually around btw? I know keith was here earlier and have seen everyone else talk since 2pm) +23:10 <+anholt> here +23:11 <+alanc> so if we're done with that, XDC plans look to be shaping up well +23:11 <stukreit1> Why don't we make it a policy for BoD people to say Hi so that their presences is recorded on these transcripts +23:11 <stukreit1> (or at least ask nicely) +23:12 <+keithp> hi +23:12 <+alanc> $260 for the insur*ance seems reasonable +23:13 <stukreit1> That's for a specific 3 day event +23:13 <+alanc> yes +23:13 <+alanc> do we need a general year round insur*ance plan? +23:14 <+emmes> btw - can anybody explain to me what exactly this insur*ance is all about? +23:14 <+emmes> I'd assume that we typically don't require this in Europe - and thus it's rather unknown to me... +23:14 <+alanc> in the US, if you exist, you are at risk of being sued, and insur*ance helps foot the bills if you are +23:14 <stukreit1> I don't know, but personal liability for $2M is about that much for a year. (e.g. to cover my home construction) +23:15 <stukreit1> I guess I'll call my ins agent to see if its easy to understand. I have to call him anyway because he messed up my car coverages +23:15 <+alanc> presumably it's mainly to cover something like someone tripping over a powercord on the stairs and breaking their legs +23:15 <stukreit1> then twisting the cord around their neck, then falling down the stairs, then... +23:15 <+emmes> understood. I know this type from car insur*ances. +23:18 <+alanc> so is there anything else we need to discuss? +23:18 <+emmes> For XDC: due to the unclear situation regarding travel funding after the attachmate takeover +23:18 <+mherrb> since we only do one physical event per year a specific insur*ance for those events is probably cheaper than an annual global one. +23:18 <stukreit1> I still haven't done anything about the Intel $15k donation. Need to work on that. +23:19 <stukreit1> I'll make an inquiry. +23:19 <+emmes> I'd like to ask whether the board could in principle agree in travel funding for me, depending on the situation in september... +23:19 <stukreit1> +1 for your travel +23:19 <+mherrb> +1 +23:19 <agd5f> +1 +23:20 <+alanc> if they will pay, thats preferred, but if not, +1 for us paying +23:21 <+emmes> ok, great. It's just me asking early so I can make travel arrangements while flights are still cheap +23:21 * alanc very much understands the fun and uncertainty of having your employer bought +23:21 * emmes sighs +23:22 <+anholt> +1 +23:24 <+alanc> so anything else for today's meeting? +23:24 <+mherrb> we got no serious evoc submissions, right? +23:25 <agd5f> none that I saw +23:25 <+emmes> not exactly +23:26 <+emmes> the sarcast in me wants to say: as soon as they saw that this is actually work... +23:26 <+alanc> there also seemed to be some confused into thinking we'd fund general projects, not just X ones +23:27 <+alanc> the only really serious evoc project proposal I saw was the one marcheu got google to pick up because it was originally submitted to GSoC then lost +23:27 <+emmes> the wording in the blog post was pretty specific, so that cannot be the source. +23:28 <+alanc> yeah, not sure if someone just copied the list and not the info from that to pass around or if people just failed to read +23:29 <+mherrb> google translate can also introduce some mis-understandings +23:29 <marcheu> alanc: some students just think "money" and don't read through things... +23:31 <marcoz> alanc, saur.... (vikash's friend) didn't get anything submitted for evoc? +23:31 <+alanc> I've seen at least one of the GSoC students (vikash) very active on #xorg-devel +23:32 <+alanc> I don't remember seeing anything - it might be stuck in the non-subscriber moderation filters if he sent one +23:32 <+alanc> having no firm deadline also allows students to put off actually submitting +23:32 <marcoz> good on vikash; ok on saur... . do you know if emeric has been active on the dri/mesa list? +23:32 <marcoz> yea, i'm hoping vikash and he are able to work at the same time; to help keep them motivated +23:33 <marcoz> i won't hog up the channel here. +23:33 <+alanc> I don't know off hand, I personally don't watch the dri/mesa stuff as closely as xorg +23:34 <marcoz> has he been active on the xorg-devel? he's still got finals so I'm not expecting yet... +23:42 <+alanc> sorry, don't remember off hand - certainly not as memorably vocal as vikash +23:42 <+alanc> so it sounds like we're done for today, since no one has had anything new to bring up for the last 10 minutes +23:42 <+keithp> sounds about right to me +23:43 <+mherrb> agreed +23:43 <+emmes> +1 +23:43 <stukreit1> +1 +23:44 <agd5f> +1 +23:44 <+alanc> thanks all for coming - see you on May 26 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/05-26.mdwn b/BoardOfDirectors/IrcLogs/2011/05-26.mdwn new file mode 100644 index 00000000..9278c3df --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/05-26.mdwn @@ -0,0 +1,146 @@ + +Date is 2011-05-26, times are UTC+02. + +Due to anti-spaming policies, the word insur*ance had to be crippled. +[[!format txt """ +23:00 <+alanc> good afternoon +23:01 <+emmes> hey +23:01 <agd5f> hello +23:07 <+mherrb> hi +23:08 <+emmes> seems a bit slow today, doesn't it? +23:08 <+alanc> yes +23:08 <+alanc> keithp mentioned vacation +23:09 <+alanc> no sign of anholt or barts +23:09 <+alanc> I haven't seen stukreit in the office today +23:11 <+alanc> we did get mail from michael about the conference, everything sounded like it was going well there +23:11 <+Bart_Massey> Sorry for my lateness +23:12 <+alanc> you didn't miss anything except roll call +23:12 <+Bart_Massey> cool. what's current business? +23:13 <+alanc> other than acknowledging Michael's progress, I don't know of anything more to say about XDC +23:13 <+alanc> anything 501(c)3 related we need to discuss? +23:14 <agd5f> alanc: it's in the IRS's hands now. we just have to wait +23:15 <agd5f> we need to adopt a conflict of interest policy at some point +23:15 <+alanc> we should at some point start the review of bylaw changes we want to make, including the ones suggested by it +23:15 <+Bart_Massey> Good point; that's probably my job. +23:16 * alanc has been failing to keep track of our to-do list unfortunately +23:16 <+Bart_Massey> Please remind me again next meeting, when this academic year is winding down. +23:16 <+Bart_Massey> I also need to organize the Book Sprint if there's going to be one. +23:16 <+Bart_Massey> My belief is that the date for XDC 2011 is pretty much set in stone at this point, correct? +23:17 <agd5f> that's my impression as well +23:17 <+alanc> I think so +23:17 <+Bart_Massey> OK, then it's time to get the invites out. +23:17 <+Bart_Massey> I would love to have any help anyone would offer with figuring out who to invite, and with logistics. +23:18 <+alanc> what is the book sprint trying to produce? a guide for developers/contributors to Xorg? +23:18 <+Bart_Massey> Yes, specifically new developers/contributors +23:19 <+alanc> so probably want to look at the work marcheu has already done, and include him +23:19 <+Bart_Massey> Yeah, that's a no-brainer +23:19 <+Bart_Massey> Although I do want to make sure it doesn't turn into just a device-driver-writer thing. +23:19 <+emmes> I guess Michael would like a definite statement for the insur*ance. And I would assume all board members are ok with his numbers. +23:20 <+Bart_Massey> I think one of the most important areas where we're having trouble is recruiting folks who can architect X apps +23:20 <+alanc> and marcoz probably knows our existing docs best at this point to know what we can pull in or link to those +23:21 <+Bart_Massey> It wants to be short (< 30 pages) and provide a good introductory narrative for a broad range of folks, plus pointers to and interpretive help with resources +23:21 <+Bart_Massey> At least, that's what I think; we'll finalize the plan at the sprint. +23:22 <+Bart_Massey> I think Matt Dew is also an easy invite. A bunch of PDXers; keithp, cworth, jamey, josh +23:22 <+Bart_Massey> Alan, obviously :-) +23:22 <+Bart_Massey> I'm hoping to have about 8, so I figure 12 is a good invite target +23:22 <+Bart_Massey> At least for the first round +23:23 <+alanc> if you wanted to cover the build system, Gaetan might be good too +23:23 <+Bart_Massey> Good suggestion +23:24 <+alanc> emmes: for the insur*ance, it looked like the quote from the institute recommended provider was $261.75, and the alternative provider was $208.17, so in the same general range +23:25 <+Bart_Massey> I'm going to look into pricing for the guy/org who ran our book sprints for GSoC; if it's reasonable I'll come back to the Board to talk it over. Otherwise, I think I can run it myself. +23:25 <+alanc> Bart_Massey: sounds good +23:26 <+Bart_Massey> Anybody have email addrs for marcoz and gaetan handy off the top of their heads? +23:26 <marcoz> just lemme know how I can help. +23:26 <+alanc> should we vote on approving the XDC insur*ance purchase today? unfortunately, stukreit's not here to remind us of the details we require for spending +23:26 <+Bart_Massey> marcoz: thanks! +23:27 <+alanc> Bart_Massey: Matt Dew <marcoz@osource.org>, Gaetan Nadon <memsize@videotron.ca> +23:28 <+alanc> (not that I've added those to a bunch of doc bugs this week or anything) +23:28 <agd5f> alanc: the insur*ance looks good to me +23:28 <marcoz> marcoz@osource.org, memsize@videotron.ca +23:28 <+Bart_Massey> Oh, sorry; I forgot marcoz was Matt :-) +23:28 <+Bart_Massey> Thanks +23:28 <marcoz> there's too many Matts. had to change handles. :) +23:28 <+Bart_Massey> :-) +23:29 <+alanc> just got email from stukreit: "Sorry for missing this meeting. I have nothing to report re. treasury or incorporation papers." +23:31 <stukreit_> hey +23:31 <+Bart_Massey> Greetings! +23:31 <+alanc> and there he is +23:31 <stukreit_> surprized myself, made this thing work. anyway, hi +23:32 <marcoz> what time duration are you thinking for the book sprint? +23:33 <marcoz> 1/2 day. a couple days... ? +23:33 <+Bart_Massey> two full days, either just before or just after xdc +23:33 <+Bart_Massey> That might be overkill, but that just means we get to lounge around more :-) +23:33 <+alanc> stukreit_: we have two quotes for the XDC event insur*ance now from Michael - is there anything else we need before voting to approve it? (and which do we want to approve? the original $261.75 or the alternative $208.17?) +23:34 <marcoz> there's a few other things we could discuss if we have extra time. :) +23:34 <+Bart_Massey> marcoz: What's up? +23:35 <stukreit_> 2 quotes are good. if there's no difference in paperwork, let's take the cheaper one. +23:35 <marcoz> Hi Bart_Massey. just lots of documentation.... +23:35 <+alanc> marcoz: discuss now or during the book sprint? +23:36 <+Bart_Massey> Also, discuss as part of the Board mtg or thereafter? +23:36 <marcoz> i don't want to intrude into the board meeting. +23:36 <stukreit_> I hope this is the start of a discipline, where the responsibility for planning things +23:36 <+Bart_Massey> As a matter of procedure, I'll move to adjourn, and we can then camp and talk about documentation +23:36 <stukreit_> includes the legwork for getting the quotes. It was hard to get this to happenthe first time +23:37 <stukreit_> but now its on record as how things are to be done. +23:37 <+Bart_Massey> Move to adjourn +23:37 <stukreit_> end-soap-box +23:37 <agd5f> seconded +23:37 <stukreit_> +1 +23:37 <+mherrb> +1 +23:38 <+emmes> +1 +23:38 <+Bart_Massey> Thanks all! +23:39 <agd5f> whoops. were we gonna vote on the insur*ance? +23:39 <+Bart_Massey> marcoz: So what's up? +23:39 <+Bart_Massey> Oh. Oops +23:39 <+Bart_Massey> Motion to reconvene :-) +23:39 <agd5f> seconded +23:40 <stukreit_> +1 on cheaper insur*ance quote +23:40 <+Bart_Massey> Someone wanna move to do some particular thing on the insur*ance? stukreit_? +23:40 <stukreit_> "" +23:40 <+Bart_Massey> Stuart moves to take the cheaper quote. Seconded. +23:40 <+alanc> +1 +23:40 <agd5f> +1 +23:41 <+Bart_Massey> mherrb, emmes, agd5f: We need one more vote :-) +23:41 <+emmes> +1 +23:41 <stukreit_> wheee +23:42 <+Bart_Massey> Move to readjourn. :-) +23:42 <agd5f> re-seconded +23:43 <marcoz> i've got little things all over the place, but the big one pertinent here would be what needs to be done before the book sprint to help it go smoothly. +23:43 * Bart_Massey pretends alanc calls for "opposed?" and no opposition is heard +23:43 <+Bart_Massey> marcoz: That's a great question +23:44 <stukreit_> marcoz: is there a ptr in this transcriptto to the book sprint topic +23:44 * alanc heard no opposition +23:44 <marcoz> stukreit, ? +23:44 <+Bart_Massey> stukreit_: we talked about it, yes... +23:44 <stukreit_> I'll read about it in the minutes.. +23:45 <+Bart_Massey> The way that the book sprints I've played in were run, it was considered a bad idea to do too much advance planning; kind of misses the point +23:45 <+Bart_Massey> But we need to have a really clear idea of the overall product goals +23:45 <+Bart_Massey> And we need to have the right group of people in the room to meet those goals +23:45 <+mherrb> +1 on the cheaper assurance +23:46 * Bart_Massey notes that while technically the motion was already passed and the meeting adjourned, the extra vote is good have on record +23:46 <marcoz> ok. does any of the existing documentation need to be organized so people can find things if they need to? +23:46 <+Bart_Massey> Uh, yeah, that would be good, but I thought you'd already done that. :-) +23:46 <marcoz> I'm working on that, but there's a _LOT_ to do. :) +23:47 <marcoz> duplicate and contradictory stuff all over (in the wiki) +23:47 <+Bart_Massey> You have a good point; maybe a secondary goal of this sprint would be to do some group reorg of the existing online docs to the extent that we need to to make the book easier to write +23:47 <stukreit_> I'm checking out now. bye all. +23:47 <marcoz> is the book sprint mainly for driver devs or any new contributor to come up to speed in any area of X? +23:47 <+Bart_Massey> bye! +23:47 <marcoz> bye +23:48 <+Bart_Massey> But I want to make careful that we don't let it devolve into a librarian sprint---we should have one of those too, but I won't organize it :-) +23:48 <+Bart_Massey> marcoz: Any new contributor. +23:48 <+Bart_Massey> I specifically am concerned about new contributors to apps and libraries, since that's one of our most needy areas IMHO +23:48 <marcoz> agreed, not a librarian sprint. i just don't want people to have to spend 20 mins looking for 'something they kinda rememeberd but cant find now' +23:49 <+Bart_Massey> Device drivers are perceived as both sexier and easier (!) as near as I can tell +23:49 <marcoz> so we should identify in advance the most pressing needs/areas +23:49 <+Bart_Massey> Yeah, we need to write a list of goals for the book. +23:50 <+Bart_Massey> I can work on that, and post the result to the X.Org list for comments when I get a chance. I'm handicapped by the fact that I haven't been keeping up with the X.Org list lately, though. :-) Is there an RSS feed somewhere? +23:51 <marcoz> i actually started trying to do a Xorg podcast kinda like Jon Master's kernelpodcast. that didn't go far. way too much to keep up with... +23:52 <+Bart_Massey> Time is fleeting, for sure... +23:52 <marcoz> impromptu meeting. +23:52 <marcoz> you guys be here a while? +23:52 <+Bart_Massey> I've got to bail in a couple of minutes. +23:53 <+Bart_Massey> Let's chat sometime next week or week after... +23:53 <+Bart_Massey> -oo? +23:53 <marcoz> ok. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/06-09.mdwn b/BoardOfDirectors/IrcLogs/2011/06-09.mdwn new file mode 100644 index 00000000..3c2194c8 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/06-09.mdwn @@ -0,0 +1,53 @@ + +Date is 2011-06-09, times are UTC+02. + +Due to anti-spaming policies, the word insur*ance had to be crippled. +[[!format txt """ +23:00 <+alanc> hello +23:00 <agd5f> hi +23:00 <+keithp> afternoon +23:01 <stukreit_> hi +23:01 <+Bart_Massey> Howdy +23:01 <+emmes> good evening +23:03 <+alanc> mherrb sent regrets earlier today +23:04 <+alanc> that leaves anholt missing +23:05 <+alanc> I haven't seen any further requests for us to do anything for XDC since we approved the insur*ance at the last meeting +23:05 <+alanc> agd5f: any news from the lawyers? +23:05 <agd5f> alanc: nope +23:05 <stukreit_> alanc: nope +23:06 <+alanc> though we need to get working in parallel on the bylaw updates and policy writing that we already know about +23:06 <+Bart_Massey> Yeah. +23:06 <+Bart_Massey> It's Finals Week here. +23:06 <stukreit_> I am expecting them to send me some boilerplate material to start the conversation +23:06 <+Bart_Massey> Give me another week :-) +23:07 <+alanc> I'm still confused where May went - I think I blinked and it was gone, and my todo list was simply longer +23:07 <+Bart_Massey> me too +23:08 <stukreit_> it was too cold to be May, and June is turning out the same. I want a do-over for the start of summer. +23:08 <+keithp> I think it washed down the river +23:09 <+alanc> haven't seen any of the people who asked us about EVoC come back, not looking like we'll have applicants there +23:09 <+alanc> is there any other business we need to discuss? +23:09 <+Bart_Massey> Not that I'm aware of. +23:11 <+Bart_Massey> Move to adjourn. +23:11 <stukreit_> +1 +23:11 <+alanc> I guess we're still waiting for catering quotes from Michael for XDC +23:12 <stukreit_> oh- we were supposed to start getting the invitations out +23:12 <+alanc> you mean announcements? +23:12 <stukreit_> That's a timely thing. Does Michael or one of us own it? +23:12 <stukreit_> yes +23:12 <+alanc> would be good to do in the next couple of weeks, since that will give 3 months notice +23:13 <+alanc> I think the organizers have previously done the announcement by e-mail to xorg-announce/-devel/etc. +23:13 <+alanc> nothing fancy - and Michael's already sort of announced on phoronix.com +23:13 <stukreit_> the word "invitation" was used in the transcript from last meeting. perhaps in reference to the book project? +23:14 <+Bart_Massey> Yeah. +23:14 <+Bart_Massey> Will get to that next week also. +23:14 <+alanc> oh, yeah, that was Bart inviting people for the book sprint days +23:16 <+keithp> we sometimes need to provide 'invitations' for people outside the US as a part of the visa process too +23:17 <+alanc> right, but those we need to get pinged by the visitor to know who needs them +23:18 <+alanc> anyways, I'll mail michael to suggest XDC mail to xorg-announce/etal., and then I think we can go back to adjourning the meeting, unless there's anything else +23:20 <+alanc> +1 to adjourn +23:22 <+emmes> also nothing else from my side +1 +23:22 <agd5f> +1 +23:23 <+Bart_Massey> Bye all! +23:23 <+alanc> bye +23:23 <+alanc> thanks all for coming, see you in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/06-23.mdwn b/BoardOfDirectors/IrcLogs/2011/06-23.mdwn new file mode 100644 index 00000000..979802a1 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/06-23.mdwn @@ -0,0 +1,119 @@ + +Date is 2011-06-23, times are UTC+02. +[[!format txt """ +23:00 <keithp> afternoon +23:00 <matthieu> hi +23:00 <+alanc> hello +23:00 <+Bart_Massey> howdy +23:01 <stukreit_> hi +23:01 <+Bart_Massey> keithp:ca +23:01 <+Bart_Massey> keithp: Cat Allman says hi +23:01 <+Bart_Massey> keithp: Are you still in France? +23:01 <+alanc> mhopf sent regrets in direct mail +23:01 <keithp> nope, home again! +23:02 <+Bart_Massey> Welcome back! +23:02 <+alanc> are anholt or agd5f around? +23:02 <keithp> anholt is off with family today +23:02 <agd5f> hi +23:03 <+alanc> so we have at least two agenda items for XDC +23:03 <+alanc> there's the travel funding request for Martin, one of the nouveau developers who has offered to talk about nouveau +23:04 <agd5f> +1 to funding him +23:04 <+alanc> his estimated cost was ~776€ / $1100 +23:04 <mupuf> hi, I'm martin +23:05 <+alanc> welcome martin +23:05 <mupuf> thanks :) +23:05 <+alanc> sounds like a good one to me too +23:05 <stukreit_> +1 to fund +23:05 <+Bart_Massey> +1 +23:05 <+alanc> +1 +23:05 <matthieu> +1 +23:05 <keithp> +1 +23:06 <+alanc> and mhopf sent his support in his message about not being able to make it today, so it sounds as close to unanimous as we can get +23:08 <+alanc> mupuf: your request is approved - stukreit can help explain to you what sort of receipts we'll need for reimbursement of expenses and work out details of the payments +23:08 <agd5f> mupuf: let us know if you need an invitation as well for visa purposes +23:08 <mupuf> alanc: thanks a lot! I'll contact him privately when you are done with the board +23:09 <+alanc> the other XDC item was the catering expenses which michaellarabel & stukreit had exchanged e-mail about +23:09 <mupuf> agd5f: Should be fine, no need for Visas to go to the US from France +23:09 <stukreit_> mupuf: Please save receipts for air, hotel, ground transport, etc. If you're well prepared with a final figure, I can give you a check in $US currency at the conference. +23:09 <+alanc> mupuf: you can also reach him at the email address listed on http://www.x.org/wiki/BoardOfDirectors +23:10 <+Bart_Massey> You don't need a Visa or a visa either :-) +23:10 <mupuf> stukreit_: Ok, perfect. I'll prepare everything so as we can sort everything out at the conference +23:10 <mupuf> alanc: ok, thanks +23:10 <stukreit_> A rounded figure will be acceptable. +23:11 <mupuf> stukreit_: ok, perfect :) (no need to chase for cents) +23:11 <stukreit_> bart: my wife starts at Visa on monday. free cards for everybody! (not) +23:11 <+Bart_Massey> lol +23:13 <+alanc> so the last e-mail I saw on the catering was that stuart was waiting for some clarifications from IIT - did we get those? do we have close enough figures to be able to vote today? +23:14 <stukreit_> no answer from them. yawn. I'm willing to go on trust with this, they can't be totally crazy, can they? +23:16 <+Bart_Massey> Unlikely. +1 for going ahead with the catering +23:16 <+alanc> do you remember the approximate costs? I believe the quote was assuming food for 70 people, right? +23:17 <stukreit_> it was the usual, $5 to $15 per person each snack depending on the treats. +23:18 <+alanc> yes, with the usual unfortunate effect of the healthy fresh fruit being a lot more expensive than sugary baked treats +23:18 <stukreit_> no alcohol on that. We might ask them (or not ask them) if we can drag a few cases of beer in. +23:19 <+alanc> michael was also going to look into the usual offsite evening dinner/drinking after we nailed down the daytime catering too +23:19 <michaellarabel> Hi, around now. +23:20 <michaellarabel> Right, for offsite dinner still looking at that and basically just looking for any further guidance what types of places are acceptable per aforementioned concerns about dietary restrictions of some. +23:21 <+alanc> so did anyone else have anything they wanted to discuss on the catering for the conference breaks? or are we ready to vote? +23:21 <michaellarabel> And in terms of bringing a few crates of beer, i think the room agreement said that alcohol can be provided by the catering company, but it's likely just crap beer, so I'd likely ignore it anyhow. +23:21 <+alanc> does it ban byob? +23:21 <stukreit_> I'm ready to vote my +1, and I'm the most curmudgeonly one here. +23:22 <agd5f> +1 for catering +23:22 <matthieu> +1 +23:22 <keithp> +1 from me +23:22 <michaellarabel> alanc: If I remember the verbage correctly, it would ban byob, but it's something I personally would at least ignore. If bringing in like barrels/kegs at a time, that could be another story. +23:22 <+Bart_Massey> +1 +23:22 <stukreit_> alanc: question one is do they prohibit b, answer is apparently no. +23:22 <+alanc> +1 +23:23 <stukreit_> +1 +23:23 <+alanc> not that we usually have too much drinking inside the meeting room itself, mostly hanging out in bars after +23:24 <+alanc> looks like all members have voted in favor of the IIT catering +23:24 <matthieu> the last 2 pages of the excel sheet seem to place heavy restrictions on alcohol on campus. +23:24 <michaellarabel> matthieu: I'll take a look again and my interpretation. Most American places though for their legal verbage always sound overly restrictive for legal reasons. +23:25 <+Bart_Massey> I'm fine with limiting drinking to with offsite dinner in the evenings. Better than fine, actually, given some of the reports I heard from last year :-) +23:25 <+alanc> as for guidance towards places for food, I think as long as they have options for people who don't eat meat at all, or who don't eat specific types of meat (pork, etc.), it should be fine +23:25 <stukreit_> just so we know ahead of time. We dont _have_ to do it. +23:25 <agd5f> a lot of restaurants in Chicago are byob +23:26 <matthieu> Bart_Massey: afaik all alcohol drunk in Toulouse was drunk outside of the university :) +23:26 <+alanc> I think we went to a seafood place in Portland, but it had salads & pasta for the vegetarians, and you probably remember the restaurant in Toulouse as well as I do +23:26 <michaellarabel> ag5f: Yes, lots of places are BYOB for free or they will charge like a $2 'corkage fee' if bringing in your own wine/beer. +23:26 <keithp> matthieu: and that was an impressive amount :-) +23:26 <jcristau> matthieu: we only drank water in toulouse +23:26 <agd5f> I'd say lets keep the drinking to the bars so we don't get kicked out of our own conference +23:26 <+alanc> there was coffee and juice in the basement in toulouse +23:27 <michaellarabel> alanc: http://www.moescantina.com/private_booking.htm so would a menu like that be acceptable in your view? +23:27 <+alanc> the overindulgence was long after the university had locked the doors for the night and the attendees were out on the town +23:28 <+Bart_Massey> cool +23:28 <michaellarabel> Bart: had you figured out your book sprint stuff yet? +23:28 <+Bart_Massey> anyway, let's go with it. I really don't care what we do, as long as I don't have to think about it any more :-) +23:28 <+Bart_Massey> michael: no :-( +23:28 <+Bart_Massey> I've been in survival mode for the last couple of weeks. +23:28 <+Bart_Massey> I'll work on it after OSBridge finishes tomorrow +23:29 <+alanc> michaellarabel: yes, that looks like it has a safe mix to me, with plenty of veggie options +23:29 <+alanc> and kosher-ish if you don't require actual rabbinical supervision +23:29 <marcoz> Bart: let me know if/how I can help with the book sprint stuff. +23:30 <michaellarabel> that restaurant looks like it would also meet the price requirements and the downtown location is in a very nice area with many other bars around for afterwards. I also have one contact at that particular restaurant as well to hopefully work out some deal. +23:30 <+Bart_Massey> marcoz: You can indeed. Let me draft you an email here in a little bit. THanks much +23:30 <marcoz> Bart_Massey, cool and you're welcome. +23:31 <+Bart_Massey> Well, I'm going to go unless we have other pressing business... ? +23:32 <+Bart_Massey> Good to talk to all of you aga +23:32 <+Bart_Massey> in +23:32 <stukreit_> no bznss, but I heard from the lawyers that 1) Karen has moved on to gnome.org, and 2) its taking a long time to get boilerplate for conflict of interest dogs. +23:33 <stukreit_> (docs) +23:35 <marcoz> conflict of interest? is that just standard paperwork now? +23:36 <stukreit_> If you have a standard doc, please send it on! +23:36 <marcoz> no I mean conflict of interest here sounds strange. I guess I wasn't expecting that in the OSS world. +23:38 <stukreit_> Most of us are employees of companies that have an interest in what we do. +23:38 <agd5f> marcoz: it's mostly to keep the foundation from doing shady things +23:38 <agd5f> there are some related sections in out bylaws, but the lawyers would rather see a formal doc +23:38 <+alanc> marcoz: part of establishing that we are worthy to be a non-profit charity and not just acting as a front for a for-profit corporation +23:38 <agd5f> *our +23:39 <marcoz> ah gotcha. +23:39 <marcoz> i apparently am stuck in the past. i forget all the business interests. +23:40 <marcoz> and human nature. lol +23:41 <+alanc> well, the IRS sees all these big company names on http://www.x.org/wiki/BoardOfDirectors and wants to make sure we're acting properly +23:42 <+alanc> since clearly they don't know how hard it would be to get the corporate overlords at Intel & AMD to agree to conspire on anything +23:43 <stukreit_> you can throw Oracle into that clash of titans too +23:44 <+alanc> I'd have used Oracle & Red Hat as an example, but there's no Red Hat folks left on the board +23:45 <+alanc> anyways, I guess we're effectively adjourned now, since no one piped up when Bart asked before leaving +23:47 <+alanc> thanks for coming everyone, see you in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/07-07.mdwn b/BoardOfDirectors/IrcLogs/2011/07-07.mdwn new file mode 100644 index 00000000..2719a94c --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/07-07.mdwn @@ -0,0 +1,105 @@ + +Date is 2011-07-07, times are UTC+02. + +Due to anti-spaming policies, the word insur*ance had to be crippled. +[[!format txt """ +23:00 <agd5f> hello +23:00 <+alanc> good afternoon +23:00 <+Bart_Massey> howdy +23:00 <+alanc> sorry about the very late reminder +23:01 <michaellarabel> hello +23:01 * alanc is failing to be a very effective secretary the last couple months +23:01 <+anholt> hey +23:02 <+Bart_Massey> pfft +23:02 <stukreit__> hi +23:02 <+Bart_Massey> we all have calendars +23:02 <+mherrb> hi +23:02 <+alanc> and the irc transcripts make me feel slightly less guilty about the lack of summaries, but only slightly +23:03 <+keithp> shocker +23:03 <+alanc> looks like everyone but emmes has said hi +23:03 * keithp was rebooting +23:03 <+alanc> we got two e-mail requests this morning for travel sponsorship +23:04 <+keithp> yeah, oddly both from australia :-) +23:04 <+alanc> both approximately $2800 US since they're coming from the same airport +23:04 <stukreit__> I separately searched prices and yes, it really costs $1700US to go Brisbane->Chicago +23:04 <+keithp> one suspects they may have colluded on shopping +23:04 <+emmes> hey +23:04 <+emmes> sorry for being late +23:05 <+alanc> no problem, you hadn't really missed anything yet +23:05 <+emmes> yes, I can see that ;-) +23:05 <+alanc> they both are regular contributors I think we'd like to see at the conference +23:06 <+keithp> agreed. +1 for both from me +23:06 <+Bart_Massey> +1 +23:06 <+anholt> +1 +23:06 <agd5f> +1 from me +23:06 <stukreit__> +1 +23:06 <+alanc> +1 +23:06 <+keithp> we should encourage them to continue to seek for funding from their employer +23:06 <+keithp> which means figuring out a time to abandon that and use X.org funds? +23:07 <+alanc> yes, we can guarantee that they'll get reimbursed by someone in the end, but can still hope their employer picks it up first +23:07 <+mherrb> +1 with encouraging them to get funding from their employers +23:07 <+emmes> +1 +23:08 <stukreit__> +1 is it ok for us to know who this employer is? +23:08 <+keithp> stukreit__: both of them work for RedHat +23:08 <+alanc> oh, I thought you knew that, especially since the second came from an @redhat.com address +23:09 <+alanc> so I see a total of +8, calling it approved unanimously +23:09 * alanc waves at whot +23:10 <whot> thanks guys! +23:10 <+alanc> so, on to other XDC business - stukreit, did you make progress with the catering? +23:10 <stukreit__> yes, I talked to a real person today. +23:11 <stukreit__> Turns out, the phone numbers I was using have a different area code, yet the numbers were the same +23:11 <stukreit__> so, "jennifer" acks that the spreadsheet has errors and she's working on it. +23:11 <stukreit__> er +23:12 <stukreit__> we're about $1000 apart, so I'd really like a correct answer +23:12 <+keithp> that does seem like a bit far +23:12 <+emmes> ouch +23:13 <stukreit__> a funny snippet in the rules regarding alcohol: you can bring it, but you must arrange to have one of their "Professional Bartenders" at $24.50/hr. +23:13 <+alanc> or we can just walk to an actual bar +23:13 <+anholt> can't even bring your own professional bartender? +23:13 <+emmes> sounds more reasonable to me (walking to a bar) +23:13 <+Bart_Massey> Yeah, it's a pretty standard way for them to try to shift liability for serving drunk or underage attendees. +23:13 <stukreit__> In case anyone's wondering, I'm not big on ethanol myself, just that the question comes up, and people seem to enjoy it. +23:15 <stukreit__> its a non-issue. For now,I'm hoping to see them do their homework, then I can send a check and get this all settled +23:15 <michaellarabel> Phoronix Media would sponsor the 'professional bartender' if it was Bavarian female wearning dirndl / an actual beer professional.... ;) but I think that rule isn't important. If I recall correctly when I went to an IIT event before, I brought my own beer since the beer they had there I didn't like. But yeah either way no big issue since lots of Chicago bars. +23:16 <+keithp> michaellarabel: you'll get plenty of that later in the year +23:16 <stukreit__> I think for now we should start the effort to get the list of presentations and attendees built up +23:17 <+alanc> anything else we need to work on now? the room reservation all in place and deposit sent in? +23:17 <+keithp> sounds like we've got a conference scheduled, just need to get people to come +23:17 <stukreit__> money is not sent yet, but we're engaged, so no worries. +23:18 <+alanc> well, we should be able to guilt talks out of at least a couple of the people we've agreed to buy plane tickets for, but that only fills half of a day +23:19 <+alanc> oh, and I guess we need to poke Bart_Massey about the book sprint planning +23:19 <+Bart_Massey> Ya think? +23:20 <+alanc> I've been trying to avoid that, too much work to think in this heat +23:20 <+Bart_Massey> Good plan. Yeah, I've got the list of first-round invites done, but haven't sent the invitations yet, which is bad. +23:21 <stukreit__> (alanc's in a nice, sealed, a/c building all day) +23:21 <+Bart_Massey> I also need to figure out what we'll do about software / formatting / etc. +23:21 <+Bart_Massey> RSN, honest +23:22 <+alanc> michaellarabel: anything else for conference organizing you're waiting for from us? +23:24 <michaellarabel> In terms of other things for the event, anl.gov is willing to give a tour as mentioned in one of my emails, and should be no cost, if anyone is interested in that for an evening social event?? Would just be a matter of settling for a date (so opposite of any formal dinner or something). Trying to remember exactly where those labs are positioned as it might be like an hour train or bus ride, so might not be of interest to many un +23:24 <+alanc> got caught off at "of interest to many un" +23:25 <marcheu> michaellarabel: did you tell anl.giv that a lot of them aren't natives US citizens? there's a complicated process to get in there +23:25 <michaellarabel> to many unless anl.gov has like a bus.... Then in terms of restaurant if planning a dinner on one of the evenings, there was that Moe's Cantina restaurant I mentioned on the mailing list a couple weeks ago looking for feedback (price should be fine, but just in terms of if there is interest / fits the necessary dietary constraints, etc). Besides that, don't recall offhand if there was anything else major open issues still. +23:25 <marcheu> gov* +23:25 <michaellarabel> marcheu: They mentioned that a form had to be filled out in advance by foreign nationals.. hadn't looked at the form to know if it's very lengthy or not. +23:25 <+emmes> michaellarabel: forgot to mail you: I'd assume there would be interested people, at least I definitely would be +23:26 <michaellarabel> ' Non-U.S. citizens will need to complete and return an access form for processing, which takes at least 10 business days.' ... I'll ask them what the form looks like. +23:27 <marcheu> yeah it's pretty long +23:27 <+alanc> there is an events mailing list that should have the usual attendees on you could ask - people seemed to like the university/research centre tour mherrb set up last year in Toulouse +23:28 <+mherrb> apropos form, people needing a visa to get to the us should ask for an invitation letter. I can provide the model I stoled from OpenBSD conferences... +23:28 <+emmes> definitely! +23:29 <michaellarabel> Okay. +23:30 <+Bart_Massey> gtg, all. Talk to you soon! -oo +23:32 <michaellarabel> should I send any reminders to any of the other lists about the event? +23:32 <+alanc> you can if you want, probably should send one by the end of July or so +23:32 <michaellarabel> Okay, I'll just wait a week or so then. +23:33 <+alanc> anything else for today's meeting? +23:34 <michaellarabel> I doubt have anything else to add today... I believe the main thing is just having the catering get sorted out and so then Stuart is comfortable sending in the pre payment, insur*ance, etc to the venue. +23:38 <+alanc> so we're ready to adjourn? +23:39 <+mherrb> I guess yes +23:39 <+emmes> seems so +23:39 <stukreit__> adjourn: +1 +23:40 <agd5f> +1 +23:40 <+emmes> +1 +23:40 <+mherrb> +1 +23:40 <+alanc> okay, thanks everyone for coming, see you all on July 21 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/07-21.mdwn b/BoardOfDirectors/IrcLogs/2011/07-21.mdwn new file mode 100644 index 00000000..52e887d6 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/07-21.mdwn @@ -0,0 +1,112 @@ + +Date is 2011-07-21, times are UTC+02. +[[!format txt """ +23:01 <+mherrb> hi +23:02 <michaellarabel> hi +23:03 <+alanc> hello +23:03 <marcoz> howdy +23:04 <+alanc> I have mail from adg5f that he can't make it today, and emmes that he might not +23:04 <+Bart_Massey> Apologies for my lateness +23:04 <+alanc> that should give us 6 members - so far I see me, bart, and matthieu +23:04 <stukreit> hi +23:04 <+alanc> anholt_? keithp ? stukreit ? +23:04 <+anholt_> hi +23:05 <+keithp> yup! +23:05 <+keithp> (sorry, impromptu mtg) +23:07 <+alanc> okay - primary agenda item I have is XDC +23:07 <+alanc> everything going according to plan? plans lining up, payments being made, etc.? +23:07 <+Bart_Massey> I'm behind still on the book sprint. +23:07 <stukreit> payments being made +23:08 <michaellarabel> (stukriet - I just reforwarded you the contract per your email to Christian a few minutes ago) +23:08 <stukreit> checks almost in the mail +23:08 <stukreit> thanks michael +23:09 <stukreit> They still didn't update the catering spreadsheet with contacts and correct phone numbers. I'll send jennifer a ping on it. +23:09 <+alanc> Bart_Massey: yeah, got my travel approval, but been waiting to book tickets until you sent dates for the book sprint +23:09 <+Bart_Massey> Aiee. +23:09 <stukreit> Also, they ask for "If tax exempt, please include Tax Exempt letter". I don't have one +23:09 <stukreit> "dear sirs, we are tax exempt. period. have a nice day" +23:10 <+alanc> are we tax exempt until the 501(c)3 is approved? +23:10 <stukreit> duhh +23:11 <+alanc> (I'm assuming there's no news on that front since we're waiting for the government to move forward) +23:11 <stukreit> I'll ask sflc +23:11 <+alanc> are there any decisions we need the board to vote on for the conference? haven't seen any more funding request e-mail since last meeting +23:12 <+Bart_Massey> OK, ok. Book Sprint invites in next day or two. I was kind of waiting to pick dates until I'd heard from people that they were attending, but I think that's a mistake. +23:12 <stukreit> is anyone pinging the 2 australians to keep pestering their managers for support? +23:13 <+Bart_Massey> Let's just plan it for the weekend before; say 10-11 September? +23:13 <+Bart_Massey> That's a short block, but probably enough time to get something useful done. +23:14 <+Bart_Massey> What's the banking situation currently? Is that about ironed out, or are we waiting on 501(c)3? +23:14 <+alanc> marcheu and the mentors should probably look at the GSoC students who made it past midterms, and see about letting them know the board will pay for XDC trips if they can make it +23:14 <stukreit> what bankingsituation? +23:15 <+Bart_Massey> stukreit: Are we all set up as far as being easier to write checks and stuff? Is our long-term plan to stay with HSBC? +23:16 <+Bart_Massey> I've noticed that things are working better, but no idea how much of that is you working harder vs it being easier :-) +23:16 <+alanc> Bart_Massey: just remember Linux Plumbers goes until Sept. 9, not sure if any of the people you're inviting will be going to that too and need a travel day to fly from CA->IL in between +23:16 <michaellarabel> Bart_Massey: Just to make sure it wasn't forgotten about... Would your book sprint have any issues with the people that are attending if any of them are also going to the Plumbers conference? LPC doesn't end until evening of the 9th. +23:17 <+Bart_Massey> Thanks to both of you. Good point. +23:17 <stukreit> I have a backburner task of visiting hsbc office and getting them to be embarrased at the random monthly fees they've been charging us, and to see if they'll reverse them. +23:17 <+alanc> stukreit: when I mailed the aussies after the last meeting to let them know we'd approved their request, I did mention we'd appreciate continued efforts to secure employer funding +23:17 <+Bart_Massey> I guess I was just concerned that people aren't necessarily going to want to lose more business days that week, but I'd do afterward if folks think it's better. +23:18 <marcheu> alanc: alright, will do +23:18 <stukreit> alanc: did they respond with something like ack on the right thing to do? +23:19 <+alanc> peter acked on irc during the meeting, didn't see anything from ben +23:21 <+Bart_Massey> So, Book Sprint Thursday 9/15 through mid-day Saturday 9/17? +23:21 <+Bart_Massey> Anyone here think that's a bad idea? +23:22 <marcoz> what's the dates for XDC? (i can't remember offhand) +23:22 <michaellarabel> 12 - 14 +23:23 <marcoz> thx. +23:23 <stukreit> bart: a pointer to this book sprint or some generic description (other than wikipedia) +23:24 <+Bart_Massey> stukreit: Will do. It's basically a bunch of people generating a short book quickly; nothing too complicated, really. +23:24 <+alanc> there was mail about it months ago, might have been before stu was on the board list though +23:24 <marcoz> video driver development guide? +23:25 <+Bart_Massey> marcoz: Not just video drivers; general X.Org new contributor guide. +23:25 <marcoz> ah, excellent +23:25 <+Bart_Massey> marcheu's stuff will figure very prominently, though :-) +23:25 <+Bart_Massey> marcoz: You'll be able to make it, right? +23:26 <+alanc> those dates work for me +23:26 <marcoz> yep, planning on it. +23:26 <+Bart_Massey> Sweet. Alright, michaellarable and alanc, I think we have dates, so hopefully you are unblocked. +23:26 <marcoz> (Bart_Massey: i need to pester you for details on prepwork.) +23:27 <+Bart_Massey> marcoz: NP, although normally there basically isn't any. +23:27 <marcoz> ah, you've done them before? sweet. +23:27 <+Bart_Massey> Part of the game plan is to come in with a fairly clean slate and figure it out together on the fly. +23:27 <+Bart_Massey> marcoz: Yeah, a couple to produce the GSoC manuals. +23:27 <marcoz> Bart_Massey: nice. +23:28 <+Bart_Massey> I think I know enough to successfully run one. I probably won't plan to do much writing myself; mostly editing, assembly and fill. +23:28 <michaellarabel> Bart_Massey: Did you determine where you're hosting the sprint at yet? +23:28 <+Bart_Massey> I will send the rest of the invites RSN. I will also post a note to xorg-devel asking people to nominate themselves. +23:28 <+Bart_Massey> michaellarabel: Was hoping you could do that :-) +23:29 <marcoz> i don't know enough to write but I fully plan on doing lots of grunt work +23:29 <+Bart_Massey> marcoz: I disagree that you don't know enough to write :-) We'll talk. +23:29 <michaellarabel> Bart_Massey: What's the details now that you know the dates.... how many people? what kind of room requirements, etc? +23:29 <+Bart_Massey> If we have a preferred hotel, just getting a room for about 12 people to work comfortably there would be great. +23:31 <+alanc> should be a smaller conference room than the XDC meeting hall +23:31 <+Bart_Massey> In general, I'd like to keep it between 8 and 12. +23:31 <+Bart_Massey> We could also use Uni space, but we found previously that it's nice to have someplace with a really pleasant environment when one needs to get out of the work room :-) +23:31 <+Bart_Massey> I don't know how well Uni would qualify there, having never been to this one. +23:31 <stukreit> so, we're paying iit $580/day for a room for 60. A room for 12 should be quite cheap. +23:31 <michaellarabel> I'd say just find a hotel in the downtown area that's in the board's price range.... there's a range of hotels from the major chains, from low-cost Holiday Inns to Westins, etc. So I guess just depending upon how much the board wants to spend from a meeting room/ +23:32 <+Bart_Massey> Ideally, the BSers will all stay at the hotel, so moderately-priced would be good. +23:32 <+Bart_Massey> I don't think we need to go Motel-6 or anything, though. +23:32 <+Bart_Massey> Actually, a Holiday Inn would probably be fine. +23:32 <+Bart_Massey> I don't have a strong preference. Figure out something good. +23:33 <stukreit> or just get a smaller room at iit. Let's put that as one option +23:33 <+Bart_Massey> I think we have enough money to subsidize the space as needed. I trust michaellarabel to suggest something sensible, if he's willing. +23:34 <michaellarabel> I'm taking a peak right now at some major hotel chains in downtown Chicago to see what they offer... I've rented executive meeting rooms at a hotel near Midway Airport before, but that's rather inconvenient. +23:35 <+Bart_Massey> Yeah, it would be nice to be near the XDC venue so that folks don't feel obligated to move in the middle of the week. Not mandatory though. +23:35 <+Bart_Massey> We don't have a hotel block anywhere right now? +23:35 <+Bart_Massey> Or even a suggested hotel for XDC? +23:35 <michaellarabel> No hotel block at the moment... On the Wiki are some suggested places IIRC. Didn't look into a hotel block as I don't recall it for past XDC/XDS events. +23:36 <+Bart_Massey> Hotel blocks are generally a pain, but it is nice to have folks staying in the same place. +23:38 <+alanc> is there any other business we need to discuss today? +23:38 <michaellarabel> Holiday Inn seems to have business center as one of the amenities... I wonder if you all stayed there if you could just basically takeover the business center at no cost. +23:38 <+Bart_Massey> michaellarabel: No, I think we need a small conference room. The business center is usually more of a niche with a computer in it. +23:39 <marcoz> conf room with lots of white board space. +23:39 <michaellarabel> ah okay, I guess depends upon the hotel then, I've seen some nice ones, but thinking about it, also some bad ones. +23:41 <+Bart_Massey> alanc: I think we're good. +23:41 <+Bart_Massey> michaellarabel: Drop the Board some email with suggestions if you would be so kind, and we'll discuss them on email. +23:41 <michaellarabel> Okay. +23:41 <+Bart_Massey> Thanks huge! +23:43 <+Bart_Massey> Move to adjourn. +23:43 <+alanc> +1 +23:43 <+mherrb> +1 +23:44 <+alanc> thanks everyone for coming, see you in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/08-04.mdwn b/BoardOfDirectors/IrcLogs/2011/08-04.mdwn new file mode 100644 index 00000000..52efe87d --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/08-04.mdwn @@ -0,0 +1,44 @@ + +Date is 2011-08-04, times are UTC+02. +[[!format txt """ +23:00 <agd5f> hello +23:00 <+mherrb> hi +23:13 <+alanc> whoops, sorry, completely failed to notice the time +23:14 <+alanc> (or that my client had disconnected and never reconnected) +23:14 <+mherrb> hi, it's been quiet here.. you didn't miss anything. +23:15 <agd5f> everything seems to be on track for xdc +23:16 <+alanc> I saw michaellarabel & stukreit exchanged mail this morning on XDC arrangements +23:16 <michaellarabel> Yeah. (I happen to be around right now... briefly) +23:18 <+alanc> and we'd seemed to be in agreement via e-mail that we weren't really in favor of the only XDC sponsorship request that came in since the last meeting +23:18 <agd5f> what was the plan for the book sprint? after XDC or in the evenings? +23:19 <+alanc> I thought Bart had planned on two full days after XDC (so Thurs & Fri I guess) +23:19 <michaellarabel> Right, I think thats what Bart planned on... +23:19 <+alanc> evenings are already filled with bar sprint +23:20 <+alanc> (or crawl as the case may be) +23:20 <+alanc> so poking bart to pick a place for that seems to be the current top of the outstanding items on the todo list +23:23 <+alanc> anything else we need to talk about or decide on today? +23:24 <agd5f> I guess we discussed the funding request on the list already +23:25 <+mherrb> yes I agree with what was said on the list. +23:25 <agd5f> me too +23:25 <+mherrb> and no other subject on my side. +23:26 <+alanc> feel like we're a bunch of slackers on summer-vacation, but I guess if we really have no business... +23:27 <+alanc> we do need to kick the election committee into gear before too long though +23:27 <stukreit> oh crap, hi all +23:27 <+alanc> and if we're going to vote on bylaw changes then, need to start drafting those soon too +23:28 <stukreit> Doesn't look like this is a quorum today +23:45 <agd5f> and conflict of interest policy +23:45 <+alanc> yeah +23:46 <+emmes> sorry for being so late +23:46 <+emmes> friendship emergency +23:52 <+alanc> it's okay, I think today's meeting was basically a non-event +23:52 <+alanc> at least the part I showed up for 8-P +23:53 <+anholt> keithp and I were out to lunch in a more literal way than usual. +23:54 <+keithp> mmm. tacos. +23:54 <+emmes> sigh. still didn't have anything for dinner. and its 12am now. +00:10 <agd5f> move to adjorn? +00:10 <stukreit> +1 +00:11 <+alanc> +1 +00:11 <+alanc> sorry I figured everyone gave up long ago +00:11 <agd5f> me too, just being formal +00:13 <+emmes> +1 ditto +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/08-18.mdwn b/BoardOfDirectors/IrcLogs/2011/08-18.mdwn new file mode 100644 index 00000000..3be6331b --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/08-18.mdwn @@ -0,0 +1,157 @@ + +Date is 2011-08-04, times are UTC+02. +[[!format txt """ +21:44 <Corbin> Gentlemen. My wifi is quite poor, so please excuse any slowness of reply. +21:45 <Corbin> I apologize for the 11th-hour timing and not going through the proper email channel, but I would like to attend XDC, and as such would like to be compensated for my travel expenses. +21:48 <alanc> any estimate of how much that would be? +21:48 <Corbin> My "preferred" (read: least likely to lose baggage) airline is American, which quotes roughly $900 for a PDX-ORD roundtrip leaving on the 11th and returning on the 15th. I will not ask for compensation on the transit to and from PDX; I can handle that on my own. +21:49 <Corbin> I am currently only employed by OSUOSL, which has no corporate expenses. +21:49 <Corbin> ...And *man* is that lag bad. +21:53 <alanc> Corbin: plus presumably a reasonable amount for 4 nights hotel, or are you finding accomodations elsewhere? +22:38 <Corbin> alanc: I was under the impression that the Foundation only compensates travel, not accomodations. +22:40 <alanc> I believe we're paying for accomodations for everyone else we're covering this year +22:40 <alanc> since flying you in and then making you sleep under a bridge is not fair +22:40 <alanc> though if you had a friends place to crash at or someone's room to share we wouldn't complain +22:44 <Corbin> I know nobody in Chicago. Lemme go look for a cheap place to stay. +22:44 <Corbin> If nothing else, there's probably a $20/night hostel somewherer. +22:46 <Corbin> Apparently the Travelodge is recommended? +22:46 <alanc> we're paying for actual hotel rooms for other people, don't have to go dirt cheap if you don't want to +22:48 <Corbin> I would certainly enjoy a real $100/night room. Makes me feel all pampered. +23:00 <agd5f> hello +23:00 <mherrb> hi +23:01 <agd5f> Corbin: Sounds fine to me +23:03 <michaellarabel> Hi +23:03 <Bart_Massey> hi +23:03 <Corbin> Ah, Linuxcon, your wifi is so bad. :c +23:04 <alanc> hello +23:04 <michaellarabel> Corbin: The WiFi has been working great for me.. +23:04 <alanc> stukreit sent, well, not quite regrets, but notice he would be absent +23:05 <alanc> so I see 4 members so far - what about anholt & keithp? +23:05 <anholt> here +23:05 <anholt> keithp is out with a family emergency +23:05 <alanc> ok, and emmes seems to be missing as well +23:06 <agd5f> emmes said he wouldn't IIRC +23:06 <michaellarabel> emmes is in Iceland on holiday +23:06 <agd5f> wouldn't make it +23:06 <alanc> for those who weren't in channel earlier, we just got a XDC sponsorship request from Corbin (aka mostawesomedude) +23:06 <alanc> oh right, he did send that last week, I forgot +23:07 <alanc> Corbin will need ~$900 for PDX <-> ORD round trip, plus hotel +23:08 <alanc> "I am currently only employed by OSUOSL, which has no corporate expenses." +23:08 <Bart_Massey> What's he gonna talk to us about? :-) +23:09 * alanc waits to see if Corbin's wifi is working well enough to answer that... +23:09 <Corbin> Bart_Massey: Good question! I figure that I have an obligation to report on my GSoC student's progress and what it means for Mesa. +23:09 <alanc> so should we estimate a max budget of $1500 to cover airfare & hotel ? +23:10 <Corbin> That sounds like enough. More than enough, even. I presume that I will pay on my own and be compensated later? +23:10 <anholt> Corbin: that's cand, right? +23:11 <Corbin> anholt: Yes. +23:11 <anholt> he's been doing cool stuff. is he getting dragged out to talk, too? +23:11 <alanc> yes, unless it's a hardship, normally you pay, then show up at the conference with receipts which you show the treasurer (stukreit) and he writes you a check +23:12 <Corbin> Sounds reasonable. The magic of plastic has enabled me greatly in this. +23:12 <Bart_Massey> I haven't booked yet, and hadn't realized tickets will be $900. I may need to ask for some help too. I can pay part out of my travel funds, but I'm not sure if I have enough. +23:12 <Bart_Massey> +1 for Corbin +23:12 <michaellarabel> (BTW Corbin, if you were just checking PDX to ORD, you may want to try PDX to MDW too Midway is Chicago's other airport with many of the low-cost carriers, not sure which ones serve PDX though.) +23:12 <alanc> and yes, I was figuring a max of $1500 would be more than enough, but allow a little flexibility in case prices change +23:12 <Corbin> I don't know if cand's able to get across the world. I gather that there's a work-study thing going on which he has to finish? +23:13 <anholt> fair enough +23:13 <alanc> +1 for Corbin as well +23:13 <mherrb> +1 as well +23:13 <anholt> +1 too. +23:13 <agd5f> +1 +23:13 <Corbin> michaellarabel: I'll check that out. I don't think I'll get a better deal than AA though, unless there's a Southwest flight I could find. I don't fly United due to a string of bad flights a few years ago. +23:13 <Corbin> Thank you kindly, guys. +23:14 <michaellarabel> Corbin: Southwest flies to MDW along with Frontier and some other LCCs +23:14 <alanc> stukreit reported via e-mail that he had contacts with the facilities & caterers in hand +23:14 <Corbin> Then I will investigate that and see if I can get a better price. +23:15 <alanc> thanks for shopping around - helps us cover more people's expenses +23:15 <michaellarabel> alanc: what does he mean by that? Last he told me he said he had things figured out and had called them, I think this was last week. +23:15 <Bart_Massey> We need to talk about my massive fail with the book sprint. I haven't done anything to organize it for many weeks. I'm assuming we should still try to go forward, but time is getting short. +23:16 <alanc> michaellarabel: unfortunately, I didn't get more detail than was in his e-mail, so we'll have to ask him later +23:16 <Bart_Massey> I could offer a host of excuses, but I guess I'll stop at apologizing profusely and leave it at that. +23:16 <alanc> yeah, the other two XDC things I knew we needed to talk about were book sprint & sponsored dinner event +23:16 <alanc> so we'll let bart go first +23:16 <Bart_Massey> What do people think. Is it too late to do the sprint? Too late to scrub it? +23:16 <Bart_Massey> Both? +23:17 <alanc> well, if we're going forward, really need to get invites out and figure out who we need to cover expenses for +23:17 <Bart_Massey> How many of the people here are/were planning on participating? +23:17 <alanc> but other than that and finding a conference room, is there a lot of advance prep needed? +23:18 <Bart_Massey> In particular, alanc, marcheu, marcoz? +23:18 <alanc> I was going to, since I've been involved in lots of the doc work +23:18 <Bart_Massey> The problem is that if we don't have enough people it's worse than fail. +23:18 <alanc> my travel approval covered me being there all week, still need to go make my reservations though +23:18 <Bart_Massey> If I had 6 solid commitments counting myself, I would consider it "on" and get going on it right away. +23:18 <agd5f> Bart_Massey: I'd like to, but I'm still working out my travel and I'm still kind of up in the air at the moment +23:19 <Bart_Massey> agd5f---sorry didn't mean to leave you off the list; would really like to have you there. +23:19 <Bart_Massey> alanc: No, it's mostly making sure there are enough people to make it worth finding a room and booking for the extra days +23:20 <Bart_Massey> I would love input. In the absence of any strong opinions, I will (for real, this time) spend an hour or two after the meeting working on invites and nailing down commitments. +23:20 <Bart_Massey> When I get 6 "definites", I'll try to book a room. +23:20 <Bart_Massey> michaellarabel suggested a Holiday Inn near the University somewhere as a place to try. +23:21 <Bart_Massey> Are we / can we all book into the same hotel? +23:21 <alanc> if we don't do it now, probably won't try again until next year +23:21 <marcheu_> Bart_Massey: as far as I'm concerned, I can't make it to XDC, I have other plans +23:21 <Bart_Massey> alanc: and it may be harder for folks to make Dublin than Chicago: IDK +23:23 <alanc> for the north american contigent, sure - I assume gaetan is somewhere in canada based on the .ca in his e-mail, but no idea what part +23:23 <michaellarabel> Bart_Massey: I would think it still should be easy to book a conference room at Holiday Inn on short notice for reasonable amount... most major conferences and events are usually at other places as far as I know. If any other information is needed in advance, I can help out, but will be leaving Chicago the day after XDC so no on-site advice. +23:24 <Bart_Massey> michaellarabel: tx +23:24 <Bart_Massey> Anyone not think I should still try to send out invites today and see who acks? +23:24 <alanc> so I'd vote for pressing ahead to see if we can get critical mass +23:25 <Bart_Massey> I was also thinking about sending a general invite to xorg-devel for folks who want to participate to ask the Board for an invite +23:25 <Bart_Massey> Does this make sense? +23:25 <Bart_Massey> I don't want just random folks, but I imagine there are good people not on my short list +23:26 <alanc> sure +23:26 <agd5f> seems fine +23:26 <Bart_Massey> OK. I'll have an email to the Board by Saturday with a go / no-go recommendation +23:26 <alanc> just make it clear up front that this is a limited working group and that if it overflows we'll have to be selective in order to keep it a workable size +23:26 <Bart_Massey> Again, my apologies for not taking care of it in a timely fashion +23:26 <Bart_Massey> alanc: Yes +23:28 <alanc> so the other XDC item I remember us needing to decide soon was the group dinner/event +23:28 <Bart_Massey> Do we have a sponsor for this? +23:28 <alanc> I remember a proposol from michaellarabel a couple months ago for a mexican restaurant that seemed nice +23:28 <alanc> I don't think we've asked for one yet +23:29 <michaellarabel> alanc: Yeah, still waiting on hearing from you guys about the dinner.... Sent a list of possible places to the mailing list last week. +23:29 <alanc> I think the foundation paid for last years? +23:29 <Bart_Massey> I don't have any strong opinions at all about venue. Again, though, I'd suggest we start contacting sponsors ASAP. In Keithp's absence, hopefully anholt can act as a POC for Intel on this. +23:29 <alanc> and seem to remember Intel picking up the bill in Portland +23:29 <michaellarabel> For what it's worth, back at the collaboration summit, keithp talked of Intel sponsoring XDC, not sure how serious he was or not. +23:29 <Bart_Massey> IIRC Intel has usually been willing to sponsor a dinner in the past. +23:30 <anholt> Bart_Massey: hmm, not sure who keithp's contacts are, nor how I would get that arranged since I won't be there. +23:30 <alanc> Intel kicked in a big check to sponsor XDC in France, so the dinner may have just come out of that overall sponsorship +23:30 <mherrb> yes. +23:30 <Bart_Massey> anholt: Can you ask around and try to find out who at Intel would be good to contact, though? +23:31 <Bart_Massey> Whoever Keithp used last year would probably be the same one again. +23:31 <Bart_Massey> I can't think of names off the top of my head, but you might know some. +23:32 <anholt> yeah, the obvious candidate isn't in today. +23:32 <Bart_Massey> anholt: tomorrow or Monday? +23:32 <anholt> I'll take a look around again monday +23:33 <alanc> so do we want to wait to decide on dinner until we have sponsorship info? +23:34 <alanc> and is there any other XDC preparations we need to discuss today? +23:34 <Bart_Massey> I guess without sponsorship I'm disinclined to host an expensive dinner, but I don't feel strongly about it +23:35 <michaellarabel> in terms of a status update from me, I am basically just waiting on deciding for the board's decision about dinner. There's multiple ones listed in the email last week that I got no responses to. Not sure which ones comply well with dietary constraints and such of others, as stukriet said before. Also not sure which ones might already be booked or otherwise not available on the given days. The date that the dinner also ends up happening is also import +23:37 <Bart_Massey> michaellarabel: I think you're blocked on us for now. Thanks much for all the info. +23:37 <michaellarabel> your welcome, no problem. +23:39 <alanc> any other business for today? +23:40 <alanc> I know once we get past XDC we need to get our act in gear on elections cycle, bylaws update, & conflict of interest policy +23:40 <Bart_Massey> COI policy? +23:40 <Bart_Massey> That's a new one on me...what's the issue? +23:41 <alanc> one of the requirements agd5f said we had to complete from the 501(c)3 stuff +23:41 <Bart_Massey> Ah. Not arising from some new issue, then. Tx. +23:42 <agd5f> Bart_Massey: IRS wants something in place for non-profit status. SFLC can help us draft it +23:42 <Bart_Massey> 'k +23:45 <agd5f> also, new board members may want to start thinking about elections assuming we want to do them in the fall +23:46 <Bart_Massey> Let me be clear: there's not a chance I'm helping with this one this time. I've had enough of my screwing up elections. :-0 +23:50 <alanc> okay, anything else for today, or is it time to adjourn? +23:50 <Bart_Massey> move to adjourn +23:50 <mherrb> yes. I'm falling asleep :) +23:51 <agd5f> +1 +23:51 <alanc> +1 +23:51 <alanc> (for both adjuorning & sleeping) +23:51 <Bart_Massey> bye all! +23:51 <alanc> thanks everyone, see you in two weeks +23:51 <mherrb> bye +23:54 <michaellarabel> hope no one else had any other questions from me, lost my VPN connection for some minutes. +23:54 <anholt> michaellarabel: doesn't look like +23:55 <anholt> just adjourning. +23:55 <michaellarabel> okay, thanks. to the board members: just fire me off an email when figuring out the dinner plans / sponsorship or have any other questions. +23:56 <alanc> will do +23:56 <alanc> thanks for your patience and hard work putting this together +23:56 <michaellarabel> no worries +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/09-01.mdwn b/BoardOfDirectors/IrcLogs/2011/09-01.mdwn new file mode 100644 index 00000000..a5dbd7f4 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/09-01.mdwn @@ -0,0 +1,169 @@ + +Date is 2011-09-01, times are UTC+02. + +Due to anti-spaming policies, the word insur*ance had to be crippled. +[[!format txt """ +23:00 <+mherrb> hi +23:00 <michaellarabel> Hi +23:01 <+alanc> hello +23:01 <agd5f> hi +23:02 <+alanc> so keith & bart sent mail saying they couldn't make it +23:02 <+alanc> emmes sent mail saying he'd be late +23:03 <+alanc> that should leave us anholt and stukreit +23:03 <+alanc> looks like anholt lost connection just before the meeting +23:05 <stukreit> alan glaring at me. +23:05 <+alanc> well, 4 should be enough to get started +23:05 <+alanc> last meeting before XDC - all arrangements ready to go? +23:06 <+alanc> I guess we never heard from anholt or keith about funding from Intel +23:06 <stukreit> I think so. we have the milk and cookies all lined up +23:07 <michaellarabel> The venue itself should be good to go.... (Stukriet: did IIT acknowledge your insur*ance email confirmation?) per my email earlier this week, any comment about the head count we should tell catering? Still do 60 or have some slightly lesser amount considering the registered attendance count? +23:07 <stukreit> yes. iit is good +23:07 <+alanc> looks like we have 31 now +23:08 <stukreit> you might tell the caterers truthfully that we have 31, but this is a very last-minute crowd +23:08 <+alanc> so 60 may be a bit high, but wouldn't be surprised to have 40-45 +23:08 <michaellarabel> So should I tell catering then to revise the count for 45~50 to be safe? +23:08 <+mherrb> last year their was between 5 and 10 last minute people (ie people asking in the last week, since I had set a limit to 50) +23:08 <stukreit> you know, the snacks are generally not that big a deal, so if you're short, I wouldn't be embarrased +23:09 <+alanc> people who don't register in advance can't complain about not getting enough free food +23:09 <+mherrb> but there were also a similar number of registered people who didn't show up. +23:09 <stukreit> so I'm saying if we think its 31 + (10 last minute), that == 35, not 41! +23:09 <stukreit> alanc: even better point +23:10 <stukreit> which is why we should start having cutoff times for registration as well as app for sponsorship. +23:10 <stukreit> "i'm sorry i'm late" is getting old +23:10 <+alanc> and yes, no cost registration by just adding your name to a wiki means no reminder/penalty to remove if you can't make it +23:10 <michaellarabel> Okay, so should I tell catering then to prepare 40~45? +23:10 <stukreit> I say 31 +23:11 <+alanc> 40 seems reasonable to me +23:11 <stukreit> I'm just the strict dad I guess +23:11 <agd5f> 35? +23:11 <+alanc> that works too +23:11 <stukreit> alan: you're the one that offered the suggestion u snooze u lose +23:11 <+alanc> any of these should save us a little off the current 60 +23:12 <agd5f> I'd say lower is better so we don't waste food +23:12 <agd5f> IIRC, it never really all gets eaten anyway +23:12 <stukreit> The point is that I well know how nerve wracking it is to arrange an XDC, and inconsiderate attendees are no help +23:12 <stukreit> So we have 31 today, the answer is 31. +23:13 <+mherrb> unless Michael knwos some local people who wish to attend but aren't registered. +23:14 <stukreit> and someone who puts their name on the list tomorrow, or just walks over... mooches from the rest of us. But I admit, it isn't much money we're talking about. but it can irritate the organizer +23:14 <michaellarabel> The only thing I can think of is that there might be 2 or 3 people from the association of computing machinery that might be there, since we invited them for getting us the discounted room, etc. +23:14 <stukreit> I've hosted 3 expensive parties (bar mitzvahs) Bad guests are a bitch +23:14 <+alanc> well, #31 is a local I invited (Brian Cameron, long time Sun/Oracle GNOME hacker, GNOME Foundation board member, lives in Chicago) +23:16 <stukreit> 35 sounds like the consensus. I'll +1 it so we can move on +23:16 <agd5f> +1 +23:16 <+mherrb> +1 +23:16 <+alanc> 35 should cover the registered attendees plus a few students, so +1 from me too +23:17 <+alanc> so is michaellarabel or stukreit informing the caterers of our new numbers? +23:17 <michaellarabel> alanc: Yep, I am emailing them right now. +23:17 <+alanc> thanks +23:18 <+alanc> anything else we need to discuss today for the conference before moving on to the last minute travel funding requests? +23:18 <+alanc> I guess we still have no decision on a dinner without sponsorship info +23:19 <+emmes> sorry for being late... +23:19 <michaellarabel> Not that I can think of besides any potential formal dinner. I've had to tell Argonne National Laboratories 'no thanks' since they had another tour on Tuesday and so that left Monday or Wednesday and without knowing what date the possible dinner would be due to last minute scheduling of that, it would just be a potential logistical problem. +23:20 <+alanc> okay, sorry about that +23:20 <michaellarabel> Additionally, the foreign nationals would need to fill out the form, which would be due like tomorrow due to processing. +23:20 <+alanc> welcome emmes +23:20 <stukreit> ml: perhaps some lighter entertainment? It doesn't have to be techygeeky +23:21 <michaellarabel> stukreit: Any recommendations of what along the lines your thinking of? Just something as simple as saying a number of developers will be going to a Chicago Blues/Jazz bar or something afterwards or what? +23:21 <+alanc> I guess we'll poke people about sponorship via e-mail and see what we can arrange +23:22 <+emmes> stukreit: need anything for my reimbursement besides what I already sent to the list? +23:23 <+alanc> I guess it's time to discuss the sponsorship requests then +23:23 <stukreit> uh, refresh me. did you send something from the airline with the price on it? +23:24 <+alanc> emmes has requested approx. $1600 to fly from germany +23:24 <+emmes> incl. hotel, that is +23:24 <+alanc> sorry, right travel + hotel +23:25 <+alanc> and I guess the usual question about employer covering it leads into a change-of-affiliation announcement that should be publicly made at some point +23:26 <stukreit> emmes: board votes on the round number, I write check on the actual (or sorta actual) number +23:26 <+alanc> anyways, that request looked good to me, so +1 for sponsoring emmes trip for approx. $1600 +23:26 <+mherrb> +1 +23:26 <stukreit> +1 +23:26 <agd5f> +1 +23:27 <+alanc> looks like it passes unanimously among the members present and not having a conflict of interest +23:27 <+emmes> I changed my member data, blogged about about it, and can do whatever else necessary for announcing. I think it really is public now ;-) +23:28 <+alanc> emmes: edit http://www.x.org/wiki/BoardOfDirectors 8-) +23:28 <+emmes> aorry for being slow, typing from a remote screen via phone right now... +23:28 <+emmes> ok +23:28 <+mherrb> and you didn't move to Intel so it doesn't create new conflicts of interest :) +23:28 <+emmes> nope ;p +23:29 <+alanc> I hadn't noticed the blog or member data yet, just the board e-mail, so I didn't realize you'd made it public in other ways +23:30 <+alanc> in any case, we also have a request from mattst88 for I believe approx. $600 +23:30 <+alanc> flying from North Carolina + 3 nights hotel +23:30 <+mherrb> more than that iirc. +23:31 <agd5f> also jamey sharp for $850 +23:31 <+alanc> right, was doing one at a time +23:32 <+mherrb> sorry I didn't see that matt's invoice was for 2 persons. +23:32 <+alanc> mattst88's mail said $261.40 for plane ticket, $126 * 3 for hotel, but that the hotel included a fee for a second person in the room +23:32 <mattst88> mine is $700 for flight + total hotel cost. if the board wants to pick up only part of the hotel cost, that's perfectly acceptable for me +23:32 <+mherrb> so ~ 600 is right +23:33 <mattst88> (the $700 figure includes only my ticket, + hotel) +23:34 <mattst88> and if the flight dates and hotel dates don't make sense to you, it's because I'm staying with a college friend on Saturday night. +23:36 <+alanc> I'm happy with voting +1 to cover somewhere in the $600-700 range - do we want to be more specific about the hotel costs or just let it be in the noise? +23:36 <stukreit> let it go. +23:37 <+emmes> in that range i'm perfectly fine +1 +23:37 <stukreit> +1 +23:37 <+mherrb> +1 ; at some point I'd like to remind of the "owe a talk" tradition.. +23:37 <stukreit> now's a good time +23:38 <+mherrb> especially since the program is a bit sparse +23:39 <agd5f> +1 +23:39 <+alanc> mattst88: consider yourself reminded that we like the people we sponsor to talk - we don't need a formal paper or slides or anything, just a topic for discussion, and it can actually be for discussion with the crowd instead of you talking at us while we read our e-mail +23:40 <mattst88> I've been working with OLPC since june, so maybe with cjb's help I could whip up some kind of talk? I'm not sure how much time I've got with classes until Sept 12 +23:40 <+alanc> so mattst88's request is approved +23:40 <mattst88> I've certainly got plenty of laptops I could bring... :) +23:41 <+emmes> i'll think of something as well - it'll be more of a discussion than a real talk, though +23:41 <+alanc> that leaves jamey's for $850 +23:41 <+alanc> he doesn't seem to be here, but we know jamey and his work, so I don't think there'd be much to ask +23:42 <+alanc> +1 for $850 for jamey +23:42 <stukreit> +1 +23:42 <+mherrb> +1 +23:43 <+emmes> +1 slow here +23:44 <agd5f> +1 +23:45 <+alanc> okay, I'll mail him to tell him he's approved +23:45 <+alanc> any other business for today? +23:46 <michaellarabel> Speaking of the schedule/talks... was working on the schedule earlier and wanted to confirm whether the Xorg foundation wants scheduled in another 'meeting' like usual (e.g. where you've discussed logo, etc) in the past? +23:46 <+alanc> as noted in the e-mail, I declared the next normal meeting cancelled since it's the day after XDC +23:46 <+alanc> michaellarabel: yes, we should have a Board session time in the agenda +23:46 <michaellarabel> alanc: Okay, 30 minutes? hour? +23:47 <+alanc> I'd say 30 minutes - I don't think we filled an hour last time +23:47 <+mherrb> please try to program it not too late in the afternoon, so I may be able to attend on irc. +23:47 <+alanc> mherrb might remember better as he put the schedule together +23:48 <michaellarabel> mherrb: Would you like it at the start of the morning? Like first thing Monday morning would that work for you with the time difference? +23:49 <+mherrb> I don't know excalty which timezone Chigago is, but it should be 6 or 7 hours. +23:50 <michaellarabel> Chicago is CST (GMT - 5) +23:50 <+mherrb> here it's CEST (GMT+2) currently so yes 7 hrs +23:51 <michaellarabel> so would a meeting at say 9 or 10AM chicago time work out for you? +23:51 <+mherrb> yes, or even 14PM +23:51 <+mherrb> err 2PM +23:52 <michaellarabel> Okay +23:53 <michaellarabel> So in terms of any formal dinner then should I just wait on an email from you guys with decision and then see what can come up in time? +23:53 <+emmes> I asked for change of my email adr for the board list - I don't think I can do it myself... +23:55 <+mherrb> its a standard mailman list, I don't see why you couln't +23:55 <+alanc> and it looks like agd5f & anholt are the admins, according to the mailiman page for it +23:55 <+mherrb> but I didn't try changing minre recently. At least I just could get my passwd reminded. +23:56 <+emmes> well, you can't subscribe yourself :] +23:57 <agd5f> other than approving emails and marking spam, I'm not sure how to make any other changes off hand +23:57 <+mherrb> no but logging to the web interface with you old address alows to change the mail addres. +23:57 <+emmes> ok, i'll try +23:58 <+emmes> I thought the list was more closed... +23:59 <+mherrb> there may be an issue if you can't get mail at your @suse address anymore already. +23:59 <+emmes> I can't. didn't think of that, as usual. +00:00 <+alanc> anholt or daniels or tollef may be able to use root powers to fix too +00:01 <+alanc> btw, congratulations Professor on your new job! +00:01 <+emmes> ok. thanks :) +00:01 <agd5f> yeah, congrats! +00:01 <stukreit> +1, great move! +00:02 <mattst88> where are you a professor? +00:02 <+mherrb> +1 welcome back to academia +00:02 <+emmes> :) +00:03 <+emmes> the place is calles Georg-Simon-Ohm University of Applied Science +00:03 <+emmes> (or short: Ohm) +00:04 <+emmes> and located just 5mins by bike from my former employer... +00:04 <michaellarabel> Prost emmes! :) +00:06 <+emmes> so no big location change for me ;) +00:06 <+emmes> and yes, i'm currently drinking a Weizen :P +00:07 <michaellarabel> It's Thursday night in NUE, of course I would expect that. I'll have a Franziskaner shortly. +00:07 <+emmes> nevertheless, anything else or should we adjorne? +00:08 <+mherrb> nothing here. +1 for adjourn +00:08 <agd5f> +1 +00:09 <+emmes> yeah, swype is nasty :( +1 +00:10 <+alanc> +1 +00:10 <+alanc> see most of you in two weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/10-13.mdwn b/BoardOfDirectors/IrcLogs/2011/10-13.mdwn new file mode 100644 index 00000000..f2294897 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/10-13.mdwn @@ -0,0 +1,202 @@ + +Date is 2011-10-13, times are UTC+02. +[[!format txt """ +23:00 <agd5f> hi +23:00 <+alanc> good afternoon +23:00 <+alanc> hopefully everyone got today's reminder e-mail in time to actually pull off a meeting, unlike last time +23:01 <+anholt_> I got it this time +23:01 <+alanc> I got mine too, without having to poke tollef to kick mailman this week +23:03 <+alanc> so who else is here today and hasn't spoken up? emmes? keithp? stukreit? Bart_Massey? +23:03 <+Bart_Massey> Howdy! +23:03 <+Bart_Massey> Just got here a sec ago. +23:03 <+alanc> yeah, I saw the join +23:04 <+emmes> hey +23:04 <+alanc> so far I have 4 board members actually around - guess I'll quickly run down the hall to poke stuart +23:04 <keithp> afternoon! +23:04 <+emmes> I'm on the road, I might lag a bit, or drop off in between +23:04 <stukreit> hi! +23:05 <+alanc> okay, looks like that's everyone but mherrb +23:05 <stukreit> (poked) +23:05 <+alanc> first agenda item I had was XDC wrapup +23:05 <+alanc> obviously big thanks to Michael for putting it all together +23:06 <+alanc> stukreit: anything you want to report about XDC expenses/payments? +23:06 <stukreit> I guess I should write up the totals. Sorry, I don't have them today +23:06 <+Bart_Massey> Indeed! Michael went through more process than I can remember us ever having, and handled it beautifully +23:06 <stukreit> I paid off all but one expense request. +23:07 <+alanc> some of that process we need to get used to for the sake of our IRS conformance though +23:08 <stukreit> yeah, bulging files +23:09 <+alanc> and we have two worthwhile proposals to start thinking about for next year (Dublin & Nuremberg) +23:09 <+Bart_Massey> alanc: Probably. But it will be hard to find someone willing to do what Michael did in 2012 :-) +23:09 <+Bart_Massey> That's good news! I guess I missed it somehow. +23:09 <+alanc> Dave Airlie mailed the board about Dublin a month or so ago, and Luc V. presented about Nuremberg during a empty slot at XDC +23:10 <+alanc> the advantage of the Nuremberg proposal is it's at least 3 people spreading the organizational load (Luc, Egbert, & emmes) +23:11 <+Bart_Massey> And they are known-good organizationally. Also, we were just in Edinburgh not too long ago, no? +23:12 <+Bart_Massey> Maybe spreading things around a bit more is better? +23:12 <+alanc> France was 2010, so Edinburgh would have been 2008 +23:12 <+Bart_Massey> That was a long time ago. Yow. +23:13 <+emmes> We also might have the advantage of getting a free conference room, either sponsored by SuSE, or in the local university. but we haven't explored all options yet :-] +23:13 <+alanc> in any case, we have a little time to decide on next year's plan +23:13 <+alanc> anything else XDC related to discuss today? +23:13 <+Bart_Massey> Yeah, doesn't have to be this month at least. But I'd like to give a little more lead time than in 2011 just for grins... +23:14 <+alanc> the next agenda item I had was kicking the ass of the election committee to remind them it's time to start planning the election calendar +23:14 <+alanc> Since that would be the most recently elected set of board members, this year's election committee is alanc, anholt_, Bart_Massey & stukreit +23:15 <stukreit> oh loverly +23:15 <+alanc> though I guess the first step is making sure the election committee mailing list points to us, so we can start working on that by e-mail +23:15 <agd5f> The election wiki on the bod wiki is pretty good. I updated it last year +23:15 <+alanc> yes, it walked us through it pretty well last time I was on the committee +23:16 <+emmes> I can agree on that. thanks for working on it, Alex! +23:16 <stukreit> I could take a look at that next week (kinda swamped for next 5 days) +23:16 <agd5f> stukreit: looks like you are stepping up ;) +23:17 <+alanc> well, if you hadn't taken the roof off your house just before the rain started, it might be less swampy +23:17 <+alanc> in any case, I think we can consider the election committee reminded and I'll try to help out stuart as well next week getting that going +23:18 <+alanc> so the last agenda item I had was the EVoC request +23:18 <stukreit> ok. bring a crowbar and work gloves +23:18 <+Bart_Massey> Am I still the EVoC lead, or did I manage to pawn that off on someone? +23:19 <agd5f> looked good to me. maybe we can actually do an EVoC +23:19 <+alanc> we discussed trying to pawn that off on marcoz (Matt Dew) at one point, but there were no actual proposals at that time so I think we just forgot before we ever asked him about it +23:20 <marcoz> alanc: say whaa? +23:20 <+Bart_Massey> 'scool. But I should pay more attention in that case. :-) +23:20 <+Bart_Massey> marcoz: You want to be point-of-contact for the Endless Vacation of Code program? +23:20 <+Bart_Massey> It's not a very hard job; you just have to answer some emails in a timely fashion. +23:20 <+Bart_Massey> More than I can manage, though. :-) +23:20 <marcoz> what else is involved ? +23:20 <+alanc> based on the similarity in email addresses and irc nicks, I assume curro is our applicant? +23:21 <curro> yeah that's me +23:21 <curro> so i'm i the first person that has ever requested you an evoc? +23:21 <+Bart_Massey> marcoz: Just make sure that the Board is paying attention and eventually does something with each proposal +23:21 <+Bart_Massey> curro: No, but we get at most a couple of requests a year. +23:21 <+Bart_Massey> Usually we have to turn them down for some reason. +23:22 <+Bart_Massey> curro: You are still a student of some sort, correct? +23:22 <curro> Bart_Massey: yes. +23:22 <+alanc> I think only one proposal made it as far as getting approved, and then the student got a fulltime job and dropped out +23:22 <agd5f> we actually did a few the year we didn't get any gsoc slots I think, but I don't think anyone finished +23:22 <marcoz> Bart_Massey: so I just have to run people down an make sure no student gets dropped through the cracks? +23:22 <+Bart_Massey> marcoz: Yep +23:22 <+alanc> marcoz: much like you were already doing unofficially earlier this year 8-) +23:23 <+Bart_Massey> After reviewing that thread, the only question I have is do we have a mentor for curro? +23:23 <marcoz> alanc: if that's what's involved, then I could probably do that. +23:23 <+Bart_Massey> marcoz: You are awesome as always +23:24 * marcoz blushing. +23:24 <+alanc> I don't know enough about the technical details of OpenCL & Gallium to comment much on that, but the proposal did look like he'd spent time understanding the problem and coming up with a plan of attack +23:24 <curro> Bart_Massey: Ben Skeggs (darktama) stepped up to do it, but i'm not sure he's eligible for the task +23:24 <+Bart_Massey> If someone is willing to be the "official" mentor POC for curro, I'm strongly +1 +23:24 <agd5f> Bart_Massey: yes. Ben said he would. and I think Tom said he could help too +23:24 <+Bart_Massey> Why wouldn't Ben be eligible? +23:24 <curro> just wondering :) +23:24 <+Bart_Massey> AFAIK anybody the Board trusts is fine. +23:25 <+Bart_Massey> I only want a singular mentor because we need a "responsible party". The mentor can share the work as widely as desired. +23:25 <+Bart_Massey> I would strongly suggest that we insist that the mentor become a member of the X.Org Foundation, though. :-) +23:25 <+alanc> the plan said 4 months - would we be planning on basically matching the GSoC rates/timeline? ($5000 total, half at midterms, half at final, subject to mentor signoff that work has been done) +23:26 <tstellar> Yeah, I could help. +23:26 <+Bart_Massey> I would be much more comfortable if there was a way to break the work into two 2-month chunks. +23:26 <agd5f> anyone want to write up the requirements in the evoc wiki? We should actually document what we expect +23:26 <+Bart_Massey> 4 months is a long time to run without a final result. +23:27 <+anholt_> hey former elections committee: any of you have the mailman admin password saved and can update the list of members? or possibly store it on expo somewhere so I can handle it? +23:27 <+Bart_Massey> But if there's no sensible midpoint, then I'd say we need to pay a little more for 4 months than Google does for roughly 12 weeks. +23:28 <+Bart_Massey> And maybe we should break things into 3 or 4 payments instead of just 2. +23:29 <+anholt_> Bart_Massey: huh, neither of them are members currently :) +23:29 <agd5f> there are 4 items on the proposal. we could break it down per item +23:29 <+alanc> the last version of his proposal in my inbox seems to have a good midpoint " At this point the code could already be used as a working but +23:29 <+alanc> non-standard computing library." after steps 1 & 2, which are estimated at 7-8 weeks +23:29 <+Bart_Massey> agd5f: You mean general requirements for EVoC or for this specific project +23:29 <+Bart_Massey> alanc: perfect +23:29 <agd5f> Bart_Massey: general +23:29 <+Bart_Massey> I thought there was already an EVoC page. If not, I guess I should make it. +23:29 <marcoz> http://www.x.org/wiki/XorgEVoC +23:30 <+alanc> the remaining part is estimated at 5 weeks, so not exactly half way +23:30 <+Bart_Massey> alanc: Close enough. On reflection, I'm actually fine with a single project, but I want to see more frequent payment milestones than twice in 4 months. +23:30 <+alanc> but perhaps he hasn't yet learned the universal law of software scheduling yet ("The first 80% takes 80% of the planned time, the last 20% also takes 80% of the planned time.") +23:30 <agd5f> Bart_Massey: even something as simple as "aim for a 3-4 month project. $5000 total, half at midterms, half at final, subject to mentor signoff that work has been done" +23:30 <+Bart_Massey> So maybe the spot you suggested is one of those milestones. +23:31 <+Bart_Massey> agd5f: Fair enough. Working. +23:31 <+Bart_Massey> marcoz: BTW, I'm putting the target for EVoC on your back. What email address should I use? +23:32 <marcoz> marcoz@osource.org +23:32 <+Bart_Massey> tx +23:32 <+alanc> there is a finer breakdown in the first half his plan of stage 1 (roughly 3 weeks) & stage 2 (roughly 4 weeks) if you wanted to break it down further +23:32 <marcoz> is one of the requirements at least _some_ programming ability, or comfort around compilers, command line, etc. ? +23:34 <agd5f> marcoz: student has to be able to accomplish what they set out to do. doesn't have to be programming per se (could be documentation,etc.), but I think most will be +23:34 <+Bart_Massey> alanc: Sounds perfect. Payment at stage 1, stage 2 and final +23:34 <marcoz> agd5f: so documentation could fall under EvoC? dang, I wish I knew that 7 months ago. +23:34 <+Bart_Massey> marcoz: We'll help you evaluate students. I'll try to edit the reqs hints on the wiki right now, and folks can change it as they desire +23:35 <marcoz> Bart_Massey: whew, I was assuming that you guys would do the actual evalutions. I just the gopher. thanks for confirming. +23:35 <agd5f> I guess we could put the curro's proposal on the wiki as a current evoc project if we accept it +23:36 <+alanc> marcoz: I'd have been happy to see you do an evoc proposal for docs - it's not too late to turn down running the show to be a student participant... +23:36 <+Bart_Massey> marcoz: The Board never actually discussed this, so chalk it up to Board fail. I'm actually fine with technical documentation for EVoC, but we'd have to think carefully about how it would work. +23:36 <+Bart_Massey> alanc: Not sure marcoz is still a student :-) +23:36 <+Bart_Massey> So are we ready to vote curro's proposal? +23:36 <marcoz> I'm not a student. I was just thinking that I was trying to get some schlep, I mean student, to help me with the docs. but GSoC doens't accept documentation. +23:37 <+Bart_Massey> marcoz: Ahh. Yes, definitely look into this. +23:37 <+alanc> and in that case, we might ask you to evaluate, as one of the most knowledgable folks in that area currently +23:37 <marcoz> Bart_Massey: if documentation is ok for GSoC? +23:38 <+Bart_Massey> marcoz: yes +23:38 <agd5f> I think google requires code +23:38 <marcoz> it is not. :( I looked into it. +23:38 <+alanc> google is pretty firm on that one +23:38 <marcoz> it has to be coding. +23:38 <+alanc> but EVoC can be whatever we want it to be +23:40 <+alanc> so we're almost ready to vote I think +23:40 <marcoz> ok, if I can find someone to work on docs for 4 months I'll let folks know. +23:40 <+Bart_Massey> cool +23:40 <+alanc> GSoC is $5000 for 12 weeks - are we expecting this to be a 16 week project and adjusting up accordingly? +23:41 <+Bart_Massey> imho yes +23:42 <+alanc> the Oct 4 mail had a schedule of 3 weeks + 4 weeks + 3 weeks + 2 weeks, which would be just 12 +23:42 <+alanc> and I guess the question also goes to curro of how long he has to devote to this before the next semester of classes start for him +23:42 <agd5f> we should probably put some time/$ limit on it +23:43 <+Bart_Massey> agd5f: I think we need to set the whole thing up explicitly up front. +23:43 <+alanc> also curro: about when did you plan on doing this? I don't see a planned start or stop date in the mail +23:43 <agd5f> otherwise, it could be abused +23:43 <+Bart_Massey> I think the Google plan of having definite milestones up front and stopping paying the student unless they make them is fine. +23:44 <+Bart_Massey> I am confident the mentor will track this for us. +23:44 <agd5f> yeah, that should work +23:44 <+Bart_Massey> (OK, the Google plan of having the mentor verify that the whole thing is continuing to make progress/sense. It's OK if the mentor and student agree on different goals. But the milestone dates should be set in stone.) +23:44 <curro> alanc: i plan to start as soon as my proposal is accepted, and as i said i have 4 months from now that i'll be able to devote to it full-time +23:45 <+alanc> so approx Oct. 14 to Feb 14? +23:46 <curro> yes, that would work for me +23:46 <+Bart_Massey> alanc: I will block on the wiki edits until you finish... Maybe I won't have to do anything. :-) +23:46 <+alanc> oh oops, I was just fixing it to list Matt as X.Org member not Board member +23:47 <+Bart_Massey> Oh well. :-) Thanks. +23:47 * marcoz almost drunk with power. +23:47 <+Bart_Massey> LOL +23:47 <+alanc> done editing +23:47 <+Bart_Massey> tx +23:48 <+Bart_Massey> Anyway, I move that we accept curro's proposal, conditional on the mentor working out a payment schedule to our satisfaction. +23:49 <+alanc> $5000 / 12 weeks = 416.66 per week, so if we're assuming 16 weeks, it would scale to $6666.66 +23:49 <marcheu> FWIW SoC is 4500/12 weeks +23:49 <marcoz> $500 goes to the organization +23:50 <+alanc> oh, then it makes a nice rounder $6000 for 16 weeks +23:50 <marcheu> marcoz: right, not to the student +23:50 <+alanc> for some reason I was remembering $5000 to student plus $500 to org/mentor +23:51 <+Bart_Massey> Anyway, I guess I will modify my proposal to reflect that we accept curro's proposal, with three payments of $2000, milestone dates to be determined by the mentor to our satisfaction. +23:51 <marcoz> "Google will provide a stipend of 5500 USD per accepted student developer, of which 5000 USD goes to the student and 500 USD goes to the mentoring organization." +23:51 <+Bart_Massey> marcoz: Yeah, they upped their rate last year. +23:51 <marcheu> heh, I had no idea +23:51 <+Bart_Massey> Anyway, I think $6000 is a nice reasonable number. Anybody object? +23:51 <marcoz> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#payments_work (for anyone interested) +23:52 <+alanc> $6000 sounds good to me +23:52 <+alanc> +1 +23:52 <agd5f> +1 +23:53 <stukreit> +1 +23:54 <+alanc> keithp? anholt_? emmes? +23:54 <marcoz> is curro's proposal anywhere public? +23:55 <+alanc> not yet, just in board e-mail +23:55 <+Bart_Massey> marcoz: I think just on the Board list right now. Have him email you a copy. +23:55 <marcoz> Bart_Massey: will do. thx. +23:55 <marcoz> curro: can you email a copy to marcoz@osource.org? +23:57 <+emmes> sorry, dropped off. sounds good to me. +1 +23:57 <+alanc> that's 5 so we have a majority +23:57 <+anholt_> sorry, turned around for conversation in the office. +1. +23:57 <+Bart_Massey> I realized too late that GSoC starts with an initial payment. This would be a better plan. Anybody object to 4 $1500 payments instead of 3 $2000 ones? +23:58 <agd5f> fine with me +23:58 <+Bart_Massey> It's not fair to curro to ask him not to eat for a month. :-) +23:58 <curro> marcoz: done +23:58 * curro is fine either way +23:59 <marcoz> curro: thx +23:59 <+alanc> anything else, or are we done for today as we come up on the hour? +23:59 <stukreit> hey, the hour is up. +23:59 <stukreit> move to adjourn +00:00 <+Bart_Massey> seconded +00:00 <agd5f> +1 +00:00 <+Bart_Massey> Gratz curro! +00:00 <+Bart_Massey> Thanks for helping us out! +00:00 <+alanc> thanks for coming everyone, see you in two weeks +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/10-27.mdwn b/BoardOfDirectors/IrcLogs/2011/10-27.mdwn new file mode 100644 index 00000000..d0ebed7d --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/10-27.mdwn @@ -0,0 +1,190 @@ + +Date is 2011-10-27, times are UTC+02. +[[!format txt """ +23:00 <+alanc> good afternoon/evening/insert-your-timezone-here +23:00 <+emmes> hey all +23:00 <+mherrb> hi +23:00 <stukreit> hi +23:03 <+alanc> agd5f? keithp? +23:03 <+alanc> guess we're also still missing Bart & anholt +23:05 <+alanc> stukreit: any treasury things to report? all bills paid from XDC? +23:06 <agd5f> hi +23:06 <stukreit> yes, I believe IIT is all paid up due to the fact that they sent some $$ back +23:06 <+alanc> did we overpay? or from reducing our catering orders? +23:07 <+Bart_Massey> Sorry I'm late +23:07 <+alanc> it's okay - all you missed so far was stuart confirming the IIT bills were now paid for XDC +23:07 <stukreit> I am not sure. I did ask them to re-check their numbers. I don't have a page that says the catering was reduced +23:08 <+alanc> okay, sounds like all is in hand +23:08 <stukreit> should ask them again. They were sending email to Mike instead of me, then he was forwarding to me. It was confusing +23:09 <stukreit> also, I need to visit the hsbc branch and get them to stop charging us a nuisance fee "analysis" each month. Its a real wtf. +23:09 <+alanc> I didn't see any election committee e-mail, so I guess we need to kick harder to get ourselves in gear +23:10 <stukreit> I can't pull that boat anytime soon. +23:10 <+Bart_Massey> Have we asked Google for a PO for X.Org GSoC yet? +23:11 <+Bart_Massey> I think the deadline is in just a few days. +23:11 <stukreit> who was assigned that task? I hope not me +23:11 <+alanc> did we send any mentors to the summit this year? +23:11 <+alanc> I would have assumed marcheu was talking to stukreit about it +23:11 <+Bart_Massey> Not that I am aware of. Both Donnie and I were there, but were on behalf of other orgs +23:12 <stukreit> I don't have email from him +23:12 <+Bart_Massey> We need to invoice Google for our $500/accepted student org money. +23:12 <+Bart_Massey> Or they won't give it to us. :-) +23:12 <+alanc> we had 4 students, right? so $2k? +23:12 <stukreit> bart: sounds like you have most of the details..?? +23:12 <+Bart_Massey> I think that's right. I can check---just a sec. +23:14 <+Bart_Massey> Don't everybody block on me... +23:14 <stukreit> Can you write it out? perhaps the PO should come from the treasurer? (but I don't have any info on this to write it) +23:14 <+Bart_Massey> Looks like five students. +23:14 <marcheu> Bart_Massey: we had 4 students through + 1 dropped +23:15 <+Bart_Massey> Yes, they pay on dropped students also +23:15 <marcheu> right, but they don't appear in the final count +23:15 <+alanc> stukreit: I forwarded on the mails I have on it to you @gmail +23:15 <+Bart_Massey> stukreit: There's a set of links with instructions for you to follow. +23:15 <+Bart_Massey> I can dig them up again if neither alanc nor marcheu has them handy. +23:15 <+Bart_Massey> You're looking for a forwarded email from Carol Smith. +23:16 <marcheu> yeah we're going to need at least the PO # from last year, I'll have to dig it up +23:16 <+alanc> "GSoC 2011 Org Admins: Mentor Stipends + GSoC Mentor Summit Travel Payments" is the subject line of the one I forwarded +23:16 <+Bart_Massey> That's the one. +23:16 <stukreit> Do you have a previous PO or invoice for this? Or from another org, what form does it take? +23:16 <marcheu> yeah we have a previous PO +23:16 <stukreit> see it +23:16 <marcheu> I'll dig it up +23:17 <+Bart_Massey> Anyway, I forget whether the deadline to start the process is Nov 3 or Nov 7, but I think it's one or the other. +23:17 <marcheu> for example I never quite knew if the money landed last year, since I can't see the X.ORg finances +23:17 <stukreit> its a payment request form. Google is the one that writes the po +23:17 <stukreit> Give me a date to look up +23:17 <marcheu> hmm I'm mostly sure there's something I have to dig up from last year +23:17 <+Bart_Massey> stukreit: Correct. We request payment they write a PO, we respond to the PO with an invoice, they send us the money. +23:18 <marcheu> maybe an account #, it's some kind of number for sure +23:18 <+alanc> right, from what I read you fill out the payment request, google issues a PO, you issue an invoice, google issue a check +23:18 <+Bart_Massey> This is *easier* than the way they used to do it. :-) +23:18 <+alanc> marcheu: our google supplier/vendor id number I think +23:18 <marcheu> hmm right +23:18 <+Bart_Massey> alanc: Right +23:18 <stukreit> and that number is ...? +23:18 <+Bart_Massey> Someone can bug Google if we can't find it, but obviously it would be better if we could... +23:19 <marcheu> stukreit: I don't know, it's at home somewhere +23:19 <marcheu> stukreit: as I said I'll dig it up +23:20 <stukreit> k. So this will be for 5 x $500? and how much was the previous year for? (so I can hunt for it) +23:21 <+Bart_Massey> $1500 IIRC, but I'm not positive +23:21 <+alanc> plus last year I think we sent two mentors to the summit, whose expenses we paid and then google reimbursed +23:21 <stukreit> Is this a fixed amount per participant or does it include the plane tix that Carol refers to +23:21 <marcheu> stukreit: last year was 2k + summit travel costs which was just donnie +23:21 <+alanc> at least I remember sending Donnie for X.Org since gentoo already had two +23:22 <+alanc> no plane tickets this year if we didn't send anyone +23:22 <marcheu> yeah +23:22 <+Bart_Massey> AFAIK we aren't sending Donnie this year, but someone should check with him :-) +23:22 <stukreit> no travel at all? then its 5 x $500? +23:23 * Bart_Massey muses "aren't having sendeden? time tenses are indeed hard" +23:23 <+Bart_Massey> stukreit: Except somebody should ping Donnie to make sure he's not expecting reimbursement from us. +23:23 <+Bart_Massey> I'm pretty sure he's not, but it would only take one email... +23:23 <+Bart_Massey> AFAIK no one else from X.Org was even there. +23:24 <marcheu> yeah we had no one from X.Org +23:24 <marcheu> stukreit: yes 5*500 +23:24 <+Bart_Massey> marcheu: We missed you there. :-) +23:24 <marcheu> Bart_Massey: the idea of going to work on the WE didn't click +23:24 <+alanc> http://gsoc-wiki.osuosl.org/index.php/Attendee_List_2011#X.Org does list donnie +23:25 <marcheu> hmm I'll get to him then +23:25 <stukreit> cc me please +23:25 <marcheu> in any case, we can issue multiple invoices +23:25 <+Bart_Massey> marcheu: It's actually more of a big party than any kind of actual work. +23:25 <+alanc> btw, while on the topic of GSoC, are we trying for the winter code-in this year? +23:25 <marcheu> stukreit: so we could request that 5*500 now and donnie's invoice later +23:25 <+Bart_Massey> marcheu: they really prefer that we issue one invoice, and all payment requests need to be by the deadline +23:26 <+Bart_Massey> So ping donnie and if he doesn't respond by tomorrow we'll assume he's not expecting reimbursement from us +23:26 <stukreit> that's what carol's letter says: get it in by 11/4 +23:26 <+Bart_Massey> alanc: I have totally quit thinking about the Winter Code-In. Thanks for reminding me. +23:26 <+Bart_Massey> Do we want to try to do it? +23:27 <marcheu> didn't marcoz_wk volunteer at some point? ;) +23:27 <agd5f> I thought we had missed the deadline for that +23:27 <marcheu> it's really hard to get in the winter code-in anyway +23:27 <+alanc> I remember trying to make a list of proposals last year, did we get in and just not get any students or did we not get in last year? +23:28 <+alanc> The deadline for applications is 1 November at 23:00 UTC. +23:28 <marcoz_wk> marcheu: winter code-in? +23:28 <marcheu> marcoz_wk: yeah, wasn't that discussed at some point? +23:28 <+Bart_Massey> http://code.google.com/opensource/gci/2010-11/ +23:28 <+alanc> https://code.google.com/opensource/gci/2011-12/index.html +23:28 <marcheu> in any case, the odds are super low +23:29 <+Bart_Massey> I don't really want to put any energy into it. I'd say let it pass this year. +23:29 <marcheu> Bart_Massey: my feeling exactly +23:29 * Bart_Massey will be back in a couple of minutes +23:29 <+alanc> for high school students over winter break, projects that take hours or days instead of months +23:29 <marcheu> right, so for us it's something like "fix graphics driver bugs in hours or days instead of months" +23:30 <marcoz_wk> was that the high school student thing that came up on the irc channel? +23:30 <marcheu> that doesn't translate too well in the freedesktop world +23:30 <marcheu> marcoz_wk: yes +23:30 <+alanc> probably more like "write a man page for a driver that is missing one" +23:30 <marcoz_wk> marcheu: i remember someone (was that you?) asking of others were intersted. I said I was interested in helping but din't hear any more. +23:31 <marcheu> marcoz_wk: I don't think I asked. as I said the odds of us (as an org) are very low +23:31 <marcheu> but don't let that stop you from trying +23:31 <marcoz_wk> I'm always trying to recruit students (even though I'm not good at it.) you all notice the spam I sent to the ML about hpr? +23:32 <+alanc> hpr? +23:33 <marcoz_wk> hackerpublicradio. +23:33 <+alanc> oh, the radio show +23:33 <marcoz_wk> there's prob a few students that listen to it. +23:33 <+alanc> yeah, took a minute for the abbreviation to click in +23:35 <marcheu> marcoz_wk: well, you have a couple of days, get going :) +23:35 <marcoz_wk> ;) +23:35 <+alanc> http://www.x.org/wiki/GoogleCodeInIdeas is our attempt from last year that didn't get accepted +23:36 * Bart_Massey returns. whee +23:38 <+Bart_Massey> marcoz_wk: We also talked about doing a virtual Book Sprint to write an X.Org Developer's Guide at some point... +23:38 <+Bart_Massey> Honestly, I think that's higher priority for me. +23:38 <+alanc> oh, and besides kicking the election committee to schedule the elections, we also need to start drafting the proposed Bylaw changes to vote on during the election +23:38 <marcoz_wk> Bart_Massey: do we still want to do a book sprint next year or ... ? +23:39 <+Bart_Massey> alanc: I may misremember but I think that Bylaw changes require a General Meeting. +23:39 <+alanc> do we ever have those? +23:39 <+Bart_Massey> marcoz_wk: I was thinking of picking a weekend and trying to do it virtual before then. +23:39 <+Bart_Massey> alanc: Each year the conference is officially designated a General Meeting +23:39 <+alanc> ah, guess we missed this year's then +23:40 <marcoz_wk> Bart_Massey: irc, skype voice telecon, some kinda of virtual white board? +23:40 <+Bart_Massey> So I think we're looking at next Fall unless we want a virtual General Meeting, which is IMHO maybe not such a good idea. +23:40 <+Bart_Massey> marcoz_wk: All of the above? :-) Whatever cool high-techie stuff would actually work. +23:41 <+alanc> oh, and at some point we need Bart to pester his xcb cohorts into scheduling the xcb workshop we approved funding for a year or two ago, or finally give up on it +23:41 * Bart_Massey turns beet red and sputters +23:41 <marcoz_wk> Bart_Massey: I'll look into it heh. anyone's company willing to donate a conf call 'room' for a bit on the weekend? +23:42 <+Bart_Massey> marcoz_wk: I think Mumble works better for voice anyhow. +23:42 <+alanc> Bart_Massey: you need more minions, maybe keith has some spare ones you can borrow? +23:42 <+Bart_Massey> alanc: OK, I'll kick folks again. Honestly I think you have spent more time on XCB in the last six months than any of us "founders". +23:42 <marcoz_wk> Bart_Massey: i've heard of it, but haven't used it. gives me an excuse to play with something new. :) +23:42 <+Bart_Massey> alanc: I'm a college professor; I can probably find my own if I bother. +23:43 <+alanc> I just happened to remember when updating the Xorg events page last week to move XDC to past events and saw the XCB workshop still listed as TBD +23:43 <+Bart_Massey> marcoz_wk: I have a couple of servers set up. Really like it. +23:43 <+Bart_Massey> alanc: Yes. +23:43 <+Bart_Massey> So clearly, I need to figure out which of three or four X.Org-related projects I should move to the front of my queue right now. +23:43 <+Bart_Massey> Does someone else want to tackle the Bylaw changes? +23:44 <+Bart_Massey> We should really start these now; it takes a *long* time to get them right. +23:44 <+Bart_Massey> Which is how I missed the last deadline. +23:44 <+alanc> the only one I remember for sure was the 501(c)3 required conflict-of-interest rules agd5f had +23:44 <+Bart_Massey> There was also some talk of bumping the ceiling on Board Members per company by one. +23:44 <+alanc> I can try to take a look at the current ones and see what looks like we're failing to do and should change +23:45 <+Bart_Massey> There was also some procedural stuff. +23:45 <agd5f> yeah, that was the main thing. the IRC wants an explicit conflict of interest section/document +23:45 <+Bart_Massey> Someone should grub the minutes and see where we were whining about the Bylaws. +23:45 <agd5f> *IRS +23:46 * Bart_Massey thinks the IRC just wants attention. We're always taking it for granted... +23:49 <+Bart_Massey> So I'll scout around for people to work on XCB workshop and virtual book sprint. I'm massively overbooked so I'll try to find an appropriate lead for each of these and pass the ball. +23:49 <+alanc> sounds good +23:49 <marcoz_wk> Bart_Massey: I can help with the virtual book sprint. +23:49 <+alanc> sounds even better 8-) +23:49 <+Bart_Massey> I was hoping you'd say that. :-) +23:50 <+alanc> anything else we need to discuss before adjourning today? +23:50 <+Bart_Massey> We just need to revive the potential attendees list and all try to find a common weekend and tech. +23:50 <+Bart_Massey> alanc: Not from me. +23:51 <keithp> hi guys +23:51 <+Bart_Massey> keithp: Howdy! +23:51 <keithp> dr appt for my daughter +23:51 <+alanc> I don't remember if there was anyone else on the list in the silicon valley area - could probably arrange a conference room here if so to conference with folks in Portland & other locales +23:51 <keithp> now enjoying powell's city of books +23:52 <+Bart_Massey> alanc: I think we'll be OK with more ad-hoc methods, but we'll bug you if we need help. THanks! +23:53 <marcoz_wk> any interest in nuking the wiki from orbit and starting all over? +23:53 <+Bart_Massey> marcoz_wk: Probably too big a topic for this point in this meeting, but we should talk soon... +23:54 <marcoz_wk> +1 +23:55 <+alanc> so shall we adjourn this meeting? +23:55 <+Bart_Massey> Seconded +23:55 <stukreit> +1 +23:56 <+mherrb> +1 +23:56 <+alanc> see you all in two weeks, on Nov. 10 +23:56 <+alanc> at which point, DST will have ended in both the US & EU I believe +23:57 <+mherrb> yes. nov 10 I'm travelling. Not sure if I will be there... +23:58 <agd5f> +1 +23:58 <+emmes> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/11-10.mdwn b/BoardOfDirectors/IrcLogs/2011/11-10.mdwn new file mode 100644 index 00000000..c01ba4ed --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/11-10.mdwn @@ -0,0 +1,150 @@ + +Date is 2011-11-10, times are UTC+01. +[[!format txt """ +22:59 <+alanc> oh duh, I do have the password to the elections committee mailman +23:00 <+alanc> just had to dig deeper in old e-mail +23:01 <+alanc> good afternoon, btw +23:01 <stukreit> hi! +23:01 <+emmes> good news. and hi. +23:04 <+alanc> okay, elections@foundation.x.org updated now +23:04 <+alanc> nothing like meeting time to remind you to clear action items from previous meetings +23:05 <+alanc> I unsubscribed all previous members and subscribed myself, anholt, stukreit & bart, and also listed us as admins/moderators in case stuff gets stuck in spam filters +23:06 <+alanc> so are our other members here? agd5f? keithp? don't see bart or anholt in channel, and mherrb said he was travelling this week +23:06 <agd5f> hi +23:07 <+alanc> that makes 4 of us +23:08 <+alanc> stukreit: want to start off with treasurer's report? everything taken care of for getting money from google? +23:08 <keithp> alanc: hi +23:09 <stukreit> we did get the application form submitted on time +23:10 <stukreit> and have a PO number. I just pinged Stephane again about whether he'd write the invoice against this PO +23:10 <+Bart_Massey> Apologies for my lateness as usual. +23:10 <stukreit> And I have an email from Donnie with travel receipts, so his thing will go into the invoice and we'll flow the $$. +23:11 <stukreit> I need to talk to Justin, our sflc rep about whether he saw the prev. year's gsoc funds come, because his address is still on the PO. +23:12 <stukreit> Also, don't remember whether I reported last time: we have cleared up and are all paid up with IIT, so the ACM guys should be content now. +23:12 <stukreit> EOF +23:13 <stukreit> xof, ttfn... +23:13 <+Bart_Massey> peace. thanks for the report. +23:13 <+Bart_Massey> and thanks as always for the hard work. +23:14 <agd5f> we may owe taxes in delaware again soon +23:15 <stukreit> Are you the one who finds that stuff out? +23:15 <agd5f> sflc let me know last time when we were working on the 501c3 stuff +23:15 <agd5f> they are still the contacts for all that stuff +23:16 <agd5f> they recommended we get a real address +23:16 <+Bart_Massey> i thought stukreit got a box near him? +23:16 <stukreit> I volunteered my home address for 5 years. I'll ask Justin about this. +23:16 <+Bart_Massey> perfect +23:17 <agd5f> let me see if I can find out about the taxes on the delaware website +23:19 <agd5f> ok, I paid it for 2010 when I paid for 2009, but we'll need to pay 2011 next year +23:19 <agd5f> for reference the site is https://delecorp.delaware.gov/eCorp/LoginAnnualReportsCLF +23:21 <agd5f> also, FWIW, the old xorg llc still owes several thousand in back taxes +23:21 <stukreit> I do not know this. Do you have paperwork? +23:22 <stukreit> Are we accumulating penalties and interest? +23:22 <agd5f> stukreit: karen mentioned it back when we were working on the 501c3 +23:23 <agd5f> the new delaware corp isn't responsible for them +23:23 <mherrb> ho - sorry to be late. Forgot that in .pt I was 1hr early +23:24 <+alanc> welcome, thought you weren't coming at all this week +23:24 <stukreit> agd5f: ok, I'll let it lie. +23:24 <+alanc> so are we done with treasury matters? +23:25 <stukreit> unless anyone has questions or is waiting on anything.. +23:25 <+alanc> and for those who came late, I found the elections committee mailman password today and updated the list, so we should start discussing election calendar there soon +23:25 <agd5f> still might be worth talking to sflc about them at some point +23:26 <stukreit> 'k, I'll mention it. +23:26 <+alanc> libv sent mail about FOSDEM & XDC +23:27 <+alanc> sounds like FOSDEM is looking good for a joint Xorg/Wayland/ICC devroom for the weekend +23:27 <+alanc> and there's nothing the board needs to do unless/until people request travel funding to go there +23:28 <+alanc> as for XDC, I guess we need to ping airlied to see how serious he is about putting forth a Dublin proposal so we can decide soonish between that & the Nuremberg one +23:29 <agd5f> sounds good +23:29 <+emmes> yes, the earlier this is decided the better. +23:29 <mherrb> I agree +23:29 <mupuf> who will talk about wayland at the FOSDEM? +23:30 <+emmes> mupuf: this is nothing the board decides :-) +23:30 <marcoz> mupuf, are you volunteering? +23:30 <+alanc> I thought keithp had some wayland talks lined up +23:30 <mupuf> no, no. I was just wondering +23:31 <mupuf> alanc: IIRC, he wasn't sure he would get his travel funding accepted +23:31 <agd5f> I think libv has a list +23:31 <keithp> alanc: Kristian was asked to speak about wayland in the main track; I haven't gotten funding for some other wayland adventures yet though +23:31 <+emmes> keithp: but if he's already in europe for the main track, a second talk about a different, similar topic might be possible *g* +23:32 <keithp> emmes: indeed +23:32 <keithp> I don't know the status of his main track talk +23:33 <+emmes> something else: +23:33 <+emmes> As libv (and earlier Michael) noted, there was a major hickup with paying fees for XDC. +23:33 <+emmes> We can't do anything about it anymore, but I think we seriously owe them an apology. +23:34 <+emmes> Given that they had their student's rights taken away - for some finite time. +23:34 <+alanc> it wasn't clear it was on our end though, since we'd already (over)paid and gotten a partial refund from the university at the time the student group was complaining to us +23:35 <+emmes> I think you have some information I'm missing here ;-) Or I missread something. +23:35 <stukreit> fwiw, it is ack'd that iit's accounting was confusing to work with +23:35 <+alanc> if we screwed up, then yes we should apologize +23:35 <+emmes> doesn't really cost us anything, and it does help everybody to feel better. +23:36 <stukreit> I would like to understand who/what I'm apologizing for. +23:36 <+Bart_Massey> It would be nice to have a detailed, accurate account of what happened, though. Does anybody know for sure? +23:37 <stukreit> I can tell you what was happening on my end of things. +23:37 <+emmes> I have a writeup from Michael, but I'd like to hear the story from a different point of view. +23:37 <+alanc> the mail that went to the board said that Stuart paid on Oct. 19, yet the ACM chapter contacted us on Oct. 27 +23:37 <+emmes> Yes, appreciated! +23:38 <stukreit> Is Michael open about what he wrote up? I don't see it as particularly useful to our org. otherwise +23:39 <+emmes> I'll have to ask him to be on the correct side, but I'm pretty sure he's fine. I'll send it to the board mailing list +23:40 <+Bart_Massey> Thanks! +23:42 <+alanc> okay, so we'll be taking that to e-mail for the details? +23:42 <+emmes> I'd think so. It's easier to deal with. +23:43 <+alanc> okay, the other item I have a note asking to discuss today is the virtual book sprint, if Bart's had any time for organization on that +23:43 <+Bart_Massey> Not so much. +23:43 <+Bart_Massey> I've had some talks with the XCB folks about a workshop, though +23:44 <+Bart_Massey> I wish I could say we'd resolved it :-) +23:44 <+Bart_Massey> But I'll let the Board know as it progresses +23:44 <+Bart_Massey> I think right now we're in the planning dates and pricing venues stage +23:45 <+Bart_Massey> marcoz and I need to coordinate on the book sprint. +23:45 <+Bart_Massey> marcoz: where are you physically located these days? +23:46 <marcoz> Colorado +23:46 <+Bart_Massey> guess he's not around +23:46 <+Bart_Massey> oh, there you are :-) +23:46 <marcoz> sorry, stepped away for a bit +23:46 <+Bart_Massey> cool. give me a call on my cell sometime soon and we'll just discuss. +23:46 <+Bart_Massey> NP! +23:46 <marcoz> do I have your #? +23:46 <+Bart_Massey> XXX XXX XXXX +23:47 <marcoz> thx +23:47 <+Bart_Massey> Well, gtg: Got a meeting in a few minutes. come late, leave early, that's my motto +23:47 <+alanc> anything else anyone wants to discuss today? +23:48 <+Bart_Massey> thanks all! +23:48 <marcoz> anyone up for being interviewed for HPR? +23:48 <+alanc> oh, I vote to cancel the next meeting, since it falls on Thanksgiving in the US +23:48 <marcoz> thoughts on wiki rework? +23:48 <+Bart_Massey> alanc: +1 +23:48 <+Bart_Massey> marcoz: HPR? +23:48 <marcoz> hackerpublicradio (.org) +23:48 <marcoz> public radio for hackers. +23:48 <+Bart_Massey> marcoz: happy to play anytime they like. lmk. +23:48 <marcoz> anyone can send in episodes. I did 4 interviews at XDC +23:49 <+Bart_Massey> marcoz: nice +23:49 <+emmes> alanc: +1 guess it doesn't make much sense in this case +23:49 <agd5f> +1 +23:49 <stukreit> +1 +23:49 <+Bart_Massey> See you all in about 4 weeks! +23:50 <+alanc> wiki reorganization is mostly an implementation detail the board leaves up to the development community to handle, unless you need us to allocate funding or something (though please don't stomp on the board pages without talking to us first so we know where to find them) +23:51 <marcoz> no funding, more of asking about thoughts on how to do it without stomping on what's there. +23:51 <mherrb> same goes for security pages. They are a bit of mess already since the last reorganization. +23:52 <marcoz> the last thing I want to do is reorg a reorg and make things worse. +23:53 <marcoz> i can't really do much until after Dec anyway. I want to finish the docbook stuff, but I wanted to get thoughts in advance +23:54 <mherrb> Are planning to stay with MoinMoin or switch to something else? If you stick with Moin it's easy to draft some pages... +23:54 <marcoz> mherrb: my initial thinking is mediawiki +23:55 <marcoz> but i realize that move isn't quick or easy and that the fd.o admins have to set things up right? +23:56 <mherrb> as far and I understand it yes. you can still draft stuff somewhere else though. +23:56 <marcoz> i'm thinking to set something up on a separate site to try things out. +23:57 <marcoz> soas to not step on things on the wiki. mupuf and I hashed some things out at XDC. I'm gonna take that and mediawiki and see what I can do. +23:58 <mupuf> marcoz: don't hesitate to ping me if you need help +23:58 <marcoz> mupuf, guaranteed I'll be pinging you. :) +23:58 <+alanc> yes, you'll need to talk to tollef or one of the other fd.o admins if you're considering a change of software +23:59 <+alanc> I do like the way the ikiwiki on xcb.freedesktop.org lets me git clone & push to the wiki, but that's far more hacker friendly than user friendly +00:00 <marcoz> my thinking is it has to be user friendly. I really want to get more people into X, especially wiki stuff, and I think something that's wellknown and used, like mediawiki, is probably the best bet. +00:01 <marcoz> i reserve the right to be completely wrong. +00:01 <+alanc> spam protection is essential +00:02 <+alanc> (not that I'm biased from being the one to hit the despam button 50 times a week on the current wiki) +00:02 <marcoz> yea, I see the wiki recent history. you're constantly busy with that. +00:03 <+alanc> having an e-mail subscription for the wiki page "*" helps me see it soon after the spam comes in +00:03 <marcheu> stukreit: RE invoice: haven't done it yet, I think the deadline is soon +00:03 <marcheu> stukreit: will get to it +00:03 <+alanc> most of the time it's just a matter of clicking the link in the e-mail, then clicking the despam link on the page +00:04 <stukreit> alanc: there is no invoice page. we have to write one up. I think there's 30 days for this, but if I can get marcheu to do it now, all the better ;-) +00:05 <+alanc> stukreit: I was still in the wiki conversation with marcoz, not talking about invoices +00:05 <+alanc> in any case, I think we've run out of board meeting, as we passed the hour +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2011/12-08.mdwn b/BoardOfDirectors/IrcLogs/2011/12-08.mdwn new file mode 100644 index 00000000..c21bc61e --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2011/12-08.mdwn @@ -0,0 +1,181 @@ + +Date is 2011-12-08, times are UTC+01. +[[!format txt """ +23:00 <agd5f> hello +23:00 <stukreit> hey +23:00 <+alanc> good afternoon +23:00 <+emmes> good night +23:01 <+alanc> mherrb was the only person I saw e-mail from that they couldn't make it +23:01 <+alanc> so hopefully we'll see keithp, anholt & bart today +23:02 <+keithp> anholt has another meeting today +23:03 <+alanc> okay, then I guess we can get started and let Bart catchup if he comes late +23:03 <+keithp> he's given me a proxy vote for xds +23:03 <+alanc> first off: looks like our EVoC student is doing well, and hopefully stukreit has posted a check to him by now +23:03 <stukreit> its in the mail +23:04 <+alanc> and I suggested he consider going to FOSDEM if it fits into his schedule (should be around the time his project wraps up - possibly when his classes begin again though) +23:05 <+alanc> any other comments on the EVoC progress? +23:05 <+alanc> oh, yeah, and Matt & Bart got him to post his project on the wiki as a future example +23:05 <+Bart_Massey> We should make sure he knows he's semi-obligated to attend XDC this year +23:05 <+Bart_Massey> and give a talk about his work +23:05 <+Bart_Massey> sorry XDS :-) +23:06 <+alanc> since he's in Berlin, it may be even closer than FOSDEM for him +23:06 <+Bart_Massey> Indeed. +23:07 <+alanc> we should also mention that the election committee needs to get a schedule published soon if we're going to mostly match last year's schedule +23:07 <+alanc> and that's all the business I had before the main event: Dublin vs. Nuremberg +23:08 <+alanc> the board got writeups for both proposals - so what do we think? +23:08 <+Bart_Massey> In general, I tend toward the sentiment for Nuremberg, for a number of reasons. But I think they're both great proposals. +23:09 <stukreit> I got the impression that Dublin is a livelier but more expensive choice +23:09 <+alanc> I agree with mherrb's comment that having 3 organizers is an advantage over one person trying to do it all solo +23:09 <+Bart_Massey> We could do Nuremberg in 2012, Dublin in 2013, and then do Americas again in 2014? +23:09 <+Bart_Massey> AFAIK there's nothing in our charter that requires us to do strict alternation; it's just a tradition. +23:10 <+keithp> Luc has done a pretty good job running the X room at fosdem for many years +23:10 <+Bart_Massey> That would also give airlied a bit more time to get a crew together, which he might actually appreciate. +23:10 <+emmes> Bart_Massey: you're right. I think it was just standard procedure so far. +23:10 <+keithp> dublin does have a more active night life; which, after Toulouse, may not be a net positive? +23:10 <+alanc> right, I thought that was just the compromise when we cut down from trying to do both in the same year +23:11 <+Bart_Massey> We could say that the compromise is now English-speaking / non-English-speaking :-) +23:11 <+Bart_Massey> Then we could hold 2014 in Brazil :-) +23:11 <+emmes> and it's not that nuernberg has everything closed during the night. there's in fact plenty of nightlife in the inner city. +23:11 <+Bart_Massey> Anyway, keithp's point is well-taken, I think :-) +23:13 <+keithp> I like both cities, and both seem similar wrt travel, with a possible slight plus to Nuremberg given the proximity to FRA +23:13 <+Bart_Massey> I plan to travel by rail from Berlin; it's a pretty short train ride. +23:13 <+Bart_Massey> I'm not sure what the trains are like from London. +23:14 <+alanc> for venues, it seems Nuremberg has a slight edge if we can get rooms at either SuSE or the Uni, though I might be able to get some help from the Oracle Dublin office (where our GNOME team is found) - not sure what facilities they have there +23:15 <agd5f> I think google has an office there too +23:15 <+Bart_Massey> I'm thinking Nuernberg by a nose at this point; I keep hearing slight sentiment in that direction. Move to select Nuernberg, with a note to airlied thanking him profusely for the Dublin proposal. +23:16 <stukreit> Is that to say we/airlied haven't explored options at Dublin thus far? because the sentiment is leaning more towards Neuremberg? +23:16 <+keithp> stukreit: it sounds like the nuremberg proposal is slightly more 'done' at this point +23:16 <stukreit> momentum +23:16 <+alanc> airlied mentioned Trinity College, the Google offices & the Oracle offices as options in his last e-mail +23:17 <+keithp> I've been to aKademy at trinity; it was lovely +23:17 <+keithp> they rent out rooms on campus +23:17 <+keithp> and have reasonable conference facilities +23:17 <+Bart_Massey> I'm confused. Is this a different Trinity than at Oxford where we were before? +23:17 * Bart_Massey feels so...American +23:17 <+keithp> Bart_Massey: this is trinity college in dublin +23:17 <+Bart_Massey> 'k +23:18 <+keithp> and, we were at cambridge last time anyways +23:18 <+Bart_Massey> So I'll take my motion off the table if folks think we need to explore a bit more. +23:18 <+Bart_Massey> But I'm concerned that there will be no clear way to decide. +23:18 <+keithp> it's a beauty contest for the most part +23:18 <+Bart_Massey> Both seem like great proposals and I'm kinda thinking we just have to pick one and live with it. +23:19 <+Bart_Massey> keithp: exactly +23:19 <+emmes> i'll remain neutral when it comes to the decision, for obvious reasons. +23:19 <+Bart_Massey> emmes: I think there's no reason for that. +23:19 <+Bart_Massey> Proximity to the folks who will be attending is a definite plus. +23:19 <+alanc> at least we have to pick one for this year - doesn't mean we can't go to the other in a later year +23:19 <+Bart_Massey> Otherwise PDX would be terrible. +23:19 <+emmes> but bart's idea of doing nbg 2012 and dublin 2013 looks like an awsome idea for me, if that is ok with the Americans... +23:19 <+Bart_Massey> Works for me! +23:19 <+emmes> that is you guys :-P +23:20 <+Bart_Massey> We'll also have to ask airlied if he's willing to wait a year, of course. I'm guessing he'd be ok with that... +23:20 <+alanc> the magic of corporate travel - getting the approval to go anywhere in the world that requires plane tickets is about the same level of difficulty, so anywhere outside the Bay Area is mostly the same to me +23:21 <+Bart_Massey> Anybody object to the plan that has Nuernberg 2012, Dublin 2013? If not, let's get some +1s... +23:21 <+alanc> +1 +23:21 <stukreit> +1 +23:21 <+keithp> +1 +23:22 <+emmes> I'd go for 0 as I'm biased, unless we need my voice for the quorum +23:22 <+Bart_Massey> emmes: just vote for it. +23:22 <+Bart_Massey> you're supposed to be biased in favor of good things; that's why you're here :-) +23:22 <+keithp> emmes: especially if you think you can swing rooms at the university +23:23 <+alanc> with anholt & mherrb out, that leaves agd5f & emmes to vote still +23:23 <+keithp> alanc: anholt had a slight preference for dublin +23:23 <+emmes> 'key. I'm unsure with the university yet, but chances are we can get one if it's outside the lecture period +23:23 <+alanc> and mherrb for nuremberg +23:23 <+emmes> so i go for +1 to make things easy +23:24 <+keithp> nice that we actually have a choice to make this year +23:24 <+Bart_Massey> keithp: indeed. thanks huge to both proposals!! +23:24 <agd5f> Either option works for me. I don't really have an opinion either way. so, +1 +23:24 <+Bart_Massey> better yet, we have a tentative plan for 2013 already. +23:25 <+alanc> it's looking unanimous then for telling the Nuremberg folks to get started for 2012 and asking airlied about hosting in Dublin in 2013 +23:25 <+Bart_Massey> Cool. +23:25 <+emmes> I'll notify Egbert and Luc +23:25 -!- mherrb [~matthieu@gw.herrb.net] has joined #xf-bod +23:26 <+alanc> welcome mherrb +23:26 <mherrb> hi +23:26 <+Bart_Massey> Before we give up this topic: I liked the suggestion of putting together an actual informal Program Committee and putting a program together in advance. +23:26 <agd5f> although, i've been to Nuremberg, but never been to Dublin, so the traveller in me would prefer Dublin ;) +23:26 <+alanc> you just came in as we were finishing the vote for telling the Nuremberg folks to get started for 2012 and asking airlied about hosting in Dublin in 2013 +23:26 <+Bart_Massey> I would be on such a committee, or even chair it if asked, since it's good for my academic career and I know how to do it +23:27 <+Bart_Massey> But I don't need to be involved: I would just like to see it happen +23:28 <+alanc> sounds good to me, and having you help should let the conference organizers focus more on the logistics +23:30 <+Bart_Massey> We need a committee of more than one, though. I know Matthieu said he'd help. (He can chair if he prefers, of course.) +23:30 <+Bart_Massey> Any other volunteers? Anyone we should ask? +23:30 <+emmes> Bart_Massey: appreciated, very! I'd probably help from the local side with that part. +23:31 <+Bart_Massey> emmes: any help greatly appreciated +23:31 <+keithp> Bart_Massey: you realize that the 'paper review' committee work will consist almost entirely of beating the bushes to make people submit stuff early, righgt? +23:31 <mherrb> academic team :) +23:31 <+Bart_Massey> keithp: Heck yes +23:31 <+Bart_Massey> But I'd like to have us write a "formal" Call For Papers with some guidance about what and how to play, sooner rather than later. +23:32 <+alanc> it could also involve planning on better preserving the talks (posting slides/videos/notes/etc.) +23:32 <+Bart_Massey> I doubt we'll reject anybody because their proposal is too late, but I'd like to set at least some kind of soft deadline. +23:32 <+emmes> and pushing people to actually *have* slides - though it was better this year than last year :) +23:32 <+Bart_Massey> I'm still trying to figure out what kind of incentives we can offer people to propose early. +23:33 <+keithp> Bart_Massey: travel sponsorship +23:33 <+Bart_Massey> keithp: Good point. +23:33 <+alanc> speakers gifts for people who make the deadline? (tshirts or beer steins or something) +23:33 <+Bart_Massey> alanc: great idea +23:33 <+keithp> I can work on having Intel sponsor travel for a set of speakers +23:33 <+Bart_Massey> keithp: Cool. +23:34 <+Bart_Massey> I forget: what is the actual conference date? +23:34 <stukreit> +1. The sooner we square away sponsorship, the easier my job is. Hate being asked for money on the spot. +23:34 <+keithp> and, custom X.org logo beer steins for speakers would be awfully cool too :-) +23:34 <+alanc> so far we've narrowed the date down to 2012 +23:34 <+keithp> alanc: sept was the proposal +23:34 <+keithp> aligns with other 'regional festivities' that occur in Germany near there +23:34 <+alanc> probably septemberish, but I think they were waiting on exact dates until we gave them the go ahead to start reserving venues +23:35 <+Bart_Massey> OK, so I'm going to target early July as the deadline, with an explicit public plan to slip it by a couple of weeks to late July. +23:35 <+Bart_Massey> I'd like the PC to start meeting regularly until we get things going. Does this time on alternate weeks work for those here? +23:36 <mherrb> yes +23:36 <+emmes> septemberish is good, because classes start in october, so the University is still deserted. Gives a good chances for a (couple of ;) room(s) for free or at least easy money. +23:36 <+emmes> yes, it does +23:37 <stukreit> I would like to see the date be not 9/16,17,26. +23:37 <+alanc> that's when the holidays line up between the calendars this year? +23:37 <stukreit> yup +23:37 <+Bart_Massey> Sweet. See you all here next Thursday. Someone please get an email list set up for us (or we can use the Board list if the Board prefers) and let's discuss getting a few more folks on the PC. +23:38 <+alanc> if you're going to include Luc or other non-board members a separate list would probably be better +23:38 <+alanc> any other business for today's meeting? +23:38 <+Bart_Massey> Works for me. Can someone with more clue than I take care of the email list? +23:38 <+emmes> i'd suggest to have Luc and Egbert on the list, so yes. +23:39 <+alanc> next meeting should be Thursday, Dec. 22, just before the holidays +23:39 <+Bart_Massey> Let's not do that, IMHO +23:40 <+emmes> do we have to decide anything then? I guess getting the venue done was the most pressing part. +23:40 <agd5f> elections? +23:41 <+alanc> elections is the next most pressing item +23:41 <variable> when are they ? +23:41 <+alanc> if we follow last years schedule, nominations would open on Jan. 16 +23:41 <agd5f> election committee needs to decide +23:42 <+alanc> if we skip Dec. 22, then Jan. 5 is next scheduled meeting to approve the schedule, but we need to get the election committee in gear in the meantime +23:42 <stukreit> I confess to being on the e committee. What's the minimum we need to do before year end? +23:43 <+keithp> stukreit: keep breathing? +23:43 <agd5f> nothing in theory, but elections need to happen at some point. maybe decide on a schedule? +23:43 <stukreit> dig up announcements and drft new one? +23:44 <stukreit> dig up old schedule and draft new one? +23:44 <stukreit> hit snooze button? +23:44 <variable> stukreit: at least do what keithp said ;) +23:45 <+alanc> there's a checklist in the wiki +23:45 <+alanc> but yeah, drafting schedule is the next step +23:45 <stukreit> no prob. I have nothing to be anxious about. +23:46 <+keithp> stukreit: unless you have asthma +23:46 <variable> :) +23:46 <stukreit> or do you mean cop? or finals? +23:47 <stukreit> anyway, yes, I volunteer to scratch up a schedule +23:48 <+alanc> stukreit: look in your e-mail for a message from me on nov. 22 titled: "Election committee reminder." +23:48 <stukreit> thanks. got it. +23:50 <stukreit> should we adjust all dates to fall on a sunday or something? +23:51 <+Bart_Massey> GTG (literally): Thanks all! -oo +23:51 <+alanc> didn't we do Monday's last year? +23:51 <+alanc> I think we're done with the board meeting business for today +23:52 <stukreit> move to end meeting +23:52 <+alanc> oh, so did we all agree to skip Dec. 22 and just meet next on Jan. 5? +23:52 <+alanc> we can deal with election schedule by e-mail +23:53 <stukreit> sure +23:56 <mherrb> +1 +23:56 <agd5f> +1 +23:56 <mherrb> (for jan 5. meeting ) +23:56 <stukreit> +1 +23:57 <+alanc> +1 +23:57 -!- alanc changed the topic of #xf-bod to: X.Org Foundation Board: just hanging the washing up | Next meeting: *Thursday* Jan. 5, 2pm US/Pacific +23:58 <+alanc> okay, I declare the motion to skip Dec. 22 has passed and the meeting now adjourned +23:58 <+alanc> thanks for coming everyone +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/01-05.mdwn b/BoardOfDirectors/IrcLogs/2012/01-05.mdwn new file mode 100644 index 00000000..e27988c6 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/01-05.mdwn @@ -0,0 +1,178 @@ + +Date is 2012-01-05, times are UTC+01. +[[!format txt """ +23:02 <+mherrb> hi +23:02 <stukreit> hi +23:02 <+alanc> good afternoon +23:03 <egbert> hi! did you guys get my email regarding the date for xds? +23:03 <+alanc> sorry for the late reminder of the meeting, still getting back into the swing after the holidays +23:03 <+alanc> I did +23:03 <stukreit> got it +23:04 <egbert> if you have any questions - i'm here for this meeting. +23:04 <+alanc> so far I see 4 members present, Bart & emmes sent apologies, just waiting to see if anholt & agd5f are here +23:04 <+alanc> and then the XDS date is the first item I have for the agenda +23:04 <+keithp> looks like anholt got dragged to another meeting +23:05 <agd5f> hi +23:05 <+alanc> okay, I guess we'll start on the XDS date then +23:06 <+alanc> as egbert mailed, the originally propose dates conflict with some event that's booking most of the area hotel rooms, so the latest proposal moves it earlier in September +23:06 <+mherrb> I'm fine with Egbert's new proposition. +23:07 <egbert> first week of september actually. +23:07 <stukreit> works for me +23:07 <+alanc> seems fine to me too +23:07 <agd5f> fine with me +23:07 <+keithp> I'll be unable to attend that week +23:08 <egbert> there's no other option in september unfortunately. +23:08 <+keithp> that's unfortunate +23:08 <egbert> unless you want to try august of october. +23:08 <+alanc> looks like Linux Kernel Summit is August 26 - 28, 2012 San Diego, followed by LinuxCon & Linux Plumber's +23:09 <egbert> i would like to avoid the octoberfest weeks as flights might me more expensive. +23:09 <+keithp> seems likely +23:09 <+alanc> which means some people would be travelling two weeks in a row, but not overlapping +23:09 <+keithp> it's almost like late sept/earlier oct is a nice time to be in Germany +23:09 <egbert> that's when octoberfest takes place. +23:10 <egbert> it starts last week of september. +23:10 <michaellarabel> 22 Sep - 7 Oct is the Oktoberfest dates for 2012 ;) +23:10 <egbert> so you want to move it to october then? +23:11 <egbert> past the 7th? +23:11 <+keithp> I'm just one vote here, just letting you know that I'm not able to travel the first week of sept +23:11 <+keithp> we'll never align with everyone's schedule +23:12 <egbert> i can check for availibility of the room in october quickly and let you know. +23:14 <+alanc> okay +23:15 <egbert> the room is still available all thru october starting from the 7th. +23:15 <egbert> did not check the week before. +23:15 <+keithp> I'm available starting oct 9 +23:15 <egbert> one caveat: weather might not be so nice in oct. +23:16 <+alanc> it can't be worse than the years we held it in Boston in February +23:16 <+keithp> alanc: january +23:16 <+mherrb> I'm available all weeks of october for now, and I don't care about weather. +23:16 <+keithp> 1988 +23:16 <+alanc> keithp: well, that was well before my time, I was thinking of the ones HP hosted at the DEC/Compaq/HP cambridge labs +23:16 <stukreit> Have it in Tahoe, CA. Its never going to snow there ever again. +23:17 <+alanc> stukreit: it will snow as soon as you no longer have ski passes there +23:17 <egbert> ok, oct 10-12th. how about that? +23:17 <+alanc> that sounds fine to me +23:17 <stukreit> yeahm why not. +23:17 * keithp hates having the most constrained schedule here... +23:18 <+alanc> looks like that's Wed-Fri +23:18 <egbert> i've already booked the room for two weeks - i should cancel those first ;p +23:18 <agd5f> works for me +23:18 <egbert> right wed-fri. +23:18 <egbert> is there any conference in oct we may have scheduling conflicts with? +23:19 <egbert> ah - lemme check about the hotel situation. +23:19 <egbert> forgot that ... +23:19 <+alanc> the only one I've seen in a couple quick searches right now is USENIX Symposium on Operating Systems Design and Implementation, October 8?10, Hollywood, CA, but there's probably not a lot of overlap in people going to that +23:20 <invariable> BSD con is in may so no overlap there +23:20 <+alanc> (checked http://usenix.com/events/ , https://events.linuxfoundation.org/ and http://conferences.oreillynet.com/ ) +23:20 <egbert> ok, that's not a good week either. +23:21 <+Bart_Massey> Hey all. Sorry to be late. +23:21 <egbert> apparently from 8-11th there is a big fair, too. +23:21 <+alanc> actually the closest I saw to overlapping was if the OpenSuSE conference is held at the same time as last year, but I figure you'll have more insight to that than we will 8-) +23:22 <egbert> i have not heard of any plans regarding the opensuse conference. +23:22 <+mherrb> eurobsdcon will probably be in october, but there is no schedule yet. +23:22 <egbert> plus it will be in the same town ;P +23:24 <egbert> so if we do want to do it in oct we need to do it in week 43 - that's 14th-19th. +23:24 <egbert> perferrably 17th-19th. +23:25 <agd5f> that's fine with me as well +23:25 <+alanc> same here +23:25 <+Bart_Massey> That will be right around the date of the Google Summer of Code Mentor Summit. +23:25 <+Bart_Massey> But it hasn't been announced yet, so I don't know for sure. +23:25 <egbert> ah, pint is: emmes won't be able to attend as university will have started by then. +23:25 <egbert> s/pint/point/ +23:26 <agd5f> set it for whatever week works best for the organizers. I agree with whatever gets picked +23:27 <+Bart_Massey> We could flip and do Dublin this year and Nurnberg next year... +23:27 <egbert> i expect to run into similar issues again. +23:27 <egbert> with either dublin or nuernberg. +23:29 <+alanc> so right now our best bets are Sep. 5-7 without keithp or Oct. 17-19th without emmes? +23:29 <agd5f> let's just pick whatever week works best for emmes and egbert. it's not gonna work out for everyone no matter what week we pick. might was well pick something good for the organizers +23:30 <agd5f> since they are doing most of the heavy lifting +23:30 <+alanc> agreed +23:30 <egbert> ok, i will talk to emmes regarding october. +23:31 <egbert> if he's fine we will pick oct 17-19 +23:31 <+alanc> okay, so we'll let you talk this over with him and mail us later with the decision +23:31 <egbert> otherwise we stay with the sept date. +23:32 <+keithp> sounds good +23:32 <egbert> ok, can we continue this over email then? +23:32 <+alanc> yep +23:32 <+keithp> good night egbert +23:32 <egbert> i would like to finalize those things by the end of next week. +23:32 <egbert> good night keith! +23:32 <egbert> let you continue with your meeting then ;) +23:32 <+alanc> under other business, I just had two things +23:33 <+alanc> 1) a reminder to board members to help finish the 501(c)3 answers that Stuart's mailed around +23:33 <+alanc> 2) election calendar +23:34 <+alanc> Stuart had volunteered to put the election calendar together, but then the 501(c)3 stuff came up and we found Stuart has no election wiki access yet +23:34 <stukreit> I'm sure everone saw my email today about the tuesday call. Need some help on these. +23:35 <stukreit> Basically, people who have published are good candidates to help put together a few pages aggregating the available papers. +23:35 <agd5f> stukreit: send me the details and I'll hop on +23:36 <+alanc> anyone else feel like volunteering for the election calendar? we need to get that going very soon now +23:36 <stukreit> ok, I can forward you email from some folks who list their papers, we need to build up a single place where all that stuff can be found +23:37 <agd5f> keithp had a bunch of X papers as well. maybe we can add them? +23:37 <stukreit> yes, my multitasking self isn't up to it. +23:37 <stukreit> agd5f: sure. If you have the list or keith can send to us, just start hashing up a wiki pages. +23:37 <+Bart_Massey> My stuff is at http://www.cs.pdx.edu/~bart/bib.html +23:37 <invariable> alanc:what needs to be done for the calendar ? +23:38 <stukreit> We need to herd up the mentors and students to give us their best verbage too +23:38 <agd5f> keith's: http://keithp.org/~keithp/talks/ +23:38 <+alanc> one of the board members on the elections committee needs to figure out when we'll do each part of the elections process this year +23:39 <+Bart_Massey> I can add you to the X.Org GSoC Mentor and Student lists for the years I was running it if you like. +23:39 <+alanc> keith's list predates the current org though +23:39 <agd5f> I can walk whoever does it through the process. I did it last year +23:39 <+Bart_Massey> It's going to be hard to track down a lot of those folks though. +23:39 <marcoz> silly question here, are all these papers and stuff for the election calendar? (i think I'm missing something.) +23:39 <+Bart_Massey> marcoz: No, for 501(c)3 +23:39 <+alanc> marcoz: no, sorry, started two parallel conversations +23:40 <marcoz> ah whew, so I wasn't loosing my mind. thx. +23:40 <+alanc> the papers and stuff were for the item #1 I listed, where we need to gather some more details to support our IRS application for non-profit status for the Foundation +23:41 <marcoz> gotcha. thx +23:42 <+alanc> (which is mostly happening in private e-mail between the Board and our SFLC attorneys, for reasons of attorney-client privilege, so sorry if this bit doesn't make sense to the non-board members in attendance) +23:44 <stukreit> ok, so re elections: I'd like someone to own the task of drafting the schedule. +23:45 <+alanc> I can do it if no one else is volunteering +23:46 <stukreit> thanks! +23:47 <+alanc> so does anyone else have anything to add to the conversation, or are we done for today? +23:47 <agd5f> once you nail down the weeks, it's mostly just a matter of copy and pasting announcement emails +23:48 <agd5f> since the major holidays have passed, the next couple months should be pretty open +23:49 <+alanc> yeah, no one is really going to notice the impact of President's day on the election schedule +23:52 <+alanc> okay, seems like time to adjourn the meeting for today +23:52 <marcoz> 2 things. 1) book sprint & 2) any evoc updates? +23:52 <agd5f> evoc seems to be going well +23:52 <+alanc> oh, right +23:52 <marcoz> 2 people have responded to the booksprint emails. I may have to start getting annoying. +23:52 <agd5f> curro is making good progress and seems to be on target +23:53 <+alanc> do we need to vote on sending him his next check for the evoc work, since he submitted another good progress report? +23:53 <marcoz> i like the progress he's making, even if I don't understand a lot (most?) of what he types. +23:53 <+alanc> also, I assume the board members are all in favor of funding his trip to FOSDEM to present it +23:53 <+alanc> since we pretty much agreed on that over e-mail +23:53 <+Bart_Massey> alanc: +1 for trip funding, +1 for funding the next payment +23:53 <agd5f> current evoc progress: http://wiki.x.org/wiki/XorgEVoC/GalliumCompute +23:54 <+alanc> so this should be $1500, with $1500 left for the last period +23:54 <agd5f> +1 trip and +1 for next paymant +23:54 <+mherrb> +1/+1 +23:54 <stukreit> ok, another check. +23:54 <+alanc> +1 to both for me too +23:54 <stukreit> =1 +23:55 <stukreit> +1 +23:55 <+keithp> +1 +23:56 <+alanc> okay, I'll call that unanimous for sending $1500 for this evoc milestone, and for funding the FOSDEM trip +23:57 <+alanc> that just leaves answering marcoz's questions about when to hold the book sprint +23:57 <agd5f> so far we've executing this evoc well. we should add it to our IRS list. +23:58 <+alanc> yes +23:59 <marcoz> alanc, keithp, marcheu, Bart_Massey: any time Mar-Apr for v book sprint? +23:59 <+Bart_Massey> Yeah, that time frame is fine for me. +23:59 <+keithp> wfm +23:59 <+Bart_Massey> We'll have to negotiate specific dates, but I think they're mostly good. +00:00 <marcoz> ok, i'll badger Jamey, Josh, Gaetan and Carl +00:00 <+alanc> yeah, I can't think of any specific constraints there right now +00:00 <marcoz> marcheu, ? +00:01 <marcheu> March is better for me, I intend to take holidays in April +00:04 <marcoz> any objections here for Mar? keithp, you're back 1st week in Mar right? +00:04 <+keithp> marcoz: yup +00:06 <marcoz> Is it safe to assume a weekend is better than 2/3 week days? +00:06 <+Bart_Massey> much +00:10 <+alanc> okay, since we've died down again, I move to adjourn the meeting for today +00:11 <+keithp> alanc: +1 +00:11 <agd5f> +1 +00:11 <+Bart_Massey> +1 +00:12 <+alanc> thanks for coming everyone, see you here in two weeks - board members don't forget the Tuesday call with the SFLC guys +00:14 <egbert> good night! +00:18 <+mherrb> Zzz +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/01-19.mdwn b/BoardOfDirectors/IrcLogs/2012/01-19.mdwn new file mode 100644 index 00000000..c6fbf950 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/01-19.mdwn @@ -0,0 +1,113 @@ + +Date is 2012-01-19, times are UTC+01. +[[!format txt """ +23:02 <+alanc> good afternoon +23:02 <+Bart_Massey> Hi all +23:02 <+emmes> hey +23:03 <+Bart_Massey> Looks like I'll be in Wurzburg 2nd or 3rd week of April; don't know if that fits with anybody's schedule. Teaching at FHWS for a week. +23:03 <+alanc> so shall we start with the XDS dates from Egberts mail? +23:04 <egbert> looks like everybody received my email. +23:05 <+emmes> thanks a lot, again, for that tremendously difficult work +23:05 <+alanc> sounds like the choices are the beginning of September without Keith, or that final weekend in September if we want to let him attend +23:05 <egbert> there are still several unknowns there. +23:06 <+alanc> speaking of which, keithp? anholt? you here today? +23:06 <egbert> it could be that our best bets would be either early september or over weekends. +23:06 <egbert> either 21-23 or 28-30 +23:06 <egbert> i'd now even favor the second. +23:06 <+Bart_Massey> Is there a problem with 9/21-9/23? +23:07 <egbert> there is a chance that we can do it during week 3 but this is an option i still need to wait for feedback. +23:07 <+Bart_Massey> I'm fine with either 9/21-23 or 9/28-30 +23:07 <+alanc> oops, sorry, I missed there were two weekends listed there +23:07 <egbert> so let's plan for the worst case scenario. +23:07 <+mherrb> I'd prefer 21-23. I have to be in Switerland 24-28. +23:07 <egbert> could be that i know more by eob tomorrow. +23:08 <+Bart_Massey> Are there issues with 9/21-23 that anyone is aware of? +23:08 <egbert> ok, let's aim for 21-23. +23:08 <egbert> hi keith. +23:09 <egbert> we are just contemplating about the date for xds. +23:09 <keithp-phone> Eric and i are at lunch +23:09 <egbert> you may have seen my email. +23:09 <keithp-phone> Yes +23:09 <keithp-phone> Eric slso likes the later date +23:09 <+Bart_Massey> We're going to hold XDS 2012 9/21-9/23 unless someone has a reason this might not work, I think? +23:10 <egbert> currently i'm still waiting for some feedback but until now i'm sure about weekend dates. +23:10 <+alanc> which is the earlier of the later dates +23:11 <egbert> and as i said i'm still waiting for feedback if the room or i can be available during week 3 in september. +23:11 <egbert> but this is less than sure. +23:11 <egbert> point is: there is susecon in exactly this week. +23:12 <+Bart_Massey> I'm not understanding. You say that there is a conflict with 9/21-9/23? +23:12 <egbert> so it looks like we can aim for 21-23 if we cannot get a more favorable date. +23:12 <+alanc> I see, Sept. 18–21, 2012 Caribe Royale Hotel Orlando, FL +23:12 <+Bart_Massey> Ah +23:12 <egbert> right. but 21-23 should be ok. +23:13 <+Bart_Massey> well, 9/28-9/30? +23:13 <egbert> i may not be available earlier in case i'm needed and the room may not be available either. +23:13 <+alanc> that will be tight for flying back to set up for you +23:13 <+alanc> but hopefully your two co-organizers can help with that +23:13 <egbert> if i have to go i don't have to be there all week. +23:14 <egbert> or maybe not at all. +23:14 <egbert> but i need to find out. i also need to find out if the room is needed for some video feed or not. +23:14 <+alanc> okay, so it sounds like the board preference is for the 21-23, but we need to wait on Egbert to find out about availability before deciding for sure +23:14 <egbert> that's the feedback i'm waiting for. +23:15 <+alanc> if necessary, we can probably find a volunteer to spend a week in Florida on your behalf +23:15 <egbert> as said i should know more by eob tomorrow. we should then be able to continue this by email. +23:16 <+alanc> okay, thanks for the update and we look forward to more via e-mail +23:16 <egbert> the other thing i'm also exploring is if we can get decend rates for rooms even during the trade shows when we bring in enough people. +23:17 <egbert> but this is a route i don't really want to go. i'd rather negotiate rates for rooms at the hotel for days with no special events. +23:18 <egbert> ok, so let's aim for 21-23 and i'll keep you posted by email as soon as i know more. +23:18 <egbert> let you go on with your other topics then +23:18 <egbert> good night! +23:19 <+emmes> good night, Egbert +23:20 <egbert> emmes, you know where to find me ;P +23:20 * emmes is scsred +23:21 <+alanc> the other scheduling issue to discuss is the election calendar I also mailed out last night +23:21 <+alanc> so far I've got two "looks good to me" responses and no complaints - shall we move forward with it? +23:21 <stukreit> alanc: +1 +23:21 <+mherrb> +1 +23:22 <+emmes> +1 +23:22 <agd5f> +1 +23:22 <+Bart_Massey> sounds like it's official +23:23 <+alanc> okay, will send out the mail next week to kick off the membership drive and post the calendar to the public wiki then +23:24 <+alanc> stukreit, agd5f: anything to say about the 501c3 paperwork that we can discuss here? +23:24 <+alanc> (i.e., non lawyer-privileged bits) +23:25 <agd5f> alanc: nothing new that I know of +23:25 <stukreit> I haven't heard from aaron other than his request for member list a few days ago. Hope he's getting finished up with the doc +23:25 <+emmes> did we had a final idea where to collect data about our publications / lecturing materials / etc? +23:26 <+alanc> so we're on track to make the response deadline? don't need to poke members to remind them to submit any more? +23:26 <stukreit> A good poke is always helpful ;-) +23:27 <stukreit> Does someone here own the job of making a collected page or 2 on the wiki for Aaron to point to? I don't have a talent for that. +23:28 <+emmes> i'll be busy correcting student tests for the next few weeks, otherwise I'd do that :-/ +23:30 <+mherrb> I'm also quite busy, but I can probably do something during the coming week-end. +23:30 <+alanc> we have the events page on the wiki, but that's probably not very well organized +23:30 <+Bart_Massey> Yeah, did somebody ever point out to Aaron that we have two professors on our Board? :-) +23:30 <stukreit> We need a page devoted to published papers. +23:31 <+Bart_Massey> Maybe somebody could bug marcoz to collect this stuff? +23:31 <+Bart_Massey> He owns the wiki more than anybody, I think... +23:31 <+emmes> papers only, or rather papers and talks? AFAICS we do have more talks than published papers. OTOH papers weight much more. +23:32 <stukreit> well, sure, both, but the page should be clearly devoted to published stuff rather than mixed with conference calendards or whatever +23:32 <+mherrb> The 1st videos on compiz had a huge impact. +23:32 <+alanc> http://lanyrd.com/topics/x-window-system/past/ & http://lanyrd.com/search/?q=X+Window+System&type=coverage also have a bunch of links to past conferences & talks +23:34 <+alanc> if I recall correctly we're trying to show our educational mission with these, not getting people excited about upcoming "product" +23:34 <+mherrb> I think it's good to mention such external links (or phoronix fwiw), it shows that the foundation action is actively followed +23:38 <+alanc> okay, so mherrb will make a "Papers" page in the wiki for that, anything else we need to get done? +23:39 <+Bart_Massey> I haven't done anything about tracking down GSoC stuff yet. +23:39 <+Bart_Massey> I think what we need to do there is to bug whot to write something, have marcheu pick a couple of recent successful project to highlight, and call it good. +23:40 <+Bart_Massey> We also need to get one of the mentors to write something about our lone EVoC project. :-) +23:41 <+Bart_Massey> Nobody needs to do more than a paragraph or two, but I think it will go a ways toward showing the ed value of these activities. +23:42 <stukreit> bart: can you volunteer to poke them? +23:42 <+Bart_Massey> I will if no one else is willing; my email is really messed up right now, though :-) +23:42 <+Bart_Massey> Maybe marcheu? +23:44 <+Bart_Massey> Maybe not. :-) OK, I'll try to send a few emails this afternoon. +23:45 <stukreit> that would help a lot. thanks! +23:46 <+Bart_Massey> What's the deadline on all this, anyhow? Did Aaron want stuff by tomorrow? +23:47 <stukreit> deadline keeps moving. I'll ping him now +23:50 <stukreit> pinged +23:53 <+alanc> anything else to discuss before adjourning today? +23:55 <+emmes> i'm good +23:58 <+mherrb> me too and feeling sleepy... +1 for adjourning +23:58 <+Bart_Massey> +1 +23:58 <marcheu> Bart_Massey: I'm not sure what you mean "pick projects and highlight them"? +23:58 <stukreit> +1 good night to all our sleepy european friends +23:58 <+alanc> okay, see you all in two weeks, on Feb. 2nd then +23:59 <+mherrb> oh I'm already committed to something else on Feb 2, I'll miss the meeting, sorry. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/02-02.mdwn b/BoardOfDirectors/IrcLogs/2012/02-02.mdwn new file mode 100644 index 00000000..d5dfa248 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/02-02.mdwn @@ -0,0 +1,215 @@ + +Date is 2012-02-02, times are UTC+01. +[[!format txt """ +23:01 * alanc isn't sure if we'll see the people who went to fosdem or not tonight +23:02 <+alanc> but hopefully we can wake up emmes, mherrb & stukreit +23:03 <egbert> stukreit sent an email just a while ago - i'm not sure if he intended to send it to me, though. +23:04 <egbert> i can ping emmes by phone. +23:04 <+alanc> he may have forgotten who is currently on the board vs. who used to be on the board +23:04 <+alanc> I can ping stukreit by walking down the hall, brb +23:04 <stukreit> egbert: I sent it individually to everyone on the board. Were you able to access the file? +23:04 <egbert> i should not show up here so often ;) +23:04 <+alanc> oh, never mind +23:05 <+alanc> stukreit: egbert hasn't been on the board for the past few years +23:05 <egbert> stukreit: i'm not on the board. +23:05 <stukreit> oh- sorry, I read too fast and shallow. it was your email that woke me up +23:06 <stukreit> the doc is only for board and attorney, but you won't find anything need-not-to-know in it +23:06 <+alanc> so we've got 4 board members here so far - given anholt & keithp are speaking at fosdem in a little over 24 hours, I'm not holding my breath for them to make it +23:07 <egbert> emmes will be in shortly. +23:07 <+emmes> sorry for the delay +23:08 <egbert> there he is :) +23:08 <+emmes> have a new smart phone, that isn't that... smart :-/ +23:08 <+alanc> so did everyone see egbert's mail about our XDC date choices? +23:09 <egbert> ok, stukreit saw my email, expect everyone else did, too? +23:09 <+Bart_Massey> not yet. sec +23:09 <+alanc> sent about 2.5 hrs ago +23:09 <+alanc> choices are: Sept 17-19 (Mo-We) or Sept 19-21 (We-Fr). +23:09 <egbert> we got things set up so we don't have to have the conf over a weekend. +23:10 <egbert> which as i learnd would generate extra hassle. +23:10 <stukreit> I can only attend 19->21'st +23:10 <egbert> i brought arguments for both dates. +23:11 <+Bart_Massey> I'd prefer 19-21, as I plan to stay if I go. +23:12 <stukreit> bart: if I were a language police I would beat you up for that;-) +23:12 <agd5f> mherrb: said he couldn't make it IIRC +23:12 <egbert> ok, when was that? +23:12 <agd5f> he replied to one of the board emails earlier this week +23:12 <+alanc> oh, that he couldn't make it today, right +23:13 <+Bart_Massey> stukreit: you wasnt are being language policer though +23:13 <+alanc> I'd forgotten about that +23:13 <egbert> he cannot attend on which days? +23:13 <agd5f> won't make it to this meeting +23:13 <+alanc> egbert: mherrb can't attend today +23:14 <egbert> ah, i thought he couldn't come during this week. +23:14 <egbert> sorry. +23:14 <egbert> he mentioned something last meeting. +23:15 <+alanc> from last meeting I see: <mherrb> I'd prefer 21-23. I have to be in Switerland 24-28. +23:15 <egbert> 24-28 that is for him +23:15 <egbert> right +23:15 <egbert> so he should be fine with either dates. +23:15 <+alanc> so far I see two preferences for 19-21 (We-Fr) +23:16 <egbert> ok, the argument against these days would be octoberfest. +23:16 <+alanc> I don't have a preference either way +23:16 <egbert> i talked to michael and he said it'd be hell going thru munich that day. +23:17 <egbert> so people should be told to try to get flights thru franfurt. +23:17 <+emmes> so people should try to fly in over frankfurt, I guess +23:17 <+emmes> lol +23:17 <egbert> or fly into nuernberg. +23:17 <+alanc> 19-21 overlaps SuSEcon - there's no problems for you with that? +23:17 <egbert> flying into and out of nuernberg would be much less hassle anyway. +23:18 <+Bart_Massey> are any hotels going to be available anytime that week for folks who don't book right away? +23:18 <egbert> no, it doesn't look like it will be. +23:18 <+Bart_Massey> it sounds like the city pretty much fills up around then +23:18 <egbert> yes, it is the one week in september without any hotel constraints. +23:18 <egbert> until monday the following week. +23:19 <+Bart_Massey> ok... +23:19 <agd5f> would august be better? it's usually a pretty slow month, although maybe a lot of vacations then +23:20 <egbert> that's exactly the problem, plus there's plumbers i believe +23:20 <+alanc> looks like it's a couple hours from nuremburg to munich, so hopefully oktoberfest hotels don't fill up that far away +23:20 <egbert> apart from this august would be perfect roomwise and hotel wise, also weatherwise +23:20 <egbert> no, octoberfest won't fill hotels in nuernberg. +23:20 <egbert> just trains. +23:20 <+Bart_Massey> ok +23:21 <egbert> one main train route from the north goes thru nuernberg. +23:21 <egbert> so when i go during octberfest i make sure i have a seat reserved on the train +23:21 <+emmes> alanc: it's actually only about 1 hour. the train is pretty fast. still, nuernberg is considered a completely different region than munich. +23:22 <+emmes> this is not the US ;-) +23:22 <+alanc> emmes: ah, google maps defaulted to driving directions, not train +23:22 <+Bart_Massey> just got an email saying anongit.freedesktop.org is down. +23:22 <egbert> ok, you guys come up with a date. you don't have to decide today either. +23:22 <+Bart_Massey> sigh. the minute keithp leaves town... +23:22 <stukreit> is this a big deal, like "you can't get a seat", or is it just a convenience factor like "gee this train is really crowded" +23:22 <+Bart_Massey> and also anholt... +23:22 <+alanc> Bart_Massey: yes, has been for over a day know +23:22 <+emmes> by car it's less than 1 1/2 h - if you drive reaonably fast, that is :-P +23:23 <+Bart_Massey> alanc: whats' the plan for fixing it? +23:23 <+alanc> between FOSDEM & Tollef's vacation, no one can find an admin +23:23 <egbert> it is from really crowded that you will have to stand in the isle +23:23 <+alanc> Bart_Massey: sit around and whine until admins show up +23:23 <jcristau> Bart_Massey: finding an admin is the first step, we haven't gotten past that. +23:23 <+Bart_Massey> I have physical access to the box. You can always call my cell 503 705 2474 when stuff like this happens... +23:24 <+alanc> I mailed sitewrangler's yesterday, though got caught in the moderation queue for not being subscribed +23:24 <egbert> stukreit: but there's always the option to fly into nuernberg which is much less hassle regardless of octoverfest. +23:24 * Bart_Massey notes that he is in country code +1. usa! +23:25 <+Bart_Massey> Well, it sounds like 19-21 is the default, but let's someone post it on the board list and wait a day or two for emails before fixing it +23:25 <+alanc> Bart_Massey: if you can lay hands on the box and heal it, many people will praise you - but I don't know if physical access is enough, or root access will be needed +23:25 <egbert> ok, fair enough. +23:25 <+Bart_Massey> alanc: i'm guessing one will more-or-less imply the other. :-) +23:26 <+alanc> most of the people with root access seem to be thousands of miles away, limiting physical access +23:26 <+Bart_Massey> anybody remember offhand which box anongit is sitting on? +23:26 <egbert> ok, i will be off. when you have reached consensus please drop me an email. +23:26 <egbert> good night! ;) +23:26 <jcristau> Bart_Massey: molly +23:26 <+Bart_Massey> thanks egbert! +23:26 <+emmes> egbert: ok, thank you! +23:26 <+Bart_Massey> jcristau: thanks +23:26 <stukreit> thanks egbert! +23:27 <+Bart_Massey> i'll call our admins after the meeting and have them look at it, then run down there if it's going to be helpful +23:27 <jcristau> thanks +23:28 <+alanc> okay, in other business, just a quick note that the election calendar is posted at http://www.x.org/wiki/BoardOfDirectors/Elections/2012 and the call for nominations has been sent out +23:28 <+Bart_Massey> thanks alanc +23:29 <+alanc> agd5f, keithp, mherrb and emmes are the members whose terms are running out, and are thus eligible to be nominated for another term +23:30 <+alanc> and of course, any other X.Org member is eligible to nominate or be nominated, though we can't elect any more Oracle employees, and only one Intel employee can be elected this time +23:31 <+alanc> stukreit: did you want to say anything about the 501(c)3 stuff other than that people should read the draft response you mailed out today? +23:32 <stukreit> yes, thanks to all for providing Aaron with input. His submission is very well fleshed out +23:32 <+alanc> and agd5f wanted to ask about VESA stuff +23:32 <agd5f> yeah +23:32 <stukreit> Aaron and Justin did inform me/us that granting of 501(c)3 status has become difficult of late and we should be prepared for alternative filing +23:32 <+alanc> that's all I remember for today's agenda +23:32 <stukreit> wait +23:32 <+Bart_Massey> AFAIK, we are no longer a member of VESA +23:33 <stukreit> which would be the .4 version. +23:33 <+Bart_Massey> I don't remember where the documents from when we were are stored, but they're online someplace +23:33 <+alanc> stukreit: alternative would be we're a non-profit, but not a charity, so people don't get tax deductions for giving us money, right? +23:33 <stukreit> Difference is mainly that contributions to us would not be tax deductable to the donors. Not that previous donors have noticed or inquired about that. +23:34 <+alanc> though keithp did note that helped freedesktop get some donations +23:34 <+Bart_Massey> The fallback plan if it looks like we'll be denied is likely to be to apply to SPI +23:34 <stukreit> right. And we're a few years away from really needing money to continue our current level of operations, although imo we should try to get some whenever possible +23:34 <+Bart_Massey> Aaron says that if we get the timing right, that could work +23:35 <+Bart_Massey> My goal was always to spend us down to $50-$100K before we started to start to set up a funding plan. +23:35 <stukreit> There was an intel donation 2 years ago, we never got it completed, darnit. I could not get attention from the Intel person to chase it down. +23:35 <stukreit> well, we're under $100k now. +23:35 <+Bart_Massey> Where are we? +23:35 <stukreit> (roughly) I haven't looked at the statements in a while +23:35 <stukreit> but we were just over $100k in the summer. +23:36 <+Bart_Massey> Last I looked, we were still at $120K or so. +23:36 <+Bart_Massey> Oh. +23:36 <+Bart_Massey> OK, then it's probably time to start thinking about it. +23:36 <stukreit> Guess I better dig out the statement. would require me to remember id/passwd for yet another account. +23:36 <+Bart_Massey> LOL. Thanks much for dealing with this. +23:36 <stukreit> sure thing +23:37 <+alanc> did we actually get the Google SoC payment straightened out? though that was only a thousand or two I think +23:37 <stukreit> I paid the 1st installment, I need to pay him the 2nd +23:37 <stukreit> make that an AI for me +23:37 <stukreit> (ie, you're free to harangue me, I am always distracted) +23:38 <agd5f> so, is there interest in rejoining vesa? Who managed that last time? anyone know where to docs are? are we allowed to distribute what we currently have to xorg members if we aren't currently a vesa member? +23:38 <+alanc> stukreit: oh you're talking about EVoC, I was thinking of the money google was trying to pay us for GSoC +23:38 <+Bart_Massey> I dealt with it last time. I think we can let members have access to what we have. +23:38 <+alanc> also, you should be paying him for his FOSDEM trip +23:39 <+Bart_Massey> Yeah, the GSoC money comes real close to covering our annual expenses. +23:39 <stukreit> he will send his expenses next week, I ssume +23:39 <marcheu> alanc: I receivedd an email saying the SoC money transfer had been done. I don't have access to the bank statements so I can't say for sure though +23:39 <+alanc> we spend a bit more on travel sponsorship lately than gsoc money covers +23:40 <marcheu> that was a while ago, I could dig it out if you want +23:40 <+Bart_Massey> I don't think there's any deep reason to rejoin VESA. AFAIK there's no new docs that are desperately needed, and it's expensive +23:40 <agd5f> Bart_Massey: do you know where the current vesa docs are? there are some members that were inquiring about them +23:40 <+alanc> marcheu: thanks, hopefully stukreit can confirm in the bank statements +23:40 <+Bart_Massey> I do not. Keithp likely would. +23:40 <stukreit> or ajax +23:40 <+alanc> I think ajax was in charge of them at one point +23:40 <+Bart_Massey> Even more likely ajax +23:40 <+Bart_Massey> yes. +23:41 <agd5f> I don't think ajax knew last time I asked him +23:41 <+Bart_Massey> I might still have dead trees in my office somewhere, but I think I threw them out on the advice of keithp. +23:41 <+Bart_Massey> They were huge. +23:41 <agd5f> I've got digital copies +23:41 <marcheu> alanc: I did transfer him that email +23:42 <agd5f> I can re-upload them somewhere if no one knows where the originals are +23:44 <+Bart_Massey> agd5f: might as well. only thing you need to do is be sure to put them somewhere that only members can access +23:44 <+Bart_Massey> if you find such a place, they may already be there :-) +23:44 <+Bart_Massey> it's also possible that they're somewhere on anongit.fdo :-) +23:44 <+Bart_Massey> I have some staff poking at the box now. +23:45 <+alanc> members.x.org is the only site I know of that all members and only members can access +23:45 <agd5f> can we put them on members.x.org somewhere and add a link to home page when you log in? +23:45 <+alanc> probably, the same way the old minutes are +23:45 <+alanc> but I don't know how, I think anholt did those +23:46 <agd5f> does anyone have shell access to members.x.org? +23:46 <+Bart_Massey> let me check +23:46 <+alanc> https://members.x.org/docs/ in fact seems like it could have a VESA directory created +23:46 <+Bart_Massey> Yes +23:47 <+alanc> isn't members just a virtual host on expo? +23:47 <+Bart_Massey> yes +23:47 <+alanc> all board members should have expo access, though we've failed at actually setting that up for several +23:47 <+Bart_Massey> yes +23:47 <jcristau> members.x.org/docs/ doesn't look restricted +23:47 <+alanc> just like stukreit still can't see the election committee wiki +23:48 <+alanc> oh, if it's not restricted then maybe not then +23:48 <+Bart_Massey> It would be easy enough to stick a .htaccess there, no? +23:48 <+Bart_Massey> I dunno. the web. all after my time. :-) +23:49 <jcristau> /minutes presumably has one, so, yes. +23:49 <+alanc> yeah, but we use 1995-era web technology on that site +23:49 <agd5f> http://xkcd.com/949/ +23:49 <+Bart_Massey> still after my time. :-) +23:49 <+Bart_Massey> even gopher is after my time. +23:50 <+Bart_Massey> in my time you had to get a license from the phone company to hook up a 300-baud modem +23:50 <agd5f> it would be nice if we could tie the authentication into the members user database +23:51 <+Bart_Massey> just a sec... +23:52 <+alanc> yep, something we can research offline with people who actually know how that site is setup +23:52 <agd5f> heh, I'm not sure anyone actually knows ;) +23:52 <+Bart_Massey> it's actually just in the apache2 config +23:53 <+Bart_Massey> oops +23:53 <+Bart_Massey> the directories /bod and /minutes are protected +23:55 <+Bart_Massey> Someone needs to expurgate the old minutes so we can open them +23:55 * Bart_Massey notes that starting a sentence with /bod doesn't do what he expected +23:56 * alanc delegates the task of publishing old minutes to the next secretary +23:57 <agd5f> I guess we could handle vesa like minutes. provide the link and login/pass in index.php +23:57 <+Bart_Massey> lol. looks like the member passwords are kept in a mysql database and thus can't be used with the php +23:57 <+Bart_Massey> agd5f: this seems like the best plan +23:57 <+Bart_Massey> someone can easily set up the basic-auth for a vesa directory +23:58 * Bart_Massey substitutes s/php/apache/ +23:59 <+alanc> so as our hour runs out, anything more to discuss today? +--- Day changed Fri Feb 03 2012 +00:00 <+Bart_Massey> Move to adjourn. +00:00 <+alanc> +1 +00:00 <stukreit> +1 +00:01 <+emmes> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/02-16.mdwn b/BoardOfDirectors/IrcLogs/2012/02-16.mdwn new file mode 100644 index 00000000..8406c311 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/02-16.mdwn @@ -0,0 +1,110 @@ + +Date is 2012-02-16, times are UTC+01. +[[!format txt """ +22:58 <+alanc> good afternoon/evening/$TZ-appropriate-greeting +23:01 <+alanc> agd5f sent mail saying he couldn't make it today +23:01 <+alanc> keithp is biking new zealand and may not be near internet +23:01 <stukreit> hi +23:02 <+alanc> that leaves anholt unaccounted for (assuming Bart_Massey is actually here since he just logged in) +23:02 <stukreit> I occasionally bike santa clara and consider myself lucky +23:03 <+Bart_Massey> hi all +23:03 <+emmes> New Zealand... Sigh... +23:03 <+alanc> as tstellar mentioned just before the meeting, it's time for orgs to apply to GSoC for this year +23:04 <+alanc> I assume we're all happy with asking marcheu to continue handling that for us if he's willing? +23:04 <+Bart_Massey> Heck yes. +23:04 <+mherrb> +1 +23:04 <+emmes> always +23:04 <+alanc> Bart_Massey & marcoz can help I'm sure, plus we'll need mentors to review proposals if/when accepted +23:05 <+Bart_Massey> Happy to help where I can. +23:05 <+emmes> i'll review, as always +23:06 <+emmes> i guess Alex will as well +23:06 <+alanc> for EVoC, it seems our student has successfully completed, and is owed a $3000 check for the second half from stukreit, plus whatever his fosdem trip expenses were +23:06 <marcoz> hi all. I'm also happy to help wherever +23:06 <+Bart_Massey> Very nice. +23:08 <+alanc> we did fail a bit on our end on the payment schedule, since we promised 4 checks, one a month, but ended up batching into 2 checks - hopefully that didn't cause hardship on the student's side +23:08 <stukreit> ah.. err.. .um... +23:09 <+alanc> as I recall, when I was a student, I would have been thrilled to get checks that size at all +23:10 <+Bart_Massey> anyway, we'll do better if/when next time rolls around, but good job everybody! +23:10 <+alanc> though $3k back then would have barely covered a first gen laptop 8-) +23:10 <+Bart_Massey> I couldn't be happier to see us finally succesfully execute one of these. +23:10 <stukreit> not as an excuse, but as parent of 3 current/recent college grads, paid internships, even in the sciences are extremely hard to come by +23:11 <+alanc> anything else we need to discuss on GSoC or EVoC? +23:11 <stukreit> its tons of money in laptop-years, but much less in food-years +23:12 <+alanc> stukreit: any issues/news on 501(c)3 filing? we get everything needed back to the lawyers/IRS on time? +23:13 <stukreit> yes, Aaron sent it all out under the deadline. no word since +23:14 <+alanc> emmes: anything to say about XDS? +23:14 <marcoz> gsoc/evoc: not a discussion topic, but a note of possible interest. I'm pinging the local unis for interested students. However, I'm not getting as much bite as I thought I might. +23:14 <+emmes> haven't heard anything new from Egbert +23:15 <+Bart_Massey> We have a fundamental problem with the learning curve for X. Hopefully marcoz can get the book spring going and we can try that as a first cut +23:15 * Bart_Massey spring->sprint +23:15 <marcoz> nice segue into book sprint. +23:15 <marcoz> or should I wait til after official business is over. +23:15 <marcoz> ? +23:16 <+emmes> AFAIK the room is still set, and we're good to advertize. However, I'll have to contact Egbert once more for that. +23:16 <+alanc> marcoz: you can go ahead now, not much more official business I have on my list of topics +23:16 <+emmes> Bart_Massey: Shall we prepare a call for papers soonish? +23:16 <+Bart_Massey> Oops. Yeah, now that we know the dates we should get that out in the next week or so. +23:17 <marcoz> so far my list of attendees: alanc, Josh, marcheu, me, +23:17 <+Bart_Massey> Am I drafted to do the first cut, or was someone else gonna do that? +23:17 <marcoz> and Bart. +23:17 <+emmes> at least you were first to volunteer ;-) +23:17 <+Bart_Massey> Fair enough. :-) +23:17 <+emmes> but I'll ask Egbert first how to continue there. +23:17 <+Bart_Massey> I'll try to write something after this meeting. +23:18 <+emmes> I guess the main advertizing should be written by Egbert, unless he'd like to delegate that. The call for papers is only a subtask therein. +23:18 <marcoz> that gives 5, plus hopefully KeithP. I haven't heard from anyone else. not even a "I won't make it" when I poke them directly. +23:20 <+Bart_Massey> Yeah, we need to get a program committee together too. +23:20 <+Bart_Massey> marcoz: I think Jamey's going to try to make it if we can hit his schedule. +23:20 <+Bart_Massey> i'll bug him again +23:20 <marcoz> that'd be great. thx. +23:20 <marcoz> I assumed you can make it. Is that a safe assumption? +23:21 <+Bart_Massey> me? yes, assuming we pick the right date. +23:21 <+Bart_Massey> right now our target date looks pretty good.. +23:22 <+mherrb> apropos lawyers/IRS: last year (http://www.x.org/wiki/BoardOfDirectors/IrcLogs/2011/02-14) we voted for a yearly $2k contrib to sflc... time to honour it? +23:22 <marcoz> Bart_Massey, I have no desire to move it at this point; it'd be late notice. That's within a mth +23:23 <+Bart_Massey> mherrb: thanks for the reminder. +1 +23:23 <+emmes> right +1 +23:23 <+Bart_Massey> marcoz: only way we would move it is way way forward +23:23 <+alanc> +1 for sflc contrib +23:23 <+mherrb> +1 too +23:24 <marcoz> so you're saying tomorrow won't work for you? +23:25 <+Bart_Massey> marcoz: wtf? i thought we were talking about march sometime? +23:26 * alanc suddenly realizes it's halfway through February and March isn't that far away +23:26 <stukreit> wait- is this in addition to the first sflc contribution? +23:26 <stukreit> (sorry, need to readthe logs better) +23:26 <+Bart_Massey> marcoz: march 9-11, no? +23:27 <stukreit> I need an excuse to go to nyc.. +23:27 <+Bart_Massey> stukreit: did we finally send them a check at some point? we've voted to several times... +23:27 <+alanc> stukreit: yes, the first one was for everything they'd done so far, and then annual contribs for ongoing work, like what justin is doing now +23:27 <stukreit> I gave them a check last year +23:27 <marcoz> Bart_Massey, correct. Mar 9-11 +23:27 <stukreit> fyi justin has moved on. We work with Aaron +23:28 <marcoz> Bart_Massey: this weekend was a joke. ;) +23:28 <+Bart_Massey> marcoz: thank goodness :-) my calendar is such a mess right now +23:28 <marcheu> alanc: yeah I can do SoC this year +23:28 <+Bart_Massey> marcheu: Thanks! +23:29 <+emmes> awesome! +23:29 <+alanc> marcheu: awesome! let us know if there's anything you need, and when you need people to start reviewing proposals +23:29 <+Bart_Massey> You can use the stats and stuff I gathered for Aaron +23:29 <+Bart_Massey> in the org app +23:31 <marcoz> Bart_Massey, alanc, did we want to open it up to the general mailing list for anyone interested in the book sprint? we _might_ get one or two +23:31 <+Bart_Massey> marcoz: Please invite them (again) to apply. It's by invitation only, but any reasonable person who expresses interest should get an invitation. +23:32 <marcoz> ok, I'll spam the mailing lists. +23:32 <+Bart_Massey> (IOW, no known wackos, no known psychos, no one we don't know) +23:32 <+alanc> so the only other business I'm remembering to discuss today is the elections +23:33 <+alanc> as usual, we extended the nomination deadline due to insufficient nominees accepting in time +23:33 <+Bart_Massey> Of course, probably a mistake to express this policy publicly, since now anyone not invited will be mortally insulted +23:34 <+Bart_Massey> alanc: i'm worried this time that the extension might not do it. What's our plan f not? +23:34 <+alanc> Bart_Massey: most of the people who've agreed to give up a weekend to this are known wackos, but their insanity works in our favor in these areas, especially the obsessive ones +23:35 <+Bart_Massey> alanc: lol +23:35 <+alanc> Bart_Massey: I'll have to double check my mail, but I think we've now hit 4 accepting, though we still need a statement from one by the Monday deadline +23:35 <+alanc> which is a minimum viable set for the board +23:35 <+Bart_Massey> alanc: good +23:36 <+alanc> I can think of at least one more potential candidate to nominate that hasn't been pinged yet, if we don't think it's bad form for the election committee members to submit nominations +23:36 <+Bart_Massey> alanc: I have already submitted several +23:37 <+Bart_Massey> please do bug anyone who might be good +23:39 <+alanc> okay, any more business to discuss today? +23:39 <+Bart_Massey> move to adjourn +23:41 <+Bart_Massey> bye all! +23:41 <+mherrb> +1 bye. +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/03-01.mdwn b/BoardOfDirectors/IrcLogs/2012/03-01.mdwn new file mode 100644 index 00000000..c89bce28 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/03-01.mdwn @@ -0,0 +1,107 @@ + +Date is 2012-03-01, times are UTC+01. +[[!format txt """ +23:00 <agd5f> hello +23:00 <+alanc> good afternoon +23:00 <+mherrb> hi +23:01 <+emmes> hey +23:01 <+alanc> I think keithp is still on the underside of the world - don't remember getting mail from anyone else that they couldn't be here today +23:02 <+alanc> everyone did get the election candidates announcement mail right? haven't seen any questions to the candidates yet +23:02 <+Bart_Massey> howdy +23:02 <+emmes> the mail was fine here; seems there are no questions +23:02 <+mherrb> yes got the mail. +23:02 <agd5f> yup, got it +23:03 <+Bart_Massey> What's on the agenda today? +23:03 <+alanc> don't see anholt here, and stukreit's been quiet, otherwise seems like the members are all here +23:04 <+alanc> things I have for the agenda today are updates (if any) on: elections, GSoC, paying our EVoC student, 501(c)3/IRS review, XDS planning +23:05 * alanc runs down the hall quickly to wake stuart up +23:05 <stukreit> uhhh +23:05 <stukreit> hi alan! +23:05 <+alanc> oh, and book sprint +23:05 <+alanc> so who wants to go first? +23:06 <stukreit> let me get my pain overwith +23:06 <+alanc> I think we've pretty much covered elections: candidates announced, voting commences next week +23:06 <stukreit> I have the checkbook pulled down, doin it as we speak +23:06 <+Bart_Massey> has anyone run a test election and verified the website still works? +23:07 <+alanc> no +23:08 <+Bart_Massey> most years it breaks the first time we try it IIRC +23:08 <+Bart_Massey> might want to bug anholt: I think he knows it best +23:08 <+alanc> I know there's instructions on the wiki page, but haven't had time to look at it +23:08 <+alanc> I'll send mail about testing it & setting it up for the real thing +23:10 <+alanc> since we haven't been poked by marcheu, I'm assuming the GSoC application is well in hand and he doesn't need anything from us yet +23:10 <+alanc> agd5f, stukreit : any news on the IRS review? +23:10 <agd5f> not that I've heard +23:10 <stukreit> me neither +23:11 <marcheu> alanc: yeah I'll port the 2011 SoC application to 2012 this week end :) +23:11 <+Bart_Massey> still trying to find time to finish the CFP and get a TPC together for XDS. haven't finished, nor forgotten. hopefully this week +23:11 <+alanc> okay, then on to emmes: any news on getting the XDS dates confirmed & announced? +23:11 <+alanc> or egbert if he's here +23:13 <+Bart_Massey> guess not +23:13 <+Bart_Massey> we good for this week then? +23:14 <+alanc> well, this is the last meeting before the book sprint I think +23:14 <+alanc> if I remembered the dates right +23:14 <marcoz> yes. +23:14 <marcoz> I haven't sent out an email to the list. sorry. +23:14 <+alanc> next weekend, right? (i.e. in 8 days) +23:14 <marcoz> ridiculously busy these last two weeks. (start new job next week) +23:14 <marcoz> yes, next weekend +23:15 <+emmes> alanc: I'll see Egbert tomorrow, he wanted to do that. I'll push him again. +23:17 <+alanc> emmes: thanks, it is still 6 months away, but on the other hand, it's now only 6 months to get everything arranged +23:17 <+emmes> exactly +23:18 <+alanc> marcoz: okay, will hope to see email from you about book sprint soonish - especially reminding me if we needed to have any software locally setup or were just using low tech methods like IRC & text editors +23:18 <marcoz> I actually have a night off tonight; that's on my list. +23:19 <+alanc> so anything I forgot for the agenda that people would like to discuss? +23:19 <marcoz> does anyone else want to email the MLs about the booksprint? +23:22 * alanc listens for volunteers, hears only rain +23:22 <marcoz> *crickets*. ok then. +23:23 <+Bart_Massey> My email situation is so bad I'd never see the responses anyhow +23:23 <+Bart_Massey> Need to get that straightened out +23:24 <marcoz> Bart, can we use your mumble server for the book sprint? I have assumed so, but I should actually officially ask. +23:24 <+Bart_Massey> Of course +23:24 <marcoz> thx. +23:24 <+Bart_Massey> Can set up for any other services you'd like to try also +23:25 <marcoz> I'm thinking a shared screen session for any prompt typing. Do you have a server? +23:25 <+Bart_Massey> I do. Can get it set up. +23:25 <marcoz> thx +23:25 <+Bart_Massey> We could also just use a collaborative editor +23:25 <marcoz> Any good ones? google docs seemed to be the best I saw... +23:25 <+Bart_Massey> That would be fine... +23:26 <+Bart_Massey> We've used gobby a lot +23:26 <marcoz> I was trying to keep as low-tech as possible just to keep it easiest. +23:26 <marcoz> gobby? +23:26 <marcoz> that short for google docs? +23:26 <+Bart_Massey> linux-based collaborative text-editor outside the browser +23:26 * alanc has Solaris, Linux, Mac and even Windows machines at home if I need to install a client +23:26 <+Bart_Massey> think that's the right name +23:27 <marcoz> found it. thx. how come I didn't see that in my google searching over the last couple months? +23:27 <marcoz> gobby never turned up +23:27 <+Bart_Massey> apparently google hates them :-) +23:27 <marcoz> competition. lol +23:28 <+Bart_Massey> it does real-time collaborative editing with colors to keep track of what's going on +23:28 <+Bart_Massey> p2p, so no server +23:28 <+Bart_Massey> pretty nice +23:28 <marcoz> nice +23:29 <marcoz> so we can possibly use that and then use screen to gen the output, then have the output dir on some apache mount (or sshfs) so folks can see the output realtime-ish? +23:30 <+Bart_Massey> i'm not sure what "the output" is? what's the plan here? +23:30 <marcoz> Marcheu's is tex and we're shooting for pdf? +23:30 <+Bart_Massey> I will do all the formatting +23:31 <+Bart_Massey> My plan is to not worry much about the PDF until the end +23:31 <+Bart_Massey> I hope to concentrate on editing / formatting +23:31 <marcheu> that's what lyx is for +23:31 <+Bart_Massey> and let others generate text +23:31 <marcoz> Fri and Sat are cranking on the content and Sun is formatting then? +23:31 <+Bart_Massey> formatting should be nbd, but yes +23:32 <marcoz> agreed, but I don't want to do all content up until the very end and then say "Ok, Bart, it's all on you." +23:32 <+Bart_Massey> I'll keep track of it. it'll be fine +23:32 <+Bart_Massey> i'll have formatted drafts throughout the weekend +23:33 <+Bart_Massey> we'll be doing chapter-at-a-time-ish things anyhow +23:33 <marcoz> ok. +23:34 <marcheu> IME the biggest part is to document yourself and double check facts when you're not sure/your memory is bad +23:34 <marcheu> it's what took me the most time +23:34 <marcheu> writing and formatting are minor compared to that +23:34 <+Bart_Massey> marcheu: makes sense, esp for what you've been doing +23:36 <+Bart_Massey> well, gtg. talk to you soon! +23:36 <+alanc> unless someone else has another topic, I think we're done for today +23:36 <+alanc> if we keep to schedule, at the next meeting we should have an announcement of our new board members +23:37 <+alanc> thanks everyone for coming! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/03-15.mdwn b/BoardOfDirectors/IrcLogs/2012/03-15.mdwn new file mode 100644 index 00000000..f6625178 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/03-15.mdwn @@ -0,0 +1,104 @@ + +Date is 2012-03-15, times are UTC+01. Note: USA timezone is already in daylight saving mode, thus the 1 hour difference to the usual meeting time. +[[!format txt """ +22:01 <+alanc> good afternoon +22:01 <+emmes> hey Alan +22:02 <agd5f> hi +22:02 <+alanc> Bart sent apologies for not being able to make it today, but that's all I saw +22:02 <stukreit> hi +22:02 <+alanc> so we should be seeing anholt, keithp & mherrb still... +22:06 <+anholt> hey all. hopefully this network works. using the phone from a conference room. +22:07 <+alanc> hello +22:07 <+alanc> I guess that gives us quorum +22:07 <+alanc> so, we had an election +22:07 <+alanc> and now we're to the last step in the election process, which is the board certifies the results +22:08 <+alanc> no members have complained to me or the elections alias of any problems they had in voting +22:08 <+alanc> (I did have to help one with fixing his e-mail address for password recovery during the election, but that was handled in time for him to vote) +22:09 <+alanc> According to the members website, of the 144 current foundation members, 40 members voted this year. This gives us 27.77% participation, barely enough to meet the 25% quorum required. +22:09 <+alanc> The results as reported by the members website are: +22:09 <+alanc> Name 1 2 3 4 Score +22:09 <+alanc> ---- -- -- -- -- ----- +22:09 <+alanc> Marc Balmer 2 3 4 5 30 +22:09 <+alanc> Alex Deucher 13 8 9 7 101 +22:09 <+alanc> Matt Dew 5 7 9 6 65 +22:09 <+alanc> Matthias Hopf 8 7 8 8 77 +22:09 <+alanc> Jeremy Huddleston 3 8 6 3 51 +22:09 <+alanc> Keith Packard 9 7 3 7 70 +22:09 <+alanc> ---- -- -- -- -- +22:09 <+alanc> Total cast 40 40 39 36 +22:09 <+alanc> Which means that our 4 newly elected or re-elected board members for two year terms are: agd5f, emmes, keithp, and marcoz +22:10 <+emmes> due to the low participation rate I suggest that let our members renew their membership before the next election. I guess quite some accounts are stale. +22:10 <+alanc> any discussion before we vote to certify this as a properly executed election? +22:11 <+emmes> looks good to me +1 +22:11 <agd5f> +1 +22:11 <+alanc> yeah, we'd been lax about renewals, but helping purge those not participating may get us a higher % voting in the future +22:11 <+anholt> alanc: +1 +22:11 <+alanc> +1 +22:11 <stukreit> +1 +22:11 <+anholt> emmes: do you mean "require" as opposed to "let"? +22:11 <+emmes> I guess so. +22:12 <+emmes> would require a longer timeframe, though. +22:12 <+alanc> unless keithp has woken up, that is a unanimous vote of the currently present board members +22:13 <agd5f> I don't think accounts expire at all at the moment +22:13 <+alanc> thanks to all our candidates for participating in the election, and congratulations/condolences to those who just won two years worth of meetings and work on behalf of our members +22:13 <+emmes> thanks for the election work! +22:13 <+alanc> there are a lot of accounts in the membership system marked as expired, but I'm not sure when they expired +22:14 <agd5f> thanks for handling the election alanc +22:14 <+alanc> I'll send out mail about choosing a new meeting time, though there's only one member difference from the current board +22:14 <agd5f> I've never renewed by account, but as far as I know it's never expired and there's no option in the web page to renew +22:15 <+alanc> I remember having to renew at some past point, but we may not have done that in a long time +22:15 <+emmes> I think I renewed it once; could be bad memory, though. +22:16 <+emmes> I guess we should at some point in time do a renewal process. Otherwise we might miss our 25% quota at some point in time. +22:17 <+emmes> doesn't have to be corrolated to elections, but renewal should be open when the next election is up. To catch those who didn't care to much about renewal before... +22:18 <+alanc> the election committee process wiki lists the cutoff date for joining or renewing membership as the same, and being about a month before elections +22:18 <+alanc> we sent e-mail reminders of "do this now if you want to vote this year" before that happened +22:19 <+alanc> Bart send an e-mail report on the Book Sprint activities last weekend - I don't think there's much more to say here, especially when Bart's not available to discuss +22:20 <+alanc> emmes: XDS news? (other than my random wiki edits generating phoronix articles on XDS planning?) +22:20 <+alanc> (or egbert if he's really here) +22:21 <michaellarabel> I've talked it over with egbert but: Phoronix will sponsor another beer event / catered lunch / or whatever... I'm just waiting on hearing back from him when he hears from the caterer to know if that caterer is required or of what are the options and any requirements, etc. +22:22 <+emmes> it seems Egbert is totally swamped company wise this week. I barely made it to meet him. +22:22 <marcoz> (sorry, I +22:22 <marcoz> m late, impromptu meeting +22:22 <marcoz> woohoo!!!!! +22:22 <+emmes> Given that Egbert is the man with the room, I do not dare posting the announcement w/o him. +22:22 <+alanc> marcoz: technically your attendance isn't required until the next meeting 8-) but of course, you're welcome as always to be here today +22:23 <+emmes> But I do have one good feedback from him: the room is definitive secure now. +22:23 * alanc has never seen anyone so excited about getting signed up for two years worth of meetings +22:23 <marcoz> lol +22:23 <marcoz> yea, I'm kinda dumb that way +22:23 <+emmes> marcoz: you'll learn. quick. ;-) +22:24 <+alanc> emmes: good, hopefully that will lead to announcement soon +22:24 <marcoz> kinda like the military eh? _never_ volunteer or show excitement +22:24 <+alanc> and until then we'll harness your enthusiasm +22:24 <+emmes> I'll keep pushing Egbert until we get one. +22:25 <+emmes> Luckily we're early this year with planning +22:26 <+alanc> next week will bring us to 6 months before the conference date +22:27 <+alanc> which should still be more than enough time for buying cheap plane tickets and getting visas arranged for the few people who need them +22:28 <+alanc> anything else to discuss today? +22:29 <marcoz> how much I should drink to celebrate? +22:29 <+emmes> that's at your discretion :P +22:30 <marcoz> in that case...all of it. +22:30 * emmes does not want to know +22:31 <+alanc> looks like agd5f & anholt are the current board mailing list admins - marcoz: tell one of them which e-mail address you'd like to be subscribed to board@foundation.x.org under +22:31 <marcoz> will do. +22:31 <+alanc> if there's nothing else, then I guess we're ready to adjourn for today +22:32 <stukreit> thanks, alan! +22:33 <+emmes> yes, thanks! +1 +22:33 <agd5f> +1 +22:33 <marcoz> +1 +22:33 <+alanc> oh yeah, all you guys on the election committee - you're all kicked off! +22:34 <+emmes> thanks again for the work! +22:34 <+alanc> and thank you for your service for the past year +22:34 <+alanc> our newly selected election committee will be: agd5f, emmes, keithp, and marcoz +22:35 <+alanc> maybe you can finally follow through on our long threatened replacement of the election web site before next year's election +22:36 <agd5f> so does anyone know how to add/remove people from the board list? It's been several years since I looked at it last +22:36 <+alanc> http://foundation.x.org/cgi-bin/mailman/listinfo/board is the easy part, finding the password is harder +22:37 <+alanc> if all else fails, poke mithrandir to use root to do it +22:37 <+alanc> or anholt +22:37 <marcoz> mithrandir? the same one that's on PCLinuxOS? +22:38 * alanc doesn't remember who all has root on expo +22:38 <+alanc> Mithrandir is the IRC nick of Tollef, who admins the freedesktop.org & x.org machines as part of his job at collabora, for which we are very grateful for the donation of his time +22:39 <+alanc> Tollef Fog Heen that is +22:40 <marcoz> Yep, I think that's the same guy +22:41 <+alanc> thanks everyone to coming, and thanks to our outgoing board members for 2 years of excellent service to the foundation +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/03-29.mdwn b/BoardOfDirectors/IrcLogs/2012/03-29.mdwn new file mode 100644 index 00000000..a0d0018d --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/03-29.mdwn @@ -0,0 +1,194 @@ + +Date is 2012-03-29, times are UTC+02. +[[!format txt """ +23:00 <+alanc> good afternoon +23:00 <marcoz> howdy +23:01 <agd5f> hi +23:02 <+alanc> anholt? emmes? keithp? stukreit? +23:05 <+anholt> hi +23:05 <stukreit> hihi +23:05 <+alanc> so that's 5 of 8, still waiting on Bart, keithp & emmes to arrive +23:06 <+alanc> the two main items I had for today's agenda are officer selections & XDC update +23:06 <+emmes> i'm here +23:06 <+alanc> and Bart makes 7 +23:07 <+Bart_Massey> Hey all. Sorry to be late. +23:07 <+alanc> all you missed so far was roll call +23:07 <+Bart_Massey> Whew. Don't want to give the new Board Members a bad impression. :-) +23:07 <+Bart_Massey> Yet. :-) +23:07 <+alanc> so for the officer selection, lets try the easy one first - stukreit has agreed to continue as treasurer +23:07 <+Bart_Massey> +1 +23:07 <+alanc> everyone in favor of that? +23:07 <+emmes> and i'm still waiting for an answer from Egbert for the XDC call he wanted to have created by now; seems he's swamped... +23:08 <agd5f> +1 +23:08 <+anholt> +1 +23:08 <+Bart_Massey> Egbert put out the call last night, no? +23:08 <marcoz> +1 +23:08 <+alanc> +1 +23:08 <+emmes> i don't see any alternative stepping forward ;-) +1 +23:08 <stukreit> folks, thanks for the votes, but actually I made an agreement to serve for 5 years +23:08 <stukreit> a while ago.. +23:08 <+alanc> stukreit: I think the bylaws require us to redo this every term though +23:08 <+Bart_Massey> stukreit: It is hugely appreciated. But I think it's better if the Board officially approves you once a year. +23:09 <stukreit> unless that agreement is considered too casual. ie its not on record +23:09 <stukreit> ok, that's fine with me. +23:09 <+emmes> so with that statement you just agreed for another 5 years? just kidding. +23:09 <+alanc> of course the bylaws also require two signatures on every check and the board sort of waived that +23:09 <stukreit> yes, it turned out to be a pita +23:09 <+Bart_Massey> Someone (probably me) needs to do proposed updates to the Bylaws before this September. +23:09 <+alanc> yes +23:09 <+alanc> was just typing in the same thing +23:10 <+alanc> anyways, on to secretary, for which the current officeholder is not continuing +23:10 <+emmes> before election time, yes. would fit with membership renewal... +23:10 <+Bart_Massey> BTW, have we abandoned XDS/XDC? I'm good either way, but we should figure it out. Table this for now; discuss today though. +23:10 <+alanc> who is willing to put in the time to be secretary? +23:11 <+Bart_Massey> emmes: Bylaws changes have to be voted at a General Meeting. This is usually XDC/XDS +23:11 <+emmes> right. forgot about that one. +23:11 <+Bart_Massey> Having been drummed out by the Membership previously, I consider myself immune. :-) +23:11 <+Bart_Massey> Keithp? +23:11 <agd5f> we need to add stuff as recommended by the IRS +23:12 <+Bart_Massey> agd5f: Sounds good. We should start putting a list together online somewhere soon. +23:14 <+alanc> while some members appreciate the secretary putting in the 30 minutes or so every other week to write a summary of the meeting, the minimum we've required for minutes is saving a log of the IRC channel +23:14 <+Bart_Massey> Other duties of the Secretary include writing an Annual Report. +23:15 <+alanc> and I've done less than the minimum for the last year or so, since emmes was the one actually posting the logs +23:15 <+Bart_Massey> I'm happy to run meetings and represent the org, but I'm terrible at keeping records and such. Somebody want to split with me? +23:16 <+emmes> i'll continue with the logs, so that one should be fine +23:16 <+alanc> in theory, somewhere out there is a official corporate record book and other physical papers, but I never got them, and I suspect they're still in leon's possesion +23:17 <stukreit> didn't Karen meet with him for this? Bart? Keith? +23:18 <marcoz> Bart_Massey: i could take a shot at helping you out. +23:18 <+Bart_Massey> I don't think we ever got anything useful out of Leon. +23:18 <+alanc> (still haven't seen keithp today) +23:18 <+Bart_Massey> It doesn't matter much, since it was all pretty much pre-X.Org +23:18 <+Bart_Massey> I'll call keithp in a minute. +23:18 <+alanc> so anyone else volunteering? or is Bart our only willing victim? +23:19 <+Bart_Massey> Let's do some other business while I try to get in touch with keithp... +23:20 <+alanc> the other business is back to XDC, for which egbert sent out the announcement to members this morning +23:20 <+alanc> 10 people signed up already on http://www.x.org/wiki/Events/XDC2012/Attendees +23:21 <+alanc> announcement at http://lists.x.org/archives/xorg-devel/2012-March/030164.html for those who missed it +23:21 <+Bart_Massey> Nice. +23:21 <+Bart_Massey> Now I have to get the CFP out and the PC together. +23:21 <+Bart_Massey> This is a busy Spring "Break" for me :-). +23:22 <+Bart_Massey> Again "XDS" or "XDC"? +23:22 <+Bart_Massey> I'm all for just giving up and calling them all "XDC". +23:22 <+keithp> sorry, schedule scrambled today -- too much rain to fly little airplanes +23:22 <+Bart_Massey> The other sensible alternative is to call the Eastern Hemisphere ones XDS and the Western Hemisphere ones XDC as we have been. +23:23 <+Bart_Massey> In which case Egbert's CFP is wrong, though :-) +23:23 <+Bart_Massey> I move to declare the name XDS kaput and XDC to be the official name for this conference from now on. +23:23 <+alanc> having different names when they were in the same year made sense, but not so much when there's just one a year +23:24 <+Bart_Massey> I agree. +23:24 <+alanc> +1 for bart's motion +23:24 <marcoz> +1 +23:24 <+alanc> retroactively making Egbert correct 8-) +23:24 <+keithp> +1 (is deleting names as good as deleting code?) +23:24 <+Bart_Massey> It's hard to delete 1M lines of names :-) +23:25 <+emmes> always been +1 +23:25 <+Bart_Massey> For the new Board Members: The traditional vote of assent on a motion is +1, of course. +23:25 <+Bart_Massey> But you knew that. +23:25 <+alanc> well, we probably need to delete some names from our membership rolls, so we're not quite so close on quorum in future elections, but that's a different topic +23:25 <+Bart_Massey> alanc: Or get some new active members :-) +23:26 <+alanc> you can call him marcoz instead of "the new Board Members" if you want to type less 8-) +23:26 <+Bart_Massey> Hi Matt! +23:26 <+Bart_Massey> When have I ever wanted to type less? :-) +23:26 <+alanc> so anything else to say about XDC before going back to secretary selection? +23:26 <marcoz> :) Hi Bart +23:27 <+Bart_Massey> So I talked to keithp, and I guess I'm willing to be Secretary again. He has promised to help as needed, and I'll try to be better about delegating in general this time around. +23:27 <+anholt> +1 on xdc +23:27 <+alanc> yes, I sucked at delegating, though I was better at accepting offers of help, like posting the irc logs +23:27 <+Bart_Massey> Yes, emmes, thanks much and please keep doing this! +23:28 <+alanc> so to all board members, if there's stuff you'd like to see the secretary do, the secret is to offer to help do it! +23:29 <+Bart_Massey> If selected, I will also occasionally ask for things. It helps a lot if someone steps up to do them. :-) +23:29 <+Bart_Massey> LMK if sending chocolate or something is required: I can arrange that. +23:29 <+alanc> so all in favor of naming Bart_Massey secretary for this term? +23:29 <+keithp> +1! +23:29 <marcoz> +1 +23:29 <+alanc> +1 +23:30 <agd5f> +1 +23:30 <stukreit> in favor of Bart sending voodoo donuts ? +1 +23:30 <+emmes> +1 +23:30 <+Bart_Massey> stukreit: Not sure how to pack them so they don't arrive icky. +23:30 <stukreit> (wifey just got back from portland with a box) +23:30 <+keithp> scary +23:31 <+alanc> not a pail of donuts, like we had at the Portland XDC? +23:31 <+keithp> that was awesome +23:31 <stukreit> TSA tried to confiscate them,said the fillings are over the allowed limits of liquids +23:31 <+Bart_Massey> LOL +23:31 <+anholt> +1 +23:32 <+alanc> in any case, seems unanimous, so Bart, consider the torch passed back to you +23:32 <+Bart_Massey> Thanks! I think! +23:32 <+alanc> oh, should I have handed the handle to you instead of putting the lit end in your hand? +23:33 <+keithp> Bart_Massey: we should schedule lunch on friday after the meeting to get things done +23:33 <+Bart_Massey> keithp: Excellent plan. Altering calendar now. +23:33 <+Bart_Massey> Someone want to volunteer to manage the Bylaws change proposal? Needs someone to set up and maintain some web pages with the proposed changes, solicit changes from the Board, get them reviewed, get ready to prep. +23:33 <+Bart_Massey> I will contribute to the changes, help edit the changes, etc. +23:34 <+keithp> Bart_Massey: you're on my calendar now +23:34 <+alanc> should be able to do that on the normal wiki instead of waiting for all the board members to get access to the private wiki +23:34 <+Bart_Massey> alanc: either way is good with me +23:35 <+Bart_Massey> I just don't want to be in the loop on getting this set up. Too much on my plate already. +23:35 <+alanc> Tollef said he'd try to get around to creating the accounts soon for board members who don't have them yet - hopefully everyone sent him the needed details +23:36 <+Bart_Massey> speaking of all of this: what *is* the protocol if one of us wants to discuss things privately with the Board? Email list, I guess? +23:36 <marcoz> alanc: do I need to send him anything? I read the email that I didn't but now I'm not sure. +23:36 <+anholt> yeah, thought it was just email list. +23:37 <+alanc> e-mail's been the only way I remember handling private stuff +23:37 <+Bart_Massey> We used to have the IRC channel private. +23:38 <+alanc> marcoz: for the expo login I think you just needed to give him a username and he'd copy the ssh key from fd.o, but if I recall correctly wiki access requires an apache htpasswd encoded passwd +23:38 <+Bart_Massey> I guess I won't worry about it for now. Eventually, though, we may want to be able to move to a closed channel temporarily. +23:38 <marcoz> ah ok. so any encoded .htpasswd then. ok. +23:39 <+Bart_Massey> marcoz: Missed your message earlier somehow. I will definitely take advantage of your help, as I have been to a huge degree already :-). +23:39 <marcoz> Bart_Massey: glad to help. btw: consider this the bi-weekly booksprint poke. :) +23:40 <+Bart_Massey> Should poke me more often than bi-weekly :-). Worked on it some last night; getting closer. +23:40 <marcoz> anything I (or anyone else *cough*) can do to help? +23:41 <+Bart_Massey> Not right this minute, but RSN. I've almost got the editing finished and the cover art pasted together. +23:41 <marcoz> sweet +23:41 <+Bart_Massey> When that's done, we're going to have to figure out format(s) and publication. +23:41 <+Bart_Massey> Somebody besides me could do that bit. +23:42 <+Bart_Massey> marcheu: tbh I haven't looked---is the stuff you wrote during the Sprint in the repo with the rest of your drivers book? +23:42 <+Bart_Massey> BTW, I haven't edited that at all. +23:43 <+Bart_Massey> And probably won't anytime soon: it's huge. I'll scout around for someone who can take it on. +23:43 <+alanc> oh, if marcheu is here, there is one more thing I forgot - did google ever say why they found us unworthy for GSoC this year? +23:43 <+Bart_Massey> I talked with Donnie. The official explanation is that they didn't like our ideas page. +23:44 <+Bart_Massey> The bar gets set higher every year, and apparently we were below it. There was no inciting incident that they would tell us about. +23:44 <+alanc> so we need to do a better job of that for next year? probably should archive the old stuff instead of just continually stuffing more in +23:44 <marcoz> uhh, seriously? +23:45 <+Bart_Massey> If we are going to apply again next year (and I'm not sure we should bother, frankly), then I think we need to completely revamp the way we're organized for this. +23:45 <marcoz> In their massive FAQ, is ideas page professionallity described? +23:46 <+Bart_Massey> Google seems to want a ton of structure these days for GSoC; I wouldn't bother applying again unless we're willing to put together something fancy enough that it would be hard for them to say no. +23:46 <marcoz> which is a nice segue into EVoC, anyone been pinged by students? I've been pinged by 4, one or two of them I expect may bite. +23:46 <+Bart_Massey> But maybe that's just me. +23:47 <+Bart_Massey> One thing about EVoC I'd like to suggest is that we launch it as an official unpaid program for non-students as well. +23:47 <+Bart_Massey> That is, anyone can participate in EVoC, but only the students get paid. +23:47 <+keithp> Bart_Massey: that's difficult given our 501(c) 3 status... +23:47 <+Bart_Massey> At the very least, it would make it clear to everyone what the rules are. +23:47 <+keithp> oh, sure, if we're not paying for them +23:47 <+Bart_Massey> keithp: Yeah. +23:47 <+keithp> not sure how much interest that would engender though +23:48 <+Bart_Massey> Maybe none. At the very least, it might stop non-students asking to apply. :-0 +23:48 <+Bart_Massey> But at best someone will want the mentoring and "prestige" of having done an EVoC... +23:49 <+Bart_Massey> It's certainly easy to do: basically a one-line change to the EVoC page. +23:49 <marcoz> Who hear can I ping later for help on effective ways to drum up student interest? I'm not having much luck. +23:50 <+alanc> we usually get a surge of interest (inquiries at least) once the students find out which of them didn't get accepted for GSoC, which is still a ways ahead +23:50 <+Bart_Massey> It's really hard. If I had good ideas I'd be using them. We do have a Capstone team that just finished here at PSU doing an X project. That's 6 prospectives... +23:51 <+Bart_Massey> alanc: But the GSoC rejects are usually a sorry lot. +23:51 <+Bart_Massey> Anyway, move to admit non-students to EVoC on a non-paid basis. +23:51 <+alanc> certainly if Jamey or Jeremy said they had a good candidate from that class they wanted to mentor for further work under EVoC I'd be happy +23:52 <+Bart_Massey> I'll remind them of that option. Second my motion? +23:52 <+alanc> seconded +23:52 <marcoz> +1 +23:52 <+Bart_Massey> in favor? +23:52 <+alanc> +1 +23:52 <stukreit> +1 +23:53 <+Bart_Massey> motion carries. editing wiki page now... +23:53 <+keithp> +1 +23:53 <agd5f> +1 +23:54 <+Bart_Massey> I couldn't even find the EVoC page from our front page. :-) +23:54 <marcoz_> bah, stupid computer +23:54 <+Bart_Massey> Someone might want to fix that as well. +23:55 <+emmes> +1. Even if it only helps keeping non-students wanting payment out +23:55 <+emmes> Bart_Massey: Another thing about XDC: Now that the message is out (and even a link to the program in the wiki) - shall we do more about a real CFP? +23:56 <+Bart_Massey> emmes: Yeah, mentioned that earlier. I'll try to get the PC together this week, and ship you all the CFP I've partially written once it's finished. +23:56 <+Bart_Massey> $#@! I need another week of Spring Break. +23:57 <+Bart_Massey> Move to adjourn. +23:57 <+alanc> seconded +23:57 <stukreit> +1 +23:57 <marcoz_> +1 +23:58 <agd5f> +1 +23:58 <+Bart_Massey> bye all! See you in a couple weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/04-12.mdwn b/BoardOfDirectors/IrcLogs/2012/04-12.mdwn new file mode 100644 index 00000000..c43a48a2 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/04-12.mdwn @@ -0,0 +1,175 @@ + +Date is 2012-04-12, times are UTC+02. +[[!format txt """ +22:59 <agd5f> hi +22:59 <+alanc> hello +23:00 <marcoz> hi +23:00 <+emmes> hey all +23:01 <Bart_Massey> We're at 6; not bad. +23:01 <Bart_Massey> keithp: ? +23:02 <Bart_Massey> anholt: ? +23:02 <keithp> yup +23:02 <keithp> sup all? +23:02 <stukreit> 2:02 pst, hi! +23:02 <Bart_Massey> notmuch :-) +23:03 <Bart_Massey> Completely confused. Who all are the current Board Members :-) ? +23:04 <+alanc> http://www.x.org/wiki/BoardOfDirectors +23:04 <Bart_Massey> OK, I'm at 7 +23:04 <Bart_Massey> Just couldn't count +23:04 <Bart_Massey> Was staring at that page, and failing +23:04 <Bart_Massey> We're all here except Anholt, then. Let's get started +23:05 <Bart_Massey> Sorry: subsequent meetings I'll try to start on time +23:05 <Bart_Massey> Actually, first item of business: my list for X.Org is pretty deep. +23:05 <Bart_Massey> If you don't want me to run screaming into the night I need some help with stuff. :-) +23:06 <Bart_Massey> 1. Feeling really guilty that I haven't finished with The Book. Need someone to volunteer for a session sometime soon to figure the last of that out. +23:06 <Bart_Massey> 2. We need to have proposed changes to the Bylaws ready to vote by XDS in September. This will happen sooner than you think. Need someone to work with on that. +23:07 <stukreit> Do we have a bullet list of items that must be fixed? +23:07 <Bart_Massey> 3. Need to get the Call For Proposals and Program Committee together for XDS; not in that order +23:07 <Bart_Massey> stukreit: No, that's the first item of business. Recover all the items we can from old IRC logs and stuff. +23:07 <Bart_Massey> After that, we need to read the Bylaws and carefully compare with current practice. +23:07 <Bart_Massey> I'm expecting 2-5 proposed amendments by the time we are done with that. +23:08 <+alanc> the bylaws issues I remember are: 1) conflict of interest statement to meet IRS reqts. 2) change check signing to single-person +23:08 <Bart_Massey> I'd add (3) let the election date float +23:08 <stukreit> oh yeah, Justin never did get us the boilerplate before he left sflc. +23:08 <Bart_Massey> We talked about (4) relaxing the single-organization member requirement by one +23:09 <marcoz> Bart_Massey: I'll help with the book however I can. lemme know what I can do.. +23:09 <Bart_Massey> marcoz: let's schedule a meeting offline to work on finishing this. +23:09 <Bart_Massey> thanks +23:10 <marcoz> k and yw. +23:10 <Bart_Massey> So yeah, somebody needs to get all this together and ready to go. I'm happy to help read things and draft the amendments, but history suggests I will not complete on my own :-) +23:11 <Bart_Massey> As far as XDS, someone needs to step up and contact Program Committee members until we have a plausible PC. emmes: would being PC Chair be useful to you academically? +23:12 <+emmes> emmes: I doubt it being useful here, but I guess I could do it. Though I'm swamped this semester due to new lectures... +23:12 <Bart_Massey> emmes: if it doesn't look good on your vita and help you get tenured, forget it. +23:13 <Bart_Massey> keithp: sounds like you're drafted to help me put a PC together. we'll talk to tomorrow +23:13 <keithp> Bart_Massey: I'm leaving at some point tomorrow; not sure what time, presumably lunch-ish though... +23:13 <+emmes> nope, won't help me. +23:13 <Bart_Massey> keithp: OK, later then +23:14 <keithp> Bart_Massey: or am on the pone +23:14 <Bart_Massey> emmes: The American system is very different, I think :-) +23:14 <agd5f> I can talk to sflc about the conflict of interest boilerplate +23:14 <Bart_Massey> keithp: In a faculty candidate job talk AM. Sometime soon +23:14 <+emmes> Bart_Massey: yes, *very* ;-) +23:14 <Bart_Massey> agd5f: thanks huge +23:14 <stukreit> agd5f: do you have the name of our current contact? +23:15 <Bart_Massey> stukreit: Not on the agenda, but there's supposed to be a Treasurer Report issued at the start of every year. Did you do that this year? Can't remember. +23:15 <Bart_Massey> I have added the State of X report to my TODO list. +23:15 <stukreit> a repor.. that would be nice. ok, my AI +23:15 <Bart_Massey> stukreit: tx much +23:15 <+alanc> can you forward our sflc contact info to the board list? I promised matttst88 to forward some questions about Xaw license cleanup to our lawyers +23:15 <agd5f> stukreit: is Aaron gone? +23:16 <stukreit> let me look.. +23:16 <+alanc> oh, is it still the aaronw we exchanged e-mail with a few months ago? +23:17 <Bart_Massey> So somebody who wants to play rules lawyer (not necessarily on the Board---feel free to suggest others) needs to help with the Bylaws and we're set +23:17 <agd5f> it was karen, then justin, then aaron IIRC +23:17 <Bart_Massey> There's no urgency on the Bylaws yet, but I want to get started +23:17 <stukreit> ok. yes, I believe its Aaron now. +23:17 <+alanc> I'll try to take a look at the current bylaws and see if I can spot problems we need to fix +23:18 <Bart_Massey> alanc: Thanks +23:18 <Bart_Massey> it would also be great to comb the logs and past notes to see what we've forgotten +23:18 <Bart_Massey> What is the status of XDS? I think it's been formally announced. Are all the logistics in place? Do we have an initial estimate of how big it will be? +23:19 <marcoz> mount +23:19 <+emmes> it would also be rather interesting for the catering... +23:20 <+alanc> oh yeah, I did notice someone from sflc recently gave a talk on how it's hard to become an open source foundation these days: https://events.linuxfoundation.org/events/collaboration-summit/williamson https://events.linuxfoundation.org/images/stories/pdf/lfcs2012_williamson.pdf should have realized it was the person we'd been working with +23:20 <Bart_Massey> marcoz: Ararat? Sermon on the? Sorry, I seem to be all Biblical here +23:20 <marcoz> stupid windows doesn't have focus follows mouse +23:20 <+alanc> Bart_Massey: and my brain jumped straight to "wrong window, run that in xterm to see your filesystems" +23:20 <Bart_Massey> lol +23:21 <+emmes> the room is officially ordered and fixed. Catering will be ordered only shortly before the event. Egbert's negotiating prices with nearby hotels, that's the last thing i heard. +23:21 <Bart_Massey> OK. So we're in good shape there. Anything else we should be worried about with the conference itself right now? +23:22 <Bart_Massey> Tx, BTW: I know how hard that work is. +23:22 <+emmes> nothing important I'm aware of... +23:22 <Bart_Massey> I keep calling it XDS: It's now officially XDC by Board vote. Correct me until I get it right :-) +23:23 <Bart_Massey> So do we have or want any specific plans or policy for funding travel to XDC? +23:23 <marcoz> unofficially - XorgConf (like in Zorro) +23:24 <Bart_Massey> If so, isn't it or shouldn't it be written down somewhere? +23:24 <Bart_Massey> I ask partly because I'll probably want some travel help. :-) +23:24 <+emmes> I'd suggest the usual - you get funding if your company really doesn't sponsor you, and you're prepared to give a talk. But I don't think this notion is anywhere near being official. +23:24 <+alanc> did we have a formal policy in past years other than "ask us, and we'll decide case-by-case"? +23:24 <Bart_Massey> alanc: nope. I'm only concerned because it seems like there are more requests every year (which is good) +23:25 <+emmes> alanc: i guess it boils down to this. +23:25 <Bart_Massey> As far as I'm concerned we can leave it loose again for now, but I thought I'd bring it up +23:25 <+alanc> fair enough +23:25 <Bart_Massey> emmes: ? +23:25 <Bart_Massey> emmes: nm got it +23:26 <+emmes> Bart_Massey: I was agreeing with "case-by-case" +23:26 <Bart_Massey> OK, I'll leave it for now. LMK if we need to do more in some future mtg +23:26 <Bart_Massey> OK, next item: Wayland +23:26 <Bart_Massey> Something I've been talking with various folks about for a long time is that there's a lot of confusion in the public about the relationsihp of Wayland to X.Org +23:26 <Bart_Massey> This is partly because we've never made any public statement about it. +23:27 <Bart_Massey> I don't propose to resolve all that this meeting, but I want to at least discuss what relationsihp the X.Org Foundation, specifically, has and should have to Wayland. +23:28 <Bart_Massey> My personal feeling is that inasmuch as Wayland becomes the natural successor to X.Org, built by mostly X.Org people for the benefit of our community, the Foundation should support it the same way we do "the rest of X". If they want us :-). +23:29 <Bart_Massey> Anybody feel differently? Don't be shy... +23:29 <agd5f> seems somewhat akin to mesa +23:29 <+alanc> for GSoC last year, we agreed Wayland was part of the larger graphics community we covered there, alongside Mesa, DRI, XCB, etc. +23:29 <Bart_Massey> agd5f: Somewhat. We should probably also clarify the relationship of the Foundation to Mesa :-) +23:29 <+emmes> good point +23:30 <agd5f> I kind of think of xorg as promoting open source gui stacks whether or not they involve X proper, but we may want to clarify the bylaws, etc. +23:30 <Bart_Massey> alanc: Yeah, that's my take as well: the Foundation should be as inclusive as possible in the X-ish stack below the toolkit layer +23:30 <+alanc> something to add to the bylaw list? clarification of charter? +23:30 <Bart_Massey> agd5f: I always sort of draw the line "below" freedesktop.org +23:31 <Bart_Massey> We're more plumbing, "they" are more porcelain +23:31 <+alanc> but "we" are "they" +23:31 <Bart_Massey> alanc: I'm not sure we have to go that formal. I'd just like a public statement e.g. on our website about what we think we're doing +23:31 <Bart_Massey> alanc: I know it's all the same people, but it's different money, different org structure, etc +23:31 <agd5f> Bart_Massey: right +23:31 <agd5f> not DEs and toolkits, but the services they use +23:32 <+alanc> I didn't think freedesktop.org really had an org structure beyond hosting service +23:32 <Bart_Massey> agd5f: Yeah +23:32 <Bart_Massey> alanc: It seems to have an org structure named Keith Packard, last I checked :-) +23:32 <+alanc> and all of X.org, mesa, xcb, wayland, and even some of DRI are hosted on fd.o +23:33 <Bart_Massey> alanc: But that's the point; the public and the US IRS would both like us to be clear about what's us and what's them. +23:33 <Bart_Massey> Although really, that isn't where I intended to take this. +23:33 <Bart_Massey> I mostly thought that Wayland (but yeah, also Mesa etc) is kind of confusing to everyone right now +23:34 <jcristau> freedesktop.org has enough of an org structure to be listed as an SPI associated project. but that may still just be keith. +23:34 <marcoz> alanc, does Xorg really have any infrastructure to offer in support? seems we use fd.o for everything and X.org really just does the money thing and a conference.... +23:34 <+alanc> at one point X.org owned some machines colocated at MIT - those should be all shut down now and migrated to VM's on fd.o hardware +23:35 <Bart_Massey> Effectively, we "subcontract" our HW infrastructure to fd.o right now. Everyone seems happy enough with this, and I don't propose to change it. +23:35 <keithp> fd.o definitely uses the X.org affiliation when doing fundraising for fd.o hardware +23:35 <Bart_Massey> I doubt anyone else here objects to that. :-) +23:36 <marcoz> no objections to anything. I just want to make sure I correctly understand how things are. +23:36 <+alanc> expo.x.org hosts the membership roster/voting system web app (which really needs to be re-written some year), and some ancient archives of the old consortia +23:36 <Bart_Massey> alanc: Yeah, the election app was on my agenda for a future meeting :-) +23:37 <+alanc> plus it used to have our vesa docs available for members to access, but I don't remember how to get to those +23:37 <keithp> alanc: used to be via ftp... +23:37 <agd5f> I'm not sure it does anymore, although I would like to post them at some point +23:38 <Bart_Massey> OK, so I think that we have this covered for now. I'll bring it up later after everyone has had a chance to think and discuss. If someone wants to draft some text for the website, we could discuss that at a future mtg +23:38 <Bart_Massey> BTW, missed stitch at the beginning: Is this meeting being logged? +23:39 <Bart_Massey> Anyone? +23:39 <stukreit> just cut&paste it into a file +23:40 <Bart_Massey> stukreit: I can, but we need to make sure the file becomes publicly available. I'll grab it at the end for now, but I thought someone was logging these regularly... +23:40 <+alanc> emmes just made them appear on the web site for me when I was secretary, so maybe if you ask nicely... +23:40 <Bart_Massey> emmes: Are you logging? If not, any chance you would? +23:41 <Bart_Massey> We appear to be temporarily emmesless. I will assume he's logging for now, and we'll patch it up later. +23:42 <Bart_Massey> Next item, membership. As alanc has pointed out, we barely made quorum for the last election. Given that we've done pretty extensive roll purges in the past, this concerns me. +23:42 <Bart_Massey> I suspect it means that the number of people who are Members and know and care what's going on is still shrinking fairly rapidly. +23:43 <agd5f> I don't think we've purged in quite a while +23:43 <Bart_Massey> agd5f: Maybe three years ago? Anholt did much of the work +23:44 <Bart_Massey> As always, we need to do three things: (1) Try to increase the number of folks genuinely involved in X, (2) try to ensure everyone involved becomes a Member, and (3) do more purging of members-in-name-only +23:44 <agd5f> I think more like 5-6 years +23:44 <Bart_Massey> agd5f: I think there was another purge more recently, but I could well be quite wrong on this +23:44 <Bart_Massey> Anyway, it's time to do it again, I'm sure. +23:45 <+alanc> clarifying the mission to include the slightly wider free graphics stack may also encourage those who just want to hack on wayland or mesa to become members +23:45 <Bart_Massey> Anyway, we're running up on stopping time, so again I'm not going to try to solve this online today. I've been working on (1), but someone else may want to pick up (2) and/or (3) +23:45 <Bart_Massey> alanc: agreed +23:46 <Bart_Massey> Mesa is tricky, BTW: I'm not so sure how much Brian (if I got the name right) wants the Foundation involved? +23:47 <Bart_Massey> Anyway, let's leave it for now and think about it over the next few meetings: again there's no real urgency here, but it's work we need to do +23:47 <agd5f> we're not supposed to be involved in the decision making, just encouragement +23:47 <+alanc> yes, should talk to the leadership of the other projects before trying to make any announcements there - want to make clear we're not trying to take over or impose any technical decisions, just offer support & resources +23:47 <+alanc> like the video hackfest of a couple years ago +23:47 <Bart_Massey> Yes, the last thing we want is to be claiming to support somebody who explicitly says they don't want our support +23:48 <Bart_Massey> Very awkward for all concerned +23:48 <Bart_Massey> Anyway, last item of business: I won't be available for our next meeting. alanc: would you be willing to run that one? +23:48 <+alanc> we also need to make sure that any statement about supporting wayland doesn't come across as abandoning X, especially not for all the non-Linux platforms Wayland doesn't run on +23:49 <Bart_Massey> alanc: Absolutely. Unless we're abandoning X. :-) :-) +23:50 <+alanc> Bart_Massey: yeah, I should be able to run the meeting on the 26th +23:50 <Bart_Massey> alanc: Thanks much. +23:50 <Bart_Massey> Any other business? +23:51 <Bart_Massey> OK. Move to adjourn. +23:51 <+alanc> +1 +23:51 <marcoz> +1 +23:52 <agd5f> +1 +23:52 <Bart_Massey> 1 more for quorum :-) +23:52 <keithp> yeah, we're out of here. +1 +23:53 <Bart_Massey> Sorry to have run so long this time: will try to keep it shorter in the future +23:53 <Bart_Massey> Thanks all! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/04-26.mdwn b/BoardOfDirectors/IrcLogs/2012/04-26.mdwn new file mode 100644 index 00000000..d563a4b7 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/04-26.mdwn @@ -0,0 +1,74 @@ + +Date is 2012-04-26, times are UTC+02. +[[!format txt """ +23:00 <agd5f> hello +23:00 <+emmes> hi +23:00 <stukreit> hiya +23:00 <marcoz> hi +23:00 <+alanc> hello +23:02 <+alanc> so I know bart said he wasn't coming today - looks like we're still awaiting anholt & keithp +23:03 <marcoz> anyone logging the irc? +23:03 <+emmes> sure +23:04 <marcoz> good deal +23:05 <+alanc> so any updates on XDS planning? +23:05 <stukreit> chirp chirp +23:06 <+emmes> nothing new so far AFAIK +23:06 <+alanc> I think bart ended up with most of the AI's from the last meeting +23:06 <+emmes> wasn't in nuernberg last week, so my knowledge is dated +23:07 <+alanc> okay, any updates on 501(c)3 ? +23:08 <stukreit> nope. I don't know if I need to ping sflc. They're usually good at informing us +23:08 <stukreit> of news. +23:08 <+alanc> I assume at this point it's mostly waiting for the IRS +23:08 <stukreit> yes. we are waiting +23:08 <+alanc> any other treasurer news to report while you've got the floor? +23:08 <stukreit> status is: "wait" +23:09 <stukreit> The treasurer owes the membership a financial report. +23:09 <+alanc> I assume our EVoC student is now paid in full for his 4 months of work, and for the FOSDEM trip, right? +23:09 <stukreit> The first check I sent him didn't make it. I have another check out, no ack yet. :-( +23:09 <+alanc> ouch +23:11 <+emmes> I already heard that mail in the U.S. isn't exactly reliable, but it actually seems even worse than I thought +23:11 <stukreit> dunno if got lost here or there. +23:12 <+alanc> this would be mail from US to Germany, so multiple points of possible failure +23:12 <+emmes> right +23:12 <keithp> hey ho. +23:13 * alanc is reading over last meeting's log and not seeing much more that carried forward and doesn't involve bart - sorry for not preparing better +23:13 <keithp> no worries +23:13 <+alanc> does anyone else have topics to bring up? +23:14 <+alanc> I still need to do the bylaw review & mail that to the board, will try to tackle soonish +23:14 <marcoz> I've heard from a student who's interested in EVoC, but he can only do part-time. What's the story on part-time EVoC? +23:15 <agd5f> if the plan is feasible, I say sure +23:16 <+alanc> I don't remember explictly deciding we wouldn't allow that, so I'd guess it's possible, though it would be less $ per month +23:16 <agd5f> we should also follow up with that other evoc inquiry from earlier this week +23:16 <marcoz> from the evoc page: "A proposal will typically be for a period of three to four months of contiguous nearly-full-time work...", doesn't specifically mention part-time. +23:17 <+alanc> clearly marcoz hasn't been on the board long enough to realize just how much of what we do is making up stuff as we go along +23:17 <+alanc> 8-) +23:18 <marcoz> :) +23:18 <+alanc> "will typically be" is not "is required to be" and we have tried to be a bit more flexible since we don't have to make it scale to 5000 students like google does +23:18 <marcoz> i'm still young and naive. think the elders are smooth and got everything figured out. :) +23:18 <+emmes> i would say: as long as we are not overcrouded we could have part-time students, as long as payment reflects the work amount +23:19 <+alanc> The elders have simply figured out how to make it look like we know what we're doing. +23:19 <stukreit> do we really want to engage evoc with someone who is budgeting their time? +23:20 <+alanc> True enlightenment comes when you first hear yourself described as an expert in X11, and realize that if you're what passes as an expert, then maybe nobody really ever actually understands it all. +23:21 <marcoz> stukreit: i've been asking the student about that. trying to figure out what could be done parttime and keeping expectations real. +23:21 <marcoz> alanc: lol +23:25 <+alanc> okay, so sounds like general consensus that we're willing to consider a solid proposal for part-time work for part-time payment +23:25 <+alanc> and we'd want to know more about how they are budgeting their time for EVoC vs. other things +23:26 <+alanc> anything else to discuss? +23:26 <marcoz> alanc: yes, that will be part of the proposal. a normal proposal just with reduced hours. +23:29 <marcoz> i'll inform the student that part-time is ok, if the proposal meets the other requirements. (mentor avail, specific milestones and targets, ...) +23:31 <agd5f> sounds good +23:31 <+emmes> thanks +23:32 <+alanc> anything else before we call it a day? +23:32 <marcoz> just a nudge for anyone who wants to respond to the other evoc-interested student to ping them. +23:35 <agd5f> I'm already replying +23:35 <+alanc> thanks +23:35 <marcoz> sweet +23:40 <agd5f> whoops, didn't mean to cc xorg-devel +23:40 <+alanc> okay then, move to adjourn +23:40 <stukreit> +1 +23:40 <agd5f> +1 +23:41 <marcoz> +1 +23:43 <+alanc> okay then, we're adjourned +23:44 <+alanc> I'd say see you all in two weeks, but I think I'm out for that one, but Bart should be back then +23:44 <+emmes> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/05-10.mdwn b/BoardOfDirectors/IrcLogs/2012/05-10.mdwn new file mode 100644 index 00000000..f40073e5 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/05-10.mdwn @@ -0,0 +1,60 @@ + +Date is 2012-05-10, times are UTC+02. +[[!format txt """ +23:02 <+emmes> hey +23:02 <+emmes> I think we'll have to do without both, Alan *and* Bart today... +23:03 <+keithp> not sure who's running the meeting today +23:03 <+emmes> be my guest ;-) +23:03 <+Bart_Massey> Howdy +23:03 <+Bart_Massey> No, it's me +23:03 <+keithp> cool, thought you were stuck in another mtg +23:03 <+emmes> oh, bart, you actually made it :-) +23:03 <+Bart_Massey> No, just hit the restroom before this one. +23:03 <+Bart_Massey> Yeah :-) +23:03 <+Bart_Massey> kind of nice +23:04 <+emmes> so no wild guessing from our side who's in charge today +23:04 <+Bart_Massey> So let me pull my agenda and we'll get started. :-) +23:05 <+Bart_Massey> 1) XDC planning. Are we on track here? Anyone got anything to add? +23:06 <marcoz> we still thinking about a book sprint right prior to? +23:06 <+Bart_Massey> We are. I think if we're going to do that though, the next few weeks are when we must plan and schedule it. +23:06 <+Bart_Massey> emmes: can we get space for people to stay before the event some easy way? +23:07 <+Bart_Massey> The other possibility is for me to prevail on my friends in Wurzburg to put us up at FHWS. It's about 1hr train ride from Nurnberg, I think? +23:08 <+emmes> Bart_Massey: asked egbert about the state on hotel negotiations; still waiting for an answer. It's possibly better for me to negotiate, though, as I'm living in Nuernberg. +23:09 <+emmes> Hotel situation in Nuernberg is pretty good, and affordable, as we do have a fair, and there's nothing on it during XDC. +23:09 <+Bart_Massey> emmes: OK. We'll need to confirm the hotel for XDC itself real soon now. +23:09 <+Bart_Massey> emmes: Good. We're thinking the book sprint would be for a couple of days before XDC. +23:09 <+Bart_Massey> Would that work? +23:09 <+Bart_Massey> Probably 8-12 of us. (I'm not doing it with less than 8 solid confirms.) +23:10 <+emmes> Yes, I know. I'll discuss it with Egbert on the Weekend. I think the few days before should be fine. The weekend especially. +23:10 <+Bart_Massey> Thanks. Let us know. Like I say, I have a backup plan, so whatever works. +23:10 <+emmes> :-) +23:11 <+Bart_Massey> marcoz: I'm assuming you will put together the invite list for the sprint, and basically take charge of setting it up. Is this possible? +23:11 <+emmes> I think flight reservations are more pressing than hotel reservations. Anyway, we should get over it soonish. +23:11 <+Bart_Massey> Excellent. +23:12 <marcoz> Bart_Massey: yep +23:12 <+Bart_Massey> marcoz: I am emailing you my partly-written CFP for XDC. Would you be willing to finish it and ship it? I was originally planning to put together a refereed track with a Program Committee, but so far I haven't seen that anyone wants it. +23:13 <+Bart_Massey> So probably not. +23:13 <marcoz> uh, sure. what's invovled in finishing a CFP? +23:14 <+keithp> Bart_Massey: only if someone needs a refereed paper +23:14 <+Bart_Massey> Just look at the document I'm sending you and figure out what it still needs. We can bounce it back and forth. When we're happy you can send it to the usual places +23:14 <+Bart_Massey> keithp: I have identified no such person +23:14 <+Bart_Massey> and I'm feeling like I have enough things to do right now without it. :-) +23:14 <+Bart_Massey> If someone speaks up and says yes, they do want a refereed paper, I'll be happy to put it all together. +23:15 <marcoz> ok +23:15 <+Bart_Massey> Next: Bylaws revision. We need to get started on this. What state did we leave it in? +23:15 <+Bart_Massey> (CFP emailed) +23:16 <+Bart_Massey> I think maybe alanc was going to do something on this? +23:17 <+Bart_Massey> OK. We'll table it for now, but sometime soon. +23:17 <+Bart_Massey> Finally, EVoC. We have a couple of possible proposals in flight. What's the state of the one we just finished? Is that all done and paid now? +23:18 <+Bart_Massey> stukreit: ? +23:18 <stukreit> I have still not sent it out. I need to do that asap +23:18 <+Bart_Massey> OK. Yes, please. +23:19 <+Bart_Massey> I think that's what was on my agenda. Are there other things we need to discuss? +23:20 <+emmes> i've got nothing on my mind currently +23:20 <+Bart_Massey> Cool. Move to adjourn. +23:20 <+keithp> sounds great; back to my other meeting :-) +23:20 <+Bart_Massey> :-) +23:20 <+emmes> +1 +23:20 <marcoz> +1 +23:20 <stukreit> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/05-24.mdwn b/BoardOfDirectors/IrcLogs/2012/05-24.mdwn new file mode 100644 index 00000000..ff3db68e --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/05-24.mdwn @@ -0,0 +1,236 @@ + +Date is 2012-05-24, times are UTC+02. + +The word in*surance had to be crippled, because it's not allowed in the text due to anti-spamming rules. +[[!format txt """ +23:00 <Bart_Massey> Hey all +23:00 <marcoz> hey bart +23:00 <mupuf> Hi everyone +23:01 <alanc> hello +23:01 <supreet> hey +23:01 <stukreit> hello +23:02 <marcoz> hi alanc stukreit +23:02 <Bart_Massey> I am sitting in a talk that starts in 15 minutes, so excuse me if I get distracted at that point. :-) +23:03 <Bart_Massey> IIRC the first agenda item is EVoC proposals and status. +23:03 <Bart_Massey> marcoz: want to summarize our status on the two proposals we have running at this point? +23:03 <marcoz> we have two of the proposal students here, ashwinravichandr and supreet . +23:04 <marcoz> for Nouveau. one is a monitoring proposal, the other is a reclocking scheme for newer cards. (mupuf correct me where I'm wrong) +23:04 <Bart_Massey> Cool: welcome! Do we have questions and concerns for the student and/or mentor? What do we still need to address? +23:04 <Bart_Massey> mupuf: Are these separate work, or related? +23:04 <marcoz> separate but related. +23:04 <mupuf> they are related in the way both are needed to implement good dynamic reclocking +23:04 <marcoz> mupuf assures me they will not be working on the same thing. +23:04 <marcheu> can they get one patch into xorg before we accept them? we would have enforced the bar for SoC this year also +23:05 <Bart_Massey> I'm not sure there's anything left to patch in X.Org. +23:05 <Bart_Massey> LOL +23:05 <marcheu> ok, let's say one non-trivial patch in a freedesktop repo :) +23:06 <marcheu> (that said xorg has enough bugs for everyone IMO) +23:06 <Bart_Massey> Yes, some evidence of ability to navigate the patch process would be a +23:06 <Bart_Massey> plus. Past patches count, of cous +23:06 <alanc> there's plenty you could patch in X.Org, a bit less that's worth patching +23:06 <+emmes> hey all +23:06 <Bart_Massey> (er, of course) +23:06 <Bart_Massey> emmes: Welcome! +23:07 <alanc> certainly if they're proposing to change nouveau there should be plenty of opportunities to submit some sort of small patch there +23:07 <Bart_Massey> emmes: we're grilling mupuf's Nouveau EVoC proposers about their stuff +23:07 <mupuf> marcheu: well, I get your point. But isn't the EVoC about getting people in X.org? The first patch is really hard to come up with, let alone having it accepted +23:07 <marcheu> mupuf: yes, but the SoC/VoC program isn't about teaching programming +23:07 <mupuf> marcheu: right +23:07 <+emmes> yeah, just read the backlog +23:08 <Bart_Massey> The point is, it doesn't have to be anything epic: a two-line null pointer check or something probably suffices. +23:08 <mupuf> marcheu: I wouldn't mind enforcing this policy of getting at least one patch before they can start working on EVoC, but isn't it a little late to warn us about that? :s +23:08 <marcoz> would patches to nouveau count? +23:08 <Bart_Massey> For me, it's not about programming (presumed), but about navigating patches +23:08 <alanc> has there been board mail about these proposals that I've overlooked? (I'm still a bit in shock that the calendar popup said today's meeting was May 24 - I don't know where this month has gone) +23:08 <Bart_Massey> marcoz: yes +23:08 <Bart_Massey> alanc: a bit +23:09 <Bart_Massey> But this is the first time IIRC we've talked explicitly about the patch submission requirement. +23:09 <marcoz> alanc, there was a thread about ashwin's +23:09 <Bart_Massey> Honestly, I'm inclined to take mupuf's word on these two, but if others feel strongly I understand... +23:10 <alanc> hmm, I don't seem to see board mail at all in May, guess I'll have to ping mithrandir to see if there's a mail delivery problem +23:10 <+emmes> mupuf: you won't be on your own, if there's troubles. *some* sort if involvment in the project would be a good prerequisite from my side, though we haven't explicitly discussed this. +23:10 <mupuf> well, we could take some time before starting the EVoC to get some patches done +23:10 <+emmes> i'm undecided. there's a point that we didn't require this before. +23:10 <mupuf> I can definitely find some simple work around nouveau +23:10 <agd5f> AFAIK, GSOC has no patch requirement and we've never enforced that before +23:10 <Bart_Massey> If I were setting policy (and I'm not), I'd be inclined to take a mentor vouching for the student as a substitute for patches +23:10 <marcoz> it does seem a bit out of the blue to say 'oh btw, have you submitted any patches?' i'm not saying it's a bit requirement, but stating it at this point seems a bit +23:11 <Bart_Massey> agd5f: many GSoC projects require it, but certainly not all. +23:11 <Bart_Massey> I move we waive this requirement for these projects, and talk about it for future projects. +23:11 <+emmes> agd5f: I think in GSOC it depends on how the according mentors see it. but you're probably right. +23:11 <Bart_Massey> Votes? +23:11 <agd5f> I meant that google doesn't require it, but sure, the individual projects may have varying requirements +23:12 <+emmes> who actually analyzed the two proposals? i fail to remember :-] marcoz? +23:12 <marcoz> I wrote up a quick summary and emailed it to you guys on ashwin's +23:12 <alanc> my understanding is that the patch requirement is usually imposed on people the mentors don't already know, to weed out those who are not yet skilled enough to take on the task of contributing to open source +23:12 <Bart_Massey> alanc: agreed +23:13 <Bart_Massey> we have some Board votes (in favor) on Ashwin's. +23:13 <mupuf> we can do it if you want, that shouldn't be a problem +23:13 <alanc> so I'd also be agreeable to taking the vouching of a known mentor in it's place +23:13 <+emmes> marcoz: if you're pretty confident about the proposald (you know them best), I'm perfectly fine. +23:13 <mupuf> a small patch won't take too much time +23:13 <marcoz> I appended a very small comment about supreet onto that thread. +23:13 <Bart_Massey> I think we shouldn'\t require this at this stage on these proposals. +23:13 <Bart_Massey> I'm open to discussing future policy. +23:13 <marcoz> s/suprett/supreet's/ +23:14 <+emmes> yes, I think I remember. just want to be sure. +23:14 <mupuf> IIRC, you only gave money when some milestones were achieved, right? +23:14 <Bart_Massey> OK, so I have a motion on the table to waive the patch requirement. Votes? +23:14 <Bart_Massey> mupuf: No, like Google, we in principle award money up front as well +23:15 <mupuf> oh, ok. +23:15 <Bart_Massey> In practice, we've been slow with those checks, so yeah. :-) +23:15 * mupuf wonders where he read that +23:15 <+emmes> ok, I'm fine +1 +23:15 <marcoz> emmes: I'm going off mupuf's past work. the proposal's have some details in them and there was a thread with the nouveau folks about it. +23:15 <+emmes> marcoz: perfectly valid. +23:15 <agd5f> I thought they pay was at the midpoint and end +23:15 <marcoz> +1 for waiving the patch requirement for these. +23:15 <agd5f> +1 +23:15 <stukreit> +1 +23:16 <Bart_Massey> We've voted different things for different people re payment schedule +23:16 <marcoz> there's another proposal from Jess VanDerwalker as well. +23:16 <Bart_Massey> marcoz: Yes +23:16 <marcoz> Jeremy is his mentor +23:16 <Bart_Massey> W/ Jamey Sharp +23:16 <marcoz> Bart_Massey: yes, +23:16 <+emmes> did we have enough votes by mail already? +23:16 <Bart_Massey> Need one more +1 on the patch requirement waiver +23:16 <alanc> +1 on the patch waiver +23:17 <Bart_Massey> emmes: no +23:17 <Bart_Massey> OK, so the patch thing is settled. I will make a note for us to discuss at future mtg +23:17 <marcoz> we need to update the wiki to reflect this new requirement (if it becomes a req) +23:17 <Bart_Massey> I propose we vote Ashwin and Jess's proposal today, as there has been a lot of email discussion on those +23:17 <Bart_Massey> marcoz: agreed +23:18 <Bart_Massey> I think we need to discuss supreet's a bit more and vote it by email this week? +23:18 <Bart_Massey> Thoughts? +23:19 <stukreit> Is there a paragraph writeup of the proposal? +23:19 <marcoz> ok, since they are all here, are there any questions for anyone regarding the proposals? +23:19 <Bart_Massey> stukreit: I know Ashwin's and Jess's are in email. +23:19 <marcoz> supreet: (that's your cue to put up a very short summary.) +23:20 <stukreit> aha, perhaps re-post it? +23:20 <supreet> I have written a summary +23:20 <supreet> but it is a little more than a paragraph +23:20 <supreet> i could do a pastebin +23:20 <Bart_Massey> Pastebin works +23:20 <marcoz> works for me. +23:20 <stukreit> good. Does it say what and why? +23:20 <supreet> yep +23:20 <supreet> everything +23:21 <Bart_Massey> Give us an URL please :-) +23:21 <supreet> http://paste.kde.org/486428/ +23:21 <marcoz> that's _way_ more than a paragraph +23:22 <stukreit> sounds like you've done your homework! +23:22 <supreet> I could tell you about it, right here +23:22 <supreet> I have :) +23:22 <supreet> depends on what exactly your concerns are +23:22 <supreet> I have been an open-source contributor +23:22 <+emmes> I remember the pains regarding reclocking with my first tries on R600 :-/ +23:23 <supreet> :D +23:23 <marcoz> he mentions documentationa. I think he's sucking up. haha +23:23 <mupuf> emmes: reclocking is already "implemented" +23:23 <mupuf> it is unsafe though +23:23 <supreet> though I won't get to work on reclocking as such +23:23 <Bart_Massey> I think we'd need a timeline and more detail in the proposed work. +23:23 <supreet> more on getting it on the way +23:23 <mupuf> and needs to be done from the card itself to be done safely +23:23 <mupuf> and tear-free +23:23 <Bart_Massey> Other than that, the proposal looks great. +23:24 <supreet> timeline and everything is in the proposal +23:24 <mupuf> Bart_Massey: didn't your receive the proposal? +23:24 <supreet> you can find it in the email +23:24 <+emmes> mupuf: in contrast to R600 you have access to microcode docs (due to rev.eng ;-) - we didn't :-P +23:24 <marcoz> Bart_Massey: that was the one I asked him to resend as pdf and txt. +23:24 <supreet> here is the link to it anyway +23:24 <supreet> https://docs.google.com/document/d/14_Iignvod0cayQcs28gbUT-8QiYaAKc-zTe1MKAE_sA/edit?pli=1 +23:24 <Bart_Massey> oh, must have issed that; thanks +23:24 <+emmes> i'm all for it. looks reasonably written. +1 +23:24 <agd5f> +! +23:24 <agd5f> +1 even +23:25 <Bart_Massey> +1 +23:25 <stukreit> +1 +23:25 <marcheu> mupuf: I don't know if it's late, I've never been told anything about it until I peeked at irc today +23:25 <+emmes> there was something about extending the existing framework in the kernel later on the mailing list, but I think that was about the other proposal regarding performance measurement. correct me if i'm wrong. +23:25 <marcheu> mupuf: had you asked me, I would've told you :) +23:26 <mupuf> marcheu: I'm sorry, I wondered if I should post this proposal to the nouveau ML, but I didn't want phoronix to have a news about this +23:26 <mupuf> and yeah, I'm really sorry, I kept you out of the loop. I should have thought about you. My bad... +23:27 <mupuf> especially since you already have experience with GSoC and I don't... +23:28 <marcoz> are these votes for all 3 proposals or for Supreet's? +23:28 <Bart_Massey> As a 13-week project, I move we fund Supreet's on the same schedule as Ashwin's. +23:28 <alanc> supreet's is the only one I've seen +23:28 <alanc> and that was when he pasted it just now +23:28 <Bart_Massey> I'm +1 on all three proposals. We have payment schedules for the other two already. +23:28 <alanc> so I'm not ready to vote on any of them +23:29 <Bart_Massey> alanc: Makes sense. Would you like to move to defer the vote? +23:29 <agd5f> I'm +1 on all of them as well +23:30 <alanc> no, I'm fine with the rest of you voting while I try to find where the mail is getting lost along the way +23:30 <agd5f> we shouldn't defer too long, it'll be June in a week +23:30 <Bart_Massey> OK, could we get votes on funding all three proposals? +23:30 <Bart_Massey> If you want to fail one, vote -1 and we'll break it down +23:30 <Bart_Massey> (or defer, not necessarily fail) +23:31 <+emmes> I have seen the other two proposals, I'm +1 on them as well +23:31 <Bart_Massey> all right, we're +3. Need votes from others +23:32 <Bart_Massey> Hey! +23:32 <Bart_Massey> anholt: we're voting the three EVoC proposals as a block. +23:32 <ashwinravichandr> this is the link to my proposal: https://docs.google.com/open?id=0Bz98yzQ_YF8aQTVLbWpWXy15VVE +23:32 <stukreit> I've only glanced at supreet's +23:32 <Bart_Massey> Have you seen them and are you prepared to +1? +23:33 <alanc> *sigh* Mithrandir found my mail problem - was still subscribed with my @sun.com address which was shut off in March +23:33 <marcoz> +1 +23:33 <alanc> no wonder I haven't seen board mail in a while +23:33 <Bart_Massey> :-) +23:34 <marcoz> lol +23:34 <marcheu> alanc: use gmail! ;) +23:34 <+anholt> Bart_Massey: I think I've seen 2/3 +23:34 <supreet> you probably missed mine so here is the link : https://docs.google.com/document/d/14_Iignvod0cayQcs28gbUT-8QiYaAKc-zTe1MKAE_sA/edit?pli=1 +23:34 <alanc> I have a gmail address, but that's where stuff goes that I don't read since I hate the click back-and-forth interface +23:35 <Bart_Massey> alanc: you can easily forward your gmail +23:35 <mupuf> alanc: or use imap to access it +23:35 <marcoz> let's not get distracted here folks. :) +23:35 <Bart_Massey> :=-) +23:36 <Bart_Massey> We're at +4, so one more and we're good. I'll give it five more minutes, and then we'll table it for now and move on. +23:37 <stukreit> ashwin: Please explain how you will manage the conclusion of your college work in August and the start of this project in June or so. I suppose you have a load of final exams, papers, or projects at the end? +23:38 <ashwinravichandr> actually it's not like that. i just have graduation in august. +23:38 <ashwinravichandr> i am currently done with my courses and have to just wait for results. +23:39 <Bart_Massey> gratz! +23:39 <ashwinravichandr> which takes a lot of time in India especially in my University as we are an affiliated college to a central college. so, our results will take time. +23:39 <+anholt> so, I've seen supreet's and ashwin's, which is the other? +23:39 <Bart_Massey> Jesse VanDerWalker +23:40 <Bart_Massey> Working with Jeremy Huddleston and Jamey Sharp +23:41 <+anholt> I guess I lied. I've seen 3/3. +1 from me. +23:41 <Bart_Massey> OK. That's +5! +23:41 <Bart_Massey> Gratz to all. +23:41 * supreet celebrates +23:41 <ashwinravichandr> :) +23:42 <Bart_Massey> stukreit: please get contact informatoin from the mentors or students and cut first checks. +23:42 <mupuf> thanks, we'll get in touch with marcoz to know the procedure +23:42 <Bart_Massey> THanks huge. +23:43 <Bart_Massey> I think this is enough for one meeting; move to table remaining business for now and adjourn +23:43 <stukreit> k +23:44 <Bart_Massey> can I get some votes on that? any other urgent business to discuss? +23:44 <stukreit> oh concerning the next conference +23:44 <Bart_Massey> stukreit: go +23:44 <+emmes> ok fine. +23:45 <+emmes> just to note you guys: +23:45 <stukreit> I asked for details of deposits and monies, dates required, and mailingaddresses, pref. in one email to all the board +23:45 <+emmes> we do have a room reserved at the university for the book sprint. more about that on the next meeting in this case... +23:45 <Bart_Massey> stukreit: k marcoz can work with mentors to round that up +23:45 <Bart_Massey> emmes: epic thanks +23:46 <Bart_Massey> stukreit: oops +23:46 <Bart_Massey> nm you're talking about conference stuff +23:46 <stukreit> yes +23:47 <Bart_Massey> stukreit: Yes, this seems reasonable. The sooner we know what to do, the sooner we can write checks. +23:47 <+emmes> stukreit: about your mail: there's a good chance that the room will be for free. nobody asked for anything so far. +23:48 <stukreit> favorite answer. but please ask, and even if its free, we're probably all aligned to making a donation. +23:49 <+emmes> i know :-) but i keep my fingers crossed. +23:49 <Bart_Massey> k will let you folks work this out. gtg. thanks all! :-) +23:49 <alanc> or if like last year we need to buy a couple days worth of in*surance to indemnify the university +23:49 <+emmes> Bart_Massey: for next meeting there's one topic from my side: videos of the conference. I have news! +23:49 <alanc> (though hopefully being in Germany instead of US reduces that level of sillyness) +23:49 <stukreit> right-- and I don't know how to buy in*surance outside of the US +23:49 <Bart_Massey> emmes: Excellent! +23:50 <stukreit> So emmes: please do raise a question or 2 with them. +23:50 <marcoz> emmes: news?! +23:50 <+emmes> alanc: yes, there's by far no that big deal. +23:50 <+emmes> stukreit: i will. +23:50 <Bart_Massey> Bye all! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/06-07.mdwn b/BoardOfDirectors/IrcLogs/2012/06-07.mdwn new file mode 100644 index 00000000..251ab65a --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/06-07.mdwn @@ -0,0 +1,288 @@ + +Date is 2012-06-07, times are UTC+02. +[[!format txt """ +22:59 <+alanc> good afternoon +22:59 <marcoz> good evening and good night. +23:00 <agd5f> hello +23:00 <+alanc> I guess we have to include good morning for our australian & asian friends +23:00 <+emmes> hello and almost good night +23:01 <stukreit> hi +23:01 <+Bart_Massey> Hey all +23:02 <+Bart_Massey> ping +23:02 <+alanc> hello +23:03 <marcoz> Hi Bart +23:03 <+Bart_Massey> Howdy! +23:03 <+alanc> sorry, we'd just all said hello right before you got here +23:03 <+Bart_Massey> cool +23:03 <+Bart_Massey> who all do we have today? +23:04 <+alanc> stukreit, emmes & agd5f were here a minute ago +23:04 <marcoz> I'm here. +23:05 <+Bart_Massey> cool +23:05 <+keithp> hey ho +23:05 <+Bart_Massey> Sounds like most of us +23:05 <+Bart_Massey> Presumably anholt will be back in a moment +23:05 <+keithp> Bart_Massey: anholt has a conflicting meeting +23:05 <agd5f> me too +23:05 <+Bart_Massey> Are these regular or one-time conflicts? +23:05 <agd5f> me too as in I'm here, not a meeting +23:06 <+Bart_Massey> We could try to find another meeting time if this is proving to be a problem for people... +23:06 <+Bart_Massey> Actually, 1s +23:07 <+Bart_Massey> No, I'm OK for this time. +23:07 <+Bart_Massey> Anyway, let's go ahead and start; if folks want to talk about changing the mtg time we can do that in parallel. +23:07 <+Bart_Massey> First order of business: we seem to have another EVoC app? This program is really taking off all of the sudden. +23:08 <marcoz> Yes we have Blaz Tomazic +23:08 <+Bart_Massey> I'm thinking that (a) it might be nice to have a committee (not necessarily all Board members) to decide these rather than the whole Board, but I'm good either way. +23:08 <marcoz> I'm on a windows box and can't do the special chars. sorry for the lettering +23:09 <marcoz> did everyone have a chance to review the proposal and look over the notes I gathered? +23:09 <+Bart_Massey> (b) We need to start thinking about funding for this. If we're going to have a half-dozen of these running at a time, the general X.Org budget will take a fairly big hit. +23:09 <marcoz> I sent two emails to everyone, hopefully in ample time. +23:09 <marcoz> from what I can tell, this is kinda an abnormal spike +23:10 <marcoz> not that I'm complaining. +23:10 <+emmes> Bart_Massey: you mentioned relaxing the (not-yet-in-place) accepted-patch-policy +23:10 <+alanc> presumably some of these would have gone for GSoC, had we gotten in this year +23:10 <+emmes> I think we can relax it to have-shown-some-work-with-open-source-projects or the like +23:10 <+emmes> alanc: indeed +23:10 <+Bart_Massey> emmes: Yeah, I would relax it to "evidence that the student has the skills to succeed" or somesuch. +23:10 <marcoz> summary and overview: http://people.freedesktop.org/~marcoz/evoc/blaz.tomazic/index.html +23:11 <+Bart_Massey> I'm not even sure that previous open source is necessary: just some kind of solid evidence that the student can code and work with others +23:11 <+Bart_Massey> and has whatever specific skills the proposal entails +23:11 <+Bart_Massey> marcoz: Thanks for the nice summary, and for all your work on these. +23:11 <+emmes> yes, but how do you phrase this? +23:12 <marcoz> Bart_Massey: You're welcome. I hope it's sufficient. I'm working on my EVoC coordinator skills. +23:12 <+Bart_Massey> I thought I just did :-) +23:12 <+alanc> previous open source experience helps show that there's potential for becoming a long term contributor, and is less likely to just take the first check and disappear +23:12 * Bart_Massey meant that last for emmes +23:12 <marcoz> emmes: yea, I'm good with Bart's wording. it's succinct. +23:13 <+Bart_Massey> alanc: sure, and I definitely don't want that, but I also want to appear open to skilled outsiders who look promising and want to figure out OSS. +23:13 <+Bart_Massey> Let's face it: a lot of our mentoring is or can be about things like how to get your patches accepted, not just how to code +23:14 <+Bart_Massey> But yeah, it's a fine line. +23:14 <+Bart_Massey> That's why I worded it a little vaguely: I suspect we can figure it out on a case-by-case basis unless we get another giant jump in proposals +23:15 <+alanc> I think we still get few enough of these proposals that we don't need to establish rules at the same rigor as GSoC, so I'd be fine with bart's proposed "some kind of solid evidence" rule, and leaving it to the board/committee to evaluate each case on its merits +23:15 <+emmes> also, we have to keep in mind that we represent open source. from my experience people who have *never* worked with open source guys before can be... difficult to work with in our environment +23:15 <+Bart_Massey> marcoz: You're doing great with EVoC. It's nice to see this program working. +23:15 <+alanc> +1 +23:15 <+Bart_Massey> alanc: I'm taking your statement as a motion, seconding, and voting +1 +23:15 <agd5f> +1 +23:15 <+emmes> but I'm fine if we do that on a case-by-case basis, unless we're getting swamped with proposals +23:15 <+emmes> +1 +23:15 <+alanc> also, you've got multiple students to coordinate at once, a huge spike over our previous coordinator's record of one at a time +23:16 <+keithp> Best to give us flexibility and not attempt to actually write down rigid rules +1 +23:16 <+Bart_Massey> Our previous coordinator *failed* at one student at a time :-) +23:16 <+Bart_Massey> OK, motion passed. +23:16 <+Bart_Massey> Move to accept Blaz's proposal. +23:17 * Bart_Massey hopes it is clear that I mean me by "previous coordinator" +23:17 <+alanc> that's who I meant 8-) +23:17 <+Bart_Massey> alanc: Oh. sorry +23:17 <+Bart_Massey> :-) +23:17 <+alanc> sorry? for agreeing with me that you were the previous one? +23:18 <+Bart_Massey> alanc: Just sorry in general :-) +23:18 <+Bart_Massey> So any discussion before we vote my motion on Blaz? +23:18 <marcoz> Does anyone have any questions, comments or concerns on his proposal and info? +23:19 <+emmes> looking good, we desperately need test cases everywhere, and you seem to be fine with it :) +23:19 <+alanc> anyways, for this proposal, I'm going to have to trust the technical judgement of anholt & stellard who gave their thumbs up +23:19 <+keithp> yeah, we've delegated review to people who know the code :-) +23:19 <+Bart_Massey> Can I get some +1s? +23:19 <marcoz> Tom and Eric looked it over and nodded in approval. Tom, tstellar, is here as well +23:20 <agd5f> +1 +23:20 <+emmes> +1 from my side +23:20 <+alanc> +1 +23:21 <+Bart_Massey> BTW, amend my motion to indicate funding at the US$5000 level, usual payment schedule, Tom to mentor. +23:21 <+Bart_Massey> We have four +1s, need one more +23:21 <+emmes> Didn't Eric already implictly vote? +23:21 <+keithp> +1 +23:21 <+alanc> yeah, should have asked that, since 12-16 weeks left it unclear if we were following a 3 month or 4 month payment schedule +23:22 <+Bart_Massey> Any objections to $5000? +23:22 <+Bart_Massey> emmes: Just like the explicit +1s for the record +23:22 <+alanc> +1 for Bart's amendment +23:22 <+Bart_Massey> Yeah, I guess we should take a full vote on that also +23:23 <+Bart_Massey> Need three more +1s on the amendment, and then we're done with Blaz. +23:23 <marcoz> from his proposal: "The proposed 12 week plan is optimistic, but if some step will take more then expected it can be extended to 16 weeks (or more if I will have time). I don’t have any exams over the summer, only one small paper to write." +23:23 <+emmes> ok, +1 +23:23 <agd5f> +1 +23:23 <+keithp> +1 +23:24 <+Bart_Massey> And both motions are carried. Congrats to Blaz, many thanks to Tom. +23:24 <+Bart_Massey> keithp: Do you have any idea who we might approach about getting some ongoing funding for EVoC specifically? Google seems right out. :-) +23:24 * Bart_Massey really means keithp or anyone... +23:25 <+keithp> Bart_Massey: with our new 501(c)3 status, we should be able to pass the hat around various corporations +23:25 <tstellar> When does the 12 week period start? Today? +23:25 * Bart_Massey seems obsessed with /me today +23:25 <+Bart_Massey> tstellar: Whenever you two like. +23:25 <marcoz> he says he's available immediately. I vote for Monday since it'll make the book keeping simpler +23:25 <+Bart_Massey> keithp: Yeah, but I don't know how or who. +23:25 <marcoz> from his proposal: "On this project I plan to work full-time for 12-16 weeks, starting immediately when (and if) I get accepted to X.Org EVoC." +23:25 <+Bart_Massey> Let's let tstellar, Blaz and stukreit sort out the start time +23:26 <tstellar> marcoz: Ok, sounds good. +23:26 <+alanc> did we ever get our last $15k donation from Intel straightened out and deposited? +23:26 <+Bart_Massey> alanc: wha? this is not something I remember talking about +23:26 <marcoz> i'm good with tstellar and blaz working out the starting date as well. though I would push for a Monday +23:26 <+alanc> oh, and are we going to announce to our membership (or at least to people not on the board list) that the IRS approved our 501(c)3? +23:26 <+Bart_Massey> alanc: That seems like a really, really good idea. +23:27 <+Bart_Massey> Want to draft and send something? :-) +23:27 <tstellar> marcoz: Can I tell him he was accepted, or should I wait for an official notification from the board? +23:27 <marcoz> i htink you just did. ;) +23:27 <agd5f> why would we not want to tell people? +23:27 <+Bart_Massey> tstellar: You may tell him anytime +23:27 <marcoz> tstellar: go ahead. I'll send him and email and cc you but you don't need to wait on me. +23:27 <+alanc> I seem to remember stukreit having to work with keithp & others to get money delivered from Intel's promised funding of one of the recent XDC's +23:27 <+emmes> i think we already add agreed on that on the board mailing list - but we can vote again here to make this official +23:28 <+emmes> (talking about making the 501 status public) +23:28 <stukreit> I guess I should put some words together on the 501 thing +23:28 <+keithp> alanc: getting mony out of intel is always hard +23:28 <+alanc> we agreed that Justin could tell the people on flossfoundations +23:28 <stukreit> I don't believe we ever got that money from intel +23:28 <+Bart_Massey> Somebody needs to actually write a note and send it to the x.org lists +23:28 <+alanc> I can write a note and send it to members +23:28 <+Bart_Massey> re intel money: ow. This was 8 months ago? +23:28 <+Bart_Massey> alanc: Thanks much! +23:29 <+alanc> I've already used the "voice of the foundation" for an announcement once this week 8-) +23:29 <+Bart_Massey> alanc: Thanks as always! +23:29 <+alanc> speaking of flossfoundations, is anyone on that mailing list or should one of us join? http://flossfoundations.org/ +23:29 <+Bart_Massey> Is there any chance we can still get this $15K out of Intel, or is it gone now? +23:29 <+Bart_Massey> I'm not on, and don't do well at keeping up with email. Yes, probably someone should be there. Volunteers? +23:29 <stukreit> wasn't that several years ago? +23:30 <+Bart_Massey> stukreit: If it was for a conference before the most recent one, I suspect there's no chance. sigh. +23:30 <+alanc> thinking it was for the France conference +23:30 <+alanc> which I guess is almost 2 years ago now +23:31 <stukreit> agreed. The only thing to do is start a new round of requests to our behemoth overlords. +23:31 <+Bart_Massey> Yeah, note for the record that we've abandoned that funding opportunity +23:31 <+alanc> so have we had any money come in at all since then? should have also gotten some google money last year +23:31 <+Bart_Massey> We definitely need to do better at tracking this stuff: fortunately stukreit is on the job now +23:31 <+alanc> and should start thinking soon about XDC2012 sponsorship requests +23:31 <+Bart_Massey> marcheu should know the situation with Google money +23:32 <stukreit> I was dl'ing the past 12 months of bank statements, but I don't recall handling any input from google. keithp: Did you somehow funnel it? +23:32 <marcoz> Bart_Massey: I'm ok with joining. though should we have a more someone@x.org email address? +23:32 <+Bart_Massey> "Could you please offer to give us some money for this year's conference? We promise we won't actually ask for it." +23:32 <+Bart_Massey> marcoz: Ask sitewranglers for an x.org address. I think m@x.org is still open :-) +23:33 <marcoz> Bart_Massey: will do. +23:33 <marcoz> stukreit: EVoc related, any luck with the bank stuff to India? +23:33 <+Bart_Massey> I definitely didn't run last year's GSoC money through PSU: marcheu handled it himself IIRC +23:33 <stukreit> I do have 2 details re treasuring to bring up +23:33 <stukreit> India? +23:34 <+Bart_Massey> marcoz: India bank stuff? +23:34 <marcoz> 2 of 3 (now 4) evoc students are in India +23:34 <stukreit> I've been working on doing a wire transfer to Francesco in Berlin. I asked him for his bank routing info. +23:35 <stukreit> I can make the same data request to the evoc students. Do I have email from you or them? +23:35 <marcoz> go ahead. +23:35 <marcoz> i was holding off asking them until I knew what you needed. +23:35 <stukreit> plz send me their emails, I'll ask them. +23:35 <marcoz> will do. +23:36 <+Bart_Massey> Action item: someone needs to track down last year's GSoC money. stukreit, I'll let you check your records and send email if you can't find it? +23:37 <stukreit> ok +23:37 <+Bart_Massey> stukreit: Two other treasury items? +23:37 <+alanc> should be both our mentoring fee for each GSoC project over the summer and reimbursement for mentor summit travel +23:38 <stukreit> 1) I'm gonna wire txfer Francesco's 284Euro reimbursement. I don't know what hsbc will charge for this. I am soliciting any advice from folks here on international money txfer methods, in particular the rumored ill-fated paypal attempt that failed and kept our money. Any chance we can fix that? +23:38 <+Bart_Massey> stukreit: Not without a lawsuit AFAICT +23:39 <stukreit> alanc: as you know I have no short term memory, I'll have to search thru the bank statements +23:39 <+Bart_Massey> I would strongly advise we not deal with Paypal going forward +23:39 <stukreit> I don't understand that, but I'll let it drop, sounds too complicated. +23:39 <+alanc> wasn't the paypal thing like 5-6 years ago now? +23:40 <+Bart_Massey> alanc: Several, anyway: I'd guess more like 3-4, but whatever +23:40 <+alanc> was before I was on the board, so at least more than 3 +23:40 <+Bart_Massey> stukreit: Just pay HSBC whatever they charge if that works. We can at least trust real banks with money +23:40 <agd5f> paypal charges a 10% fee on a lot of transactions +23:40 <stukreit> well, I overheard about it but wasn't listening carefully because it wasn't my problem ;-) +23:41 <stukreit> HSBC is charging us some kind of analysis fee every month. I need to call them and demand they stop doing it. +23:41 <+Bart_Massey> keithp: Action item for you; figure out how to bug the usual suspects for more money effectively. We'll talk at lunch tomorrow +23:41 <stukreit> (that was item 3 of 2) +23:41 <+Bart_Massey> stukreit: That would be nice +23:42 <+Bart_Massey> stukreit: Thanks as always for your treasurerizations +23:42 <stukreit> My 2nd issue is that NRAI informs me that we are delinquent in filing 2011 taxes. huh? we've never filed taxes.. so.. +23:42 <+Bart_Massey> "NRAI"? +23:43 <agd5f> stukreit: delaware corporate taxes? +23:43 <+alanc> I remember having to pay the deleware taxes in the past +23:43 <stukreit> National registered agents, inc. yes, delaware corp tax +23:43 <agd5f> I've got the link for that somewhere. I paid the taxes myself the last time +23:44 <+alanc> wasn't it like $25/yr or something in that range? +23:44 <stukreit> that would explain at least 1 year of amnesia, but I've Never co-signed such a check +23:44 <+Bart_Massey> OK, so we need to pay our back taxes, and make sure we schedule it going forward +23:44 <agd5f> yeah, something like that +23:44 <+Bart_Massey> agd5f: Thanks huge. Lots of cool people on this Board. +23:45 <agd5f> IIRC, it requires a credit card +23:45 <stukreit> the form says we have till march 2013 to fix it, so, am not stressing +23:45 <+Bart_Massey> agd5f, stukreit: I'll let you two figure out offline how to deal with this. Let the Board know if you need anything. +23:45 <stukreit> yes, just letting it be on the record so you can pester me next time about it. +23:45 <+Bart_Massey> stukreit: Thanks much +23:45 <stukreit> (the snooze button on my alarm clock is the most-used button) +23:46 <+Bart_Massey> I hereby declare our money and EVoC business tabled for today, unless there are any more urgent issues? +23:46 <marcoz> status on the 2 of the 3 current EVoC students: mupuf tells me they are off and running. Ashwin got a bout of food poisoning so was down for about 1/2 of last week. Supreet started this Monday. I haven't heard from Jeremey about Jess. +23:46 <+Bart_Massey> marcoz: Thanks for tracking this +23:46 <marcoz> I guess that should read 2 of the 4. ;) +23:47 <+Bart_Massey> One more item of business: Do we have a process for private Board discussion, shy of the email list? +23:48 <agd5f> Bart_Massey: not that I know of +23:48 <+Bart_Massey> There's a conversation I want to have with the Board, but not in public. (Not a big deal, so don't panic, but something that I'd like to evaluate / consider) +23:48 <+Bart_Massey> I think there are times when this is necessary / appropriate. +23:48 <+Bart_Massey> What do other people think, and what shall we do about it? +23:48 <stukreit> Perhaps you should test the waters with your issue but just talking to 1 or 2 members. +23:48 <+alanc> email or in-person @XDC are the only current ways I know of +23:48 <+Bart_Massey> stukreit: Done that +23:49 <+Bart_Massey> alanc: Me too. +23:49 <+emmes> I don't think we have anything in place, less even something "official" +23:49 <+Bart_Massey> OK, just checking. +23:49 <+Bart_Massey> I'll read the Bylaws and see what's currently allowed, and will drop the Board some email RSN. +23:49 <marcoz> Bart_Massey: you're welcome. (bit slow) +23:49 <+Bart_Massey> The Board list is officially private, correct? +23:50 <+alanc> we could probably create a temporary, invite-only channel on some IRC server if needed, or use a google hangout or something +23:50 <+Bart_Massey> alanc: Good suggestions +23:50 <+Bart_Massey> Anyway, there's no time for more business today I think. Thanks once again to everyone for the great work. Any last minute stuff? +23:50 <+alanc> to the best of my knowledge the board list only has board members subscribed and the archives should only be accessible to board members +23:50 <+Bart_Massey> alanc: perfect thanks +23:50 <+alanc> should be able to verify both of those via the mailman web interface +23:51 <+Bart_Massey> alanc: i'm not that concerned, just wanted to verify that that was the policy +23:51 <+Bart_Massey> move to adjourn! +23:51 <agd5f> +1 +23:51 <marcoz> Bart_Massey: I'll ping you on the CFP later. +23:51 <stukreit> +1 +23:51 <marcoz> +1 on adjourn +23:51 <+alanc> +1 +23:51 <+Bart_Massey> marcoz: or call if you prefer +23:52 <+Bart_Massey> Bye all! +23:52 <+emmes> +1 +23:52 <marcoz> Bart_Massey: is phone preferable to email? +23:52 <+Bart_Massey> marcoz: This week, it's much more likely to get a timely response :-) +23:52 <marcoz> noted. +23:54 <agd5f> just logged into the delaware tax site +23:54 <stukreit> ok. what's it say? +23:54 <agd5f> the normal fee is $25, but since we are late, there is a $125 penalty +23:54 <agd5f> plus 1.5% monthly interest +23:54 <marcoz> ouch +23:55 <+Bart_Massey> fair enough, though +23:55 <agd5f> total amount due $157.50 +23:55 <stukreit> ok, I'll pay that asap. Now now about getting email notice to more than 1 person? +23:55 <agd5f> also, as usual, I need the names and addresses of all board members and officers +23:55 <stukreit> Is this simply a matter of paying the money? or is there a form to file? +23:55 <+alanc> mine is same as last year's +23:56 <agd5f> I'll email the details to the board +23:56 <+alanc> (or same as was in our 501(c)3 form if you have that still) +23:56 <agd5f> please get back to me with your info +23:56 <+alanc> k +23:56 <stukreit> I'm sorry I missed this until the drubbing notice. Need to make sure this doesn't happen again +23:57 <agd5f> we need an address +23:57 <agd5f> IIRC we used SFLC last time, any the notices may have gone there and gotten lost +23:58 <agd5f> *and +23:58 <+alanc> thought we were switching to using Stuart's address for stuff like that +23:58 <agd5f> I'll use that this time +23:58 <stukreit> I would give my address, but then I'd get doubly blamed for biffing this. sigh... I don't want to grow up. +00:00 <+alanc> don't let your kids grow up before you do +00:00 <stukreit> can use my address, but keep in mind that it may change in 6 months. My house is on a corner and I'm doing a 90degree clockwise remodel. +00:00 <agd5f> stukreit: ok +00:01 <stukreit> I will take the responsibility if I can be somewhat assured of a backup. +00:01 <+alanc> sounds like NRAI got the notice as well this time +00:02 <stukreit> ok then, the AI is for me to loginto nrai and figure out how to inject the money. +00:03 <agd5f> stukreit: I sent you the link +00:04 <stukreit> thanks, are we done for now? +00:05 <agd5f> nothing more from me +00:06 <+alanc> i think everyone else already left +00:06 <stukreit> so just one question, agd: +00:06 <agd5f> sure +00:07 <stukreit> Do you think what happened is that the notice came into sflc and no one there informed me (possibly due to 2 changes in persons rep'ing us)? If so, I wonder how nrai finally send the notice to me? +00:08 <agd5f> maybe they tried the sflc and when they got no response, send something to the treasurer +00:08 <stukreit> I have 2 pieces of mail from them: 11/19/11 sent to sflc for statutory representation. I paid that one on the website. +00:08 <agd5f> IIRC, you were listed as treasurer +00:09 <stukreit> then this one, to me, dated april 23 2012 +00:09 <stukreit> ok, anyway, I'll go over there and straighten this out. +00:09 <stukreit> I'll let you go now. +00:11 <agd5f> cool. let me know if you need a hand with anything +00:11 <stukreit> sure, you've been most helpful and gracious +00:12 <agd5f> might be worth calling them. I think last time justin called then and they took off the penalty +00:12 <stukreit> ! I'll try that +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/06-21.mdwn b/BoardOfDirectors/IrcLogs/2012/06-21.mdwn new file mode 100644 index 00000000..7e915a89 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/06-21.mdwn @@ -0,0 +1,104 @@ + +Date is 2012-06-21, times are UTC+02. +[[!format txt """ +22:57 <marcoz> hey mupuf, how's Ashwin and Supreet doing? +23:02 <+emmes> hi all +23:02 <marcoz> hey emmes +23:03 <+emmes> bart doesn't seem to be here yet, I also don't see alex so far +23:03 <+alanc> good afternoon +23:05 <+alanc> wasn't alex going to be on a plane instead of coming today? or was that someone else? +23:05 <+alanc> I remember Bart was going to be in Hawaii +23:05 <stukreit> I'm 1/2 here (on a con call) +23:06 <+alanc> guess we can ask if he can see our CEO's new vacation place from there 8-) +23:06 <+anholt> back. +23:07 <+keithp> hey ho +23:07 <marcoz> who you callin' ho? +23:08 <+keithp> alanc: bart said he'd try to join, but frankly, hawaii seems more interesting than x.org bod +23:08 <+alanc> understood +23:09 <+keithp> I don't have anything new this week either +23:09 <+emmes> i have one point: video recording on xdc +23:09 <+alanc> also lets him skip out out giving an update on the XDC CFP he was supposed to be doing though +23:09 <+keithp> lucky for him +23:10 <+alanc> though I'm a couple action items behind myself (bylaw review, 501c3 announcement) so I'll shut up now 8-) +23:10 <+keithp> last I heard, there wasn't much interest in a formal paper review process for XDC, but some kind of 'submissions time folks' email would be good +23:10 <+alanc> so I say we give the floor to emmes for his xdc item +23:11 <marcoz> I told Bart I'd help with the CFP. Looks like I'm the one holding him up +23:11 <+emmes> ok, it's not a big deal +23:11 <+emmes> a friend from suse agreed on doing the video, with the (semi-) professional equipment (3-chip 1080p cameras) we have at suse +23:12 <+emmes> some of you might know him, it's Juergen Weigert, on of the authors of screen +23:12 <+alanc> cool +23:12 <+emmes> there is one caveat, though (there always is ;-) +23:12 <marcoz> sweet. can he give a short pres on awesome tricks in screen? +23:13 <+emmes> he requires a few helpers, in fact he's more keen in teaching them how to deal with the cutting. +23:13 <+emmes> so it's more like: do you want to know how to record a talk reasonably? then join here. +23:13 <+emmes> i'll join, of course, because I want to learn ;-) +23:14 <+alanc> sounds like an opportunity to do some of that educational stuff we talked about in our IRS paperwork +23:14 <+emmes> but we probably would need 1,2 more (preferably students) who are willing to learn +23:14 <+emmes> exactly +23:14 <marcoz> i'll help if we end up being short on student volunteers +23:14 <+emmes> cool +23:15 <+alanc> if any of our students want to help thats great, if a professor in the area of the conference had some students from his school who wanted to come learn about video even if they're not involved in X.Org, I'd be happy with that too +23:16 <+emmes> only thing would be, that it would be awesome if the volunteers were here the day before the conference starts, so Juergen can do some introduction. He told me that his experience shows, that almost anybody is able to do that after 1 or 2 hours... +23:16 <+emmes> ok, i'll ask at my place, i'm teaching media engineering so this fits ;-) +23:17 <+emmes> one minor additional thing: +23:18 <+emmes> i'll try to setup a live video streaming solution, and if that works, i'll probably need some support on one of our machines (installing stuff or so). Which of our machines would be best suited for that? +23:21 <+emmes> apparently nobody has an idea... +23:21 <+alanc> I'd suggest asking Tollef or one of the other fd.o admins +23:22 <+alanc> certainly would want to at least give them a heads up of bandwidth spiking the 3 days of the conference +23:22 <+emmes> i thought anholt was one of the fd.o admins. Eric, you there? +23:23 <+keithp> alanc: we've got gods gift to bandwidth; I wouldn't worry about it +23:23 <+emmes> i'll certainly will talk to Tollef, but only after I've confirmed that the system is actually working... which i've no idea of yet. +23:24 <+alanc> keithp: I was more worried about them not being surprised by the sudden change, rather than worrying we wouldn't have enough +23:24 <+anholt> I don't do any management of the software on fdo machines. +23:24 <jcristau> the debconf video team has some experience with conference video recording and streaming, they've gotten quite good at it. if you want to talk to them. +23:24 <+anholt> but yeah, b/w and storage should not be problems +23:25 <+keithp> they're a bit busy at present getting ready for debconf, but holger in particular is quite knowledgeable and helpful +23:25 <+emmes> jcristau: I think juergen uses a cutting engine based on the one used at debconf. +23:25 <jcristau> ok +23:26 <+emmes> it's basically a live cutting engine - the only thing that frees you from the laborous work of cutting the talks afterwards... and it should enable live streaming +23:27 <+alanc> I guess when our EVoC students pass their midterms and we decide they're ready to be invited to EVoC we should ask if any are interested in media production and offer to fly them in early enough for the setup/training on the prior day +23:27 <+alanc> err, ready to be invited to XDC +23:27 <+emmes> exactly that's what i had in mind +23:27 <+alanc> stupid typos hiding until right after you hit return and they jump out in your face +23:28 <marcoz> is that my cue for evoc report? +23:28 <+emmes> i guess so - I'm done :-) +23:28 <+alanc> sounds good to me +23:29 <marcoz> Ashwin was out for 1 1/2 weeks for food poisoning, ended up in hospital. +23:29 <marcoz> he's back at it. mupuf gave him lots to read so he wasn't completely out of it. +23:30 <marcoz> the others, no complaints. Jess emailed me ~1 hr ago that Blaž is doing well. +23:30 <+alanc> ouch, poor guy - though I'd probably have taken a laptop to the hospital and written incoherent stuff for days +23:30 <marcoz> we've mailed out 1/4 initial payments. To Jess. the others were missing some info. Stuart got me a template that I sent to the other 3, they filled it out and sent it back and I got it to Stuart late last night +23:31 <marcoz> yea, I'd be like "who wrote this crap? oh yea, me" +23:31 <marcoz> stukreit: did you get the info ok? +23:32 <marcoz> Jess is camping this weekend. so we won't know if he's received it until prob Mon. +23:32 <marcoz> that's my report. +23:36 <+alanc> okay +23:36 <+alanc> anything else we have to discuss today? +23:39 <+alanc> are we all mentally out on the beach sipping drinks with little umbrellas, like bart presumably actually is doing? +23:39 <marcoz> ugh, i can hear seagulls cawing now. +23:39 <marcoz> makes this cube seem even smaller +23:40 <+emmes> i'm mentally sleeping... +23:42 <stukreit> unsnooze: sorry, the other call.. +23:43 <stukreit> marcoz: got your emails, haven't opened them yet +23:43 <marcoz> ok +23:43 <stukreit> i'll let you know if any more probs +23:43 <marcoz> thx +23:44 <marcoz> i'm writing this process all down so it's smooth next EVoC +23:44 <stukreit> that is, if we still use wire txfers. We'll see how smooth/expensive this goes +23:45 <marcoz> is it fixed cost or % for wires of that amt? +23:45 <stukreit> they haven't told me yet +23:45 <stukreit> I'm just doing it. +23:45 <marcoz> ok +23:47 <stukreit> have to deal with crap like: if its a currency exchange, the order must be made before 3pm EST, they can't let the order sit overnight. the error message didn't explain that reason to me, I had to get someone on the phone. +23:48 <marcoz> good times +23:48 <stukreit> also, since I haven't made a wire txfer in 24 months (actually, never), they stepwise reduced the ceiling to $0. So, now they raised it to $250k. I told them I'd prefer a ceiling of $10k as a safety fence. no can do. +23:48 <stukreit> just to let you know- my little brain cell is running back and forth on this. +23:49 <marcoz> what does ceiling mean in this case? +23:49 <marcoz> (keep up the good work. thx for doing that) +00:04 <+emmes> it seems we can move to ajourn? +00:04 <marcoz> +1 +00:04 <+anholt> +1 +00:05 <+alanc> +! +00:10 <+emmes> so see you all (and bart again) in two weeks time +00:12 <marcoz> have a good one +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/07-05.mdwn b/BoardOfDirectors/IrcLogs/2012/07-05.mdwn new file mode 100644 index 00000000..983b8361 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/07-05.mdwn @@ -0,0 +1,130 @@ + +Date is 2012-07-05, times are UTC+02. +[[!format txt """ +23:01 <agd5f> hi +23:01 <+Bart_Massey> howdy all! +23:01 <marcoz> except when the kids or pets have had too much sugar. then the office is so much better. ;) +23:01 <marcoz> Hi Bart +23:02 <stukreit> my kids are grown, and my 14 year old dog is mellow company +23:02 <+Bart_Massey> Where are the meeting minutes kept, again? +23:02 <+emmes> hey bart +23:02 <+alanc> though we miss having stu's dog come to the office with him since the acquistion ended the pets-at-work policy +23:02 <+alanc> Bart_Massey: http://www.x.org/wiki/BoardOfDirectors/IrcLogs +23:03 <+emmes> haven't uploaded the last one yet +23:03 <stukreit> yeah, because he's the best dog in the world(tm), at least that's what the vet told me 14 years ago. +23:03 <marcoz> too bad. it's kinda nice having pooches around. Did you ever hear of a dog deciding to mark a cube wall? +23:03 <+Bart_Massey> emmes: ok. just wanted to make sure i wasn't missing something. +23:04 <+alanc> did hear of very rare occasional accidents, as well as the occasional coworker with allergy attack +23:04 <+Bart_Massey> Sorry to not be available last meeting. Anything of note? +23:04 <marcoz> pencil lashing for my falling behind on the CFP +23:04 <+Bart_Massey> LOL +23:05 <+alanc> we all wished we'd been with you on the beach with drinks containing little umbrellas instead +23:05 <+Bart_Massey> Yeah, I wish you could have been there too :-) +23:05 <+Bart_Massey> I'm not sure why I left... +23:05 <+Bart_Massey> So anyway, let's make this quick, as I don't have too much on my list. +23:05 <+Bart_Massey> Anybody got specific things we need to talk about? +23:05 <stukreit> if you'd bought the island, you could stay as long as you want. +23:06 <+Bart_Massey> $600M is an insane bargain +23:06 <stukreit> I have things. Some wire transfers made +23:06 <+Bart_Massey> stukreit: cool. tell us +23:06 <stukreit> Ok, to Sundar Ravichandran: $1000 +23:07 <+Bart_Massey> EVoC? +23:07 <stukreit> Francisco Jerez Plata: $3000 ( last 2 payments of prev year) +23:07 <stukreit> yes.. these are all evoc +23:07 <+Bart_Massey> Yay! +23:07 <stukreit> to Supreet Pal Singh: $1000 +23:07 <stukreit> to Jess Vanderwalker: $1000 +23:08 <stukreit> To Francisco Jerez Plata: $329.89, travel expenses (Fosdem, I believe?) +23:09 <marcoz> any luck with Blaz? +23:09 <stukreit> Our balance in savings account is $89,968/21, checking: $135.15 +23:09 <+alanc> yeah, we covered his trip to fosdem to talk about his winter EVoC projects +23:09 <+Bart_Massey> Cool. Thanks much as always. +23:10 <+Bart_Massey> BTW, alanc: thanks much for the note you sent out on travel funding and stuff. That was really nice. +23:10 <stukreit> re blaz: looking, wait +23:10 <+alanc> sure, was quick to write up +23:11 <+Bart_Massey> Speaking of which, anyone hoping to go to FLOSS.in or whatever it was? +23:12 <+Bart_Massey> OK. I'm tempted, but I'll have to take a really close look at my schedule before I commit. +23:12 <+Bart_Massey> Other outstanding business: Have we paid our Delaware back taxes and penalties? +23:13 <stukreit> re Blaz: I don't think I completed the order for him because we went back and forth on his banking numbers. I try to save a pdf of each wire order, but I'm not excellent at recordkeeping, admittedly. I Thought I tried to send his order. There are so many gotcha's in the wire txfer process, sometimes its an hsbc website failure. +23:13 <+Bart_Massey> stukreit: NBD. Do email him again and check where the two of you are, though. +23:13 <stukreit> Didn't attack the delaware fee yet. The action was to contact them and beg for leniency on the penalty one more time. +23:13 <+alanc> didn't actually hear back from anyone about FOSS.in, LCA, or others, but their CFPs have a few days left I think +23:14 <+Bart_Massey> stukreit: Delaware really needs to be done sooner rather than later. Do you need some help with it? +23:14 <stukreit> yes, will do. It has a new line in my notebook with the clever checkbox in front. +23:14 <+Bart_Massey> You should also find out whether we can pay a year ahead, maybe... +23:15 <stukreit> well, yeah. Did Alex contact them the first time? +23:15 <+Bart_Massey> Probably. I was involved at some point early on also, as was cworth. +23:15 <+Bart_Massey> agd5f: Around today? +23:15 <stukreit> I scanned in this and a few docs. I intend to scan in all of the bulging folder so people can help without holding the filebox. +23:16 <+Bart_Massey> stukreit: Excellent +23:16 <agd5f> Bart_Massey: contact whom? +23:16 <+Bart_Massey> Delaware +23:16 <stukreit> it'll be excellent when someone other can make good use of it. +23:16 <agd5f> they contacted SFLC and filled in the web form and paid the taxes +23:17 <+Bart_Massey> agd5f: "they"? +23:17 <marcoz> just fyi: Ashwin (SUndar) mentioned he might be interested in FOSS.IN and talking about CUDA. I haven't had a chance to run this down any further. +23:17 <stukreit> right now I can't find the fed tax id. in my pile. anybody have it handy? +23:17 <agd5f> Bart_Massey: they contacted SFLC and *I* filled in the web form and paid the taxes +23:17 <agd5f> whoops +23:18 <stukreit> agdfffff: wasn't that the previous year? or this year too, making my page obselete? +23:18 <+Bart_Massey> marcoz: That would be cool, I think? IDK Ashwin, but it would be nice to have someone there +23:19 <agd5f> stukreit: I thought you were handling this latest one +23:20 <stukreit> oh, well, damn, ok. +23:20 <agd5f> I only did the last two years, not the most recent one +23:20 <stukreit> I'm kind of rejection averse. What did you say to make them give in? +23:21 <stukreit> and will they realize we keep screwing up and whining? +23:22 <+Bart_Massey> Anyway, if agd5f and stukreit could figure out the tax thing and send Delaware whatever money they think they are owed ASAP, that would be great. +23:22 <+Bart_Massey> I don't think we need to whine or mess around: Just send them what they asked for, no? +23:22 <stukreit> the bill is like $175, $150 of that is penalty +23:22 <+Bart_Massey> That's fine: we're good for it. +23:23 <+Bart_Massey> We screwed up. Let's just pay the penalty and get on to next year's taxes :-) +23:23 <stukreit> not sure why we were late nor why the bill finally came to my house +23:23 <stukreit> I can do that. +23:23 <+Bart_Massey> Cool. Thanks! +23:24 <+Bart_Massey> Next item: I'm back to working on getting the e-book from our book sprint together. I should have a draft in a couple of weeks. +23:24 <marcoz> Bart_Massey: yay +23:24 <stukreit> on a related note: hsbc charges us "analysis fee" which apparently bundles various service including wire fees. This month it was $96. I really should ask about that and get it knocked down. +23:25 <+Bart_Massey> I've learned how to build epub with Sigil, and I think that's the plan: convert everything to HTML, then to epub, then to whatever format folks want using Calibre +23:25 <+Bart_Massey> stukreit: We need to get a better bank, IMHO. We've had nothing but trouble with HSBC. +23:25 <+alanc> do we have a plan for book sprint @XDC yet? getting near time to make travel plans for september +23:25 <stukreit> How about Barclay's? +23:25 <+Bart_Massey> Now that we have the 501(c)3, I think there's no reason not to move. +23:26 <+Bart_Massey> stukreit: I don't really know much about choosing a bank. Talk to keithp, who has more experience. +23:26 <+Bart_Massey> alanc: Good point; we should figure this out. +23:26 <stukreit> ok +23:26 <+Bart_Massey> marcoz: What's the organizational plan for the f2f book sprint at XDC? +23:26 <marcoz> I believe emmes and the Nuernburg posse have reserved a room for those days. +23:26 <marcoz> for the book sprint +23:27 <marcoz> the two days before XDC +23:27 <+Bart_Massey> marcoz: Yes. Now we need invites, and a vague plan for what we'll be doing there. +23:27 <marcoz> "the same thing we do every fall pinky....plan to take over the world" +23:27 <+Bart_Massey> Oh, that *never* ends well... +23:27 <marcoz> ;) +23:28 <+Bart_Massey> Given that we're so close to done with the new developers' guide, I'm wondering if a driver developers' guide based around marcheu's stuff would be the right thing to do there. +23:29 <+Bart_Massey> We could take his apart and put it back together with him. I could edit, which is the limit of my technical competence on that topic. +23:30 <+Bart_Massey> Anyway, let's take that whole discussion offline. marcoz: charging you with doing an email dialogue with the board and interested x-ers to get something together in the next week or two. Good? +23:30 <marcoz> I like that. how much editting would be required? It looks in pretty good shape already. +23:30 <marcoz> Bart_Massey: ok. +23:30 <+Bart_Massey> marcoz: IDK. It's obviously well-written and looks complete to me, but I'd feel better if keithp and airlied and whoever reviewed it thoroughly. +23:30 <+alanc> is the Wayland API stable enough yet that we should be having wayland book sprints to get documentation for developers? +23:31 <+Bart_Massey> alanc: Ooh, good idea. +23:31 <+Bart_Massey> marcoz: Add that to the list. +23:31 <marcoz> will that spread us too thin? +23:31 <+Bart_Massey> marcoz: No, we have to pick +23:32 <+Bart_Massey> I'd say if keithp and airlied and agd5f and whoever else I should be mentioning look at marcheu's stuff and say "almost done", then the Wayland thing is a better plan. +23:32 <marcoz> ok, that'll be part of the discussion then. +23:32 <+Bart_Massey> New content trumps old content for a book sprint. +23:32 <+Bart_Massey> marcoz: yes +23:32 <+Bart_Massey> OK, I don't have anything more obvious to talk about. Any more items from others? +23:33 <agd5f> where is marcheu's latest version? Last time I looked at it was probably 6-9 months ago or longer +23:33 <+Bart_Massey> agd5f: I don't think it's changed much since then. +23:33 <+alanc> http://cgit.freedesktop.org/~marcheu/lgd/ +23:34 <agd5f> oh cool. git. last one I had was a pdf +23:35 <+alanc> that's the sources that generate the pdf, I've got the pdf link somewhere as well +23:35 <+Bart_Massey> Move to adjourn. Thanks all! +23:35 <stukreit> +1 +23:35 <marcoz> +1 +23:35 <agd5f> +1 +23:35 <+alanc> +1 +23:36 <+Bart_Massey> motion carries. thanks again! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/07-19.mdwn b/BoardOfDirectors/IrcLogs/2012/07-19.mdwn new file mode 100644 index 00000000..fd99134b --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/07-19.mdwn @@ -0,0 +1,257 @@ + +Date is 2012-07-19, times are UTC+02. +[[!format txt """ +23:01 <+alanc> good afternoon +23:01 <+Bart_Massey> Greetings. +23:01 <+Bart_Massey> What business do we have to transact today? +23:01 <+keithp> hola +23:01 <stukreit> hi +23:02 <+Bart_Massey> I've got one set of agenda items, related to the Bylaws +23:02 <+Bart_Massey> Is anything else pressing? +23:02 <stukreit> do we need to approve alan's message re. 501(c)3 announcement? +23:02 <+anholt> switching rooms +23:03 <+alanc> all the mail I got seemed to be in favor of it, I was just going to see if I could post the required public disclosure stuff that Aaron forwarded and stick the URL in, then post +23:03 <+keithp> sounds good to me +23:03 <+emmes> hey all +23:04 <+emmes> i'm online via phone only, so i might drop off silently... +23:04 <+Bart_Massey> I'm not seeing this email +23:04 <+Bart_Massey> when was it sent? +23:04 <marcoz> hi all. sorryIm' late +23:05 <+alanc> which e-mail? the announcement? +23:05 <+Bart_Massey> Yeah. +23:06 <+alanc> Date: Sun, 15 Jul 2012 19:33:00 -0700 +23:06 <+alanc> From: Alan Coopersmith <alan.coopersmith@oracle.com> +23:06 <+alanc> Subject: Draft press release for X.Org 501(c)(3) status +23:06 <+Bart_Massey> Found it, thanks +23:07 <+emmes> yes that one - looked very good to me +23:07 <+Bart_Massey> Yeah, looks good to me also. Let's do it. +23:07 <+Bart_Massey> Has someone put the documents up? +23:07 <+Bart_Massey> Anyone opposed to any of this? +23:08 <+Bart_Massey> Hearing no opposition, the motion is carried. Thanks much, alanc! +23:09 <+alanc> looks like I don't have privs to make a new directory under /srv/xorg.freedesktop.org/www - probably need anholt or keithp to help - I was thinking /foundation/ so it would appear as www.x.org/foundation/ +23:09 <+Bart_Massey> Sigh. We really need to sort wiki privs rsn. +23:09 <+keithp> alanc: I wonder if that would actually work :-) +23:09 <+alanc> seems to work for /archives/ and /videos/ +23:09 <+Bart_Massey> The one very small edit I would make to the announcement is to capitalize "Foundation" throughout.... +23:10 <+alanc> not sure if those needed httpd configuration though +23:10 <+Bart_Massey> Are we good on all this? +23:10 <+alanc> Bart_Massey: will capitalize +23:11 <+Bart_Massey> tx +23:11 <+Bart_Massey> Next up: I've been reading the Bylaws carefully to see what we might want to change. I've discovered some "interesting" things. +23:11 <agd5f> hi, sorry I'm late +23:11 <+keithp> alanc: give it a shot +23:11 <+keithp> (foundation dir created) +23:12 <+Bart_Massey> Perhaps the most relevant is around Annual Meetings +23:12 <+keithp> provides a nice directory list at present +23:12 <+Bart_Massey> Perhaps all of you knew all this, but it was news to me: +23:13 <+Bart_Massey> There are supposed to be two Annual Meetings: An Annual Meeting of the Board and an Annual Meeting of the Members. To transact business at the Members meeting, there must be a quorum of the Membership. +23:13 <+Bart_Massey> Further, voting for business at the Members meeting is required to be electronic under the current Bylaws (?!) +23:14 <+Bart_Massey> So it looks like holding an IRC meeting, separate from XDC, is the only reasonable way to run the Members meeting if we actually want to transact business? +23:14 <+Bart_Massey> In particular, if we want to change the Bylaws. +23:14 <+alanc> right, my reading was the members meeting was purely online and the voting was via our web ballot system +23:14 <+alanc> which I think is how we voted on bylaws last time, as part of a board election +23:15 <+Bart_Massey> OK. What this tells me, then, is that there's no real deadline tying any proposed Bylaws changes to XDC, which is good. +23:15 <+Bart_Massey> XDC can still be the Annual Meeting of the Board. +23:15 <+alanc> keithp: thanks, seems to work, copying docs into place now +23:15 <+Bart_Massey> But we are really supposed to hold an Annual Members Meeting every year. +23:15 <+Bart_Massey> (Whether we have business or not.) +23:16 <+Bart_Massey> There's some other interesting stuff, but I'll pack that into an email and send it later. +23:17 <+Bart_Massey> Just wanted everyone to know where I was with this stuff. +23:17 <+alanc> well, electing the board is always business for the annual meeting +23:17 <+Bart_Massey> When does everyone want to hold the Annual Meeting of Members? +23:17 <+alanc> we've just not been that formal about doing calling it a meeting instead of just an election +23:18 <+Bart_Massey> We are supposed to announce it 21 days in advance, and IMHO it would be wise to do it before elections. +23:18 <+Bart_Massey> alanc: I'm not so sure that under the current Bylaws the Election can count as the Annual Meeting of Members. Is that what we've been relying on in the past? +23:18 <+alanc> btw, there were already a couple e-mails on this in the "Bylaws Review" thread also starting Sunday evening +23:19 <+alanc> Bart_Massey: well, I think we've mostly ignored that in the past, I was just trying to hand wave us into compliance after the fact +23:20 <+Bart_Massey> Fair enough. :-) +23:20 <+Bart_Massey> I think the best plan is to come into compliance now and actually schedule a special Annual Meeting of Members on IRC. +23:20 * Bart_Massey s/special// +23:21 <+Bart_Massey> As the Bylaws are currently drafted, I don't think the Members can actually vote any business at the Meeting :-), but we can say we had one. +23:21 <+alanc> okay - I know some other open source groups do similar - have a channel open for a few days so that people can come & go as time zones/schedules allow +23:22 <+Bart_Massey> Thanks for the Bylaws Review thread, BTW. Sorry I'm missing so much email. +23:22 <+Bart_Massey> OK, I'll schedule it RSN and we can announce it. I'm guessing mid-August will be good? +23:22 <+Bart_Massey> (well, late August: 21 days notice) +23:23 <+Bart_Massey> Not hearing any objections, I'll work on that plan then. We'll try to get Bylaws changes together to be voted together with the next Election in January or February. +23:24 <+Bart_Massey> Let's take the rest of this to email, unless someone has specific things they think we need to talk about? +23:25 <agd5f> sounds good to me +23:25 <+alanc> +1 +23:25 <agd5f> +1 +23:26 <marcoz> +1 +23:26 <+Bart_Massey> OK. I have no other business. Anyone? +23:26 <marcoz> EVoC +23:26 <+Bart_Massey> marcoz: Go +23:26 <marcoz> I'll type this up more formally and send to everyone, but here's summary: +23:26 <marcoz> Tom reports Blaz gets a pass +23:27 <marcoz> This is mid-point reviews +23:27 <marcoz> (the students are at their midpoints in there projects ) +23:27 <marcoz> Martin reports Supreet gets a pass +23:27 <marcoz> Jeremy just got back from his honeymoon so haven't gotten Jess' review yet; he doesn't get a mid-point payment though so not as urgent +23:27 <marcoz> Ashwin, however, has had some problems. +23:27 <marcoz> In the hospital with food poisoning for 2 weeks. +23:27 <+Bart_Massey> Ow. +23:28 <marcoz> plus problems with his university. apparently they didn't like him working on EVoC instead of getting a 'real' job. +23:28 <marcoz> so he's behind +23:28 <marcoz> mupuf: you there? +23:28 <marcoz> he's been offline a lot too; Martin reports he's been somewhat difficult to get ahold of. +23:28 <+Bart_Massey> Why does the university care / get to say? odd +23:28 <marcoz> connection problems are partly to blame +23:29 <marcoz> no idea. +23:29 <marcoz> I'm hoping mupuf is online +23:29 <+Bart_Massey> OK, it sounds like marcoz and mupuf and Ashwin need to sort this out. +23:29 <stukreit> I'm on the google forum, reading lots of debates on how to handle unforeseen issues with students. good stuff +23:29 <+Bart_Massey> I think the Board is going to be fine with anything that the Mentor and marcoz agree on. +23:30 <marcoz> ok. 2 of the students are doing well and get passes from their mentors +23:30 <+Bart_Massey> stukreit: Yeah, they deal with far worse, and have way more bureaucracy in the process. +23:30 <+Bart_Massey> Not a lot, mind you, but way more. :-) +23:30 <marcoz> should I write it up officially before we approve payments to those two or ... ? +23:31 <+Bart_Massey> Thanks for the summary. Let us know if there's some way to help with Ashwin. +23:31 <marcoz> will do. +23:31 <+Bart_Massey> Move to approve payments to Blaz and Supreet +23:31 <mupuf> marcoz: yes +23:31 <mupuf> sorry, missed the begining +23:31 <marcoz> i propose pushing Ashwin's midpoint review back a couple weeks. +23:32 <+Bart_Massey> mupuf, marcoz: please hold a sec +23:32 <agd5f> Bart_Massey: +1 on approving Blaz and Supreet +23:32 <+Bart_Massey> Board: Can I get votes on the motion to approve payments? +23:32 <+Bart_Massey> agd5f: thanks +23:33 <stukreit> Someone please write in the payments amounts in this record.. +23:33 <+Bart_Massey> marcoz: Do you have the payment amounts handy? +23:33 <marcoz> USD2000 +23:33 <+Bart_Massey> For both? +23:33 <marcoz> supreet definitely. +23:34 <marcoz> i'm looking for blaz to verify. I apparently didn't put it on that page +23:36 <stukreit> bart: yes, its $2000 per participant when they pass the midterm eval +23:36 <marcoz> blaz also USD2000 +23:36 <+Bart_Massey> marcoz, stukreit: Thanks +23:36 <+Bart_Massey> So, we have a motion pending. Can we get three more +1s from the Board? +23:37 <stukreit> +1 +23:37 <+alanc> +1 on approving USD2000 mid-term payments for Blaz & Supreet +23:37 <+Bart_Massey> marcoz: ? +23:37 <marcoz> (I'd prefer not to vote on these. stay neutral.) +23:37 <+Bart_Massey> marcoz: There's no reason for you not to vote on them, and keithp and others seem to be asleep :-) +23:37 <marcoz> (unless there's noone else.) +23:38 <+keithp> Bart_Massey: +1 from me :-) +23:38 <+Bart_Massey> There we are. +23:38 * keithp is multi-tasking +23:38 <+Bart_Massey> :-) +23:38 <+Bart_Massey> Motion is carried. +23:38 <stukreit> retroactively... do we want 25 words from each mentor re. midterm eval? +23:38 <marcoz> (I'd prefer not to vote because I"m the coordinator. maybe I'm weird.) +23:39 <stukreit> marcoz: see above +23:39 <+Bart_Massey> marcoz: Not "weird", but yeah, there's no reason not to vote, I think +23:39 <+Bart_Massey> stukreit: That would be nice +23:39 <marcoz> i have 3 of the 4 of those evals. +23:39 <marcoz> just waiting on Jeremy. He was on his honeymoon +23:39 <+Bart_Massey> Move that future payments be authorized by the Board to be made without a vote of the Board, at the discretion of the Coordinator. +23:40 <+keithp> I'm ok with voting; makes sure we're all aware of progress +23:40 <stukreit> ok, then where will we read them? email or posted publicly (I assume email) +23:40 <marcoz> not sure I want that responsibility. I already stress about this stuff +23:40 <+Bart_Massey> OK, motion is withdrawn based on objections +23:40 <marcoz> stukreit: I can sned one at a time or in digest when I get Jess' from Jeremy. ? +23:40 <+Bart_Massey> If we keep getting EVoC students at this rate, it's going to get time-consuming, though :-) +23:40 <stukreit> marcoz: sounds like you're good for this role. we want someone who cares too much +23:41 <+Bart_Massey> marcoz: Send 'em as you get 'em, I think. +23:41 <marcoz> 1 vote for as I get them. anyone else? +23:41 <stukreit> m: I'd prefer to receive all in one doc. easier to track +23:41 <marcoz> stukreit: btw, we have another proposal in the works. ;) +23:41 <+Bart_Massey> I'm shocked. +23:42 <stukreit> i'll push a little harder then: It also encourages the last person to get r done +23:42 <marcoz> Bart_Massey: : pleasantly I hope. +23:42 <marcoz> stukreit: I'll ping jeremy +23:42 <+Bart_Massey> Sarcastically, mostly :-) +23:42 <marcheu> so this time can we require at least one patch in one of the fd.o repos before taking the students in? +23:42 <marcoz> lol +23:42 <+Bart_Massey> This program is pretty clearly taking off. +23:42 <marcheu> last time was too late, but this time is not too late right :) +23:42 <mupuf> marcheu: yeah, that would be a good thing :) +23:43 <marcoz> does the patch need to be accepted or just submitteed and in their queue/ML? +23:43 <marcheu> I'd say accepted, or rejected on unrelated grounds +23:43 <+Bart_Massey> marcheu: I think it should be either a patch or some other evidence of student readiness +23:43 <marcheu> yeah, but "one patch" is an easily defined entity +23:43 <+Bart_Massey> I don't see that we've had a problem with the actual coding of any of the students so far? +23:44 <marcheu> IMO it's more about commitment than coding +23:44 <stukreit> marcoz: do we have the name of the schools that each evoc'r attends? +23:44 <mupuf> Bart_Massey: not really, but some things take time. Sending a patch means the student has the right state of mind and understands what he is doing +23:44 <marcoz> stukreit: good question. +23:44 <+Bart_Massey> I just think that making people jump through arbitrary hoops is only a good idea if we have a lot of unready applicants. +23:44 <+Bart_Massey> \So far, I haven't seen that. +23:45 <marcoz> I think most of the students yes, possibly not all. I'll have to run that down. +23:45 <+Bart_Massey> Anyway, if the rest of the Board thinks that a patch requirement is a good thing, obviously I won't try to get in the way. +23:45 <stukreit> eg. ken philips communicates thru a gmail account. what's up with that? +23:45 <+Bart_Massey> stukreit: Perhaps you haven't experience a modern University email system? :-) +23:45 <marcoz> you'd prefer @microsoft.com ? +23:46 <+Bart_Massey> But yeah, we definitely need to have a firm record of the student status of everybody. +23:46 <+Bart_Massey> If somebody not actually a student slipped by, it would be...bad. +23:46 <marcoz> i'll run down the unis and get that added to the info page +23:46 <+Bart_Massey> marcoz: Thanks +23:46 <marcoz> Bart_Massey: np +23:46 <marcheu> stukreit: yeah as the owner of a UC email account, I can explain why you wouldn't want to use it :) +23:47 <stukreit> explain it offline. but I am interested. +23:47 <mupuf> Could we discuss this EVoC program at the XDC? I already proposed a talk and I feel like we should define a little more what we expect and how we track progress and so on. +23:47 <+Bart_Massey> mupuf: Heck yes. +23:47 <mupuf> I am willing to prepare the framework of an eventual discussion +23:47 <mupuf> based on my RoE +23:48 <marcoz> The passing students get invites to XDC right? +23:48 <marcoz> and help with travel if needed. They have to present their project I believe. +23:48 <+Bart_Massey> marcoz: Absolutely. Apparently from the email I just saw we're not requiring it, but they're encouraged. +23:49 <marcoz> Bart_Massey et al. I'll officially invite Blaz and Supreet to XDC then? +23:49 <+Bart_Massey> Yes, unless anyone has an objection? +23:49 <+Bart_Massey> Yes. +23:49 <marcoz> How does reimbursement of travel expenses (and hotel) work? +23:50 <agd5f> no objections here +23:50 <+Bart_Massey> marcoz: They submit an application for reimbursement (or imbursement, anyhow) to the Board, who votes it. +23:50 <+Bart_Massey> They are expected to be willing to fly cattle class and stay in reasonably-priced rooms :-) +23:51 <+Bart_Massey> The Board understands that travel from some places is way more expensive than from others. +23:51 <+Bart_Massey> Indeed, the Board is fully capable of using the web to find out how much travel costs should be. :-) +23:51 <marcoz> ;) +23:51 <+keithp> marcoz: *anyone* can come to xdc +23:52 <+Bart_Massey> And *anyone* can get travel expense help if they need it. +23:52 <+Bart_Massey> (and can make a reasonable case for it) +23:52 <mupuf> Bart_Massey: that's not what the wiki says +23:52 <+alanc> as I recall, we decided not to require students attend xdc because it overlaps with class schedules at some universities (like US schools on semester systems) +23:52 <marcoz> Bart_Massey: ahhhh, _that_ part I didn't know. +23:52 <+Bart_Massey> mupuf: What does it say? +23:52 <mupuf> Bart_Massey: you need to present something :) +23:53 <marcoz> definitely not a requirement, but an official invite give you warm fuzzies. ;) +23:53 <mupuf> Bart_Massey: curro isn't really looking forward to asking for funding because of this :D +23:53 <+Bart_Massey> mupuf: I definitely have things in mind +23:53 <+Bart_Massey> mupuf: Oh, wait nm +23:53 <+alanc> we can issue official invites to those who need them for visa purposes +23:54 <marcoz> keithp: so you're saying *anyone* reading this. anyone at all can come in September? *Everyone* is invited? (yes, I'm baiting the news rags.) +23:54 <+Bart_Massey> mupuf: Yeah, the normal case for travel funding is to present. +23:54 <+Bart_Massey> But it's really not very scary. I'm happy to talk to curro if you like :-) +23:54 <+Bart_Massey> We could put together some kind of panel or something for EVoC students if that reduced the social pressure... +23:54 <mupuf> Bart_Massey: no need to ;) He his checking his time schedule +23:55 <mupuf> many nouveau dev should come, that's quite an insentive to get even more of them :) +23:55 <+Bart_Massey> Anyway, we're running onto EOM. Any last-minute emergencies that can't wait for email or two weeks? +23:55 <marcoz> Bart_Massey: or just have them look at my presentation. that'll remove any pressure. ;) i set that bar soo low. haha +23:55 <marcoz> CFP +23:56 <marcoz> Bart_Massey: should I just send that to the board for review so we can get it out? +23:56 <marcoz> (very quick review) +23:56 <marcoz> also stukreit: any luck with Blaz payment? +23:56 <+Bart_Massey> marcoz: Heck yes. +23:56 <stukreit> i'm on another call... I was working on it today and belive I have all the data to make it work +23:56 <marcoz> what about Ashwin's mid-point? push back til next meeting? +23:57 <+Bart_Massey> marcoz: Work it out with mupuf. +23:57 <marcoz> stukreit: thanks! +23:57 <marcoz> Bart_Massey: consider it done +23:57 <+Bart_Massey> OK, move to adjourn. +23:57 <agd5f> also, not the change the subject, but with all the HSBC news in the last fews days, I feel like we should look for a new bank. +23:57 <stukreit> so, yeah. my session will timeout but then I'll get back in and try to push it. ... when my stack shortens +23:57 <stukreit> me too +23:57 <+alanc> which we'd already discussed doing anyway +23:57 <stukreit> ] +23:57 <+alanc> back when it was less trendy +23:58 <+alanc> http://apps.irs.gov/app/eos/pub78Search.do?ein1=26-4691413&names=&city=&state=All...&country=US&deductibility=all&dispatchMethod=searchCharities&submitName=Search +23:58 <+alanc> we are officially listed on the IRS charity list now +23:58 <+Bart_Massey> keithp, stukreit, alanc: Please discuss and figure out what we should do about banking RSN? +23:58 <+Bart_Massey> (And whoever. I just know those three have been involved in the past.) +23:59 <+keithp> Bart_Massey: with stukreit acting as treasurer for an extended period, I'd say he should pick something he can get to reasonably easily. I know it's possible to do everything over the phone, at least in theory, sometimes just showing up and not leaving is powerful +00:00 <+Bart_Massey> keithp: Complete agreed. Point is, come to the Board with a recommendation and we'll all enthusiastically +1 it, I suspect +00:00 <+alanc> http://www.x.org/foundation/ exists now, will be polished up and ready to announce shortly +00:00 <+Bart_Massey> alanc: THanks huge. And thanks much to all! +00:00 <+keithp> ok, I've got another mtg to get to anyways +00:00 <+keithp> have fun guys +00:00 <+Bart_Massey> I'm going to call this mtg on time. Talk to you all soon! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/08-02.mdwn b/BoardOfDirectors/IrcLogs/2012/08-02.mdwn new file mode 100644 index 00000000..c0e1c9c9 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/08-02.mdwn @@ -0,0 +1,119 @@ + +Date is 2012-08-02, times are UTC+02. +[[!format txt """ +23:00 <agd5f> hello +23:01 <stukreit> hi +23:01 <+Bart_Massey> Howdy +23:01 <+alanc> good afternoon +23:01 <+Bart_Massey> alanc, emmes, keithp: ? +23:01 <+Bart_Massey> er +23:01 <marcoz> hi all +23:01 <+Bart_Massey> anholt +23:02 <+Bart_Massey> OK, looks like we're 5, which looks like what we've got today +23:03 <+Bart_Massey> Start with the obvious: it looks like no one has an objection to joining OIN. Correct? +23:03 <agd5f> +1 +23:03 <+Bart_Massey> +1 +23:03 <stukreit> +1 +23:04 <marcoz> +1 +23:04 <+Bart_Massey> alanc: ? +23:04 <+alanc> sorry, got interrupted +23:04 <+alanc> +1 +23:05 <+Bart_Massey> Motion made and carried. alanc: let us know what we need to do. +23:05 <+anholt> hi +23:05 <+anholt> +1 +23:05 <+Bart_Massey> Hi! +23:05 <+alanc> I'll respond to them and find out +23:05 <+Bart_Massey> alanc: thanks +23:05 <+Bart_Massey> marcoz: EVoC stuff? +23:06 <+emmes> hey all +23:06 <agd5f> hi +23:06 <stukreit> evoc: all paid up +23:06 <+emmes> about OIN i'm +1 as well +23:06 <+Bart_Massey> OK, we're 7/8 on that one. +23:07 <+Bart_Massey> stukreit: Thanks huge +23:07 <marcoz> last i pinged the mentors. Blaz, Supreet and Jess continue to do well. +23:07 <marcoz> Unfortunately, Ashwin has had some trouble. +23:07 <+Bart_Massey> we talked about that some last week. +23:07 <+Bart_Massey> er last meeting +23:07 <+Bart_Massey> do we still have an app outstanding? +23:07 <+Bart_Massey> or are we caught up there? +23:08 <marcoz> We have an app outstanding, but it's taking some time +23:08 <marcoz> He seems eager, has some commit history, +23:08 <marcoz> There's a conversation going with some of the piglit/mesa folks, +23:09 <marcoz> trying to narrow down his focus, +23:09 <marcoz> but finding a Mentor is proving difficult +23:09 <+Bart_Massey> OK. Do let us know when it's figured out. Thanks much as always. +23:09 <marcoz> will do. +23:09 <+Bart_Massey> Any XDC stuff we need to deal with here today? +23:10 <+Bart_Massey> Not hearing anything. +23:10 <marcoz> re: CFP. I'm afraid I've dropped the ball on this. +23:10 <marcoz> At this point, is it worth sending out? +23:11 <marcoz> It's ready, but the dates are so short. +23:11 <+Bart_Massey> Yeah, we have to send something. +23:11 <+Bart_Massey> Just stretch the dates again. +23:11 <+Bart_Massey> What is it currently set at? +23:11 <agd5f> we need to get slots filled up +23:11 <+alanc> I can't remember when, if ever, we've had a formal CFP before, so I don't think anyone would notice not having one, just having a informal request for talks +23:11 <+Bart_Massey> We have a CFP ready, let's just send it. +23:12 <marcoz> **Proposals due:** Monday 6 August 2012 17:00 UTC +23:12 <marcoz> lol +23:12 <marcoz> **Notification of acceptance:** Monday 13 August 2012 +23:12 <agd5f> maybe also a reminder to sign up for slots +23:12 <agd5f> or no one will be presenting +23:12 <marcoz> What makes sense? I'll change and send out +23:12 <+alanc> set deadline to Aug. 15, i.e. ~ 2 weeks, just before our next meeting & 1 month prior to conference? +23:12 <+Bart_Massey> Works for me +23:13 <agd5f> sounds good +23:13 <marcoz> Aug 15 for deadline, and Sep 3 for Notification? +23:13 <agd5f> sure +23:13 <+emmes> yes, reasonable. I mean, we don't need much time to validate the entries +23:14 <marcoz> that's 2 weeks to validate. +23:14 <agd5f> also maybe mention travel funding +23:14 <+alanc> still expect most people will just sign up for a talk slot, not formally submit a paper +23:15 <+Bart_Massey> alanc: almost certainly, which is fine. I think this thing is a "Call For Proposals"; we've pretty much abandoned the refereed paper track +23:15 <+Bart_Massey> er Call For Presentations +23:15 <+Bart_Massey> er whatever +23:15 * Bart_Massey is mightily confused today +23:16 <stukreit> Its sad that we're late on this, but we must write copy that encourages preparation and organization of presentations. This has occasionally been an issue. +23:16 <+Bart_Massey> On another topic... +23:16 <+Bart_Massey> Next topic: How are we doing on paying our Delaware taxes +23:17 <stukreit> didn't do it yet. I know I said I would. need to get it done +23:17 <+Bart_Massey> Thanks much! +23:17 <stukreit> yeah... +23:17 <+Bart_Massey> I think those are the topics I had for today. Anyone got anything else? +23:18 <agd5f> nothing here +23:18 <marcoz> any updates on the book sprint? topics or location? +23:18 <+emmes> location is clear +23:18 <+emmes> but i'm interested about the exact dates... +23:18 <+alanc> attendees confirmed? +23:18 <+alanc> I can make it if we hold it, but if not, I'll go visit our Prague office those two days instead +23:19 <marcoz> exact dates: Mon and Tues before XDS +23:19 <marcoz> XDC +23:19 <+emmes> weekend as well or rather not? +23:20 <+Bart_Massey> I think 2 days is good... +23:20 <+Bart_Massey> I'm in, of course +23:20 <marcoz> I hadn't planned on the weekend. +23:20 <marcoz> I think I'll be there anyway (two more days in Deutschland. ;) ) +23:21 <+Bart_Massey> Yeah, I'll visit friends in Berlin before, likely +23:21 <marcoz> http://www.x.org/wiki/Events/BookSprint2012 +23:21 <+Bart_Massey> marcoz: How many exactly do we have confirmed right now? +23:21 * marcoz checking +23:22 <agd5f> Unfortunately, I won't be there. I think Michel and Christian are going to XDS from AMD this year since they are based in Europe +23:23 <+Bart_Massey> agd5f you are definitely eligible to ask the Board for travel money if thats an issue +23:23 <marcoz> Bart, me, and alan sadly are the only confirms I can find +23:23 <+emmes> just asking because ATM I have the room reserved also over the weekend. will keep it that way, nevertheless, but i might be planing something for the weekend if nobody shows up then ;-) +23:24 <+Bart_Massey> If we can't get to 6 by next meeting, I'd say cancel it. +23:24 <+Bart_Massey> I don't want to watch marcoz and alanc write epically by themselves again: that's harsh :-) +23:24 <marcoz> ouch. ok. everyone can expect me to bug them +23:24 <marcoz> ;) +23:24 <+Bart_Massey> Thanks! +23:25 <+Bart_Massey> emmes: I think there's 0 chance we'll want the room for the weekend +23:25 <+Bart_Massey> so unless you want it for something else feel free to let those days go. +23:26 <+Bart_Massey> OK. I think we're done for today. Move to adjourn. +23:26 <stukreit> +1 +23:26 <+alanc> +1 +23:26 <agd5f> +1 +23:26 <marcoz> +1 +23:26 <+Bart_Massey> Thanks much all! +23:27 <+emmes> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/08-16.mdwn b/BoardOfDirectors/IrcLogs/2012/08-16.mdwn new file mode 100644 index 00000000..901252e8 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/08-16.mdwn @@ -0,0 +1,136 @@ + +Date is 2012-08-16, times are UTC+02. +[[!format txt """ +22:59 <marcoz> howdy all +22:59 <+Bart_Massey> howdy +22:59 <stukreit> hey hey +23:00 <agd5f> hi +23:00 <+emmes> hey +23:01 <+Bart_Massey> give it a minute or two more to see who else shows? +23:03 <+Bart_Massey> OK, let's get started... +23:03 <+Bart_Massey> We'll try to take things in rough order of shortest-longest +23:03 <+Bart_Massey> stukreit: Delaware tax payments? +23:03 <stukreit> ok, yeah, I banged on it this morning and got er done. +23:03 <+Bart_Massey> Thanks! +23:04 <+Bart_Massey> We might want to just pay ahead a year. :-) +23:04 <stukreit> for the record, its a filing fee, not a tax payment. +23:04 <+Bart_Massey> Ah. +23:04 <stukreit> Now that I am getting the mail and email reminders, I can interact with nrai.com directly and do this. +23:05 <stukreit> the lost notice had gone to sflc. +23:05 <+Bart_Massey> excellent +23:05 <+Bart_Massey> Next item: XDC +23:05 <+Bart_Massey> Are things looking reasonable there? Any issues? +23:06 <+emmes> we had only one proposal, and that looks good +23:06 <+Bart_Massey> Also: Has anyone talked to Intel or others about funding dinner as per usual? +23:06 <+Bart_Massey> emmes: One proposal is not very many :-) +23:06 <+emmes> question is whether we need a formal publication; probably have to ask +23:06 <+Bart_Massey> Do we need to do something special to get people to talk at this one? +23:06 <marcoz> we have 2 students (planning/wanting) to come, possibly a 3rd +23:06 <+Bart_Massey> emmes: If they need it, it's easy to do. +23:07 <+emmes> we do have a number of talks, but only one in the formal process +23:07 <stukreit> i'm getting pushback from management on whether I can travel, so I should go for broke and ask them to buy the dinner. +23:07 <+Bart_Massey> Oh, OK. +23:07 <+Bart_Massey> stukreit: would be great if they felt like doing it +23:07 <+emmes> still we could require a little advertizing ;) for talks, that is +23:07 * alanc is partially here (also in an in-person meeting that's taking most of my cycles) +23:07 <+Bart_Massey> Yeah, want to make sure we have a reasonable slate of talks. +23:08 <+Bart_Massey> alanc: thanks for multitasking +23:08 <marcoz> our wiki is down? i was looking up the deadline for CFP submission. that was yesterday right? +23:08 <+emmes> we also had one proposed talk, if funding is possible. it's inside germany, so no big costs +23:08 <marcoz> we do have one formal paper. +23:08 <+emmes> marcoz: yes +23:09 <marcoz> (emmes: i see you mentioend the paper above. I'm behind in my reading.) +23:09 <+Bart_Massey> OK, so we have 1 paper, a few talks, some approved funding reqs, one pending funding req. +23:10 <+Bart_Massey> Who is taking responsibility for doing the overall conference scheduling/agenda? +23:10 <+emmes> i think egbert wanted to be in the loop +23:10 <marcoz> also, Egbert's email about students and hotel reimbursement +23:11 <+Bart_Massey> marcoz: had missed this email +23:11 <alanc> the website has been crashing a lot lately so Tollef put in a caching front end, which doesn't seem to be helping, just changing the errors +23:11 <+Bart_Massey> Move to have x.org directly pay students hotel bills at the conference hotel +23:12 <stukreit> there has to be a safeguard re. no-show +23:12 <marcoz> Bart_Massey: does x.org have a credit card or someone does it and gets reimbursed? +23:12 <alanc> I thought stu had a debit card on our checking account +23:12 <stukreit> we reimburse. +23:12 <+Bart_Massey> stukreit: is it easy for x.org to get a card? +23:13 <stukreit> i'd like to make a point here about this +23:13 <+emmes> the issue with reimbursing is that fees for american cheques are pretty high here. and elsewhere (no idea about india, but it certainly isn't cheaper). +23:13 <stukreit> there's a difference between someone fronting the money for their trip, then getting reimbursed vs just showing up +23:14 <stukreit> and I realize that we have a wider than usual socioeconomic spectrum, I don't have an answer about that part +23:15 <stukreit> and the cost of txfering money is roughly the same whether I pay an individual vs a hotel +23:15 <stukreit> it is probably easier to pay a hotel because its a business, but I'm not counting that as +/- +23:17 <+Bart_Massey> stukreit: more to say? +23:17 <stukreit> I don't want to bludgeon it, but ok, I'll make my point +23:18 <stukreit> paying ahead for a visitor gives them less incentive to follow through and show up than if they are reimbursed later. +23:19 <marcoz> +1 +23:19 <+emmes> i don't think anybody talked about paying up front +23:19 <stukreit> If they simply don't have enough $$, well, they'd have to really insist that. And if they've earned GSOC or EVOC money, then they must be flush. +23:20 <+Bart_Massey> Oh yeah, "flush" :-) :-) +23:20 <+emmes> rather during the stay showing up at the hotel and just paying (at the end of the conference). i think that was the idea. +23:21 <stukreit> um, that would be new process, and it depends on me (current treasurer, yikes) being present. +23:21 <+Bart_Massey> Anyway, I don't feel too strongly about any of this. The only point I'd make is that X.Org's history of prompt reimbursement is *terrible*. Until we've established more credibility on that score, I'd prefer any plan that doesn't require broke students to rely on us. :-) +23:21 <stukreit> I have less than 90% certainty of being there in sept. +23:21 <+emmes> i don't have a strong opinion here, just trying to make sure we speak about the same process +23:22 <stukreit> yes, I've had trouble txfering. wire txfer has been an improvement. Also, reimbursement on the spot as in portland last year was great. +23:22 <+Bart_Massey> I'm happy to pay the student hotels on my credit card while I'm in Nuremberg and have X.Org reimburse me later. +23:22 <+emmes> in case you're not in NBG, what would the process be in the end (in any case)? +23:23 <+emmes> Bart_Massey: that's one nice idea :) +23:23 <agd5f> I thought normally the students would email stukreit their receipts and he's send them a check/transfer, etc. +23:23 <stukreit> then it would have to be by wire or paper check. at least we could get started on the last day of the conference. +23:23 <agd5f> *he'd +23:23 <+emmes> i think reimbursing inside the US is easier +23:23 <stukreit> agd5f: yes, that's what we were doing. +23:23 <stukreit> emmes: yes, reimbursing outside the US is harder. +23:24 <+emmes> ok, something to decide on site then. thanks for the offer, Bart! +23:24 <+Bart_Massey> NP. +23:24 <stukreit> I'll take suggestions on intl money txferring. we've known for 10 years that intl banking sucks and no bank is our friend +23:24 <+emmes> over sea banking, that is ;-)) SCNR +23:24 <+Bart_Massey> OK, any other XDC things we need to do? +23:25 <marcoz> book sprint? +23:25 <+emmes> how about the one pending funding proposal? +23:25 <+emmes> yours first :) +23:25 <+Bart_Massey> Do we still have one pending? +23:25 <+Bart_Massey> I thought we were all caught up? +23:26 <marcoz> Lucas Stach +23:26 <+emmes> there's one from Lucas Stach +23:27 <+emmes> he would talk about nvidia's tegra platform +23:27 <marcoz> mupuf? +23:27 <+Bart_Massey> Found it. Sorry; someday I +23:27 <+Bart_Massey> will learn to do email +23:27 <+emmes> expenses would be fuel (2x350km) and hotel +23:28 <+Bart_Massey> I +23:28 <+Bart_Massey> I'd actually prefer to discuss this one offline. +23:28 <+Bart_Massey> I think we need to get input from some outside people. +23:28 <+emmes> ok +23:28 <+Bart_Massey> Why don't we vote it by email in the next few days. +23:29 <+Bart_Massey> OK, book sprint. Whatever the opposite of a plan coming together is, so far we seem to be there... :-) +23:29 <+emmes> i won't be around for 2 weeks beginning on 25th, just for info +23:29 <+emmes> room is reserved. +23:29 <+Bart_Massey> emmes: ok. we'll try to do it sooner rather than later. +23:30 <marcoz> we have 3 1/2 people for the book sprint. +23:30 <marcoz> I will be in Nuremberg regardless and happy to work with people on it. Otherwise I'll be practicing my rusty German with locals +23:32 <+Bart_Massey> I don't think we are going to be able to wait too many more days to decide whether it will happen. +23:32 <+Bart_Massey> I'm inclined to can it at this point, on the grounds that (a) it's too few people, and (b) I have no experience with a book spring for editing an existing book (which seems to be where we are headed). +23:33 <+Bart_Massey> But I don't feel strongly. I will likely book to be there if it is held, as long as I find out in the next few days. +23:33 <marcoz> I have an email ready to spam all the MLs. if we wanna give it until Monday? +23:34 <marcoz> doubt we'll get many, but it'll give phoronix more material to beat on us. ;) +23:34 <+Bart_Massey> What do other people think? +23:34 <+emmes> i'm flexible +23:35 <agd5f> I'm ok with whatever you all want to do +23:35 <marcoz> we can always fall back and just help polish marcheu's. +23:35 <marcoz> agd5f: you coming? +23:35 <+emmes> but i won't be able to contribute much - i'll be around for keeping the room open, talking about food and beer places, but i'm otherwise swamped +23:35 <agd5f> marcoz: can't make it this time +23:36 <marcoz> if no objections: I'll spam all the MLs I can think of giving folksuntil Monday. +23:37 <+Bart_Massey> I have no objections: hopefully you won't just get a bunch of enthusiastic cranks :-) +23:37 <marcoz> absolute worst case, I'm there in that room by myself, annoying emmes, and drinking while working on documentation +23:38 <+Bart_Massey> OK. We'll leave it for another few days, then. I'd really like to decide by a week from today whether this thing is official or unofficial, though. +23:38 <+Bart_Massey> Any last comments on that? +23:38 <+emmes> sounds like a plan. if wheather is good we could even walk a few meters and sit by the river. and you're allowed to drink in public in good ol' Germany :-P +23:39 <marcoz> emmes: sweet. i'm so there +23:39 <+Bart_Massey> Excellent. +23:39 <+Bart_Massey> The last agenda item I had was about the Bylaws, but I think it can wait until next meeting. Any other business we need to discuss? +23:40 <+Bart_Massey> OK. Let's adjourn, then. Bye all! +23:40 <+emmes> bye +1 +23:40 <marcoz> +1 +23:41 <stukreit> byr +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/08-30.mdwn b/BoardOfDirectors/IrcLogs/2012/08-30.mdwn new file mode 100644 index 00000000..634edf5a --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/08-30.mdwn @@ -0,0 +1,84 @@ + + +[[!format txt """ +<agd5f> hi +<Bart_Massey> Hope a quorum will show - forgot to send a reminder this week. +<Bart_Massey> Forgot about the meeting until my wife reminded me 5min ago :-) +<alanc> hello +<omcfadde> hi +<agd5f> some people may be at LPC +<marcoz> morning +<Bart_Massey> Keithp is in Kansas flying rockets AFAIK +<marcoz> where in KS? +<Bart_Massey> At any rate, I expect a short meeting; don't have too much agenda +<alanc> stuart just walked past my office +<Bart_Massey> First of all, XDC. Do we have a workable program? What do the attendee counts look like right now? +* Bart_Massey heads for the wiki +<stukreit> hello +<Bart_Massey> howdy! +<agd5f> also we got one more funding request +<Bart_Massey> The wiki appears to be down. Good. +<alanc> unfortunately I think both egbert & emmes are on vacation +<alanc> Bart_Massey: try again in a minute - they rigged an autorestarter for all the crashes +<Bart_Massey> alanc: tx. epic +<omcfadde> agd5f: that would be me; unfortunately Intel won't cover travel/hotel for XDC. +<agd5f> welcome to popcopy can I help you? +<agd5f> omcfadde: yup +* Bart_Massey heads for the email discussion +<alanc> all the fd.o wikis seem to fall over lately, not sure if it's out-of-memory, bad VM config or what +<omcfadde> I sent basically all the details to the board's email. I'm just here if you need any clarification or further information. +<Bart_Massey> Appreciated. +<Bart_Massey> I think the current process for these is to discuss them by email. Anybody opposed to doing so over the next couple of days and then voting it by email? +<Bart_Massey> Time is getting short, but I'm not sure this meeting is the best place to proceed. +<Bart_Massey> Anybody have any questions for omcfadde? +<agd5f> proposal looks fine to me. no further questions on my end +<alanc> I talked with him about it last night, and am satisfied +<Bart_Massey> Maybe we should just vote it now, then. +1 from me +<agd5f> +1 +<stukreit> +1 +<marcoz> +1 +<alanc> +1 +<stukreit> (and do I need more votes for my own request?) +<Bart_Massey> Carried. +<agd5f> stukreit: +1 for you +<Bart_Massey> +1 +<alanc> +1 +<marcoz> +1 +<alanc> (though I already +1'd stu via email) +<alanc> omcfadde: for fastest reimbursement, bring receipts to the conference so Stuart can write a check on the spot +<stukreit> thanks. Is 4 enough for these 2 votes? +<Bart_Massey> First one got 5 +<stukreit> I don't think I can vote to reimburse meself +<omcfadde> alanc: ok, will do. my thanks to the board for the positive decision. :-) +<stukreit> omcfadde: +1, where ~fastest = forever, choose wisely +<Bart_Massey> I'd have to review the Bylaws to check. Let's assume it's good, and if there's a problem we'll finish by email +<Bart_Massey> omcfadde: thanks for your contributions to X.org! +<stukreit> ok, thanks. does anyone know how much the train from frankfurt costs? I'll be getting into FRA around 2pm on tuesday +<marcoz> 1 mmmillion dollars <pink to mouth> +<marcoz> pinkY +<Bart_Massey> I don't know for sure, but I'd guess around $50US. +<stukreit> I can cover that, just want relief on the hotel. +<marcoz> the EVoC students projects are wrapping up. do we want to do the final vote on reimbursement at XDC? I haven't pinged the mentors on final pass/fails yet. (very busy 2 weeks.) +<Bart_Massey> Move to approve final reimbursement via simple mentor approval. +<Bart_Massey> Thus not requiring a Board vote. +<Bart_Massey> Do I hear +1? +<Bart_Massey> Anybody? +<Bart_Massey> Am I netsplit here? +<omcfadde> stukreit: regarding reimbursement for my flights/accommodation: either a check or a IBAN transfer is fine with me; whichever is easiest for you. +<Bart_Massey> Hello? +<alanc> hello +<agd5f> Bart_Massey: +1 +<omcfadde> stukreit: I guess IBAN might be a bit tricky if it's coming from a US account. +<agd5f> for mentor approval +<marcoz> +1 +<alanc> +1 +<Bart_Massey> I'm at +4 +<Bart_Massey> Again, will rule the motion carried. +<Bart_Massey> Given the number of people missing, I'm inclined to adjourn. Any other business? +<agd5f> none here +<stukreit> all: in these cases, a US paper check handed in person works best. It might get easier to do the IBAN, but the last few took a few tries each to squirt the money through +<Bart_Massey> stukreit: Good to know. Thanks for handling it. +<omcfadde> stukreit: ok, paper check is fine with me. +<Bart_Massey> Oh, one more thing: Our next meeting would nominally be 13 September. Is there any objection to meeting then, even though XDC is close? +<Bart_Massey> I will plan to meet you all here 13 September, then. THanks all! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/10-04.mdwn b/BoardOfDirectors/IrcLogs/2012/10-04.mdwn new file mode 100644 index 00000000..b9d057b6 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/10-04.mdwn @@ -0,0 +1,142 @@ + +Date is 2012-10-04, times are UTC+02. +[[!format txt """ +23:00 <+Bart_Massey> Hey all +23:00 <agd5f> we having a meeting today? +23:00 <+Bart_Massey> That's my plan. +23:00 <agd5f> cool +23:00 <+Bart_Massey> Assuming we have a quorum. +23:00 <+anholt> moving rooms... +23:00 <+Bart_Massey> k! +23:03 <stukreit> hi +23:03 <+Bart_Massey> Howdy! +23:03 <+Bart_Massey> Should have anholt back shortly, which will make four of us +23:04 <+alanc> hello +23:04 <+Bart_Massey> Greetings! +23:05 <+Bart_Massey> Give a couple more minutes for anholt to return, and we should be able to get started. +23:08 <+Bart_Massey> anholt: ? +23:08 <+Bart_Massey> OK, let's go ahead and get started; he'll show when he shows. +23:08 <+Bart_Massey> My count is myself, agd5f, stukreit and alanc makes 4; did I miss anyone? +23:09 <+alanc> no keithp, emmes, or marcoz? +23:09 <agd5f> so are we going to start on a new two week meeting schedule starting today? i.e., no meeting next week, next meeting the following week? +23:09 <+keithp> alanc: sorry, bisecting X server failure +23:09 <+Bart_Massey> OK, keithp makes 5 +23:09 <+Bart_Massey> IDK where marcoz is +23:09 <+keithp> Bart_Massey: anholt has a conflicting meeting on Thursdays... +23:10 <+keithp> sometimes he joins from the middle of that meeting +23:10 <+Bart_Massey> agd5f: I move we start a new two-week schedule today +23:10 <+Bart_Massey> Any objections? +23:10 <stukreit> go for it +23:10 <+Bart_Massey> With no opposition, the motion is carried +23:11 <+Bart_Massey> Next meeting 15 October +23:11 <agd5f> Bart_Massey: 15th is a monday +23:11 <+Bart_Massey> So, I'm going to start running this giant agenda, and we'll get where we get +23:12 <+Bart_Massey> er 18 October :-) :-) +23:12 <+Bart_Massey> cannot add 14 and 4 today, apparently +23:12 <+Bart_Massey> So, first: XDC wrapup. What kinds of things do we need to discuss re XDC? +23:13 <+keithp> how much we enjoyed eating pork? +23:13 <+Bart_Massey> In particular: (1) are there administrative things left that need to get done right away? +23:13 <+Bart_Massey> keithp: Rather not think about the pork +23:13 <+Bart_Massey> Also: (2) Lessons learned, things to do differently next year, etc? +23:13 <+alanc> need to send thanks to egbert, emmes, & libv +23:14 <+keithp> Yeah, I can't think of a more professionally run XDC. +23:14 <+keithp> it was fabulous +23:14 <+Bart_Massey> alanc: Absolutely. I'll work on that letter today. Thanks for the reminder! +23:14 <+Bart_Massey> There was a strong suggestion that we do better/different publicity for the event next time. +23:15 <+alanc> need to get egbert, etal to put together some notes for the wiki on things that worked, like getting mobile phone numbers for all presenters, getting the video recording setup so well, etc. +23:15 <+Bart_Massey> In particular, that we get as much agenda posted as early as possible; make sure the previous meeting was well-documented, etc. +23:15 <+alanc> yeah, Michael from LWN had a lot of feedback on publishing agenda earlier to help people decide if they should come +23:16 <+Bart_Massey> Of course one of the fundamental XDC conflicts I don't have a strong opinion on is how much this is an outreach vs "inreach" event +23:16 <+alanc> guess we're used to everyone just knowing they'll come no matter what we talk about, but that may limit attendance to those who are willing to come no matter what +23:16 <+Bart_Massey> We talked about maybe doing a federated freedesktop-ish event with XDC next year, as more of an outreach thing +23:17 <+alanc> like the old DesktopCon in Ottawa were supposed to be? +23:18 <+Bart_Massey> alanc: Yeah, that +23:19 <+Bart_Massey> Sounds like there's not so much feedback there, but wanted to get this stuff on the record to remind us later (if we could ever be bothered to read our meeting logs) +23:19 <+Bart_Massey> Are we done with TOPIC:XDC, or is there more to discuss? +23:20 <+Bart_Massey> OK, check. +23:20 <+Bart_Massey> Next topic: election status. Are people starting to work on that? +23:20 <stukreit> I want to say thanks to the sponsered folks for getting their paperwork in. At this time, all checks have been paid, including direct payment for the people staying at Azimut +23:20 <+Bart_Massey> stukreit: Everybody but me. I suck. My apologies. Working on it today. +23:21 <+anholt> Bart_Massey: no progress other than what happened at xdc +23:21 <+Bart_Massey> OK! Just going to keep bringing it up every meeting on the theory that it might be helpful :-). Any blocking issues there? +23:21 <stukreit> bart: don't be so sucky. get the receipts. You at least can get reliable usps mail and no international exchange foolery +23:22 <+Bart_Massey> stukreit: I was thinking I'd just email you stuff. RSN. +23:22 <stukreit> Scan it, muy better +23:22 <+Bart_Massey> 'k. +23:23 <+Bart_Massey> Next topic: infrastructure stuff. Are there things the Board should be doing here, or should we just wait for keithp and jrayhawk to magically get things under control, or what? +23:23 <+anholt> I need to write up a proposed schedule, but in the past our schedule has basically started in january. +23:24 <+Bart_Massey> I think we can agree that using alanc as a human spam filter for the wiki is no good, and having our web presence crashed half the time is no good, etc. +23:24 <+alanc> spam rate on fd.o wiki has dropped since the latest admin tweaks, still coming in (though slower) on x.org wiki +23:24 <+Bart_Massey> anholt: I think we've started in January after repeated failures in October/November/December to move things forward :-) +23:25 <agd5f> fall has historically been fail for elections. do I bylaws require any particular time period? +23:25 <agd5f> *our +23:25 <+Bart_Massey> agd5f: I'm not sure what the bylaws actually require; it's kind of ambiguous +23:25 <+anholt> yeah, any intersection between elections and end of year was disaster. if we're not restricted on scheduling, I'd like to start in jan. +23:25 <+Bart_Massey> I'm fine with starting in January, but let's make sure everything is in place to just push the button in January and get it done. +23:25 <+Bart_Massey> So I'll quit badgering about elections for now. +23:26 <agd5f> jan works for me too +23:26 <+Bart_Massey> kk +23:26 <+Bart_Massey> So infrastructure wise, is there anything the Board should be doing this week or next that it's not doing right now? +23:27 <+Bart_Massey> I hear nothing +23:27 <+alanc> not that I can think of +23:27 <+Bart_Massey> Since marcoz doesn't seem to be here, I think we'll table EVoC-related topics until next meeting. Objections? +23:28 <agd5f> the dri wiki uses capcha and doesn't seem to have as much spam +23:28 <agd5f> although I think that wiki may have limited edit group +23:28 <+Bart_Massey> I've had really poor results with captcha on my personal wiki; apparently people are being paid to solve them AFAICT. +23:29 <+Bart_Massey> Anyhow, we'll bug the fd.o sysadmins about a grand technology plan for spam mgmt I guess. +23:29 <+Bart_Massey> They're pretty smart. +23:30 <+Bart_Massey> Next topic: Wayland. Specifically, IMHO it's time the Board developed an official, well-publicized position about Wayland. We've talked about this before. +23:30 <+Bart_Massey> I think at the least we should identify Wayland as part of the X.Org Foundation purview. +23:30 <+alanc> can we just declare Wayland to be the code name for X12? 8-) +23:30 <+Bart_Massey> alanc: de facto, I think that's exactly what we should do :-) +23:32 <+Bart_Massey> I would like to see somebody on the Board (who is not me) produce a wiki page we can point to that describes Wayland for outsiders, describes the relationship(s) between Wayland and X, and declares that the Board wants to support Wayland in the same way that it's supporting Boston...er, X11 +23:32 <+anholt> as far as I know, krh still plans on not ever dealing with making wayland able to replace the x desktop. +23:32 * Bart_Massey wishes he had said "Cambridge" +23:32 <+anholt> it's all about embedded these days +23:32 <+alanc> but yes, I think it would be good when we revise our bylaws to change the Purpose section in the preamble to state that our role is for the entire FOSS graphics stack, including the traditional X Window System plus Mesa, Wayland, DRI +23:33 <+Bart_Massey> alanc: Yeah, what you said. +23:33 <stukreit> +1 +23:33 <agd5f> +1 +23:33 <agd5f> I guess we should compile a list of bylaw changes for the election +23:33 <+Bart_Massey> But even before the Bylaws revision I think we can publically say this. +23:34 <+alanc> yes, we've informally said it on a number of occasions, but should write it down +23:34 <+Bart_Massey> Except that if we're going to claim to support Mesa we should probably talk to Brian and the other Mesa leads first :-). +23:34 <+Bart_Massey> Does somebody on the Board want to take each of these two tasks? +23:35 <+Bart_Massey> (1) Talk to Brian about X.Org Foundation support of Mesa +23:35 <+Bart_Massey> (2) Write a page saying what alanc said in more detail +23:35 <agd5f> I'll take (2) +23:35 <+Bart_Massey> Thank you! +23:35 <stukreit> agd5f: I can help edit +23:36 <agd5f> stukreit: thanks +23:36 <+Bart_Massey> I don't know the Mesa folks at all, so while I'd be happy to take (1) I'd want some help from someone who does. +23:36 <+Bart_Massey> Should I try to draft idr? +23:36 <agd5f> half of us are mesa folks. Can probably just email mesa-dev +23:37 <+Bart_Massey> agd5f: If you could do this also, I'd be forever grateful. Use my name freely if it's at all helpful, which I doubt. +23:38 <+Bart_Massey> If you want me to produce a draft or read one, I'd be good with that also. +23:38 <+Bart_Massey> :-) :-) +23:38 <agd5f> Bart_Massey: I'm not entirely sure we need to do it since we aren't claiming ownership or anything, mostly just providing help, but I guess it's a nice courtesy +23:39 <+Bart_Massey> agd5f: Exactly. And a genuine offer, I think, to help do more if they want it. +23:39 <agd5f> fine. I'll take (1) as well +23:39 <+Bart_Massey> Thanks hugely. Like I say, LMK how I can help. +23:40 <+Bart_Massey> OK, one more topic, since we have a couple more minutes. +23:40 <+Bart_Massey> I'm looking right now at about 5 different "logo design contest" sites. +23:40 <+Bart_Massey> Is there consensus that it's time for a new, officially-trademarked X.Org logo? +23:40 <+Bart_Massey> If so, how much are we willing to pay for it, and shall I set the contest up this week? +23:42 <+Bart_Massey> Anybody? +23:42 <agd5f> I don't have a strong opinion either way +23:43 <+Bart_Massey> Alright, I guess I'll take that one to email or we'll try again next mtg +23:43 <stukreit> bart: was it you or someone else who raised this issue? +23:43 <+Bart_Massey> stukreit: It has been raised several times in the last year or two. +23:43 <+Bart_Massey> But there was a lot of talk of it at XDC +23:43 <stukreit> please refresh me on 2 or 3 reasons why its important +23:44 <+Bart_Massey> The recent "Messenger-X" thing highlighted the fact that we currently have no logo that is trademarked or even trademarkable +23:44 <+Bart_Massey> The current logo doesn't reproduce well, doesn't look good on t-shirts and the like, is terrible at small sizes, and is generally disliked +23:45 <+Bart_Massey> We have a new organization now, and might want to differentiate ourselves +23:45 <stukreit> maybe in sync with the wayland shift we can do a bit of name change, like call it Xorg and nothing else +23:46 <+Bart_Massey> I think using Xorg as a nickname is fine; do keep in mind that we are officially the X.Org Foundation, so we have to be a bit careful in official docs, but I don't think that matters for most purposes +23:47 <+Bart_Massey> Anyway, it looks to me like the meeting's about played out. Move to adjourn... +23:47 <agd5f> +1 +23:47 <+keithp> yeah, seconded. +23:47 <stukreit> +1 +23:47 <+alanc> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/10-18.mdwn b/BoardOfDirectors/IrcLogs/2012/10-18.mdwn new file mode 100644 index 00000000..0077636b --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/10-18.mdwn @@ -0,0 +1,177 @@ + +Date is 2012-10-18, times are UTC+02.h The log had to to be altered, because htt.p links are not allowed due to antispam rules. +[[!format txt """ +23:02 <+Bart_Massey> Hey all +23:03 <+Bart_Massey> Anyone here yet? +23:03 <agd5f> Bart_Massey: keithp, marcoz, and me +23:03 <+Bart_Massey> cool. +23:04 <+Bart_Massey> let's get started. +23:04 <+Bart_Massey> First of all, there's some EVoC things to discuss... +23:05 <+Bart_Massey> keithp and I have been wondering about what an "EVoC for women" would look like. +23:05 <+Bart_Massey> We'd like to increase the participation of women developers above the current apparent 0% +23:06 <marcoz> what are you ideas? (note, I'm all in favor ) +23:06 <+Bart_Massey> Our current plan is to talk to Karen Sandler about Gnome's women-focused efforts, and try to put together something a little different than the standard EVoC +23:06 <+Bart_Massey> In particular, we'd like to see something a little more mentor-driven and in smaller chunks. +23:06 <+Bart_Massey> (Or at least I would.) +23:06 <+Bart_Massey> But I think we need to talk to some people and see what ideas they have. +23:07 <+Bart_Massey> Just thought the Board should be aware of it. +23:07 <+Bart_Massey> Next is infrastructure. +23:07 <agd5f> sounds good to me +23:08 <+Bart_Massey> keithp has graciously offered the assistance of fd.o in transitioning our wiki, replacing the aging and awful members.x, and helping to set up a merchant site for donations +23:08 <+Bart_Massey> I'm assuming that's OK with everyone here? +23:08 <marcoz> wiki -> ikiwiki (note; i'm not trying to start a religious war, just curious) +23:08 <stukreit> hi, sorry I'm late. was with bossman +23:09 <+Bart_Massey> marcoz: It's cool. We have a lot of positive experience with iki. +23:09 <+keithp> marcoz: yeah, that's the obvious choice +23:09 <+Bart_Massey> And we've done transitions of large wikis from moin to iki before +23:09 <+keithp> makes monitoring changes really easy too (git fetch, gitk, git revert, git push) +23:09 <stukreit> bart: send receipts.. +23:09 <agd5f> +1 from me +23:10 <+Bart_Massey> stukreit: dammit you're right. after this meeting. +23:10 <marcoz> it can't be worse than moinmoin. (famous last words. lol) +1 from me. +23:10 <stukreit> oh, need a vote? +1 +23:10 <+Bart_Massey> 'k. I'm not sure we need a vote, but if there's dissent I'd like to hear it now :-) +23:11 <+Bart_Massey> Third topic: fundraising +23:12 <+Bart_Massey> One of the reasons that I want a merchant infrastructure up quickly is that agd5f has pointed out that we need to raise 10% of our fund intake from individual donations +23:12 <stukreit> i missed an opportunity to go to a "fundraising for o.s. projects" last week, but I'll contact josh berkus separately and get some knowledge from him +23:12 <+Bart_Massey> stukreit: that would be awesome +23:12 <+Bart_Massey> For this year, it's not clear that we took in any money that the IRS would count, so I think we're good :-) +23:12 <stukreit> plz reserve awesome for things delivered, not promised +23:12 <+Bart_Massey> I think "would be awesome" is sufficient :-) +23:12 <stukreit> I have not made a deposit in.. forever +23:13 <stukreit> aha, subjunctive +23:13 <+Bart_Massey> But keithp is already making some progress toward next year's fundraising +23:13 <+Bart_Massey> In particular, we can expect some money from Intel most likely if we do XDC in Portland. +23:13 <+Bart_Massey> So we need to be set up to get some money from just folks. +23:14 <+Bart_Massey> Along those lines: I'd like to go ahead and commission a new logo. +23:14 <+keithp> SPI gets regular contributions through a fairly ugly web page; cloning that would be easy +23:14 <marcoz> do donations from board members count as individual donations? (just curious) +23:14 <+Bart_Massey> It looks like it would cost us about $200-$300 +23:14 <+Bart_Massey> marcoz: yes +23:14 <+Bart_Massey> Assuming they delivered something we liked +23:15 <+Bart_Massey> I would then like to get a bunch of reasonable-quality t-shirts made, as well as some other merch +23:15 <+Bart_Massey> I've had some pushback on this in the past, so let's discuss... +23:15 <stukreit> when an entity pays our vendor directly (eg. conf room, beer) isn't it a non-issue to our accounting? +23:15 <+Bart_Massey> stukreit: I think it mostly depends on whether they're writing off the payment. But we should ask a tax lawyer. +23:16 <+Bart_Massey> I'd also like to pay the several hundred dollars it costs to register our shiny new logo as a US trademark +23:16 <stukreit> well, in anycase, I ack we must work on enabling collection of 10% small payers. +23:16 <marcoz> I'm in favor of new logo, and the t-shirt and other schwag. I'd also like to hear the pushback. I poked at that ~2 yrs ago and it didnt' go anywhere. +23:17 <+emmes> hey all +23:17 <+emmes> sorry for being late +23:17 <+Bart_Massey> Once we're set up to take individual donations, I suspect it will be easy to get people to go there just by explaining the situation. Could be wrong +23:17 <+Bart_Massey> emmes: np; thanks for coming +23:18 <marcoz> I'm in favor of new logo, and the t-shirt and other schwag. I'd also like to hear the pushback. I poked at that ~2 yrs ago and it didnt' go anywhere. +23:18 <+Bart_Massey> So does anyone have any objections to this plan of mine? +23:18 <+keithp> yeah, we've had less than optimal experience contracting out for graphic design in the past +23:18 <+Bart_Massey> keithp: I plan to use a contest site. +23:18 <+Bart_Massey> That's what we used for Linux Plumbers, and it worked out really well +23:18 <+keithp> Bart_Massey: I agree; as I said, SPI gets a regular stream of small contributions through their web interface +23:19 <+Bart_Massey> The best feature of the contest approach is if you don't find something usable you just don't pay +23:20 <+Bart_Massey> So I'll put this in the form of a motion, and lets vote: I move to develop logo stuff as outlined above. +23:20 <marcoz> Bart_Massey: are there any legal issues with logos from those contest sites? +23:21 <+Bart_Massey> marcoz: No. You buy the rights from the creator when you award them the prize. +23:21 <agd5f> you'd need fine print when entering the contest +23:21 <+Bart_Massey> All of that is handled by the site itself. +23:21 <+Bart_Massey> You end up with assignment of the copyright. +23:21 <marcoz> any worries about artist's ripping off other logos, tweaking and submitting? would we be absolved from that (question for lawyer?) +23:22 <+Bart_Massey> marcoz: I think it would be similar to the worries if we hired a designer. +23:22 <+Bart_Massey> As long as we weren't complicit, the worst that could happen is to be C&D'ed. +23:23 <+Bart_Massey> And I don't think that's very likely. +23:23 <stukreit> isn't there a way to search for image plagiarism the way you can search for writing plagiarism? +23:24 <+Bart_Massey> IDK. I think we might be overthinking this; like I say, I've seen uniformly happy reports from other folks who've used this approach, and have been happy with the one time I watched it in person. +23:25 <+emmes> i don't see any issues with that. i think we all agree that the current logo is - say - less than optimal. +23:25 <+Bart_Massey> Or maybe we should just use Neko the Kitty from the XCB logo :-) +23:25 <marcoz> I'm just being anal. I don't want someon suing us for the $20 we have in our account. haha +23:26 <+Bart_Massey> marcoz: One of the reasons we've tried to spend down the x.org account is to be less of a target for opportunistic legal action +23:26 <marcoz> I can help with the money spending. :) +23:26 <+Bart_Massey> emmes: I'm also proposing to actually bother to US trademark our logo this time around... +23:27 <+Bart_Massey> So can I get some +1s or -1s or whatever? +23:27 <agd5f> +1 +23:27 <marcoz> +1 +23:27 <stukreit> +1 +23:28 <+keithp> +1 +23:28 <+Bart_Massey> motion is carried. i'll let you know as things progress. +23:29 <+Bart_Massey> last item: I'm assuming XDC 2013 Portland OR USA. Anyone (esp keithp) want to try to do anything different? +23:29 <+keithp> Ian said he'd be willing to organize +23:29 <+Bart_Massey> Excellent +23:29 <+Bart_Massey> We will help of course +23:30 <+Bart_Massey> Do we need to look for alternate proposals, or shall we just announce it now? +23:31 <agd5f> maybe email the list and send out an RFP? +23:31 <stukreit> our arms could be twisted to do on in norcal, but it sounds like the PDX folks have it covered. +23:31 <+Bart_Massey> This is why I wanted the discussion :-) +23:32 <+Bart_Massey> I'm good with whatever, but we should probably figure it out in the next month or so, at least as far as location and month +23:32 <+Bart_Massey> I want to do better publicity this year, as so many have suggested +23:32 <+Bart_Massey> Does somebody want to take this as an action item? +23:33 <+Bart_Massey> professional superhero +23:33 <+keithp> Bart_Massey: I'll work with Ian to firm up the proposal +23:34 <+emmes> for the notion: +1 from me as well (line is lagging here) +23:34 <agd5f> I can send out an RFP email if folks want a formal solicitation process +23:34 <+Bart_Massey> keithp: OK. +23:35 <+Bart_Massey> I'm not sure whether we need an RFP, but we've been moving in that direction. +23:35 <+emmes> Ian for teh win! +23:35 <+Bart_Massey> I guess whatever the Board thinks on that one is good by me. +23:35 <+Bart_Massey> I don't see any harm in opening the process up. +23:36 <+Bart_Massey> So yeah, agd5f, +1 for you sending an RFP. Informal is probably better than formal; "Does someone want to host XDC 2013?" +23:36 <+keithp> agreed +23:36 <+emmes> +1 +23:37 <agd5f> Bart_Massey: yeah, that's my thought as well +23:37 <agd5f> how many people were at the last XDC? +23:37 <marcoz> is it too early to discuss booksprint for next year? IE: do we want one? +23:37 <stukreit> bart: there was a request for the updated drm doc. to be posted. is it available? +23:37 <+Bart_Massey> agd5f: Good question; I want to say around 50? +23:38 <+emmes> agd5f: about 55 +23:38 <+Bart_Massey> stukreit: I didn't really contribute to that one; I was busy working on the previous one :-) +23:38 <+emmes> difficult to tell; quite a few from SuSE were there who were not registered. but i think this was exceptional due to the location. +23:38 <agd5f> ok. I'll say ~50-60 in the email +23:38 <+Bart_Massey> It may be a bit bigger if we do the publicity right. +23:39 <+Bart_Massey> stukreit: There's a repo somewhere people can clone, but I didn't catch exactly where. +23:39 <+Bart_Massey> marcoz: Can you remember? +23:39 <marcoz> the repo? Martin's or marcheaus? +23:40 <+Bart_Massey> martin's, that has the stuff from the sprint in it +23:40 <marcoz> git@mupuf.org:lgd +23:40 <+Bart_Massey> I thought the in-person book sprint was a grand experiment, but kind of fail; having a bunch of pre-written stuff but not the author made it really hard to work on +23:41 <+Bart_Massey> I think that if we try again next year, we need more people and better advance planning +23:41 <mupuf> Bart_Massey: agreed +23:41 <+Bart_Massey> In particular more people, esp more people knowledgable about whatever we're going to write about. +23:42 <stukreit> if you want, take this offline and let the board business end. But I would like someone to get back to me, I will read (and use) the doc immediately. +23:42 <+Bart_Massey> stukreit: Just clone the repo marcoz mentioned above, and you should have what we have +23:42 <mupuf> Bart_Massey: this repo isn't public +23:42 <marcoz> ok. i'll ping people offline. i still want docs but Bart's right, the right people need to be there. +23:42 <+Bart_Massey> mupuf: Why is it private? +23:43 <+Bart_Massey> Did marcheu want to keep it that way? +23:43 <+Bart_Massey> I guess we did talk about licensing issues +23:43 <+Bart_Massey> Someone should resolve this so we can make the result public +23:43 <mupuf> Bart_Massey: just because I don't know how to do it ... yet +23:43 <mupuf> Bart_Massey: let me look into it +23:43 <+Bart_Massey> mupuf: Oh, OK. You'll figure it out. If you want us to host it we can +23:44 <marcheu> ah I should just merge it... I keep forgetting +23:44 <+Bart_Massey> mupuf: In the meantime, send stukreit a copy please :-) +23:44 <+Bart_Massey> marcheu: Cool! +23:44 <marcheu> work has been crazy lately +23:44 <marcheu> let me do it +23:44 <+Bart_Massey> tx +23:44 <stukreit> oh, yes please! +23:44 <marcoz> yay! +23:44 <mupuf> yeah, that would be easier +23:45 <marcheu> done! cgit.freedesktop.org/~marcheu/lgd/log/ +23:45 <mupuf> and I won't need to add the git daemon on my server :) +23:45 <marcheu> I have to do some fixups +23:45 <+Bart_Massey> Nice. +23:45 <marcheu> but I'll put them as followup commits later +23:45 <mupuf> marcheu: thanks :) +23:45 <+Bart_Massey> move to adjourn +23:45 <stukreit> +1 +23:45 <marcoz> 1 more thing. +23:45 <marcoz> supreet's LCA and FOSS.in reimbursement +23:45 <+Bart_Massey> Oh, ok motion withdrawn +23:46 <+Bart_Massey> I'm not sure this should be a public discussion, though; we might want to resolve it on the email list? +23:47 <+Bart_Massey> let me try that again. move to resolve supreet's thing via email, and adjourn +23:47 <agd5f> +1 +23:47 <+Bart_Massey> we're out of time anyhow +23:47 <stukreit> +1 +23:48 <+emmes> +1 +23:49 <marcoz> (abstain) +23:49 <stukreit> ? +0 ? +23:49 <+keithp> +1 +23:49 <+Bart_Massey> Thanks everyone! Catch you in a couple weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/11-01.mdwn b/BoardOfDirectors/IrcLogs/2012/11-01.mdwn new file mode 100644 index 00000000..091fc7d4 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/11-01.mdwn @@ -0,0 +1,73 @@ + +Date is 2012-11-01, times are UTC+01. The log had to to be altered, because htt.p links are not allowed due to antispam rules. +[[!format txt """ +22:04 <+Bart_Massey> Hey all. Sorry to be a bit late. +22:05 <+alanc> we'd just gotten as far as all saying hello +22:06 <+Bart_Massey> Cool. +22:06 <+Bart_Massey> OK. Status reports. +22:06 <+Bart_Massey> marcoz: Any EVoC news? +22:06 <+alanc> agd5f, alanc, marcoz, anholt, & stukreit at least - no word yet from emmes or keithp +22:07 <marcoz> nothing new. One or two new people pinged me but haven't heard back from them +22:07 <+Bart_Massey> On the infrastructure front, keithp and I are moving forward with plans. We will let you know when we've accomplished anything. +22:07 <+keithp> oh, I'm here, just being boring +22:08 <+Bart_Massey> On the book front, I need to get the NDG guide someplace where people can help finish it. Hopefully this week... +22:08 <+Bart_Massey> For the logo contest, I am just finishing up the wording I want to use. I'll run it by you all when I'm ready to go. +22:08 <marcoz> also, Sent Supreet that certificate. He ack'd but hasn't replied since. +22:08 <+Bart_Massey> marcoz: Thanks +22:08 <marcoz> Bart_Massey: yw +22:08 <+alanc> marcheu did merge in the changes to the driver guide to his git repo as well +22:09 <+Bart_Massey> What is our current tax/fee status? Is there work to be done there? +22:09 <+Bart_Massey> Did someone post the CFP for XDC 2013 to the lists? Have we heard anything? +22:10 <agd5f> I posted an RFP for locations/plans, but no response +22:11 <+Bart_Massey> agd5f: Thanks. We'll give it another week or two, and if we hear nothing we'll assume PDX. I'd like to get it settled ASAP. +22:11 <agd5f> sounds good +22:12 <+Bart_Massey> A long time ago we started to go over the Bylaws, but I'm not sure we ended up with anything like an actual list of proposed amendments. +22:12 <+Bart_Massey> I'd be happy to work with someone on this, but I'm a bit swamped to do it myself... +22:12 <stukreit> I paid a fee required by nsaid (spelling?) a few weeks ago. That's all I know of. +22:13 <agd5f> did we ever pay the delaware franchise fee? +22:13 <stukreit> bart: I owe you a check. +22:13 <+Bart_Massey> stukreit: absolutely no rush +22:13 <stukreit> agd5f: I think that's what nsaid took care of. +22:13 <agd5f> ah, ok +22:13 <+Bart_Massey> Who is NSAID? +22:13 <stukreit> some kind of broker for fees. I'll dig around here and see if I can find the form +22:14 <stukreit> (my office is in boxes atm) +22:14 <+Bart_Massey> np. sounds like things are under control. +22:14 <+Bart_Massey> So: volunteers for bylaws work, or am I stuck with it? :-) +22:15 <+Bart_Massey> Oh, did anyone ever hear back from the Mesa folks etc re our desire to announce explicit support of their work? +22:15 <agd5f> no response +22:15 <+Bart_Massey> Huh. Should we try again, or what? +22:16 <agd5f> I think everyone already assumes we support mesa and related projects +22:16 <+Bart_Massey> I don't think most people have much idea what we do. :-) +22:16 <agd5f> since most of our evoc and gsoc are non-X of late +22:16 <marcoz> :q +22:16 <+Bart_Massey> Anyway, I'm fine with just going ahead and listing them and waiting for them to object, unless people think otherwise... +22:16 <+keithp> wfm +22:17 <+Bart_Massey> keithp: wfm? +22:17 <+keithp> works for me +22:17 <+alanc> +1 +22:17 <+Bart_Massey> k +22:17 <agd5f> +1 +22:17 <+Bart_Massey> alanc: Didn't you draft some kind of statement already? +22:17 <+Bart_Massey> Or do I need to do this? +22:17 <marcoz> +1 +22:18 <agd5f> Bart_Massey: I updated some language on the wiki +22:18 <+Bart_Massey> Ah, that must be what I'm thinking of. Thanks +22:18 <+alanc> yeah, was agd5f not me +22:19 <+Bart_Massey> OK, I'm out of current business. Anyone else got anything? +22:19 <stukreit> so what's the ptr to the book git repo? +22:20 <+Bart_Massey> stukreit: Old book or new? +22:20 <stukreit> marceau's +22:20 <+Bart_Massey> IDK offhand. Anyone got it handy? +22:20 <agd5f> htt.p://cgit.freedesktop.org/~marcheu/lgd/ +22:20 <stukreit> the driver guide you referred to earler +22:20 <stukreit> Thanks! +22:21 <+Bart_Massey> Move to adjourn. +22:21 <agd5f> seconded +22:21 <stukreit> +1 +22:21 <marcoz> +1 +22:21 <+anholt> +1 +22:21 <+Bart_Massey> Thanks all! See you in two weeks! +22:21 <+alanc> +1 +22:21 <+keithp> enjoy! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/11-15.mdwn b/BoardOfDirectors/IrcLogs/2012/11-15.mdwn new file mode 100644 index 00000000..45a3397a --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/11-15.mdwn @@ -0,0 +1,53 @@ + +Date is 2012-11-15, times are UTC+01. The log had to to be altered, because htt.p links are not allowed due to antispam rules. \ +[[!format txt """ +23:00 <agd5f> hello +23:00 <+alanc> good afternoon +23:00 <stukreit> hi +23:01 <stukreit> la la la +23:04 <marcoz> hi, sorry Im' late. meeting. +23:04 <+alanc> it's okay, you still beat Bart, so we haven't really started yet +23:05 <marcoz> It's not official until Bart's here. :) +23:14 <+alanc> well he said he had a short agenda +23:14 <+alanc> I don't remember anything specific to talk about off hand +23:15 <marcoz> any wiki news? +23:16 <+alanc> spam rate still running at zero due to the ban on "htt.p" +23:16 <+alanc> every time I lift that it returns, so I put it back +23:17 <+alanc> haven't heard from fd.o admins on replacement plans +23:17 <+alanc> I think keithp was talking to jrayhawk about that +23:17 <marcoz> ikiwiki ? +23:18 <+Bart_Massey> aiiee. I was programming and totally lost track of time. My sincere apologies. +23:19 <+Bart_Massey> Did I miss everything and everybody? +23:19 <+alanc> we didn't really have much to talk about +23:19 <+alanc> mostly been sitting around waiting 8-) +23:20 <+alanc> agd5f, stukreit, marcoz & I are actually here +23:20 <+Bart_Massey> Apologies. I went out of my way to be at my desk by meeting time :-(. +23:21 <+Bart_Massey> Like I said in my email, I don't have too much business anyhow. +23:21 <+Bart_Massey> Some stuff has come up, and I do not yet have the logo thing started. +23:21 <+Bart_Massey> Nor the first book ready to go. +23:21 <+Bart_Massey> But both things are on my stack. +23:21 <+Bart_Massey> I believe other things on our stack are: bylaws revision, fundraising, elections, XDC 2013 +23:22 <+Bart_Massey> Has anyone heard any other proposals for XDC 2013? +23:22 <+alanc> I haven't +23:23 <+Bart_Massey> Then, if we have a quorum, I'd like to move we officially set up XDC 2013 for PDX and announce this somewhere. +23:24 <+Bart_Massey> Or maybe choose a date first and then announce; let's try to get that done before next mtg. +23:24 <+alanc> who is the organizing commitee? you, keithp & idr? +23:25 <+Bart_Massey> I think so. +23:25 <+Bart_Massey> We may be able to draft cworth and/or anholt also. +23:26 <+alanc> okay, I'm happy to vote to officially appoint you folks as the XDC 2013 committee for Portland, and let you find a venue/date before making the official announcement to the world +23:26 <+Bart_Massey> +1 +23:26 <marcoz> +1 +23:27 <+alanc> +1 if that wasn't already clear +23:27 <stukreit> +1 +23:28 <agd5f> +1 +23:28 <+Bart_Massey> motion carries. thanks all. +23:29 <+Bart_Massey> i will bug keithp as soon as he gets back from his latest travel adventure and we will get the ball rolling +23:29 <+Bart_Massey> any other urgent business? +23:30 <stukreit> none here +23:30 <+alanc> I don't have any +23:31 <+Bart_Massey> alright; move to adjourn. thanks all +23:31 <stukreit> +1 +23:31 <agd5f> +1 +23:32 <+alanc> +1 +23:34 <marcoz> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/11-29.mdwn b/BoardOfDirectors/IrcLogs/2012/11-29.mdwn new file mode 100644 index 00000000..4369dcd4 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/11-29.mdwn @@ -0,0 +1,111 @@ + +Date is 2012-11-29, times are UTC+01. The log had to to be altered, because htt.p links and the word web.site are not allowed due to antispam rules. +[[!format txt """ +23:00 <+emmes> HELO +23:02 <+alanc> EHLO +23:03 <agd5f> hi +23:03 <marcoz> hey +23:05 <Bart_Massey> Hey all. +23:05 <+emmes> How's it going? +23:05 <Bart_Massey> Good, if busy. Right at the end of our academic quarter :-). +23:05 <Bart_Massey> You? +23:06 <Bart_Massey> Who else do we have today? +23:06 <+emmes> well, it's in the middle, so all courses are busy at the same time... +23:07 <Bart_Massey> emmes: Yeah, know that feeling too. +23:07 <+alanc> agd5f, marcoz, & I had all said hello just before you got here +23:07 * alanc walks down the hall to wake up stukreit... +23:07 <Bart_Massey> alanc: cool. sounds like we have one of those quorum thingies. +23:07 <Bart_Massey> We'll wait to see if stukreit and/or keithp shows up. +23:07 <+keithp> hey ho +23:07 <+keithp> previous mtg went long (shocker) +23:07 <stukreit> hi +23:07 <Bart_Massey> howdy! +23:08 <stukreit> ok then +23:08 <Bart_Massey> OK, let's do the short list of agenda items. +23:08 <Bart_Massey> 1) Elections. What's the status here? +23:09 <Bart_Massey> I forget: who's Election Chair? +23:09 <Bart_Massey> I think it was Edison---no, wait, that's Electric Chair... +23:10 <+alanc> anholt I thought, as the only one who remembered how to drive the election web voting thingy +23:11 <Bart_Massey> That's what I thought also. Ok, so we'll table that until next time and hopefully anholt will be here. +23:11 <+keithp> yeah, he signed himself up +23:11 <Bart_Massey> But let's not drop the ball on that one. +23:11 <+keithp> he's currently got a recurring meeting on Thursdays at 14:00PST... +23:11 <+keithp> I suggest discussing that over email +23:11 <Bart_Massey> If he can't move his Thu mtg we should probably resched this one... +23:12 <Bart_Massey> Anyhow, we've still got some time, but it does come up pretty fast. +23:12 <Bart_Massey> Second, fundraising. I've still dropped the ball on getting the logo thing going. +23:12 <Bart_Massey> I'm hoping that we can get Rayhawk to help getting a secure site set up for individual donations. +23:13 <Bart_Massey> Keithp, you want to work with him on that? +23:13 <Bart_Massey> Finally, we need to start approaching corporate and other larger sponsors. +23:13 <+keithp> Bart_Massey: a fine plan; shall we try to meet with him over lunch-ish tomorrow? +23:13 <Bart_Massey> keithp: Tomorrow is booked fairly solid for me; let's aim for sometime next week? +23:13 <+keithp> sounds good +23:14 <Bart_Massey> keithp, I think you also got volunteered at some point to do the larger-sponsors thing. +23:14 <Bart_Massey> ? +23:14 <Bart_Massey> What do we need to do there? +23:15 <Bart_Massey> I'd like to target stabilizing our slush fund at something like $75K? This is nominally enough for about 2 years of operation at our current burn rate, which seems about right... +23:15 <stukreit> we're pretty close to that now. +23:16 <Bart_Massey> Yes: so it's a matter of sustaining that level, IMHO. +23:16 <Bart_Massey> Probably means bringing in something like $30K/year in ongoing support. +23:18 <Bart_Massey> Anyone got any thoughts on how we're gonna get there? +23:18 <stukreit> our balance today is $74409. +23:18 <marcoz> bake sale? +23:19 <agd5f> charge for conferences? +23:19 <Bart_Massey> I guess I'm hoping that we could find about 6 sponsors willing to commit $5000 annually to support what we do. +23:19 <stukreit> Colorado style? +23:19 <+keithp> I think getting a significant fraction from non-corporate sponsors will be harder than passing the hat around for $30k a year +23:19 <Bart_Massey> keithp: I think and hope you're right, but someone needs to get the hat passing going... +23:19 <marcoz> stukreit: we make some mean brownies here now. ;) +23:20 <+keithp> I'd also like to suggest that instead of asking for slush funds, we should have a budget and target specific programs (EVoC, XDS, etc) and ask for support for those +23:20 <Bart_Massey> I think the experiment of just putting up a web.site and seeing what we get in individual donations is worth trying. +23:20 <agd5f> Bart_Massey: agreed +23:20 <+keithp> People like being able to donate to specific projects more than just handing out money for 'good works' +23:20 <agd5f> we can post periodically about donating and tax deductibility +23:21 <marcoz> can you merge the two? allow people to target their donations? +23:21 <Bart_Massey> keithp: You've suggested this before, and I'm fine with that, but we probably also need O($5k/year) in just stuff. Maybe that's what individual donatoins are for +23:21 <Bart_Massey> marcoz: absolutely, but I want to make sure the general operating monies don't get lost in the shuffle. +23:21 <+keithp> the less 'overhead' of that form that we have, the easier things will be +23:21 <agd5f> how do we deal with tax deductibility? I assume we have to provide some sort of receipt? +23:21 <+keithp> agd5f: yup, just send a letter. I've got dozens of examples (and will have a lot more in a couple of weeks ;-) +23:22 <Bart_Massey> In the US, tax deductability is easy; we just provide donors with some information. +23:23 <Bart_Massey> So it sounds like we have a plan: we just need to get going on executing it. Keithp, let's you and I talk offline about this and bring some work and/or a proposal back to the Board next meeting? +23:23 <stukreit> I don't see any reason not to put a donate button on the web.site immediately, to be followed up by some explanations +23:23 <+keithp> Bart_Massey: sounds good, especially if 'talking' involves sushi +23:23 <+keithp> stukreit: agreed +23:23 <Bart_Massey> stukreit: Because our web.site is an invitation to get hacked right now. +23:23 <Bart_Massey> The last thing I want is for folks to inadvertently "donate" to somebody not us :-) +23:24 <Bart_Massey> We'll do it as soon as we can figure out how to do it right. +23:24 <+alanc> also, our web.site is currently configured to block all htt.p & htt.ps links right now +23:24 <stukreit> Maybe you're right. Is there some fast way to absorb web.site hardening features? +23:24 <+alanc> since that was the only way to stop the spam +23:24 <Bart_Massey> stukreit: Keithp, Rayhawk and I will figure it out in the next couple of weeks. +23:24 <stukreit> k +23:25 <Bart_Massey> (and probably anholt and whoever else wants to help) +23:25 <Bart_Massey> Those were the urgent items on my agenda for today. +23:25 <Bart_Massey> Anything else we need to talk about? +23:25 <stukreit> I just heard the jingle of loose change and started dreaming of making deposits, not just withdrawals ;-) +23:25 <Bart_Massey> stukreit: I'm with you, man +23:25 <stukreit> I got this year's NRAI bill. +23:26 <Bart_Massey> What's it come to? +23:26 <stukreit> $189. and I need to send Bart's travel reimbursement check. +23:26 <Bart_Massey> We can do $189 :-) +23:26 <Bart_Massey> Other agenda items? +23:26 <stukreit> how is fosdem shaping up? +23:27 <+alanc> we have a devroom for one day +23:27 <+alanc> Luc had 5 or 6 talks coming last I looked +23:27 <Bart_Massey> Cool. +23:27 <+keithp> I'm not going to be able to make it this year -- scheduled the same day as LCA, alas +23:27 <stukreit> pretty big then. He should post info.. just next to the donate button +23:27 <Bart_Massey> LOL +23:28 <Bart_Massey> OK, I think we're good for this round. Move to adjourn... +23:28 <stukreit> +1 +23:28 <+alanc> htt.ps://staging.fosdem.org/2013/news/2012-11-18-announcing-devrooms/ says our day is saturday +23:28 <+alanc> did we need to vote on the $189 for NRAI? +23:28 <+keithp> see y'all later on +23:28 <Bart_Massey> alanc: Not AFAIK +23:29 <+alanc> k, then +1 to adjourn +23:29 <+alanc> actually, htt.p://www.x.org/wiki/fosdem2013 seems to be up to 9 confirmed, 2 tentative +23:30 <Bart_Massey> Nice. +23:30 <Bart_Massey> I think we have 4 votes, which is enough to adjourn. Bye all! +23:30 <+alanc> both tentative seem to be pending budget/approval from Intel 8-) +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2012/12-13.mdwn b/BoardOfDirectors/IrcLogs/2012/12-13.mdwn new file mode 100644 index 00000000..18b9f507 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2012/12-13.mdwn @@ -0,0 +1,31 @@ + +Date is 2012-12-13, times are UTC+01. +[[!format txt """ +23:00 <+Bart_Massey> Hello all. +23:00 <agd5f> hello +23:00 <marcoz> hiya +23:02 <+Bart_Massey> We'll give it a few more minutes and see if we get a quorum. +23:07 <+emmes> hey +23:07 <+Bart_Massey> Howdy! +23:07 <+Bart_Massey> We're waiting for attendees. Will start in a few minutes... +23:10 <+Bart_Massey> OK, let's go ahead and run whatever agenda we have... +23:11 <+Bart_Massey> Old business: (1) Still working on logo contest materials. Hope to have them ready shortly. (2) Still working on a date for XDC 2013: hope to have that shortly as well. (3) Still working on editing up the first sprint book; ditto. :-) +23:11 <+Bart_Massey> Probably could use some help with one of these at some point. :-) +23:12 <+Bart_Massey> Keithp and I had a long talk with jrayhawk a few days ago about infrastructure: we are converging quickly on figuring some things out. +23:12 <+Bart_Massey> Without stukreit, not sure how to proceed on end-of-year finances. +23:13 <+Bart_Massey> Discussion? New business? +23:13 <marcoz> if I can help on anything lemme know. My freetime has dwindled substantially but I'll help where I can. +23:13 <+Bart_Massey> appreciated. if you knew somebody who wanted to take over some editing on the first sprint book, that would be great. +23:14 <+Bart_Massey> i feel like there's no point getting it formatted until some more cleanup can be done of the text, and I think most of it is fairly mechanical? +23:14 <marcoz> that requires actually English ability correct? +23:14 <agd5f> speaking of infrastructure, are user directories backed up on fdo or not? There was some discussion last time there was a failure, but I don't remember what came of it +23:14 <+Bart_Massey> marcoz: yes +23:15 <+Bart_Massey> agd5f: not AFAIK. keithp considers this sort of a feature; I'm not so sure. AFAIK we can fix it if desired... +23:16 <+Bart_Massey> Any other business? +23:17 <+Bart_Massey> OK, then. Short meeting: move to adjourn. +23:18 <marcoz> +1 +23:18 <+Bart_Massey> Opposed? +23:19 <+Bart_Massey> Good to see you all. Adjourned. Happy Holidays! +23:26 <+keithp> oops, looks like I missed the meeting :-) +23:48 <stukreit> oop++ +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/01-10.mdwn b/BoardOfDirectors/IrcLogs/2013/01-10.mdwn new file mode 100644 index 00000000..b6a404e6 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/01-10.mdwn @@ -0,0 +1,70 @@ + +Date is 2013-01-10, times are UTC+01. +[[!format txt """ +22:38 <marcoz> meeting over? +22:43 <agd5f> not started yet +22:44 <agd5f> starts in 15 minutes +22:48 <mupuf_> oh, good :) +22:49 <mupuf_> have you decided when will the XDC2013 happen? +22:51 <agd5f> not sure it's my decision to make ;) +22:56 <mupuf_> agd5f: :) I would be glad if it could happen before the 21th of september. +22:57 <mupuf_> I wouldn't like missing Roger Waters' "the wall" concert in Paris +23:02 <+Bart_Massey> Hey all! +23:02 <+anholt> hello +23:03 <agd5f> hi +23:03 <stukreit> hi, Alan is home sick, but if he's conscious, he'll probably chime in soon. +23:03 <stukreit> (he's got the flue) +23:04 <+Bart_Massey> OK. Sorry to hear about alanc. We'll start in a minute or two more in case someone shows late. +23:08 <+Bart_Massey> OK, let's see what the four of us can get done. +23:09 <+Bart_Massey> First up, elections. I think we're supposed to call for candidates RSN? +23:09 <+Bart_Massey> anholt, you're running this, right? +23:09 <+anholt> that's the theory, but it fell off my radar for a couple of months. checking schedule stuff now +23:10 <+Bart_Massey> I think there's kind of been broad consensus that after the new year is better anyway, so I haven't pushed it too much. +23:10 <+anholt> is www.x.org working for others? +23:10 <+Bart_Massey> sigh. nope +23:10 <+Bart_Massey> I'll bug Rayhawk today and find out where we are with getting a working x.org +23:10 <stukreit> nope! +23:11 <agd5f> down here as well +23:11 <+anholt> don't have a cached version of the schedule, but I think the schedule tells me to get moving. +23:11 <+Bart_Massey> Looks like the cert for members.x.org has expired, sigh. +23:12 <+Bart_Massey> Anyone object to us paying to renew it? :-) +23:12 <agd5f> no objections from me +23:12 <+Bart_Massey> OK, we'll get that one done this week too. +23:12 <stukreit> erm, send me the pay-to info. +23:12 <+anholt> I'd like that done before we announce stuff if possible. +23:12 <+Bart_Massey> anholt: yeah, that's why I was checking on members.x.org +23:12 <stukreit> send it to me sooner! +23:13 <+Bart_Massey> stukreit: send it to you as soon as we know what it is and who it goes to +23:15 <+Bart_Massey> stukreit: We'll need a Treasurer Report sometime this month, I think? +23:15 <stukreit> re financial report: I made an in/out spreadsheet, could separate expenses by 3 or 4 major categories. Does that sound like enough detail? +23:15 <+Bart_Massey> Sounds great! +23:15 <+Bart_Massey> Are we OK with IRS filings, corporate papers, etc? +23:15 <stukreit> I suppose I'm supposed to make an IRS filing ? +23:16 <+Bart_Massey> I don't know who or how, which is why I'm asking. Somebody needs to find out ASAP? +23:16 <stukreit> fuzzy. I'll have to dig into this instead of watching kittens on youtube +23:16 <+Bart_Massey> LOL +23:16 <stukreit> I had a pamphlet on this a while ago, need to dig it up. Have a reall home office now, so things are getting more organized +23:17 <+Bart_Massey> Thanks! +23:17 <stukreit> ok, I have 2 action items to evade scolding on. +23:17 <stukreit> (by delivering them) +23:17 <+Bart_Massey> I need to do a State of the Org report as well. I think that's all the urgent stuff, and I'm inclined to punt non-urgent stuff until we're less busyh and have more Board members present. Anything else we need to talk about? +23:18 <stukreit> fosdem? +23:18 <+Bart_Massey> Do we need to figure something out about fosdem? Who's going, I guess? +23:18 <stukreit> usually Luc.. +23:19 <+Bart_Massey> what does the Board need to do? +23:19 * Bart_Massey is amused that xchat won't let him type "t-e-h" +23:20 <+anholt> Bart_Massey: settings -> advanced -> auto replace to fix that iirc +23:20 <+Bart_Massey> anholt: tx! +23:21 <+Bart_Massey> stukreit: is there any action we need to take re: FOSDEM? +23:21 <+anholt> I don't recall the board doing anything in particular for fosdem, other than saying thanks for organizing. +23:21 <+Bart_Massey> Cool. agd5f, any chance we could get you to draft them a nice email? +23:21 <stukreit> yes. but its worth inquiring, perhaps encouraging +23:21 <agd5f> Bart_Massey: draft an email to whom? +23:22 <+Bart_Massey> Luc/FOSDEM saying thanks for organizing, offering what assistance we can, etc I guess? +23:22 <agd5f> sure +23:22 <+Bart_Massey> Tx! +23:22 <+Bart_Massey> OK, I think I'm good. Move to adjourn... +23:22 <stukreit> +1 +23:22 <agd5f> +1 +23:22 <+Bart_Massey> See y'all in a couple weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/01-24.mdwn b/BoardOfDirectors/IrcLogs/2013/01-24.mdwn new file mode 100644 index 00000000..4df6123a --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/01-24.mdwn @@ -0,0 +1,132 @@ + +Date is 2013-01-24, times are UTC+01. +[[!format txt """ +22:55 <+keithp> I'm here too +22:55 <+Bart_Massey> Howdy! +22:55 <agd5f> hi +22:56 <+anholt> hey +22:56 <+Bart_Massey> keithp: So I found those beading containers 30/$10 on overstock.com. +22:56 <+keithp> nice +22:57 <+Bart_Massey> Ordered three sets; will now probably go down and buy the one at Michael's to get the tray as well. +22:59 <+Bart_Massey> OK, there's really only one big agenda item today: elections. We need to get these going by the end of the month, which means that the official process needs to start before the next Board Meeting. +23:00 <+Bart_Massey> anholt: What's the state of the software at this point? +23:00 <stukreit> hya +23:00 <+Bart_Massey> Greetings! +23:00 <+Bart_Massey> Elections! +23:01 <marcoz> hi all +23:02 <+Bart_Massey> OK... I'm looking at the Board list right now and realizing that anholt is up for election this cycle anyway, so... +23:03 <+Bart_Massey> in spite of his generous offer, he probably shouldn't be Election Chair anyhow. +23:03 <+Bart_Massey> I think? +23:03 <+Bart_Massey> Which four have terms up this January? +23:04 <+Bart_Massey> Is it anholt, alanc stukreit and myself? +23:04 <+Bart_Massey> I think? +23:05 <+Bart_Massey> the whole "term ends 2012" thing is a little confusing; I assume that this election is for those people? +23:05 <+alanc> that's what http://www.x.org/wiki/BoardOfDirectors says +23:05 <+alanc> yes, our "term ends" thing got messy when our elections slipped from end of the year to start of the next one +23:05 <+Bart_Massey> so the "term ends 2013" people are the ones up next year? OK. +23:05 <+Bart_Massey> Yeah. +23:05 <+keithp> Bart_Massey: anholt was chatting with tolef this morning about fixing the members.x.org site +23:06 <+alanc> so the election committee should be marcoz, emmes, agd5f & keithp +23:06 <+Bart_Massey> Right +23:07 <+Bart_Massey> and one of those needs to step up to chair it, which in practice has historically meant doing most of the work :-( :-( +23:07 <+Bart_Massey> keithp: I think it's great for anholt to continue to work on geting members. +23:07 <+Bart_Massey> to work +23:08 <+Bart_Massey> as we've done that in the past +23:08 <+Bart_Massey> but we need somebody not up for election to run the elections +23:08 <+Bart_Massey> marcoz: IMHO you'd be a great choice, if you were willing... +23:08 <+keithp> afaik, anholt volunteered to run them, is he actually up for election? +23:09 <+Bart_Massey> keithp: unless he's choosing not to run again, yes +23:09 <+Bart_Massey> at least according to the wiki, which probably knows more about it than I do :-( +23:10 <marcoz> what all's involved? +23:10 <+Bart_Massey> Issue a call for candidates, gather candidate statements and publish them, issue an election announcement +23:10 <+Bart_Massey> that's about it +23:11 <+Bart_Massey> we have good detailed documentation on the process, with a checklist +23:11 <agd5f> setting up the election on the website and sending a few emails. I did it last time I was on the election committee +23:12 <marcoz> there a task list of something that people used in the past? I don't want to be as disorganized as I was on the booksprint +23:12 <+Bart_Massey> You'll want anholt or somebody to deal with the website for the most part, since it's...not pretty +23:12 <+Bart_Massey> marcoz: Yes, hard as it is to believe for us, we have a checklist and good documentation +23:12 <+alanc> the ElectionCommittee page in the board wiki has the details if you can remember your login to it +23:12 <+alanc> a simple 17-step process +23:12 <marcoz> heh +23:13 <marcoz> Bart_Massey: umm yea, who do I contact for password reset? +23:13 <+Bart_Massey> Probably anholt +23:13 <+Bart_Massey> What's the board wiki URL again? +23:14 <+Bart_Massey> sitewranglers would also probably work +23:14 <+alanc> just mailed the list with the URL, wasn't sure if you wanted the private wiki URL in the meeting log +23:14 <+Bart_Massey> OK thanks +23:15 <+Bart_Massey> So are we set to get the Call for Candidates out next calendar week? +23:16 <+alanc> are we going to overlap it with the call for membership applications? +23:16 <+Bart_Massey> Oh yeah, we need to worry about that too, don't we +23:17 <+Bart_Massey> Yes, all candidates need to be Members, so this is a good time to invite people to be members. +23:17 <+alanc> anholt had also wanted to look into expiring people who haven't voted in years, if he could find the scripts for that from last time, so we don't come as close to missing quorum as we did last year +23:17 <agd5f> anholt wanted to do a renew pass first +23:17 <+Bart_Massey> Somebody want to take the onus of filtering the recent xorg-devel and the like and invitiing those folks to apply/renew? +23:17 <agd5f> since we barely made quorum last time since the code to expire members is commented out +23:18 <+Bart_Massey> And yes, we should extend a general invite to renew if appropriate to the existing members +23:18 <+alanc> also I guess we need to decide if we're proposing bylaw changes for this election soon +23:18 <agd5f> basically expire all the people who haven't renewed in the last year and ask the membership to renew +23:18 <+Bart_Massey> I don't think the Bylaws changes are coupled to the election meeting? +23:18 <+Bart_Massey> I think we actually need a separate meeting for those. +23:18 <+Bart_Massey> Let me check the Bylaws again. +23:18 <+alanc> I thought they had to go through the election process so it was easier to do with the election than separately +23:20 <+anholt> sorry for missing a bit -- had to move rooms. were there elections questions? +23:20 <+Bart_Massey> Lots and lots :-) +23:20 <+Bart_Massey> anholt: Are you running for re-election this year? +23:21 <+anholt> I don't think so -- I thought I was running the election committee this year. +23:21 <+alanc> http://www.x.org/wiki/BoardOfDirectors says your term is up though +23:21 <+Bart_Massey> anholt: You are up this year if you want to run again, in which case you probably shouldn't run the election committee :-) +23:22 <+anholt> whoops. +23:22 <+anholt> sounds like I don't have to run an election! +23:22 <+Bart_Massey> OK, I was wrong: any vote of 2/3 of the membership appears to be sufficient to change the Bylaws +23:23 <+Bart_Massey> So if we want to overlap Bylaws changes with the Board election, we'd have to do it right quick +23:23 <+anholt> elections are hard enough to organize, I'd recommend keeping it separate. +23:24 <+Bart_Massey> I'd agree, but I think politically it will potentially be easier to pass our changes during a Board Election maybe. I'd say we work on the Bylaws changes this year and put them up during next year's election? +23:24 <+anholt> that sounds reasonable +23:25 <agd5f> anholt: can you still finish the renewal stuff before you step aside? +23:25 <+Bart_Massey> I don't think there's any conflict between the renewal stuff and the elections +23:25 <+anholt> absolutely -- I think I've got that figured out, so if the real elections committee wants it to happen, I'll push the button. +23:25 <+Bart_Massey> they are notionally separate activities +23:25 <+Bart_Massey> even if they will help the election process +23:25 <+anholt> the renewal stuff is supposedly automatic if we hadn't misplaced a cronjob. +23:26 <+Bart_Massey> I move that anholt be empowered to do what is necessary in the renewal process. +1s from the Board? +23:26 <marcoz> +1 +23:26 <agd5f> +1 +23:27 <+alanc> +1 +23:27 <+Bart_Massey> Opposed? +23:27 <stukreit> +1 +23:27 <+Bart_Massey> Thank you anholt! +23:27 <+anholt> on the topic of elections, I'm feeling out mithrandir for interest in building us a better elections site. I've sent him a rough spec and he's thinking about it. +23:28 <+Bart_Massey> anholt: that's awesome; let us know how we can help +23:28 <agd5f> sweet! +23:28 <+alanc> I'm also good with him continuing to handle incoming member applications as we poke people to join in time for the elections +23:28 <+Bart_Massey> So marcoz, are you willing to step up as Elections Chair? +23:28 <+Bart_Massey> alanc: of course +23:29 <marcoz> yes +23:29 <+Bart_Massey> Thanks! +23:29 <+Bart_Massey> OK, so ideally we get the membership stuff and the call for Candidates out by the end of next week, then proceed from there. Sound good to everyone? +23:30 <marcoz> works for me +23:30 <agd5f> anholt: I'd say go ahead and hit the button on the renewal +23:30 <+anholt> will do +23:31 <+Bart_Massey> OK, I think that's enough for one meeting. Anybody have other urgent business? +23:31 <+Bart_Massey> stukreit: You still need to do a Treasurer's Report, and I need to do a report as well. These should happen before the Call for Candidates, so hopefully this week or early next? +23:32 <+alanc> not urgent, but did we ever get any part of the book sprint output posted so others can see? still get occasional questions about it in various forums +23:32 <+Bart_Massey> It's urgent, and I've mostly failed. +23:33 <+Bart_Massey> It's available, but not in any good place: just in my account on people +23:33 <+alanc> well, not as urgent as the election stuff +23:33 <+Bart_Massey> I think the other book sprint output is available somewhere too, but we need to get them in a well-known place and figure out how to finish at least hte first one into something that is ready for general publication +23:33 <+Bart_Massey> Let's tackle that topic at the next meeting? +23:33 <+anholt> marcoz: I've updated the elections@ list, haven't hit the mysql. you've got the wiki page for the election? +23:34 <+alanc> okay +23:34 <marcoz> no, what is? +23:34 <+anholt> https://members.x.org/bod/ElectionCommittee +23:35 <+Bart_Massey> LOL oh well :-) +23:35 <marcoz> thanks! now I just need to remember my pasword +23:35 <+Bart_Massey> Somebody kick stukreit about hte Treasurer's Report and we'll call it good. +23:35 <+Bart_Massey> Move to adjourn +23:36 <marcoz> +1 +23:36 <agd5f> +1 +23:36 <+anholt> +1 +23:36 <+keithp> +1 +23:36 <+alanc> +1 +23:36 <+Bart_Massey> See you all next week! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/02-07.mdwn b/BoardOfDirectors/IrcLogs/2013/02-07.mdwn new file mode 100644 index 00000000..2893e942 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/02-07.mdwn @@ -0,0 +1,127 @@ + +Date is 2013-02-07, times are UTC+01. +[[!format txt """ +23:00 <+emmes> hey all +23:00 <agd5f> hi +23:00 <marcoz> hey +23:00 <+keithp> changing rooms. bbiaw +23:01 <stukreit> hi +23:02 <+Bart_Massey> Hey all! +23:03 <+Bart_Massey> Is it just stukreit and I today? +23:03 <marcoz> hi +23:03 <agd5f> hi +23:03 <+emmes> nope, you just missed our "hey all" by a few seconds ;) +23:03 <+Bart_Massey> :-) +23:03 <+emmes> keithp is almost here as well +23:03 <+Bart_Massey> Is keithp back in USA? +23:04 <stukreit> alan is home with flu, I emailed him +23:04 <+emmes> btw - sorry that i've not been able to join last time... +23:04 <+Bart_Massey> He sent email earlier. +23:04 <+Bart_Massey> emmes: np. We know you'll make it when you can. +23:04 <+keithp> back +23:05 <+Bart_Massey> Howdy! +23:05 <+Bart_Massey> keithp: Are you in town again? +23:05 <+keithp> Bart_Massey: indeed. been sleeping most of the week though; up for lunch tomorrow +23:05 <+Bart_Massey> Sounds good! +23:05 <+Bart_Massey> OK, I +23:06 <+Bart_Massey> OK, let's get 'er going. +23:06 <+Bart_Massey> Three agenda items today. First is the Report. Got good comments from a couple of you. Anything else anyone wants to add before I send it out? +23:06 <+Bart_Massey> Anything that seems wrong, awkward, etc? +23:06 <stukreit> I read it, no comment other than looks good +23:06 <+emmes> ... reading... but so far it looks good. +23:07 <+Bart_Massey> OK. If there's no major discussion to be had, we'll handle the rest of that in email. +23:07 <+Bart_Massey> stukreit: Of course, part of the reason I'm pushing it out is to put pressure on the Treasurer to do likewise. :-) :-) +23:07 <stukreit> yeah. +23:07 <marcoz> Ah, i always thought the S was Summit +23:08 <+Bart_Massey> stukreit: We are still with HSBC, right? +23:08 <stukreit> workinonit today +23:08 <stukreit> that too. any recommendations on alternative banks? +23:09 <+Bart_Massey> Not really. Keithp and I looked into US Bank a couple of years ago, but there were issues. IDK. Find out what other 501(c)3 open source orgs are using, maybe? +23:09 <+Bart_Massey> Okay, the other two agenda items are elections and elections. Where are we? +23:09 <stukreit> def. guess I can ask Karen +23:10 <marcoz> the committee has agreed on the schedule +23:10 <+keithp> stukreit: mostly needs to be convenient for you +23:10 <+Bart_Massey> marcoz: cool. hopefully it finishes in February? +23:10 <stukreit> any excuse to run up to SF +23:11 <marcoz> i'll be sending out the nominations email here, so that week2, the nom window start, is next week +23:11 <+emmes> Bart_Massey: finished reading, it's fine from my point of view. +23:11 <marcoz> with anholt_ 's email, the renewal, we're in week 1 +23:11 <+Bart_Massey> So actually early March. Bummer, but how it has to be, I guess. We *must* do better next year (or amend the Bylaws to a 14-month election cycle :-) +23:11 <+Bart_Massey> emmes: thanks! +23:12 <agd5f> marcoz: should probably mention renewals and a request for sign up in that email as well +23:12 <marcoz> agd5f: will do. +23:12 <+Bart_Massey> Is election infrastructure ready or getting ready? +23:12 <+emmes> I guess to have an election early in the year it means starting the election process in late summer :-/ +23:12 <marcoz> well, I still don't have access to expo, so I'd say 'getting ready'. Can someone help me with that? +23:13 <+Bart_Massey> anholt_: you were going to get that all going, right? +23:13 <marcoz> btw, what's the norm for elections? Is this the first, to miss the Feb? +23:13 <+emmes> i'll check - i did the database stuff (the frontend stuff only, though) last time. Anholt helped me with the backend (low level) stuff. +23:13 <+Bart_Massey> Yeah, it's moved from November to December to January to Feb. +23:13 <+Bart_Massey> Hence my comment. +23:13 <agd5f> marcoz: historically they are supposed to be in the fall +23:13 <jcristau> the norm is to be late +23:13 <agd5f> but they've slipped every year +23:14 <+anholt_> the fall was always a mess, I think the new timeframe makes a lot more sense, if we could be consistent in the future. +23:14 <marcoz> so we can say we use the lunar calendar +23:14 <+Bart_Massey> The most recent intent of the Board was that they consistently be held late January / early February, which seems to be a good time for it if we can hit it. +23:14 <+anholt_> Bart_Massey: election infrastructure is basically ready -- renewal was the hard part. +23:14 <+Bart_Massey> anholt_: awesome, thanks. +23:14 <+emmes> how about *starting* the election process in - say - November, so there's a positive possibility that election is actually happing in January? +23:15 <+Bart_Massey> Uh, I started bugging everybody about it in October :-) +23:15 <+emmes> i wasn't talking about buggin ;-) that has to be two months earlier, the minimum... +23:16 <+Bart_Massey> So, yeah. We will try again this October and hopefully hit it again. +23:16 <+Bart_Massey> If we can get the actual process running by second week of January, I think that's fine. +23:17 <+Bart_Massey> So we're not *worlds* behind at this point. :-) +23:17 <+Bart_Massey> Is there anything else we should be thinking about, election-wise? +23:17 <marcoz> someone wanna cronjob that renewals email and force us to kick off the process at a given time? +23:18 <+emmes> marcoz: I have access to expo - though I'd need to remember what has actually to be done there, and I won't have internet access for a week beginning tomorrow... +23:18 <marcoz> alanc mentioned that I needed to create a .htpasswd file +23:19 <marcoz> not sure if I generate the moin username though? +23:19 <+Bart_Massey> agd5f: Please do find the SFLC-suggested Bylaws changes, and we'll fast-track those as much as possible. +23:19 <agd5f> Bart_Massey: will do +23:19 <+Bart_Massey> Thanks huge! +23:20 <marcoz> this is all just so I can get to https://members.x.org/bod/ElectionCommittee +23:20 <+emmes> marcoz: ah, right, I remember. I don't have root access, so can't help here. +23:20 <+Bart_Massey> LOL. I can't get to that page either; seem to have lost whatever password I might have had. +23:20 <+Bart_Massey> Somebody want to take point on rebooting the bod wiki? +23:20 <+Bart_Massey> It might be a useful resource if we could use it. :-) +23:21 <marcoz> lol +23:21 <+emmes> I have access to it - my browser remembered my password ;-) +23:21 <+Bart_Massey> keithp: does jrayhawk have the perms he would need to fix this up nice for us? +23:22 <+emmes> Bart_Massey: I could give you the md5sum - I doubt it would help +23:22 <+Bart_Massey> emmes: No we need to future-proof this anyhow. We may be about to change out some Board Members, in any case, so... +23:22 <+Bart_Massey> But thanks! +23:22 <agd5f> there's some sort of htpasswd magic required +23:22 <+keithp> Bart_Massey: I don't think so... +23:22 <+Bart_Massey> keithp: Can you fix this? +23:23 <+emmes> Bart_Massey: sure. i was jus missing the smilie. +23:23 <+emmes> the htpasswd is owned by root... +23:23 <+Bart_Massey> keithp: (I mean, can you give jrayhawk the necessary access?) +23:24 <agd5f> IIRC, I setup a htpasswd in my home dir on expo and anholt or Tollef took it from there +23:24 <+Bart_Massey> OK, that's all I have. Anybody got anything else urgent we need to talk about? +23:25 <marcoz> when start discussing GSoC/EVoC? +23:25 <+Bart_Massey> I think EVoC is ongoing, no? +23:25 <marcoz> y, +23:26 <marcoz> just GSOC rather. +23:26 <+Bart_Massey> I don't know how people feel about continuing to apply to GSoC? +23:26 <marcoz> email discussion? +23:26 <+Bart_Massey> I can't personally muster much enthusiasm, but if others think it would be neat to try again this year that would be great... +23:27 <+Bart_Massey> Yeah, maybe take it to email and sort it. It will be a little while before Google announces GSoC 2013 regardless. +23:28 <+emmes> I would suggest trying it again - I mean, it wasn't a lot of work to just apply, was it? +23:28 <+emmes> Whether to improve any documentation beforehand is a different story, though. +23:28 <+Bart_Massey> emmes: It wasn't. But that may be part of why we were rejected. :-) +23:28 <+emmes> lol +23:28 <marcoz> marcheu was the organizer before right? would be again? +23:29 <+Bart_Massey> marcoz: Yeah, I think the key requirement would be to find somebody excited enough about being an Org Admin to put in the work of doing a really nice app and running a really nice program for the students who got in. +23:30 <+Bart_Massey> Being an Org Admin is kind of fun: the Mentor Summit is pretty neat, too. +23:30 <+emmes> only if he volunteers again - we certainly don't want to press him into that role :-) +23:30 <+Bart_Massey> emmes: Exactly. +23:30 <+Bart_Massey> OK, let's table this for now, but everybody think about it. +23:30 <+Bart_Massey> Anything else? +23:31 <+Bart_Massey> Move to adjourn. +23:31 <+emmes> +1 +23:31 <marcoz> +1 +23:31 <stukreit> +1 +23:31 <agd5f> +1 +23:31 <+Bart_Massey> Talk to all y'all in a couple of weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/02-21.mdwn b/BoardOfDirectors/IrcLogs/2013/02-21.mdwn new file mode 100644 index 00000000..cc731fd9 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/02-21.mdwn @@ -0,0 +1,132 @@ + +Date is 2013-02-21, times are UTC+01. +[[!format txt """ +22:58 <+Bart_Massey> Hey all. +22:59 <marcoz> hi Bart +22:59 <+alanc> hello +23:00 <+emmes> Hey all +23:00 <+Bart_Massey> OK, I think not too much to do today. alanc, any sign of stukreit? +23:01 <stukreit> i see me +23:01 <agd5f> hello +23:01 <+alanc> found him +23:02 <+Bart_Massey> Excellent! +23:02 <stukreit> loving the attention. more than my dog gives me these days. he's way old +23:03 <+alanc> stukreit: yes, I see the mail you sent on financials about half an hour ago +23:03 <+Bart_Massey> OK, the two big deals on which we must concentrate today. +23:03 <+Bart_Massey> alanc: Oh. Let me look. +23:04 <+alanc> sorry, didn't mean to derail your agenda +23:04 <+Bart_Massey> Did we really spend nothing on XDC last year? That's cool. +23:04 <+Bart_Massey> alanc: NP, first agenda item was getting reports out. :-) +23:04 <stukreit> yeah, I just added that to the notes +23:04 <+alanc> oh, then on target +23:04 <marcoz> infrastructure, I'm assuming that's servers and such? +23:04 <+Bart_Massey> So yeah. I cannot explain why I haven't posted my Report yet, but I will do it today. +23:05 <+Bart_Massey> And stukreit, it looks like you're in a position to write a brief note and send this spreadsheet, also today. Awesome. +23:05 <stukreit> I realize I owe Bart an air tick reimbursement. +23:05 <+Bart_Massey> The reason I am nagging is that if we don't get these reports out by the end of February, we are in violation of our Bylaws, which now that we're IRS 0wned would not be good. +23:06 <+Bart_Massey> stukreit: Would be nice, but absolutely no panic at all. +23:06 <+alanc> from the note at the bottom "infrastructure" seems to be more corporate fees/taxes +23:06 <stukreit> is it appropriate to give the entire spreadsheet? should there be more detail? I didn't list the names of evoc recipients, e.g. +23:06 <+Bart_Massey> I would definitely disclose the entire spreadsheet IMHO: I think we have nothing to hide, and want to be transparent. +23:06 <stukreit> yes. that's the column also for networking/caging fees, but we haven't seen a bill from MIT. Are our machines off? +23:06 <marcoz> ahh, duh ;) +23:06 <+Bart_Massey> I think we can make details available by request, for privacy reasons. +23:07 <+alanc> we were supposed to get out of MIT a year or two ago +23:07 <+Bart_Massey> AFAIK PSU is not charging, so if there's a charge for networking/caging I think it's from MIT. +23:07 <+Bart_Massey> alanc: Yes, we voted to kill MIT. +23:07 <+alanc> any reason for the ? on EVOC in Sept? +23:07 <stukreit> well, they've never found my address apparently, so if there's a final bill.. +23:08 <stukreit> alanc: I was intending to double check my checkbook register. I assumed that all even valued checks (multiples of $100 or more) were EVOC +23:08 <+Bart_Massey> Is PSU charging us for infrastructure? If so, I can perhaps fix that... +23:08 <stukreit> nobody sends me bills. ;-) +23:09 <+alanc> the only item in the "infrastructure" column is noted as "incorporation fee to NSAI" +23:09 <stukreit> not the same thing as saying there's no bill. Should I ask? +23:09 <+Bart_Massey> stukreit: I'd be fine with you not writing checks without documentation in hand describing the purpose, going forward :-). +23:09 <+Bart_Massey> alanc: Ah, good. +23:10 <+Bart_Massey> OK, so it looks to me like we're good on the Reports front. Anybody got anything else to add? +23:12 <+Bart_Massey> stukreit: Like I say, would be grateful if you'd add a paragraph or two before the spreadsheet giving an overview of our financial situation and making any commentary you deem appropriate :-). If you want to run this by the Board by email, we'll look at it. +23:12 <stukreit> ok, willdo +23:12 <+Bart_Massey> OK, second item: elections. This is getting urgent. Where are we? +23:12 <marcoz> i sent out an email just before the meeting detailing what I currently know +23:12 <+alanc> looks like our balance has finally fallen to the point where our bank fees going out are higher than the interest coming in +23:12 <marcoz> nomination window is open, 1/2 through +23:12 <marcoz> no nominiations received yet +23:13 <+Bart_Massey> alanc: Yes, once these two items are out of the way, fundraising is a next priority. +23:13 <+emmes> haven't received any test mail on elections@ yet, though. If anything was sent there, it might be sitting in /dev/null +23:13 <marcoz> are any/all of the current ones running for re-election? +23:14 <+Bart_Massey> marcoz: I missed the announcement on the nomination window :-(. Probably just email fail on my part. +23:14 <stukreit> I could apply again +23:14 <marcoz> i sent to annouces, xorg and xorg-devel. are there other lists I should post to? +23:14 <+Bart_Massey> marcoz: It is traditional for the Chair to nominate all the currently-expiring members to run again. I hereby officially nominate us :-). Is there anything I need to do? +23:14 <jcristau> haven't seen anything about elections on members@, is that just me? +23:15 <marcoz> Bart_Massey: good to know. :) I second the nominations +23:15 <+emmes> jcristau: ETOOMUCHMAIL lately. Can't say. +23:16 <+Bart_Massey> The only email I see was not sent to members@x.org ; just to announce and to xorg-devel AFAICT. +23:16 <marcoz> bah, i dind't send it to members, just those other 3 lists. :( +23:16 <marcoz> blast it. my bad +23:16 <+Bart_Massey> But maybe I'm not subscribed to members@? But I should be. +23:17 <+Bart_Massey> marcoz: Having made that mistake before myself, my condolences :-). +23:17 <+Bart_Massey> OK, so we need to extend the nominations window, probably, or someone will howl bloody murder. +23:17 <+Bart_Massey> (Based on past history.) +23:17 <marcoz> dammit, I've been trying to be on top of this. +23:18 <+Bart_Massey> marcoz: Please don't beat yourself up; these things happen with freakin' Elections. +23:18 <+Bart_Massey> Do add a note to the wiki, though, with the list of addresses to which things should be sent. +23:18 <+Bart_Massey> That way copy-and-paste will save us next time. +23:18 <+alanc> members should be autopopulated from the membership system, but we just purged something like 80% of members due to renewals +23:18 <+Bart_Massey> alanc: Yeah. +23:18 <+Bart_Massey> We should check that the email list matches the current membership. +23:19 <marcoz> grumble. ok, do we want to extend the window or leave as is and extend if someone does howl? +23:19 <+Bart_Massey> It's not impossible there's a bug. +23:19 <+Bart_Massey> I think we should just suck it up and extend the window. Others? +23:19 <+alanc> when is the window supposed to go until? +23:19 <marcoz> Mar 3 +23:20 <+Bart_Massey> I think we should set March 10 as the new deadline, and call it good. A week one way or the other doesn't make any difference at this point. +23:20 <+Bart_Massey> But I'm happy to be overruled. +23:21 <marcoz> will it matter? Honest question there, not trying to be a smartass. +23:21 <+Bart_Massey> marcoz: Will what matter? +23:21 <+alanc> not sure it matters, but I'm okay with extending it a week +23:21 <stukreit> my thought too. How about a mid-period announcement to the members, see if anybody wakes up/ +23:22 <marcoz> Bart_Massey: extending the window. +23:22 <+Bart_Massey> I just know that last time I forgot to post to members@, several people complained. IDK. +23:23 <marcoz> there's always someone who complains. +23:23 <marcoz> anyway, I'm cool either way +23:23 <+Bart_Massey> marcoz: I think it matters in that a bunch of members are very vocal and strong defenders of due process in these elections; IMHO it's better to get the process right than to try to slop through it. +23:24 <+Bart_Massey> OK, unless there's any dissent, lets push the window to March 10 and announce on members@ today. Make that a motion from me... +23:24 <stukreit> or to enlist them in doing some of the hard work of making elections go smoothly +23:24 <stukreit> +1 +23:25 <marcoz> +1 +23:25 <+emmes> +1 +23:25 <marcoz> Bart_Massey: (no slop intended. ) +23:25 <+Bart_Massey> marcoz: Again, we've saddled you with the ugliest job on the X.Org Board--one that I categorically refuse to do ever again. Don't feel bad. +23:26 <+alanc> +1 +23:26 <+Bart_Massey> OK, the other election issue: agd5f, anholt, marcoz: is there a solid plan for having the web stuff ready for a mid-March election? +23:27 <marcoz> talking with anholt, I believe that's in place. eric? +23:27 <+Bart_Massey> I'm not sure anholt is here today, but if he says it's in place I think we're good. +23:27 <marcoz> i still don't have access to anything, so I'm very reliant on others at this point. +23:28 <marcoz> my 'chair' doesn't have any legs. :) +23:28 <+Bart_Massey> marcoz: Yeah, we should probably fix that, too. Talk to sitewranglers or somebody to get you the right permissions there. +23:29 <marcoz> i've pinged site-wranglers and email tollef directly. +23:29 <marcoz> no luck so far. +23:29 <+alanc> or more likely anholt, since site-wranglers seemed non-responsive so far, and eric should have root +23:29 <+Bart_Massey> Yeah, anholt and keithp. +23:29 <marcoz> do we push membership appliation renewals back a week also? Mar 8 to Mar 15? +23:30 <marcoz> or is that independent? +23:30 <+Bart_Massey> marcoz: Yes, the whole process shifts a week. +23:30 <+emmes> certainly, I would say. +23:30 <+Bart_Massey> One last item for stukreit, before I forget: Do you know what filings we need with US IRS? Also, when does Delaware need to get paid again? +23:30 <stukreit> I must look into that. +23:31 <stukreit> I have a delaware bill around here somewhere +23:31 <marcoz> ok, I'm planning on just resending the same email with updated dates and a short note at the top explaining +23:31 <stukreit> found it +23:31 <+Bart_Massey> stukreit: Please don't miss paying the Delaware bill--it would be really awesome for us to not do so every year :-). +23:32 <stukreit> got it in front of me. will attempt electronic payment +23:32 <+Bart_Massey> And yes, please do talk SFLC about what we need to do. +23:33 <stukreit> ok yeah. +23:33 <+Bart_Massey> Alright, anything else? +23:35 <+Bart_Massey> Move to adjourn. Thanks all! +23:35 <+emmes> +1 +23:35 <stukreit> +1 +23:35 <marcoz> +1 +23:36 <agd5f> +1 +23:36 <+alanc> +1 +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/03-07.mdwn b/BoardOfDirectors/IrcLogs/2013/03-07.mdwn new file mode 100644 index 00000000..557e5d1d --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/03-07.mdwn @@ -0,0 +1,201 @@ + +Date is 2013-03-07, times are UTC+01. +[[!format txt """ +23:00 <+alanc> hello +23:00 <Bart_Massey> howdy! +23:00 <marcoz> heyo +23:01 <agd5f> hi +23:02 <+anholt> hi +23:02 <stukreit> hello +23:03 <Bart_Massey> Five of us, anyhow. Missing keithp, anholt. Who else? +23:04 <agd5f> Bart_Massey: anholt is here +23:04 <Bart_Massey> Oops. I fail reading comprehension forever +23:04 <+alanc> I saw stukreit in the hall earlier +23:04 <+alanc> oh, wait, I failed too +23:04 <stukreit> alan fails too +23:04 <Bart_Massey> OK, I guess that's everybody but keithp? +23:04 <Bart_Massey> Anyway, let's get started +23:05 <+anholt> marcoz: are you set up for accounts to get elections running? +23:05 <marcoz> i still have no access to anything. +23:06 <+anholt> so, I don't see email from you to sitewranglers, or a request on bugzilla +23:06 <marcoz> did you see the sitewranglers ticket? +23:06 <marcoz> sigh... +23:06 <+anholt> you also said something about "nabble", which confused me +23:06 <marcoz> what is the link I should be using? +23:07 <+anholt> freedesktop bugzilla? +23:07 <marcoz> specific URL please +23:07 <+anholt> https://bugs.freedesktop.org/ +23:07 <+alanc> every time I mail sitewranglers I get a moderation message - does someone drain the moderation queue regularly? +23:07 <+anholt> yes/no: drains, but extremely irregularly +23:08 * alanc is tempted to mail sitewranglers a "Told you so!" followup to my "please turn off wiki account creation" mail now that jrayhawk found part of the fd.o website problem is the 388 thousand moin accounts +23:09 <marcoz> product: freedesktop.org ? what component? +23:09 <Bart_Massey> alanc: 388K active wiki editors is *awesome*! Think of how they're improving our web presence!! +23:09 <+anholt> admin or new accounts -- I don't think anyone searches based on those +23:10 <+alanc> I'm not sure "503 Guru Meditation" really counts as an improvement, but it's about the same as the usefulness of some of our web pages +23:11 * Bart_Massey pauses for a moment of Guru Meditation +23:11 <agd5f> marcoz: http://www.freedesktop.org/wiki/AccountRequests you can probably use this as a template. just adjust the bug to request elections stuff +23:11 <Bart_Massey> I need to get in touch with jrayhawk again and we need to get our web infrastructure under control +23:12 <marcoz> ok, ticket submitted. +23:12 <+alanc> he and keithp were talking on #freedesktop earlier today +23:13 <marcoz> anholt: can you check if it's in the queue? +23:13 <Bart_Massey> Meanwhile: Does somebody want to send a response to Wayland Crowdsource person? It seems like the consensus of the Board is that this is something we don't really want to take on at this time? +23:13 <stukreit> do we need to vote on it? +23:14 <Bart_Massey> We can. Any discussion before I make a motion? +23:14 <agd5f> I don't remember the wayland crowd source request? what was it about? +23:14 <stukreit> i suppose the rejection is because it is beyond our scope and definition +23:14 <Bart_Massey> stukreit: I don't think so. +23:14 <stukreit> agd5f: email from late yesterday +23:14 <+alanc> it seems like if Wayland needed more paid programmers, Intel or someone could hire them +23:15 <Bart_Massey> I'm against it just because it's more Board work than I want to take on at a time when we have other things on our plate. +23:15 <+anholt> marcoz: for asking for an account, you probably need the other information on accountrequests, like ssh pubkey and account name +23:15 <+alanc> much easier for them to add more programmers than us becoming an employer and having to deal with payroll & other HR headaches +23:15 <Bart_Massey> I'm much more concerned with general X.Org Foundation funding, in particular, than funding for a specific project. +23:15 <stukreit> actually, link it to our bylaws: we are not an org about hiring programmers. we're an educational non profit +23:15 <Bart_Massey> Yes, we definitely have a policy of not hiring developers. +23:15 <stukreit> so that's the reason +23:15 <Bart_Massey> (Except students.) +23:16 <agd5f> Ah, I missed that one, reading now +23:16 <stukreit> evoc is not a real hiring. its an internship basically +23:16 <Bart_Massey> But we certainly are an org that could do Wayland fund-raising to be administered by some Wayland group. +23:16 <Bart_Massey> But as I said, if we're going to do fund-raising this year, IMHO it needs to be for plain ol' X. +23:17 <stukreit> so I see this as a way to put out our mission statement +23:17 <+alanc> could also link him to "The Mythical Man Month" - "adding more programmers to an already late project makes it even later" +23:17 <Bart_Massey> Move to politely decline the offer of help with crowdsourcing Wayland funding, due to perceived conflicts with the role of the Board. +1? +23:17 <stukreit> please, i'm serious. this can be an exercise in declaring our corporate position +23:18 <stukreit> +1 I'd like to work with whomever writes the note. I'm willing to start it. +23:18 <Bart_Massey> stukreit: Yes, I think we can make it clear what our position is in our response +23:18 <marcoz> which email is this? I'm not seeing one. +23:18 <+alanc> +1 +23:18 <+anholt> +1 +23:18 <agd5f> probably makes more sense to fund evoc wayland projects that some big wayland project +23:19 <agd5f> marcoz: subject "Would crowdfunding Wayland development make sense?" +23:19 <stukreit> the issue here is how we explain our rejection of his offer +23:19 <+alanc> "Would crowdfunding Wayland development make sense?" to board@x.org last night +23:20 <Bart_Massey> stukreit: If you would like to draft a response to him, emphasizing our position as a Board that we don't want to directly hire developers, that would be awesome... +23:20 <marcoz> Hmmm, nothing. Can one of you forward that to me? +23:21 <agd5f> marcoz: done +23:21 <marcoz> thanks, got it. +23:21 <stukreit> yes I'll do that. Does anyone here think that the premise of his letter is valid? ie. could it happen? +23:21 <Bart_Massey> stukreit: IDK. +23:22 <agd5f> realistically... no +23:22 <+anholt> seems quite unlikely +23:22 <stukreit> I guess wayland might be the wrong vehicle, because it already has much corporate sponsorship +23:22 <stukreit> And does anyone here take seriously the "threat" of Mir? +23:22 <Bart_Massey> On a related topic: Two things about the Ubuntu Y..er..Mir Window System announcement +23:22 <Bart_Massey> Yeah, me too +23:23 <Bart_Massey> So, two questions: What, if anything, do we want to say publicly as a Board about it? +23:23 <agd5f> it's not really our decision as the board to decide whether mir or wayland or something else is "better" +23:23 <Bart_Massey> agd5f: Wayland is something we have agreed is part of the X.Org umbrella; Mir definitely is not +23:23 <+alanc> the developer of FreeType has raised ~ $15k via crowdfunding, a far cry from a full time developer salary +23:23 <stukreit> not asking for adecision, just impressions of where things are going. +23:24 <+keithp> Bart_Massey: jrayhawk wants to meet tomorrow to talk about wikis +23:24 <+keithp> do you have time for breakfast? +23:24 <Bart_Massey> I would suggest we make a highly supportive and encouraging announcement re Mir. +23:24 <Bart_Massey> keithp: Yep let's do it +23:24 <stukreit> +1 +23:24 <agd5f> Bart_Massey: sure, but if mir suddenly took off and there was an evoc student that had a good mir proposal... +23:24 <Bart_Massey> Emphasize that we think that it would be fantastic if Canonical could replace X on desktop in 12 months. +23:25 <Bart_Massey> agd5f: All I meant is that we haven't yet taken a position on Mir. +23:25 <stukreit> save us all so much grief +23:25 <+alanc> amazing, astounding, unbelievable +23:25 <agd5f> right +23:25 * alanc stops just short of "utterly impossible" +23:25 <Bart_Massey> Given that Mir is a single-corporation effort, I don't think it's appropriate for us to be supporting it, but that's just my position... +23:26 <Bart_Massey> I'll draft a Mir announcement for the Board to review. +23:26 <stukreit> would be nice to get out infront of comments by some of our beloved bloggers. +23:26 <Bart_Massey> Second question: How does Mir impact our ability to raise funds for X.Org in the short term? +23:26 <Bart_Massey> Is it going to hurt us? Badly? +23:27 <stukreit> My management won't care. +23:27 <agd5f> probably not much in the short term +23:27 <stukreit> imho it doesn't matter +23:27 <Bart_Massey> Good. +23:27 <marcoz> how would it hurt? other than splitting already scarce resources. or is that what you are getting at? +23:27 <+alanc> would think most of our contributors wouldn't care that much - probably can't count on much from Canonical though, but I don't think they've ever given us cash +23:28 <Bart_Massey> marcoz: Sometimes companies want to fund "the next big thing" rather than "same ol same ol" +23:28 <Bart_Massey> Anyway, sounds like everyone is pretty sanguine. +23:28 <+anholt> I don't imagine many people seeing mir as the next big thing. +23:28 <Bart_Massey> Which is good, because I think that's the next big thing. +23:28 <stukreit> I'm not anticipating "hurt", I'm dreamily thinking about when I'll see "the year of the *nix desktop" +23:28 <Bart_Massey> Stabilizing X.Org funding, I mean +23:29 <Bart_Massey> stukreit: Sadly, I doubt we'll ever see another "year of the desktop", period :-) +23:29 <agd5f> I mean if mir took off, we could support it as well +23:29 <Bart_Massey> agd5f: I think only if it wasn't a totally Canonical-centric effort, though... +23:29 <stukreit> I've started nudging on my side. Keith was helping me wrestle Intel a few years ago, but it fizzled out. +23:29 <agd5f> sure. I mean if it took off and there were suddenly a lot of community developers behind it +23:30 <stukreit> We're all enjoying the year (month) of the smartphone, pad, and soon flexible screentop. +23:30 <Bart_Massey> So what I need everyone to do is to do what stukreit is doing: figure out where we're going to get money from. +23:30 <agd5f> basically developer interest leads us +23:30 <Bart_Massey> My goal is to get a recurring income of $25K-$50K for the Foundation +23:31 <Bart_Massey> This should about offset our current expenses, if I understand them right. +23:31 <agd5f> maybe get a donate button on the website for starters? +23:31 <stukreit> funding: one component is a totally optional request to the membership so we can have >50% individual donations +23:31 <Bart_Massey> agd5f: Yes, the dollar amount from the website donations will unlikely be large, but it's important for getting our individual donations for 501(c)3 and for letting people feel like they're participating +23:32 <Bart_Massey> stukreit: I think we only need 10%, no? +23:32 <stukreit> I don't remember, need to look it up. +23:32 <Bart_Massey> agd5f?: 10%, isn't it? +23:32 <agd5f> yeah, 10%, I was wrong last time +23:32 <Bart_Massey> OK, we're good. +23:32 <Bart_Massey> Does anyone have a contact at the Mozilla Corp they could approach? +23:33 <Bart_Massey> keithp: Are you better than me at asking Google for money? +23:33 <Bart_Massey> keithp: Can you poke at Intel again? +23:33 <Bart_Massey> What about AMD? Even NVidia? Smaller graphics companies? +23:34 <stukreit> How about LTSP. They should be concerned with our viability +23:34 <Bart_Massey> stukreit: I hate to try to take "secondary funds" from folks who are nonprofit already... +23:34 <Bart_Massey> Would prefer to get money from commercial sponsors directly +23:34 <+anholt> agreed +23:35 <stukreit> ok. then let's go down the corp. list. We have contacts in AMD (Bridgeman) and Nvidia (...i forgot.) +23:36 <+alanc> Andy & Aaron +23:36 <agd5f> I can try at AMD +23:36 <+alanc> also, agd5f for AMD +23:36 <stukreit> oh yeah, sorry +23:36 <Bart_Massey> What is signature authority for corps these days? $5K? +23:37 <+alanc> the corp I work for has sliding scales - each level up the org chart has higher spending authority +23:38 <Bart_Massey> I guess what I'm asking is vaguely "at what level of request is it now non-trivial, so we might as well ask for a lot?" +23:38 <Bart_Massey> Should we be looking for 5-7 commitments at $5K each, or 1-2 at $25K each? +23:38 <Bart_Massey> Or some combination of the two? +23:39 <stukreit> I used to pull $10/year from Sun, so I was thinking along those lines for Oracle. I mentioned that number to my mgr last week. +23:39 <agd5f> I'd say a combination +23:40 <Bart_Massey> OK! Well, I think it's not too early to say "let's get started". I will keep bugging all y'all every mtg (assuming I get re-elected) and we'll see how it goes. LMK if I can help in any way. +23:41 <Bart_Massey> My goal is to end the year with (a) at least as much money in the bank as we started with, and (b) a plan for maintaining that +23:41 <marcoz> Bart_Massey: speaking of reelection. elections needs your (updated) statement. +23:41 <Bart_Massey> marcoz: Yeah, I know. I'll try to get it in today. +23:41 <Bart_Massey> stukreit: Speaking of "the bank"... :-) +23:41 * alanc needs to send in mine too +23:41 <marcoz> thanks guys +23:42 <stukreit> we spent around $25k last year +23:42 <Bart_Massey> That's what I thought. What I was wondering about was progress changing banks... +23:42 <stukreit> I have 200 words blurb. guess I'll send it around. +23:42 <Bart_Massey> stukreit: Awesome. Please do. +23:43 <Bart_Massey> OK, one more item of business, at least. GSoC. Are we doing it? If so, who is taking point this time? +23:43 <stukreit> I feel like I oughta have about 10 questions to ask banks. Maybe fewer, but enough to get a solid takeaway. I fear talking to banks is like talking to the phone company. +23:44 <Bart_Massey> stukreit: Let's take that conversation offline. +23:44 <marcoz> (jic) i'll help with evoc, but my plate is too full for gsoc +23:44 <Bart_Massey> keithp: Can you summarize in an email for stukreit what we already know about banks? +23:45 <Bart_Massey> I really only want to do Portland State GSoC this year, so I'm out. (I've got big plans here...) +23:45 <agd5f> we could request gosc help from the membership +23:45 <Bart_Massey> Does somebody want to post to devel and see if any obviously-qualified non-Board-Members pop up? +23:45 <agd5f> see if anyone bites +23:46 * Bart_Massey jinxes agd5f +23:46 <agd5f> I'll email the xorg-devel list about it +23:46 <Bart_Massey> agd5f: Thanks! +23:46 <+alanc> marcheu has said he doesn't have time to do it again +23:47 <marcoz> yes, thanks agd5f +23:47 <+alanc> but after, what, 4 years, he deserves a break +23:47 <mupuf> sorry to pop in, but do we even have project ideas? +23:47 <Bart_Massey> Donnie Berkholz has done in the past; you might beg him, although I know he's crazy busy too +23:47 <+alanc> don't we also need to discuss XDC dates today? +23:47 <Bart_Massey> mupuf: We always have project ideas, but whoever take Org Admin will definitely have to build an epic Ideas Page this time... +23:47 <Bart_Massey> alanc: Yes, thanks! +23:49 <Bart_Massey> keithp: Are any of those dates out for you? Because if they are, given that you and I are doing local arrangements... +23:51 <Bart_Massey> It sounds like (d) 9/25-9/27 works the best for the most people. +23:51 <Bart_Massey> Any objections to that date? +23:52 <stukreit> can't get to calendar.. +23:52 <+anholt> looks great to me +23:52 <+alanc> that seemed to be the consensus in email +23:52 <agd5f> yeah +23:53 <Bart_Massey> OK, I am officially declaring that XDC 2013 will be 9/25-9/27 in Portland, Oregon USA. +23:53 <Bart_Massey> (Declaration subject to actually securing the space. Will try today.) +23:54 <Bart_Massey> We're past out of time. Any other emergency business? +23:54 <+alanc> none here +23:54 <Bart_Massey> Thanks all! See you in a couple of weeks! +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/IrcLogs/2013/03-21.mdwn b/BoardOfDirectors/IrcLogs/2013/03-21.mdwn new file mode 100644 index 00000000..af953b35 --- /dev/null +++ b/BoardOfDirectors/IrcLogs/2013/03-21.mdwn @@ -0,0 +1,117 @@ + +Date is 2013-03-21, times are UTC+02. +[[!format txt """ +22:00 <agd5f> hello +22:00 <+Bart_Massey> Hey all! +22:01 <marcoz> hi +22:02 <+alanc> hello +22:02 <+alanc> stuart just walked by and said he was logging in +22:03 <stukreit> hello +22:04 <+Bart_Massey> OK, I guess we'll get going and see who else shows... +22:05 <+alanc> looks like we're short keithp, anholt, and emmes? +22:05 <+Bart_Massey> Yep +22:05 <stukreit> bart, I don't know what we're gonna do without your engine of activity to help propel us along +22:05 <+Bart_Massey> Are "elections" on track? Has the voting been opened to the membership, and are votes being collected? +22:05 <+alanc> well, hopefully their irc clients just beeped or flashed at them to wake them up +22:06 <marcoz> yes, yes and yes +22:06 <+Bart_Massey> stukreit: Kind of you to say, but I think you'll be OK :-) +22:06 <+Bart_Massey> marcoz: Awesome. Thanks. +22:06 <+alanc> I saw mail telling me I can vote, but another member I asked hadn't seen it +22:06 <+alanc> of course, that could be a factor of the mail system, not the sender +22:06 <marcoz> did everyone here see the email? +22:06 <agd5f> yes +22:06 <+Bart_Massey> Let me check. +22:06 <agd5f> and I voted already +22:06 <+keithp> alanc: I'm around +22:07 <+Bart_Massey> Yeah, I saw it. +22:07 * keithp voted even +22:07 <marcoz> cool. +22:08 <+Bart_Massey> OK, second item: 501(c)3. Anything to report / do there? keithp, did you want to talk about the alt plan there? +22:08 <stukreit> Aaron made contact with the IRS, they will reply in more detail in 30 days, but basically, we have to re-gen the app materials and resubmit +22:08 <+keithp> Bart_Massey: the alternative would be to become an SPI affiliate project and use their 501(c) 3 status for new monies +22:09 <+keithp> keep our existing accounts intact, but route future charitable donations through SPI +22:09 <marcoz> pros? cons? +22:09 <+keithp> oddly, they have an accountant running their books and keeping filings up to date +22:09 <stukreit> would we be parking funds there and able to pull them across when this is straightened out? +22:09 <+Bart_Massey> stukreit: Is the application likely to be a multi-year process the second time? +22:10 <stukreit> Don't know. +22:10 <+keithp> stukreit: that's one option, the other would be to just remain a spi affiliate indefinitely +22:10 <stukreit> if it were possible to get the same IRS reviewers lined up, maybe that would expeedite. +22:10 <agd5f> It shouldn't take as long since we don't have to gather all the info for the application +22:10 <+Bart_Massey> The nice thing about the SPI plan, which we've discussed before, is that they would handle books, corporation, taxes, etc. +22:10 <agd5f> that's what dragged on last time +22:10 <+alanc> right, I thought it was only because of history that we were a separate corporation in the first place +22:11 <stukreit> that's true, the time it took for the final approval was short +22:11 <+Bart_Massey> agd5f: Yeah, our end should be quicker, but it took more than a year for IRS to respond IIRC? +22:11 <agd5f> Bart_Massey: I think their response was pretty quick. took us over a year to apply +22:11 <+Bart_Massey> 'k. +22:12 <stukreit> anyway, I'm on the hook to push this paper along. Hope to know more in a month or 2 what kind of time it will take +22:12 <+Bart_Massey> We don't have to settle this today, but if X.Org is going to go SPI, probably should decide soon to avoid the rework of filing again. +22:13 <+Bart_Massey> Let's all y'all take it to email to discuss, unless anybody has ideas or opinions or questions now? +22:14 <stukreit> we'll find out soon whether refiling consists of reading the docs once, updating to 2013, and stuffing an envelope again. It shouldn't be much harder than that +22:14 <agd5f> I'd rather be our own if we can do it +22:14 <+Bart_Massey> agd5f: How come? +22:14 <stukreit> I'll inform the board of each step/expense before taking any action +22:15 <agd5f> Bart_Massey: seems like a shame to forgo all the effort we put in. that said, I don't know much about spi +22:15 <+Bart_Massey> agd5f: Fair enough. +22:16 <+Bart_Massey> Any other discussion? +22:16 <+Bart_Massey> OK. Last thing; for some time now Karen Sandler has been urging us to take part in a Gnome Women's Outreach program they have going. +22:17 <+Bart_Massey> The deadline is next week or something now, so I told her I would bring it to our Board and we'd discuss. +22:17 <stukreit> got a pointer to explanation? How would we engage with it? +22:17 <+Bart_Massey> AFAICT, the immediate commitment would be for us to fund an EVoC-like slot for a Gnome Women Student position. +22:18 <+Bart_Massey> With said student to be supplied by them, as near as I can gather. +22:18 <+alanc> it sounds like it's an EVoC-like program, but targeted at increasing female involvement in open source communities, instead of student involvement +22:18 <agd5f> seems fine to me +22:18 <marcoz> yea +22:18 <+Bart_Massey> alanc: I think it's maybe female intersect student? +22:18 <+alanc> I don't remember that detail - think I sent a link to the board list a few months back +22:19 <+Bart_Massey> I think we can only fund students according to current policy, so we need to make that clear to them. +22:19 <+alanc> https://www.gnome.org/news/2013/01/25-women-in-10-free-software-organizations-for-gnomes-outreach-program-for-women/ +22:20 <+Bart_Massey> Let's do a formal motion. I move to fund a position for a female student in Gnome's outreach program. +22:20 <stukreit> +1 +22:20 <marcoz> would this be an X EVoC project? or X funding a gnome project? +22:20 <jcristau> "Unlike Google Summer of Code, the Outreach Program for Women is open to non-students and non-coders, so you should just apply for the Outreach Program for Women internship if you are either not a student or not a coder.", from https://live.gnome.org/OutreachProgramForWomen +22:21 <+alanc> https://live.gnome.org/OutreachProgramForWomen sounds like they don't necessarily restrict to students, though we may be able to do so for our slot +22:21 <+Bart_Massey> jcristau: Thanks +22:21 <+Bart_Massey> alanc: I think we have to be able to for our slot. +22:22 <+alanc> also says cost for 1 participant is $5,750 - $5,000 (USD) stipend, $500 travel allowance, and a small administrative fee for the GNOME Foundation. - which is in line with our normal EVoC costs +22:22 <+alanc> +1 for funding that +22:23 <marcoz> reads like evoc, just not coding specific. It mentions documenation and marketing so +1 from me. :) +22:24 <+Bart_Massey> We need one more +1 to carry, by my count... +22:24 <+keithp> Bart_Massey: restate as a motion to fund a women student? +22:24 <+Bart_Massey> keithp: I will restate as a motion to fund a woman student, with other details to be worked out later. +22:25 <+alanc> oh, and like EVoC, I think our funded slot should be open to work on X11, Mesa, Wayland, or other closely affiliated projects (they specify that people funding slots can decide which projects they are funding it for) +22:25 <+keithp> +1 for a women student then +22:25 <+Bart_Massey> alanc: I think someone needs to negotiate with Karen on how specific we can be. Can you or keithp call her? +22:27 <agd5f_> sorry, having issues here +22:27 <+Bart_Massey> I promised her someone would call her today or tomorrow. I can do it if no one else will, but it would be better to have someone who is continuing with the Board IMHO. +22:27 <+alanc> I'm traveling the rest of this week - I could do it next week, but not this week +22:28 <+alanc> can keithp do it this week? +22:29 <+keithp> I should have time tomorrow +22:29 <+Bart_Massey> Great! +22:29 <+Bart_Massey> I think that does it. Any other business? +22:29 <+keithp> Bart_Massey: breakfast tomorrow, then you'll remind me :-) +22:30 <agd5f_> I guess I'm going to fill out the GSoC application if anyone wants to help +22:30 <+Bart_Massey> keithp: Have to be downtown at 10, so if you want *early* breakfast... +22:30 <+keithp> harsh, dude +22:30 <+Bart_Massey> agd5f: What happened to our volunteer GSoC admin? +22:30 <+alanc> agd5f_: wasn't tom stellard helping with that, or just with the ideas page? +22:30 <agd5f_> Bart_Massey: he's moving this week and next +22:30 <+alanc> oh +22:31 <+Bart_Massey> Oh. Thanks for taking it, then! I'll help how I can--LMK. +22:31 <+Bart_Massey> Anything else? +22:32 <+Bart_Massey> OK. Move to adjourn. Been great working with all of you lo these many years. An honor and a privilege. +22:32 <stukreit> thanks for all your help, Bart! +22:32 <marcoz> Bart_Massey: it's been brief for me, but a pleasure. +22:32 <+alanc> you're still organizing an XDC, we won't let you escape talking to us that quickly +22:32 <+Bart_Massey> And it's not like I'm disappearing or anything--I'll try to keep helping. +22:32 <+Bart_Massey> alanc: Indeed. Among other things. +22:32 <+alanc> or at least co-organizing with idr, keithp, etal +22:32 <agd5f_> thanks Bart_Massey! +22:33 <marcoz> any swag this year? +22:33 <+Bart_Massey> Thank y'all! +22:33 <+alanc> thanks for all the work in the past years +22:33 <stukreit> Elvis has left the building, sniff +22:34 <marcoz> we actually have one more meeting before the new board members +22:34 <+alanc> well that'll be anticlimatic for Bart 8-) +"""]]
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries.mdwn b/BoardOfDirectors/MeetingSummaries.mdwn new file mode 100644 index 00000000..9060353f --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries.mdwn @@ -0,0 +1,9 @@ + +Summaries of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] Meetings are posted here. They were not posted, or only posted to the members.x.org site, for several years, before resuming in 2010. + +* [[2006|BoardOfDirectors/MeetingSummaries/2006]] +* [[2008|BoardOfDirectors/MeetingSummaries/2008]] +* [[2009|BoardOfDirectors/MeetingSummaries/2009]] +* [[2010|BoardOfDirectors/MeetingSummaries/2010]] +* [[2011|BoardOfDirectors/MeetingSummaries/2011]] +* [[2013|BoardOfDirectors/MeetingSummaries/2013]]
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2006.mdwn b/BoardOfDirectors/MeetingSummaries/2006.mdwn new file mode 100644 index 00000000..b4c91d06 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2006.mdwn @@ -0,0 +1,27 @@ + +Summaries of the Board of Director Meetings are posted here. + +* [[BodMeetingSummaries-01-10-2006|BodMeetingSummaries-01-10-2006]] +* [[BodMeetingSummaries-01-17-2006|BodMeetingSummaries-01-17-2006]] +* [[BodMeetingSummaries-01-24-2006|BodMeetingSummaries-01-24-2006]] +* [[BodMeetingSummaries-01-31-2006|BodMeetingSummaries-01-31-2006]] +* [[BodMeetingSummaries-02-14-2006|BodMeetingSummaries-02-14-2006]] +* [[BodMeetingSummaries-02-21-2006|BodMeetingSummaries-02-21-2006]] +* [[BodMeetingSummaries-02-28-2006|BodMeetingSummaries-02-28-2006]] +* [[BodMeetingSummaries-03-07-2006|BodMeetingSummaries-03-07-2006]] +* [[BodMeetingSummaries-03-14-2006|BodMeetingSummaries-03-14-2006]] +* [[BodMeetingSummaries-03-21-2006|BodMeetingSummaries-03-21-2006]] +* [[BodMeetingSummaries-04-11-2006|BodMeetingSummaries-04-11-2006]] +* [[BodMeetingSummaries-04-25-2006|BodMeetingSummaries-04-25-2006]] +* [[BodMeetingSummaries-05-16-2006|BodMeetingSummaries-05-16-2006]] +* [[BodMeetingSummaries-05-30-2006|BodMeetingSummaries-05-30-2006]] +* [[BodMeetingSummaries-07-14-2006|BodMeetingSummaries-07-14-2006]] +* [[BodMeetingSummaries-08-08-2006|BodMeetingSummaries-08-08-2006]] +* [[BodMeetingSummaries-08-15-2006|BodMeetingSummaries-08-15-2006]] +* [[BodMeetingSummaries-08-22-2006|BodMeetingSummaries-08-22-2006]] +* [[BodMeetingSummaries-08-29-2006|BodMeetingSummaries-08-29-2006]] +* [[BodMeetingSummaries-09-05-2006|BodMeetingSummaries-09-05-2006]] +* [[BodMeetingSummaries-09-26-2006|BodMeetingSummaries-09-26-2006]] +* [[BodMeetingSummaries-10-03-2006|BodMeetingSummaries-10-03-2006]] +* [[BodMeetingSummaries-10-10-2006|BodMeetingSummaries-10-10-2006]] +* [[BodMeetingSummaries-10-17-2006|BodMeetingSummaries-10-17-2006]]
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2008.mdwn b/BoardOfDirectors/MeetingSummaries/2008.mdwn new file mode 100644 index 00000000..64093131 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2008.mdwn @@ -0,0 +1,2 @@ + +Coming soon diff --git a/BoardOfDirectors/MeetingSummaries/2009.mdwn b/BoardOfDirectors/MeetingSummaries/2009.mdwn new file mode 100644 index 00000000..0ac1797f --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2009.mdwn @@ -0,0 +1,2 @@ + +Coming Soon. diff --git a/BoardOfDirectors/MeetingSummaries/2010.mdwn b/BoardOfDirectors/MeetingSummaries/2010.mdwn new file mode 100644 index 00000000..61949c9a --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010.mdwn @@ -0,0 +1,26 @@ + +Summaries of the 2010 meetings of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]]. +[[!table header="no" class="mointable" data=""" + 2010 | [[2011 >>|BoardOfDirectors/MeetingSummaries/2011]] +"""]] + +* [[March 2|BoardOfDirectors/MeetingSummaries/2010/03-02]] +* [[March 16|BoardOfDirectors/MeetingSummaries/2010/03-16]] +* [[March 30|BoardOfDirectors/MeetingSummaries/2010/03-30]] +* [[April 13|BoardOfDirectors/MeetingSummaries/2010/04-13]] +* [[April 27|BoardOfDirectors/MeetingSummaries/2010/04-27]] +* [[May 25|BoardOfDirectors/MeetingSummaries/2010/05-25]] +* [[June 22|BoardOfDirectors/MeetingSummaries/2010/06-22]] +* [[July 6|BoardOfDirectors/MeetingSummaries/2010/07-06]] +* [[July 20|BoardOfDirectors/MeetingSummaries/2010/07-20]] +* Aug. 3 - Meeting was canceled due to lack of quorum +* [[August 17|BoardOfDirectors/MeetingSummaries/2010/08-17]] +* [[August 31|BoardOfDirectors/MeetingSummaries/2010/08-31]] +* Sept 14 - Meeting skipped due to [[XDS2010|Events/XDS2010]] +* [[Sept. 28|BoardOfDirectors/MeetingSummaries/2010/09-28]] +* [[Oct. 11|BoardOfDirectors/MeetingSummaries/2010/10-11]] - Meetings moved from Tuesday to Monday +* [[Oct. 25|BoardOfDirectors/MeetingSummaries/2010/10-25]] +* [[Nov. 8|BoardOfDirectors/MeetingSummaries/2010/11-08]] +* [[Nov. 22|BoardOfDirectors/MeetingSummaries/2010/11-22]] +* [[Dec. 6|BoardOfDirectors/MeetingSummaries/2010/12-06]] +* [[Dec. 20|BoardOfDirectors/MeetingSummaries/2010/12-20]]
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2010/03-02.mdwn b/BoardOfDirectors/MeetingSummaries/2010/03-02.mdwn new file mode 100644 index 00000000..6ec110fd --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/03-02.mdwn @@ -0,0 +1,66 @@ + +Summary of the 02 March 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/03-02|BoardOfDirectors/IrcLogs/2010/03-02]]. + + +### Board Member Attendance + +Outgoing Members: + +* Adam Jackson: _Present_ +* Daniel Stone: _Present_ +* Carl Worth: _Absent_ +Ongoing Members: + +* Eric Anholt: _Present_ +* Donnie Berkholz: _Absent_ (sent apologies) +* Alan Coopersmith: _Present_ +* Matthieu Herrb: _Present_ +* Bart Massey: _Present_ +Incoming Members: + +* Alex Deucher: _Present_ +* Matthias Hopf: _Present_ +* Keith Packard: _Present_ + +### Discussion & Decisions + + +#### Changing of the Board: + +The outgoing board members were thanked profusely for their service to X.Org, and the new board members welcomed. Bart was thanked for his service as Board secretary. + + +#### Election of 2010 Officers: + +* Secretary: Alan Coopersmith was nominated and elected by a 6-0 vote. +* Treasurer: Stuart Kreitman, who has assisted Keith in the past, was nominated and elected by a 7-0 vote. + +#### Current State: + +To help bring the new members up to speed, Bart gave a recap of the current state of affairs: + +* Perhaps the most pressing item this year is to complete the never-ending "bank transition" and "corporate transition" bullet items. +* We also have some concerns we've been discussing around trademarks and logos and stuff that need to get resolved. +* There has been some talk of trying to review and potentially revise the Bylaws; it's been a while, and there are some places where they have diverged a bit from practice. +* Infrastructure and system administration is an ongoing concern. We've made some progress but there's still a lot to think about. System administration is expected to improve as tollef comes on board, thanks to support from Collabora. It would be nice to have an improved membership and voting web application in place before the next election. +(See the [[2010 State of the Foundation report|XorgFoundation/Reports/2010]] for further details.) + + +#### X.Org Mirrors: + +Bart raised a concern about the X.Org official mirrors list, as he occasionally receives mail from people asking permission to mirror. While the Board agreed no permission is needed to mirror binaries, and the MIT license gives the freedom to mirror at will, X.Org has maintained a list of recognized mirror sites on our web pages, and we have exercised control over adding new sites to that list. Discussion was held over what level of control X.Org should maintain - from whether we should be responsible for checking that mirrors are still active, up to date and with uncorrupted binaries, to just providing a world-editable wiki page with a "use at your own risk" disclaimer, or somewhere in between. No decision was reached, and members were asked to think on the issue for future discussion. + + +#### Meeting time: + +After discussion about possible adjustments to the meeting time, the Board agreed to leave the meetings at the same time, 2pm US/Pacific, since moving them earlier in the day would put them into early evening hours in Europe, where the European board members would be more likely to have conflicts in their social calendars. + + +#### Action items: + +New actions: + +* **Alan**: File freenode registration for #xorg IRC channels +* **Keith**: Contact Stuart to transfer Treasurer records and paperwork.
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2010/03-16.mdwn b/BoardOfDirectors/MeetingSummaries/2010/03-16.mdwn new file mode 100644 index 00000000..6ef8511e --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/03-16.mdwn @@ -0,0 +1,42 @@ + +Summary of the 16 March 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/03-16|BoardOfDirectors/IrcLogs/2010/03-16]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: none + +### Discussion & Decisions + + +#### 501(c) transition + +Bart reported the previous LLC has been dissolved, and the 501(c) formed. Bart informed the Software Freedom Law Center (the Foundation's legal counsel) that Alan is now secretary. The next steps are getting the treasurer transfer complete and getting some financial documents together that SFLC needs. Keith has the details and needs to provide them to Stuart. + + +#### Election Committee + +The Election Committee for next year will be Alex, Matthieu, Matthias, & Keith (the members not up for re-election). We ensured they have access to the system with the steps needed to run the election. + + +#### Google Summer of Code + +The board heartily thanked [[StephaneMarchesin|StephaneMarchesin]] for putting together this year's successful application for the GSoC program. Developers have posted [[project ideas|SummerOfCodeIdeas]], and Google will start accepting student applications March 29. + + +#### XDS 2010 Travel Sponorship + +[[PeterHutterer|PeterHutterer]] requested sponsorship for his travel to [[XDS 2010|Events/XDS2010]]. The board approved up to $3000 for travel from Australia to France and lodging in Toulouse. + + +### Action items: + +Existing actions: + +* **Alan**: File freenode registration for #xorg IRC channels + * Filed, awaiting response. +* **Keith**: Contact Stuart to transfer Treasurer records and paperwork. + * Stuart has checkbook and PDFs of recent bank statements.
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2010/03-30.mdwn b/BoardOfDirectors/MeetingSummaries/2010/03-30.mdwn new file mode 100644 index 00000000..cc964486 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/03-30.mdwn @@ -0,0 +1,50 @@ + +Summary of the 30 March 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/03-30|BoardOfDirectors/IrcLogs/2010/03-30]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Bart Massey, Keith Packard +* **Absent**: Matthias Hopf + +### Discussion & Decisions + + +#### Google Summer of Code + +Alan mentioned that X.Org had been officially accepted into GSoC, and that developers who can help mentor should contact [[StephaneMarchesin|StephaneMarchesin]] (marcheu on IRC), and that students should read the [[SummerOfCodeIdeas|SummerOfCodeIdeas]] wiki page for more information on applications and project ideas. + + +#### Trademark Registration + +Bart mentioned that he'd been working with a new volunteer named Matt Dew who's been really helpful looking into a couple of long-standing issues. The first of these is to register the name X.Org as a US Trademark. It would cost $750, but Bart recommended that we do this, just to prevent someone else doing it instead and us having to deal with it. No formal vote was taken, but the general consensus was that this sounded reasonable, and should be discussed with our counsel at the SFLC. + + +#### Domain Registration + +Bart and Matt have also been working to get the x.org domain name technical and admin contacts reassigned. They have contacted Leon Shiman, the current listed contact, and are awaiting his response. Alex agreed to help Matt work this issue. + + +#### Documentation + +The third item Bart reported on working with Matt was the library of X documents. They would like to see a central, managed document repo of some kind in the X.Org space (beyond the wiki). Discussion of the known problems with the X.Org documentation ensued, but no decisions were reached. + + +#### Mentoring + +Bart mentioned that beyond the GSoC program and X.Org's [[Endless Vacation of Code (EVoC)|XorgEVoC]] programs for mentoring students while they're paid to work on specific projects, it would be useful to have additional mentoring programs to pair experienced developers with new contributors. Past attempts were made at this, such as the xorg-mentors list, but have not been followed through. Bart would like to see Matt come to the [[XDS2010|Events/XDS2010]] this fall to talk about "getting started with X.Org" to help us figure out what the pain points are for new contributors. + + +### Action items: + +Existing actions: + +* **Alan**: File freenode registration for #xorg IRC channels + * Filed, awaiting response. +* **Keith**: Contact Stuart to transfer Treasurer records and paperwork. + * Stuart has checkbook and PDFs of recent bank statements. +New actions: + +* **Alan**: Contact SFLC to discuss trademark registration.
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2010/04-13.mdwn b/BoardOfDirectors/MeetingSummaries/2010/04-13.mdwn new file mode 100644 index 00000000..e8d69584 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/04-13.mdwn @@ -0,0 +1,27 @@ + +Summary of the 13 April 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/04-13|BoardOfDirectors/IrcLogs/2010/04-13]]. + + +### Board Member Attendance + +* **Present**: Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: Eric Anholt + +### Discussion & Decisions + + +#### Google Summer of Code + +[[StephaneMarchesin|StephaneMarchesin]] reported on the progress in student/project selection. + + +#### Domain Registration + +Alex asked who the desired contacts should be for the X.Org domain. Bart suggested SFLC for the administrative contact. The Freedesktop sitewranglers list was suggested for the technical contact, though a physical mailing address may be needed. + + +#### Hideki Hiura + +Alan reported the recent passing of Hideki Hiura, one of the original Xlib Input Method framework authors for [[X11R6|X11R6]], and one of the founders/chairs of openi18n.org/li18nux.org with the FSG. The Board asked Alan to express condolences to his family on behalf of X.Org. diff --git a/BoardOfDirectors/MeetingSummaries/2010/04-27.mdwn b/BoardOfDirectors/MeetingSummaries/2010/04-27.mdwn new file mode 100644 index 00000000..87d5a884 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/04-27.mdwn @@ -0,0 +1,29 @@ + +Summary of the 27 April 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/04-27|BoardOfDirectors/IrcLogs/2010/04-27]]. + + +### Board Member Attendance + +* **Present**: Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthias Hopf, Bart Massey +* **Absent**: Eric Anholt, Matthieu Herrb, Keith Packard + +### Discussion & Decisions + + +#### Google Summer of Code + +Alan mentioned that [[StephaneMarchesin|StephaneMarchesin]] had posted [[the list of accepted GSoC students for X.Org and their projects|http://lists.freedesktop.org/archives/xorg-devel/2010-April/007826.html]]. The projects cover not just the core X code base, but the wider X community, including Mesa, DRI, and XCB. The board members all thanked Stephane for his work in organizing this year and appreciate the efforts he put in. + +Students who are not involved in GSoC but have project proposals (including at other times than Google's traditional GSoC period) are encouraged to investigate the XorgEVoC program for funding from the [[X.Org Foundation|XorgFoundation]]. Mentors were reminded that students who successfully complete the GSoC program are traditionally funded by the board to attend the next developer conference, such as this year's [[XDS2010|Events/XDS2010]] to present on their projects and discuss their perspective as a new developer getting involved in X. + + +#### XDS 2010 + +Matthieu has posted more hotel and travel information to the [[XDS2010|Events/XDS2010]] wiki page. + + +#### Domain Registration + +Alex reported that he's contacted Leon & Karen, but has not yet gotten a response. diff --git a/BoardOfDirectors/MeetingSummaries/2010/05-25.mdwn b/BoardOfDirectors/MeetingSummaries/2010/05-25.mdwn new file mode 100644 index 00000000..2f16ddfd --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/05-25.mdwn @@ -0,0 +1,25 @@ + +Summary of the 25 May 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/05-25|BoardOfDirectors/IrcLogs/2010/05-25]]. + + +### Board Member Attendance + +* **Present**: Alan Coopersmith, Alex Deucher, Matthieu Herrb, Bart Massey, Keith Packard +* **Absent**: Eric Anholt, Matthias Hopf +* **Excused**: [[Donnie Berkholz|https://twitter.com/dberkholz/status/14724043051]] + +### Discussion & Decisions + + +#### XDS 2010 + +Matthieu asked about budget for a social event at XDS 2010. He attempted to find local sponsors, but has not found any. Intel & AMD were suggested as potential sponsors, Alex will check at AMD. Costs are estimated at €30 per person, with 22 people currently registered (though Matthieu is hoping to see 40 or so). + +Matthieu will send out a call for talks soon, as the schedule is currently empty. + + +#### Non-profit status paperwork + +Alex is working on the 1023 form for registering as a 501(c)(3) non-profit with the IRS, but needed some more information, which Bart supplied. diff --git a/BoardOfDirectors/MeetingSummaries/2010/06-22.mdwn b/BoardOfDirectors/MeetingSummaries/2010/06-22.mdwn new file mode 100644 index 00000000..1004d95a --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/06-22.mdwn @@ -0,0 +1,22 @@ + +Summary of the 22 June 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/06-22|BoardOfDirectors/IrcLogs/2010/06-22]]. + + +### Board Member Attendance + +* **Present**: Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, +* **Absent**: Eric Anholt, Donnie Berkholz, Keith Packard + +### Discussion & Decisions + + +#### 501(3)c Conversion + +Alex had no news to report on the progress. He is still gathering information needed for the form. Bart mentioned that we need to involve our SFLC contacts. + + +#### XDS 2010 + +Matthieu prepared a flier to solicit sponsorship for various activities during the conference, including refreshment breaks and evening social events. The Board agreed that the revised version was ready to be distributed to companies that may be willing to participate. (Contact Matthieu if you would like a copy of the flier to present to a potential sponsor.) diff --git a/BoardOfDirectors/MeetingSummaries/2010/07-06.mdwn b/BoardOfDirectors/MeetingSummaries/2010/07-06.mdwn new file mode 100644 index 00000000..049dcf25 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/07-06.mdwn @@ -0,0 +1,22 @@ + +Summary of the 6 July 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/07-06|BoardOfDirectors/IrcLogs/2010/07-06]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Bart Massey +* **Absent**: Matthieu Herrb, Matthias Hopf, Keith Packard + +### Discussion & Decisions + + +#### 501(3)c Conversion + +Alex reported on progress on the 501(3)c paperwork, and that he was meeting with Karen, our SFLC lawyer, the next day for discussion on the remaining work. Bart asked if the financial reports were done yet - Stuart was unable to attend, but relayed that he had no update. + + +#### Open Group license discussion + +Adam Jackson asked if we could approach The Open Group to request relicensing the X Test Suite suite from the original Artistic license to an OSI-approved license, to make it more acceptable to distros such as Fedora. Alan agreed to take the action item to discuss this with them. diff --git a/BoardOfDirectors/MeetingSummaries/2010/07-20.mdwn b/BoardOfDirectors/MeetingSummaries/2010/07-20.mdwn new file mode 100644 index 00000000..b2d52d39 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/07-20.mdwn @@ -0,0 +1,38 @@ + +Summary of the 20 July 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/07-20|BoardOfDirectors/IrcLogs/2010/07-20]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Keith Packard +* **Absent**: Bart Massey + +### Discussion & Decisions + + +#### 501(3)c Conversion + +Alex thanked the board members for providing the required information about themselves for the 501(c)3 paperwork and reported the IRS Form 1023 was almost done. Karen, our SFLC lawyer, sent him a draft to review, and they were scheduled to meet to discuss the next week. They are also looking into whether we owe back taxes or not. + + +#### XDS 2010 + +Matthieu asked if anyone had heard back from companies we'd asked to sponsor XDS events/refreshments - no one had anything concrete to report yet. (Contact Matthieu if you would like a copy of the flier to present to a potential sponsor or if you would like to be a sponsor.) + +Matthieu asked if the Board wanted to pick up the tab for the social event if no company steps forward. The estimated cost is EUR 1500 for 50 people, but only 33 people have signed up on the [[XDS 2010 Attendees List|Events/XDS2010/Attendees]], including 19 marked as "tentative". + + +#### Open Group licenses + +Alan mentioned that he had done some investigation into the Open Group licenses for the X Window System and the X Test Suite, including mail to past board members that went to the board mailing list, but had not yet contacted the Open Group itself. + + +#### MIT hosted machines + +Jim Gettys had asked the board via e-mail for space on an X.Org machine to store some old archived materials of the X Consortium. The board members all agreed that the resolution reached via e-mail to provide space on expo.x.org, one of the machines hosted at MIT was fine. + +This led to discussion of the MIT hosted machines. Eric asked about the status of backups for those machines - no one present was aware of backups being done, but many members agreed that it is important to have them backed up and reasonable to pay MIT for backups in addition to the other hosting services we pay them for. Keith reported that the past invoices covered rack space, power and bandwidth, but not backup. The question was raised of the value of continuing to host machines at both MIT & PSU. It was suggested that since we do little in the way of replication or failover between the two sites, having two sites is currently costing more overhead than the perceived benefits. Several of the machines hosted at MIT were donated to MIT for use by X.Org due to donor's restrictions on donating to educational institutions vs. industry groups, so could not be moved to PSU and would have to be given to MIT for their use, but those machines are now 5 years old or older. + +Since the meeting had gone past the hour, the board tabled the discussion of whether to keep or leave the MIT hosting for further thought and input via e-mail before the next meeting. diff --git a/BoardOfDirectors/MeetingSummaries/2010/08-17.mdwn b/BoardOfDirectors/MeetingSummaries/2010/08-17.mdwn new file mode 100644 index 00000000..0d3af1c4 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/08-17.mdwn @@ -0,0 +1,41 @@ + +Summary of the 17 August 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/08-17|BoardOfDirectors/IrcLogs/2010/08-17]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey +* **Absent**: Keith Packard + +### Discussion & Decisions + + +#### GSoC Hardware Reimbursement + +Matt Turner asked if the board could reimburse him for approximately $65 worth of video cards purchased for his Google Summer of Code project to add KMS support to the glint driver and document KMS in the process. The Board approved this request. + + +#### 501(3)c Conversion + +Alex is still gathering required information, delayed by the outage in board mail delivery. + + +#### XDS 2010 + +Intel has offered to donate funding to the foundation in support of XDS 2010. + +The board voted to use some of this funding to approve 4 travel sponsorship requests it had received. + + +#### X.Org logo + +It was brought to the board's attention that a Brazilian cable company is using a logo that looks remarkably similar to the X.Org logo (though better rendered). The board is unsure of the trademark status or ownership of the X.Org logo through the chain of X ownership since the X Consortium, and it was suggested that it may be time to create a new logo with clear ownership we can trademark. + +Bart suggested running a contest for a new logo design. Since none of the board members volunteered to organize this, Alan suggested this was an area we could ask for a community volunteer to organize. + + +#### SFLC contribution + +Bart raised the issue that the Software Freedom Law Center has done a lot of legal work on behalf of the Foundation, especially around getting our 501(c)3 conversion completed, and that while the board had previously agreed to make a donation to SFLC, it had never been made. A contributition in the range of $5000 - $10000 was discussed, but the issue was tabled for later discussion. diff --git a/BoardOfDirectors/MeetingSummaries/2010/08-31.mdwn b/BoardOfDirectors/MeetingSummaries/2010/08-31.mdwn new file mode 100644 index 00000000..adbef81c --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/08-31.mdwn @@ -0,0 +1,22 @@ + +Summary of the 31 August 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/08-31|BoardOfDirectors/IrcLogs/2010/08-31]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Keith Packard +* **Absent**: Matthias Hopf, Bart Massey + +### Discussion & Decisions + + +#### 501(3)c Conversion + +Stuart is meeting this week with Karen at SDLC to discuss the financial records required for the conversion. + + +#### XDS 2010 + +The $15,000 donation from Intel was discussed - there should be enough left over after the travel sponsorships to cover the social event as well since no further requests are pending. Matthieu continues to work on planning the program. diff --git a/BoardOfDirectors/MeetingSummaries/2010/09-28.mdwn b/BoardOfDirectors/MeetingSummaries/2010/09-28.mdwn new file mode 100644 index 00000000..f0c92c35 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/09-28.mdwn @@ -0,0 +1,32 @@ + +Summary of the 28 September 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/09-28|BoardOfDirectors/IrcLogs/2010/09-28]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb +* **Absent**: Matthias Hopf, Bart Massey, Keith Packard + +### Discussion & Decisions + + +#### Change of Meeting Schedule + +Bart & Keith now have conflicts with the 2pm Tuesday timeslot, but the same time on Monday works for all the board members, so we're moving 24 hours earlier, to 2pm US/Pacific on Mondays, starting October 11. + + +#### Mirrors + +Everyone agreed with updating the wiki to just tell mirror sites to add themselves to the wiki list of mirrors instead of contacting the board to update the wiki. (That's why it's a wiki!) + + +#### Elections + +The election committee (members who were just elected and not up for re-election this time) was reminded that they need to start working on the election calendar, following the instructions on the board wiki, which was unfortunately down at the time of the meeting. Eric pinged the freedesktop admins to look into it. + + +#### 501(3)c conversion + +Stuart is working on updating the financial reports with the XDS2010 spending & sponsorship information. The board agreed with the decision made during the informal meeting at XDS to pay our $25 Delaware annual corporation fee. diff --git a/BoardOfDirectors/MeetingSummaries/2010/10-11.mdwn b/BoardOfDirectors/MeetingSummaries/2010/10-11.mdwn new file mode 100644 index 00000000..535343bb --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/10-11.mdwn @@ -0,0 +1,27 @@ + +Summary of the 11 October 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/10-11|BoardOfDirectors/IrcLogs/2010/10-11]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Bart Massey, Keith Packard +* **Absent**: Matthieu Herrb, Matthias Hopf + +### Reports, Discussion & Decisions + + +#### Election Committee + +The election committee wiki is still down, so Eric sent a copy of last years instructions to the board, so that progress can continue while the wiki is fixed. [It was fixed shortly afterwards.] + + +#### Treasurer Status + +Stuart sent the replacement check for Matt's XDS sponsorship to Keith for cosigning. Alex is waiting for Stuart to provide the updated financial data for the 501(c)3 conversion that incorporates the XDS 2010 expenses and funding. + + +#### Logo replacement + +Matt Dew looked into some existing sites that provide infrastructure for design contests and provided information to the board. A discussion was held on whether a small payment was actually less incentive than no payment. So far no one seems to be passionate enough about replacing the logo to drive forward, so if no one comes forward, we may let the matter drop and stick with the existing one. diff --git a/BoardOfDirectors/MeetingSummaries/2010/10-25.mdwn b/BoardOfDirectors/MeetingSummaries/2010/10-25.mdwn new file mode 100644 index 00000000..a2c0394b --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/10-25.mdwn @@ -0,0 +1,32 @@ + +Summary of the 25 October 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/10-25|BoardOfDirectors/IrcLogs/2010/10-25]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: Matthieu Herrb + +### Reports, Discussion & Decisions + + +#### Google Code-In + +The Board discussed the Google Code-In program for High School students to do smaller open source tasks during the late November-early January timeframe. Donnie volunteered to submit the application to google, and Alan to set up a wiki page to collect task ideas. + + +#### Developer book sprint + +Bart suggested having a book sprint in conjunction with the XDC2011 to produce an X.Org New Developer Guide. The board agreed this sounded like a good thing to do, and Bart volunteered to work on planning. Stephane Marchesin offered a draft of the guide he's been working on for Writing Linux Graphics Drivers. + + +#### Elections + +The Election Committee wiki issues have been fixed and Alex will send a draft schedule to the committee for discussion. + + +#### XDC 2011 + +The board discussed the proposal Michael Larabel put forth for XDC 2011 in Chicago. No decisions were reached though. diff --git a/BoardOfDirectors/MeetingSummaries/2010/11-08.mdwn b/BoardOfDirectors/MeetingSummaries/2010/11-08.mdwn new file mode 100644 index 00000000..d142e6a2 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/11-08.mdwn @@ -0,0 +1,27 @@ + +Summary of the 8 November 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/11-08|BoardOfDirectors/IrcLogs/2010/11-08]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthias Hopf, Bart Massey +* **Absent**: Matthieu Herrb, Keith Packard + +### Reports, Discussion & Decisions + + +#### Google Code-In + +X.Org was not one of the projects Google selected for the Code-In program - they accepted less than 1/7th the number from the recent Summer of Code. + + +#### Treasurer Status + +Stuart is working on gathering details for outstanding checks, and is sending the check for the Delaware Corporate Franchise fee to Keith for cosigning. + + +#### Election Committee + +Alex asked the election committee members to respond to his proposed election schedule e-mail. diff --git a/BoardOfDirectors/MeetingSummaries/2010/11-22.mdwn b/BoardOfDirectors/MeetingSummaries/2010/11-22.mdwn new file mode 100644 index 00000000..f1f2418f --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/11-22.mdwn @@ -0,0 +1,22 @@ + +Summary of the 22 November 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/11-22|BoardOfDirectors/IrcLogs/2010/11-22]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf +* **Absent**: Donnie Berkholz, Bart Massey, Keith Packard + +### Reports, Discussion & Decisions + + +#### Treasurer Status + +Stuart sent the last rollup of expenditures to Keith, and is waiting for confirmation from him that its complete, before sending on to the lawyer for the 501(c)3 paperwork. He also sent the $25 check for the Delaware corporate franchise fee to Keith for co-signing. + + +#### Election Committee + +Alex asked the election committee members to respond to his proposed election schedule e-mail. diff --git a/BoardOfDirectors/MeetingSummaries/2010/12-06.mdwn b/BoardOfDirectors/MeetingSummaries/2010/12-06.mdwn new file mode 100644 index 00000000..ecd87c9d --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/12-06.mdwn @@ -0,0 +1,36 @@ + +Summary of the 6 December 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/12-06|BoardOfDirectors/IrcLogs/2010/12-06]]. + + +### Board Member Attendance + +* **Present**: Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb +* **Absent**: Eric Anholt, Matthias Hopf, Bart Massey, Keith Packard + +### Reports, Discussion & Decisions + + +#### Delaware Corporate Franchise Fee + +The state of Delaware will only accept payment via credit card or ECH, so Alex will pay on his card, and have Stuart & Keith reimburse him via check from X.Org. + + +#### Treasurer Status + +Stuart is continuing to have troubles getting our account information from HSBC, thus cannot confirm we received Intel's contribution for XDS2010, nor provide the financial data needed for the 501(c)3 paperwork. + + +#### Election Committee + +Alex again asked the election committee members to respond to his proposed election schedule e-mail. + + +#### System Administration and Git Repository Vandalism + +There was general discussion of what the Board could and should do, both in the aftermath of specific recent events, and in terms of setting general policy and direction to prevent future events. + +Matthieu suggested we clarify on the wiki the split of responsibility and authority between X.Org and freedesktop.org. Stuart reported we paid $3000 this year for hosting fees for the machines X.Org has placed at MIT. Alan noted that the freedesktop.org system admins have been managing these as well for us. + +Alan brought up the possibility of adopting of a code of conduct (like [[Ubuntu|http://www.ubuntu.com/community/conduct]] & other projects have) or a statement of respect (like [[Jono Bacon's recent efforts|http://openrespect.org/]]) to formalize that trying to piss off other developers is not something our developers should be doing. There were also questions about whether there should be any link between X.Org commit access and X.Org Foundation Membership. Stuart suggested an "Access Czar" who could be a single point to determine when abuse requires privileges be removed and to handle the backlog of requests for commit access. Since half the board was missing, and time ran out on the meeting, the issue was tabled for members to think about and discuss again later. diff --git a/BoardOfDirectors/MeetingSummaries/2010/12-20.mdwn b/BoardOfDirectors/MeetingSummaries/2010/12-20.mdwn new file mode 100644 index 00000000..b13cc64e --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2010/12-20.mdwn @@ -0,0 +1,28 @@ + +Summary of the 20 December 2010 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2010/12-20|BoardOfDirectors/IrcLogs/2010/12-20]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: Donnie Berkholz + +### Reports, Discussion & Decisions + + +#### Election Committee + +Alex's proposed schedule was approved by the election committee, and the elections mailing list was updated today to reach the correct set of members. Alex volunteered to chair the committee and handle the mailing of announcements. Matthias is working on preparing the database for the voting software. + + +#### Treasurer Status + +Alex asked about the 5 years of financial data needed for 501(c)3 paperwork. Stuart still has not received the electronic dongle to access our accounts online, so has not been able to complete it. Keith reported that even with access, he can only access the last year online. + +Alex raised the issue of needing a fixed postal address for this paperwork. After discussion about logistics of renting a PO Box somewhere, Stuart volunteered his home address for a 5 year period. + +Alex reported he had paid $50 for the Delaware Corporate Franchise Fees for 2009 & 2010. Stuart said he'd write the check to reimburse Alex and forward to Keith for cosigning. + +Stephane Marchesin asked if the Google funding for Summer of Code Mentor Summit travel had arrived so that the mentors could be reimbursed. Since Stuart could not check the accounts electronically, Alan suggested the Foundation just go ahead and reimburse the mentors, since the Foundation can better afford to wait for funds to arrive than the individual mentors can. diff --git a/BoardOfDirectors/MeetingSummaries/2011.mdwn b/BoardOfDirectors/MeetingSummaries/2011.mdwn new file mode 100644 index 00000000..71e70076 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011.mdwn @@ -0,0 +1,13 @@ + +Summaries of the 2011 meetings of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]]. +[[!table header="no" class="mointable" data=""" + [[<< 2010|BoardOfDirectors/MeetingSummaries/2010]] | 2011 +"""]] + +* [[Jan. 3|BoardOfDirectors/MeetingSummaries/2011/01-03]] +* Jan. 17 - canceled (US holiday: Martin Luther King, Jr. Day) +* [[Jan. 31|BoardOfDirectors/MeetingSummaries/2011/01-31]] +* [[Feb. 14|BoardOfDirectors/MeetingSummaries/2011/02-14]] +* [[Feb. 28|BoardOfDirectors/MeetingSummaries/2011/02-28]] +* [[Mar. 14|BoardOfDirectors/MeetingSummaries/2011/03-14]] +* Mar. 28
\ No newline at end of file diff --git a/BoardOfDirectors/MeetingSummaries/2011/01-03.mdwn b/BoardOfDirectors/MeetingSummaries/2011/01-03.mdwn new file mode 100644 index 00000000..96107225 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011/01-03.mdwn @@ -0,0 +1,24 @@ + +Summary of the 3 January 2011 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2011/01-03|BoardOfDirectors/IrcLogs/2011/01-03]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey +* **Absent**: Keith Packard + +### Reports, Discussion & Decisions + + +#### Election Committee + +Alex reported the election committee was on track to send out the election notices to the membership on January 10. Eric reported the queue of membership applications had been taken care of. + + +#### Treasurer Status + +Stuart reported that Keith is going to work with the Portland HSBC branch to get Stuart the required access so he can work on the 5 year financial statements for 501(c)3 paperwork and other pending issues. + +The Board voted to go ahead and reimburse Donnie and Corbin for their travel expenses to the Google Summer of Code Mentor Summit without waiting for Google's check to the Foundation to clear first. diff --git a/BoardOfDirectors/MeetingSummaries/2011/01-31.mdwn b/BoardOfDirectors/MeetingSummaries/2011/01-31.mdwn new file mode 100644 index 00000000..f0821d6a --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011/01-31.mdwn @@ -0,0 +1,42 @@ +[[!table header="no" class="mointable" data=""" + [[<< 03 January|BoardOfDirectors/MeetingSummaries/2011/01-03]] | **31 January** | [[14 February >>|BoardOfDirectors/MeetingSummaries/2011/02-14]] +"""]] + +Summary of the 31 January 2011 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2011/01-31|BoardOfDirectors/IrcLogs/2011/01-31]]. + + +### Board Member Attendance + +* **Present**: Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: Eric Anholt + +### Reports, Discussion & Decisions + + +#### Election Committee + +The election committee members reported that only 2 members had accepted nominations so far for the 4 open slots, with only 1.5 hours left until the deadline. The committee members voted to extend the deadline by another week. + + +#### Treasurer Status + +Stuart reported he got the package from Keith with the necessary paperwork for updating the bank account access, and that most of the checks were sent out. + +Discussion was held on changing the checking account from requiring two signatures per check to only requiring one. The bylaws currently require two, which led into... + + +#### Bylaw Amendments + +Bart brought up that our Bylaws need amending for various issues, such as the check signing requirements. Since this requires a vote of the members, it would be convenient to include in the upcoming election. Matthias agreed to ask Egbert if he still has the original editable document, instead of just the PDF posted on the web site. Alex will check his notes from discussions with SFLC lawyers to see if there was anything we needed to change for the 501(c)3 conversion. + + +#### SFLC Donation + +Bart asked if we'd ever sent a donation to SFLC as discussed multiple times. Stuart said he'd never gotten told an amount to send. Alan will check the previous minutes for the decision. + + +#### Google Summer of Code + +Google announced GSoC 2011 at LCA last week. Stephane Marchesin agreed to be the project administrator for X.Org again this year, and will submit our application when the group applications open. diff --git a/BoardOfDirectors/MeetingSummaries/2011/02-14.mdwn b/BoardOfDirectors/MeetingSummaries/2011/02-14.mdwn new file mode 100644 index 00000000..e8252265 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011/02-14.mdwn @@ -0,0 +1,44 @@ +[[!table header="no" class="mointable" data=""" + [[<< 31 January|BoardOfDirectors/MeetingSummaries/2011/01-31]] | **14 February** | [[28 February >>|BoardOfDirectors/MeetingSummaries/2011/02-28]] +"""]] + +Summary of the 14 February 2011 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2011/02-14|BoardOfDirectors/IrcLogs/2011/02-14]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Bart Massey +* **Absent**: Matthias Hopf, Keith Packard + +### Reports, Discussion & Decisions + + +#### Election Committee + +The final slate of 6 candidates was posted to the members mailing list. + + +#### Treasurer Status + +Stuart reported that HSBC is processing the paperwork to get him the electronic security device to access the accounts online. + + +#### Bylaw Amendments + +The board members agreed it was too late to try to get bylaw amendments in for this election, and that we should continue working to determine what to change for a future vote. + +Raising the per-company limit from 2 members to 3 was suggested for consideration in the bylaw amendments, as that still keeps any company from having a majority of board members. + + +#### SFLC Donation + +Search of the past minutes found discussion of SFLC donations but no vote on an actual donation amount. Donnie suggested an initial donation of $7500, and an ongoing annual pledge of $2000. The board unanimously voted in favor. + + +#### X.Org Machine hosting at MIT + +Freedesktop.org is getting new hardware and has offered to transfer the services from expo.x.org, which is currently hosted at MIT, to a virtual machine on one of their new systems. This would allow the Foundation to stop paying MIT for hosting of aging hardware systems. + +The board voted to accept this offer. diff --git a/BoardOfDirectors/MeetingSummaries/2011/02-28.mdwn b/BoardOfDirectors/MeetingSummaries/2011/02-28.mdwn new file mode 100644 index 00000000..ef6b9159 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011/02-28.mdwn @@ -0,0 +1,27 @@ +[[!table header="no" class="mointable" data=""" + [[<< 14 February|BoardOfDirectors/MeetingSummaries/2011/02-14]] | **28 February** | [[14 March >>|BoardOfDirectors/MeetingSummaries/2011/03-14]] +"""]] + +Summary of the 28 February 2011 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2011/02-28|BoardOfDirectors/IrcLogs/2011/02-28]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz, Alan Coopersmith, Alex Deucher, Matthieu Herrb, Matthias Hopf, Bart Massey, Keith Packard +* **Absent**: + +### Reports, Discussion & Decisions + + +#### Election Committee + +Elections are almost complete, with voting closing 2 hours after the meeting started. There were no major issues to report, and mixed response to the candidate Q & A. Bart suggested investigating alternative voting software before next years election. + + +#### Treasurer Status + +Stuart has received the security device and have setup web access with HSBC, and is working with HSBC to transfer the Foundation account from the New York branch to the Palo Alto branch, so that he can take care of items that HSBC requires a person to visit the branch for, such as getting the 5 years of past statements for the 501(c)3 forms. + +Bart asked if our SFLC donation check had been sent yet and Stuart said he would take care of it. diff --git a/BoardOfDirectors/MeetingSummaries/2011/03-14.mdwn b/BoardOfDirectors/MeetingSummaries/2011/03-14.mdwn new file mode 100644 index 00000000..512ecf46 --- /dev/null +++ b/BoardOfDirectors/MeetingSummaries/2011/03-14.mdwn @@ -0,0 +1,77 @@ +[[!table header="no" class="mointable" data=""" + [[<< 28 February|BoardOfDirectors/MeetingSummaries/2011/02-28]] | **14 March** | [[28 March >>|BoardOfDirectors/MeetingSummaries/2011/03-28]] +"""]] + +Summary of the 14 March 2011 meeting of the [[X.Org Foundation|XorgFoundation]] [[Board of Directors|BoardOfDirectors]] + +Full IRC meeting logs are posted at [[BoardOfDirectors/IrcLogs/2011/03-14|BoardOfDirectors/IrcLogs/2011/03-14]]. + + +### Board Member Attendance + +* **Present**: Eric Anholt, Donnie Berkholz (outgoing), Alan Coopersmith, Alex Deucher, Matthieu Herrb, Bart Massey +* **Absent**: Matthias Hopf, Keith Packard, Stuart Kreitman (incoming) + +### Reports, Discussion & Decisions + + +#### Elections + +Results were posted to the members mailing list last week: + + +[[!format txt """ + Alan Coopersmith 130 Oracle + Bart Massey 84 Portland State University + Stuart Kreitman 81 Oracle + Eric Anholt 61 Intel + + Tiago Vignatti 56 Nokia + Carl Worth 26 Intel + + Thus, the four officers that will join the Board for two-year terms starting in 2011 are Alan Coopersmith, Bart Massey, Stuart Kreitman, and Eric Anholt. +"""]] + +#### Treasurer Status + +Stuart submitted a report by e-mail before the meeting since he was unable to attend: + + +[[!format txt """ + I visited my local HSBC branch to inquire about moving the + accounts there and about getting the 3 years of transaction data. + + Now that I have the authority to request the statement data, it is + on its way. For security reasons (!?) hsbc insists on sending + paper copies only, at a cost of $5 per requested statement. I + asked them to send the 2 preceding years because I have downloaded + this past year from online. It also occured to me late that Keith + sent me a pile of statements electronically, so I will try to + reduce the number of paper copies made to the minimum. + + In order to move the accounts, I have to actually open new account + numbers, and that process requires the participation of the branch + manager, who is presently out of country. I won't start this until + after the statement reporting work is finished. +"""]] +Alex pointed out that the deadline for submitting the information to the IRS was coming up very soon (possibly within a month). + + +#### Secretary and Treasurer selection + +The board members discussed re-appointing Alan as Secretary and Stuart as Treasurer for another term, but there was not enough quorum for voting, so it was tabled until the next meeting. + + +#### Meeting Times + +The board will hold an e-mail discussion to determine if the meeting times should change to better fit the member's schedules. + + +#### Corporate Sponsorship for Development + +The board discussed a recent inquiry by a company of sponsoring a developer, similar to GSoC or EVoC, to write code for a feature they desired. The board members seemed to agree that it was reasonable to consider, as long as the sponsor is clear that doing so does not guarantee integration into the master code base, since it would need to undergo the same technical review and acceptance as any other contributed code. + + +#### XDC 2011 + +Bart asked if we have a date and venue for XDC 2011 yet. The only proposal so far was received from Michael Larabel to hold it in Chicago. The board agreed to put out a call for volunteers to organize the conference. diff --git a/BodMeetingSummaries-01-10-2006.mdwn b/BodMeetingSummaries-01-10-2006.mdwn new file mode 100644 index 00000000..7d1fd849 --- /dev/null +++ b/BodMeetingSummaries-01-10-2006.mdwn @@ -0,0 +1,45 @@ + + +[[!format txt """ +Summary of the BoD meeting Jan 10, 2006: + +Present Stuart Kreitman, Jim McQuillan, Kevin Martin, Stuart Anderson, + Leon Shiman, Egbert Eich + +Topics discussed: +- Management + * note taking + * system administration +- Budget + +Details: +* Note taking: we will continue to collect notes taken by board + members. + + Leon offered to create edited notes. + + Egbert offered to create a summary from notes he took. + Use these as a basis for decision on the format for publication +* System administration + + The question was raised if the organization needs somebody hired to + do system administration and possibly share this person with other + OS projects (idea from last year's XDevConf) + + Stuart Anderson offerd to continue to do this for us pro bono + which would require that he is allowed to do it his way without + major interference from others to keep the burdeon on him low. + + For backup and emergency he will give the root passwords to other + board members. + + Stuart would also be happy to take requests to improve things like the + web site according to ideas from our community provided he is + given the time to look around for the best existing software solution. +* Budget + + Discussion form previous week was continued and closed. + + People agreed that we don't have to make provisions for paid management + tasks as yet as current proposal leaves enough room to add these as + discretionary items. + + Egbert Eich agreed to provide insight into the data that he used for + his estimates. + + He will also turn the budget into a publishable form adding the minor + modifications discussed and circulate this to the board for apporval. + + A consensus exists that we need to work with the community to see + which events interesting for X.Org exist that we can use our funds for. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-01-17-2006.mdwn b/BodMeetingSummaries-01-17-2006.mdwn new file mode 100644 index 00000000..afab2d0f --- /dev/null +++ b/BodMeetingSummaries-01-17-2006.mdwn @@ -0,0 +1,67 @@ + + +[[!format txt """ +Summary of board telecon Jan 17, 2006. + +Attendees: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) (joined later) +Egbert Eich (EE) + +Subjects: +- Publication of conference summary +- Board meeting with sponsors +- How to deal with travel funding requests +- Conferences: + California + FOSDEM +- BoD travel expenses + +1. Conference Summaries + + The board decided to publish the summary of the Jan 10, 2006 + confcall as prepared by EE on the x.org wiki. + + Page needs to be write protected. SA created the BoD group to + be able to restrict write access to the board. + + BoD minutes can be linked to http://wiki.x.org/wiki/BodMinutes + +2. Board sponsor meeting. + + The XDevConf2006 in California provides a good opportunity to meet + with the sponsors. + + The board will have a face to face meeting on Tuesday, Feb 7, 2006 + in San Jose, California. + + It was decided to hold the Sponsors-BoD meeting on Thursday, Feb 9, 2006 + from 7:30 - (apporximately) 10:00 AM. + + SK will organize a meeting room in the building where the conference + will take place. + + The first talk on this day will be scheduled for 10:00 AM to give + the sponsors and BoD members the opportunity to attend all talks. + +3. Funding Request + + The board has received a request for travel funding to XDevConf + from Dave Airlie. Dave will give a presentation at the conference. + + Funding this in full would require us to spend 1/5 of our budget + set aside for this purpose. + + LS will communicating with Airlie regarding air fare and other costs + + LS reported that a group of X contributors at the GPLv3 meetings + confirmed that a strong policy providing travel support for meeting + participation was important. + + + LS will look for an inexpensive flight opportunity. + + SK will look for an opportunity to get additional funding + from SUN. + + SK will look for inexpensive accomodation. + +4. Conferences + + SK will investigate opportunities to get local people involved in + providing a better infrastructure for conference attendees. + + Information about the FOSDEM meeting were exchanged. + SK is interested in attending. + +5. BoD Travel Expenses + + LS requires funding for travel to attend the BoD meeting. + + It was confirmed that BoD members who don't have other sources + of funding can request support from the budget set aside for this. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-01-24-2006.mdwn b/BodMeetingSummaries-01-24-2006.mdwn new file mode 100644 index 00000000..fe736f77 --- /dev/null +++ b/BodMeetingSummaries-01-24-2006.mdwn @@ -0,0 +1,75 @@ + + +[[!format txt """ +Board Meeting 01-24-06 + +Attendees: +Stuart Kreitman (SK) +Leon Shiman (LS) +Jim McQuillan (JM) +KM Kevin Martin (KM) +Stuart Anderson (SA) +Egbert Eich (EE) + +Topics: +- Minutes/Summaries +- Travel funding +- Agenda for f2f board board+sponors meeting in California +- Conferences + +* Minutes/Summaries + - LS circulated minutes of last meeting to the BoD on Monday, 01-23-06. + They will be approved unless somebody objects by email. + - Summaries on BoD meetings for publication: + Focus on topics discussed, results and action items assigned. + EE has circulated draft of summary on 01-17-06 and will continue + to do so for future meetings. + Responsibilities of the secretary: + . take and circulate minutes of calls. + . make sure summaries are published. + +* Travel funding + - LS has worked with Dave Airlie on finding inexpensive transportation + opportuinites. Dave agreed to cover some of his costs himself. + Based on available transportation rates LS and Dave agreed that + X.Org will fund USD 1300. + Board members will work on finding a room sharing opportunity for Dave. + LS will add to agenda for follow up meeting: policy for travel funding + for future events. + +* Agenda for BoD face to face meeting at XDevConf2006 + a. Treasurer + Board decided that dependent on the issue if participation of + the treasurer is required a meeting with him will be arranged. + LS will therefore make up a list of issues to be discussed. + b. Rewrite of the bylaws. + - Proposals for organizational changes have been made which have + not been drafted in words yet. + - Architecture WG should be removed from the bylaws. + (The architecture board is still in place but not acting any more + as board members have agreed to assign the responsibilities to the + architecture working group.) + - Draft should be in time for the upcoming election for the members to + vote on. + c. Define role of the sponsors group. Some confusion about the role of + the sponsors seems to exist. + LS will collect and circulate further items/details. + +* Agenda for BoD - sponsor group meeting at XDevConf2006 + - Final agenda may depend on the outcome of the board f2f meeting. + - Some topics may require discussion with/feedback from the sponsors. + - LS will circulate preliminary list of topics together with the + BoD meeting topics to the board. + +* Conferences + + XDevConf + - Everybody should provide a short abstract for talk. + - People should also provide slides for proceedings on the web. + - SK will prepare preliminary talk schedule. Can be modified according + to requirements. + + Socal Linux Expo in LA, Californa Feb. 11-12 + - SK will attend and organize booth. + - LS will provide booth material. + - Others are welcome to join in booth activeties. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-01-31-2006.mdwn b/BodMeetingSummaries-01-31-2006.mdwn new file mode 100644 index 00000000..fb48636e --- /dev/null +++ b/BodMeetingSummaries-01-31-2006.mdwn @@ -0,0 +1,58 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon Jan 31, 2006 + +Present: +Leon Shiman (LS) +Jim Gettys (JG) +Jim McQuillan (JQ) +Stuart Kreitman (SK) +Stuart Anderson (SA) +Kevin Martin (KM) +Egbert Eich (EE) + +Agenda: +1. Minutes +2. Reimbursement requests for BoD travel +3. Expenses for LA show +4. Schedule and agenda review of f2f meetings +5. Should X.Org issue a statement on the software licensing + policy discussions presently going on? +6. Organizational issues regarding XDevConf. +7. SK FOSDEM travel funding +8. Reports on possible sponsoring opportunity + +1. Minutes + The minutes taken by LS are for internal use by the BoD. LS tries to + capture the conversation as close as possible and post them to the + BoD for review. He is asked to reword emotionally charged statements + such that they still capture the meaning without conveying the emotion + when requested. +2. BoD travel + SA asks for funding for accomodation. He will be sharing with LS and + Dave Airlie. BoD travel expenses have been budgeted. No objections. +3. Expenses for LA show + SK asks X.Org to pick up shipping expenses for the LA show. + Since there is a budget for this there is no objection. +4. Schedule and agenda for the BoD meetings. + Scheduling and location issues have been discussed for the BoD f2f + meeting, the BoD-sponsors meeting and a possible meeting of the BoD + with the treasurer. + An email thread has been created to add/clearify agenda items. +5. Software licensing issues + Currently numerous individuals and groups trigger discussions on open + source licensing issues should X.Org make an official statement. + X.Org will make no statement unless addressed directly BoD will make + sure any incorrect statements it discoveres are corrected. +6. Organizational issues regarding XDevConf + SK gives update XDevConf organization. + Conference moderation issues are discussed: schedule will be tighter than + on last years conference therefore talk and discussion afterwards need + to stay in given time frame. +7. SK FOSDEM travel funding + SK's airfare and hotel will be covered by SUN. He informs board that he + may need funding for other expenses. +8. A possible sponsoring opportunity was mentioned. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-02-14-2006.mdwn b/BodMeetingSummaries-02-14-2006.mdwn new file mode 100644 index 00000000..a52d06ff --- /dev/null +++ b/BodMeetingSummaries-02-14-2006.mdwn @@ -0,0 +1,35 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon Feb 14, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Jim Gettys (JG) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics: +1. Lenght of meeting +2. Report from SOCAL +3. X@FOSDEM +4. LWE Boston +5. XDevConf + +1. Agreed to have a brief meeting due to last week's travel and time demands. +2. SK attended SOCAL 2006 with an X.Org booth. Reported positive feedback. +3. No action required at this point. +4. LS reported that he received notice that IDG's Industry Advisory Group + did not approve .Org space for X.Org in the April LWE in Boston. The + decision was reportedly based on industry reports that X is only used + on unix and linux, and that freedesktop.org fully represents them. + SK took action item to investigate. LS will also investigate further. +5. BoD moved to officially thank SK and SUN for their effords to make this + year's XDevConf a success. + + + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-02-21-2006.mdwn b/BodMeetingSummaries-02-21-2006.mdwn new file mode 100644 index 00000000..671dbd3c --- /dev/null +++ b/BodMeetingSummaries-02-21-2006.mdwn @@ -0,0 +1,105 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon Feb 21, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. FOSDEM funding requests +2. IRS 501(c)(3) filing status / bylaws +3. Minute taking for the records of the organization +4. Proposal: reduce frequency of calls +5. Drafting proposal for travel funding policy +6. Timetable for board elections and bylaw ratification by + the members. +7. Follow up on the meeting with the sponsors to draft a + proposal for an advisory group. +8. LWE Boston (April) status + +1. FOSDEM funding + + Discussed funding request for FOSDEM: + Luc Verhaegen asked for USD ~550 to accomodate people attending + the HotHouse and DevRoom at FOSDEM. + Request was approved. + Daniel Stone requested partial funding of his airfare to FOSDEM. + Although this funding request was received rather late board + approved partial funding of USD 200 based on lowest available airfare + for the trip. + +2. IRS filings + + LS reported on the status of the IRS 501(c)(3) filings. Our legal + counsel has assigned one of his staff members to this issue. There + are still some issues to be resolved in connection with flaws in the + transition processes between predecessor organizations. Also + 'open software' is not a common purpose among organizations that + file for 503(c)(3). However problems to be expected. + Legal counsel will use bylaws in present state for filing. + The group that's working on the bylaw revision (KM, SA and EE) + would like to get in touch with legal counsel about open questions. + +3. Minute Taking for Records + + Issues about the level of details of the meeting minutes for the + records were raised. + LS reported from conversations with legal counsel that the + organization is responsible to keep records of its meetings that + it has applied due diligence to the issues it has dealt with. + Therefore the records need to contain enough to show the background + of an issue dealt with and the different roads to a resolution it + has considered taking. + LS will produce minutes containing enough background information + to show that. + EE will continue to produce notes for publications independently. + This serves as a check for omissions in either set. + Both should have been read and be approved by the time of the + next meeting. + +4. Proposals + + The proposal was made to reduce the frequency of the calls. + There was support for this among the board members. + +5. Travel funding Policy + + Board agrees that there is still room in approving the communication + with the contributors about the availability of funds for travel + support to X.Org developers events. + Considering that funding requests that were made came in in a rather + short timeframe for the event to attend it was agreed upon that + the organization should put together travel funding policies. + Some board members have some ideas on this issue. Issue was deferred + to email discussion. + +6. Election Timeframes + + People on both the election committee and the bylaw group will + work out a time table to syncronize bylaw ratification and board + elections. Their rough draft is pretty much in line with what LS + has drafted. + +7. Establishing an Advisory Board. + + LS circulated his minutes from the meeting with the sponsor + organizations of X.Org. He strongly suggests to the board to read + them to extract issues to see how to proceed on setting up an + advisory board. + +8. LWE Boston April 2006 + LS Received notice from LWE that the X.Org Foundation will be given + booth space there. X.Org will receive a room at no charge + to allow developers and contributors to X to meet. Preparation + should start soon. + Also it is proposed to hold an informal follow up meeting with + our sponsor organizations. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-02-28-2006.mdwn b/BodMeetingSummaries-02-28-2006.mdwn new file mode 100644 index 00000000..38b0ea12 --- /dev/null +++ b/BodMeetingSummaries-02-28-2006.mdwn @@ -0,0 +1,68 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon Feb 28, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. Approval of minutes and notes from last meeting +2. Report on exchange with assigned lawyer of SFLC +3. Bylaw workgroup (KM, SA, EE) report rewrite status +4. Report FOSDEM +5. Upcoming events + +1. Approval of minutes and notes + Minutes taken by LS and summary notes for publication by EE taken at + last call were approved. Also new minute format which does not list + individual statements but describes the course of the discussions and + the arguments looked at was approved. It was noted as notes and minutes + are taken independently that there may be slight differences due to + different perspectives of the authors. It was agreed that this should + not be a problem as long as the differences are insubstantial. + It also was noted that each one serves a different purpose. + +2. Report on exchange with assigned lawyer of SFLC + LS as secretary reported reported that SFLC has assigned Karen Sandler + as the laywer to help with the irc 501(c)3 filings and bylaw revisions. + She will look into what has been filed so far and if it may be useful + to redo things already done. + SA has been appointed as the contact to the legal counsel by the bylaw + workgroup. + +3. Bylaw workgroup (KM, SA, EE) report rewrite status + The bylaw workgroup reported that it had met 3 times already however + that further meetings are required to complete the task and provide + a draft for board and legal review. March 6, is the current target + date for completion. If there is a slip the board will be notified in + time. + Two of the bylaw workgroup members are also on the election committee; + since the completion of the bylaw revision is a prerequisite for the + election and is the more time consuming task the majority of the current + effords were spent on it. + +4. Report FOSDEM + SK and EE have attended the FOSDEM X HotHouse and DevRoom. It was + noted that the event was a big success, the HotHouse had attracted + more participants than expected. It provided a good opportunity for + developers to meet and exchange. The talks at the DevRoom were well + visited (some were crowded). + It was noted that there seems to be a disconnect between X.Org as + an organization and the people who are working for X.Org as a + development project. + The board formally thanks Luc Verhagen for the excellent job he + has done to organize the event. + +5. Upcoming events + X.Org has been invited to give a presentation at FOSE - a US government + trade show held in Washington DC (USA). + Also FISL at Brasil is coming up. JQ will be there and SK might. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-03-07-2006.mdwn b/BodMeetingSummaries-03-07-2006.mdwn new file mode 100644 index 00000000..c108c98a --- /dev/null +++ b/BodMeetingSummaries-03-07-2006.mdwn @@ -0,0 +1,36 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon March 07, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Jim Gettys (JG) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. Approval of minutes and notes of previous meeting +2. Discussion on first draft of the rewrite of the bylaws + +1. Minutes and notes approval + Board agreed to ratify the notes and minutes from the previous + meeting unless objections are raised within 24 hours after the + call. + +2. Bylaw discussions + The board received the initial draft of the bylaws from the bylaw + committee including a schedule for the ratification process. + This schedule includes period for public review and discussion. + The ratification will be concluded by a vote of the members. + The bylaw committee explained the changes made and collected the + initial feedback from board members. + It was noted that the current draft is not yet complete pending + the rewrite of one section and feedback from legal counsel on + specific questions. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-03-14-2006.mdwn b/BodMeetingSummaries-03-14-2006.mdwn new file mode 100644 index 00000000..20bc1459 --- /dev/null +++ b/BodMeetingSummaries-03-14-2006.mdwn @@ -0,0 +1,49 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon March 14, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. Recreation of Banner for booth. +2. Approval of minutes and notes for publication. +3. Further discussion on bylaw draft. + +1. Recreation of Banner + The main X.Org banner with logo for the LWE booth got lost and + therefore needs to be recreated. + The following suggestions were put on the table: + - Remove dated information (possibly candidates + lists of technologies, sponsors) + - Minimise cost of graphics work required, make it reusable. + LS will have the graphics work done and propose a new design to the + board. Board authorized funds. + The cost are estimated at USD 150 for the graphics work and + USD 600 for the printing. + +2. Approval of minutes + Notes for publication approved immediately, minutes approved if + no objections within 24h. + +3. Bylaws + Bylaw committee pointed out that closure on bylaws is prerequisite + for upcoming BoD election. Any delay will delay election thus because + of the tightness of schedule cooperation of board members is required: + Comments on bylaws not mentioned during this meeting are due by end + of day Wednesday (March 15, 2006). + Continued discussion of bylaws: - correction of numerous typos, + ambiguous and unclear wordings and phrases were discussed changes + were suggested or left for discussion by the bylaws committee. + Further issues to be included into the bylaws were mentioned. + Consensus on most issues was reached. Remaining issues are pending + further discussion by email. + LS agreed to send in his comments and suggestions. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-03-21-2006.mdwn b/BodMeetingSummaries-03-21-2006.mdwn new file mode 100644 index 00000000..35609e79 --- /dev/null +++ b/BodMeetingSummaries-03-21-2006.mdwn @@ -0,0 +1,61 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon March 21, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Jim Gettys (JG) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. Approval of minutes and notes from last meeting. +2. Changing the schedule for the upcoming election and bylaw approval. +3. Further discussion on bylaw rewwrite. + +1. Minute Approval + The different understandings of last weeks discussion on recreating + the banner were discussed briefly. + The group agreed that the points brought up last week were mere suggestions + and no final decision had been made. + LS will work together with Paul Swart (sponsor) on a draft. The graphics + work will be prepared by Ruth Shiman. + +2. Rescheduling the election process + Last year the date we aimed at for holding the election was during + June/July. The low turnout of the nomination process suggested + that the summer month may not be the right time for an election. + A lot of members seem to attend conferences or have planned vacation + during this time. + The board saw two possibilities to remedy this: either move the election + process to an earlier time (such as May) or to a later date in the fall. + + The board came to the conclusion that the old board should be allowed + to finish its business before summer without being hampered by the + election process. Then first thing in early fall the annual board + election can be held such that the new board can constitute itself + and start working. + + In our present situation this would have the additional benefit that + the schedule for the bylaw and membership agreement rewrite can be + more flexible giving us more time for public review and debate. + + September/October seems to be a good time for the election as it seems + to be suitable for people both on the northern and southern hemisphere. + +3. Further bylaw discussions + The initial draft of the bylaws presented by the bylaw committee + is almost complete now. + The majority of the board members have read the document. Issues + about details in wordings and the procedures outlined in the draft + were discussed and suggestions for modifications were put onto the + table. Discussions are expected to continue while the bylaw committee + is considering the suggested changes before the document will be + passed to X.Org's legal counsel for review. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-04-11-2006.mdwn b/BodMeetingSummaries-04-11-2006.mdwn new file mode 100644 index 00000000..5a516e5a --- /dev/null +++ b/BodMeetingSummaries-04-11-2006.mdwn @@ -0,0 +1,52 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon April 11, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Leon Shiman (LS) +Kevin Martin (KM) +Egbert Eich (EE) + +Topics +------ +1. Approval of Minutes and Notes +2. Further Schedule +3. Bylaw Status +4. Security Releases + +1. Approval of Minutes and Notes + No minutes have been taken on last call. Summary for publication + has been circulated just prior to call - will be arroved unless + issues are raised by email. LS will try to generate minutes from + EE's private notes. + +2. BoD discussed further schedule: + a. It was agreed that discussion of upcoming events should not take + place among the board but be held on a more open forum. + b. Bylaws have to be finished, including the membership agreement. + c. Work on reimbursement and spending policy needs to be done. + It was discussed how ideas should be collected: There are people + who could contribute valuable input outside of the board. + d. Further issues to be collected on the mailing list to be put + on agenda. + +3. Bylaws: + Bylaw committee incorporated comments collected on last call and + during the past two weeks. Document is almost ready for legal + review. Deadline for further comments has been set. Later comments + should not delay the process. + +4. Security Releases: + The issue of how to announce and make available security fixes has + come up in the community: the last security release has not yet + been made available on X.Org's official web site. + Resolution: + Among the security WG a volunteer should be found who'd willing + to be responsible for such announcements to be given access to + the X.Org web page. SA will make an announcement to the security + maling list. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-04-25-2006.mdwn b/BodMeetingSummaries-04-25-2006.mdwn new file mode 100644 index 00000000..ae8cb590 --- /dev/null +++ b/BodMeetingSummaries-04-25-2006.mdwn @@ -0,0 +1,83 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon April 25, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan n(JQ) +Leon Shiman (LS) +Kevin Martin (KM) +Egbert Eich (EE) + +Topics +------ +1. Moving more BoD discussions to email. +2. Bylaw review process. +3. State of X.Org machines. +4. Additional machines from SUN +5. Notes approval + +1. Moving more BoD discussions to email. + It was noticed that it is getting increasiongly difficult to hold + a board call as board members have other obligations at the time of + the call. + - Last weeks call was canceled. + - LS and EE announced that they will not be available for calls the + following two weeks. It was therefore suggested to cancel the next + two calls. + - Some board members were not able to join this call from the beginning. +p It was therefore decided to move more discussions to email which would + give people who cannot make it at the time the calls are scheduled to + participate in the discussions. + +2. Bylaw revision progrss + Bylaw committee announced it had received the last set of reviews from + board members. It will schedule a time for a call to discuss these issues. + +3. State of X.Org machines + Daniel Stone has repeatedly approached the board on the state of the + X.Org machines. Presently freedesktop.org acts as the canonical upstream + source for X.Org releases. + - ftp.x.org does not have the latest security patches + - www.x.org doesn't announce the availability of these patches. + Daniel pointed out that people looking for the availability of security + fixes will normally check the projects main web site. + Not announcing the availability of security patches there may in + give those people a false sense of security. + Therefore he started a discussion on the X.Org security mailing list + making suggestions on how to remedy this problem. + The board decided to move the discussion on how the community would + loke to see the X.Org machines used to a larger audience. It was + furthermore decided that the mailing list xorg@freedesktop.org + would be the right audience. + KM will make an announcement on the security mailing list suggesting + to move the discussion and to repost the messages that were exchanged + on the security mailing list on this matter to xorg@freedesktop.org + if noone objects. + Furthermore it was decided to not start a separate discussion on + the web server issue as both matters belong together. + +4. SK reported that the machines donated to X.Org by SUN Microsystems + had been shipped to MIT. These machines are explicitely titled to + MIT and thus cannot be moved to a different location. + He also mentioned that they are equipped with remote management + facilities. + Thus they only require physical attendance for the initial setup + and the configuration of the remote management console. + The taks to do this has not yet been assigned to anyone. + SK furthermore mentioned that SUN would like to see OpenSolaris to + be the OS used on these machines to demonstrate the capabilities + of this other open source OS. + It was pointed out that this would make it more difficult to find + people who are willing to administrate these machines as the expertise + in OpenSolaris is not too pelntyful in our community. + +5. Notes approval. + The notes of the last board meetings have not been read by all board + members. Since they had been circulated almost two weeks ago it was + decided that if no objection was raised within 24 hours they would + be approved for publication. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-05-16-2006.mdwn b/BodMeetingSummaries-05-16-2006.mdwn new file mode 100644 index 00000000..b34263d8 --- /dev/null +++ b/BodMeetingSummaries-05-16-2006.mdwn @@ -0,0 +1,66 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon May 16, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQuillan (JQ) +Leon Shiman (LS) +Kevin Martin (KM) +Egbert Eich (EE) + +Topics +------ +1. Approval of Notes from +2. Bylaws +3. Press Release for 7.1 release. +4. Status of Mirroring +5. Misc +6. State of Machines from SUN. + + +1. Approval of Notes from April 24 + Notes circulated on April 27. Although not everybody has read the + notes no extension of review period has been requested. + +2. Bylaws + Issue was tabled as bylaw committee has not made any progress + since last meeting due to other committments. Due to urgent work on + the 7.1 release KM will be unable to join a meeting before next + week. + +3. Press release for 7.1 release + KM described the progress of the 7.1 release. Release is scheduled + for the coming Friday if everything runs on schedule. The question + was brought up if provisions need to be made for the press release + as in the past X.Org avoided weekends when making press releases. + It was pointed out that media are expected to pick up press releases + at any time. It was decided to contact Ajax as release manager if + sees any issues. + +4. Status of Mirroring + After the issues with the directory structure on freedesktop.org + have been resolved mirroring of the release tree has been started. + +5. Misc. + LS reported that on his trip to Europe he met a corporate group + from South Korea that is very intereseted to participate in our + community and possible also become a sponsor. + Cultural and language barriers exist. Mentoring may be required. + Furthermore LS reported on a group from St.Petersburg he has met + on LinuxTag that is also very interested in participating in the + X.Org community. Since the group has been busy manning a booth + they were unable to visit the X.Org booth to meet with people + from the community. + No immediate action by the board required. + +6. State of Machines from SUN + LS will schedule a meeting with Ajax at MIT to introduce him to + the location and get him access. It is planned to rack the SUN + machines at this time. + SK reported that he found issues with the remote management unit + of those machines. If remote management is not possible over the + network a remote dump terminal facility may be required. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-05-30-2006.mdwn b/BodMeetingSummaries-05-30-2006.mdwn new file mode 100644 index 00000000..09a64d3b --- /dev/null +++ b/BodMeetingSummaries-05-30-2006.mdwn @@ -0,0 +1,41 @@ + + +[[!format txt """ +Notes form X.Org BoD telecon May 30, 2006 + +Present: +Stuart Kreitman (SK) +Jim McQuillan (JQ) +Leon Shiman (LS) +Kevin Martin (KM) +Egbert Eich (EE) + +Topics +------ +1. Portland Machine +2. Bylaws +3. Status of Machine at MIT +4. Notes from last Meeting +5. Next Meeting + +1. State of Portland Machine + Discussed machine at Portland State and remote management facilities + of the new SUN machines. + +2. Bylaws + Decided to move bylaw discussion to next meeting since the latest + version has not been circulated. Otherwise bylaw committee is in + good shape. + +3. Status of Machine at MIT + No news as Adam who volunteered to help racking it was busy so far. + +4. Notes from last Meeting + Notes from last meeting will be approved unless objections filed until + Friday. + +5. Next Meeting + It was agreed to close this meeting early. + The next meeting will probably be in two weeks. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-07-14-2006.mdwn b/BodMeetingSummaries-07-14-2006.mdwn new file mode 100644 index 00000000..01e2f2aa --- /dev/null +++ b/BodMeetingSummaries-07-14-2006.mdwn @@ -0,0 +1,59 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon July 14, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim Gettys (JG) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics +------ +1. Bylaw Subcommittee Report +2. Planning an F2F Meeting this Year +3. Board Elections +4. Status Incorporation Documents / other unfinished Business +5. Status of Server at MIT + +1. Bylaw Subcommittee Report + The bylaw subcommittee has received feedback from the laywer. + The feedback was discussed issues that the subcommittee felt + it was unable to solve itself were posted back to the laywer + with questions and comments. + +2. Planning of F2F Meetings this Year + There will be no f2f meeting of the board at OLS as not all members + will be there. The next phone meeting will be scheduled for Jul, 25th. + +3. Board Elections + The election process will not start until after the summer (ie. middle + of August). Election subcommittee will meet in Ottawa to discuss + schedule details. + JG is presently looking into the election software that is used by + the Gnome Foundation. + +4. Status Incorporation Documents / other unfinished Business + LS hopes to be able to have the Incorporation Documents + which include the non profit status documents and the paperwork + for the IRS filings ready for the next meeting. + He will also refile the applications to give SK counter signature + authority for money transfers with our bank. + Recent difficulties with money transfers were discussed. LS assured + the board that the procedures the bank applied for money transfers + were reasonable and were not the cause of the delays. + +5. Status of Server at MIT + The status of the servers at MIT were discussed. + SA would like to reinstall expo. The current setup is suboptimal + which caused the delay in email delivery to the board when mailman + died due to a full root fs. + The SUN machines have not been mounted in the racks, yet. Adam Jackson + who volunteered to do this together with LS was busy with other things. + SK asks to run OpenSolaris on the SUN machines. He will take over the + responsibility to administrate these machines. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-08-08-2006.mdwn b/BodMeetingSummaries-08-08-2006.mdwn new file mode 100644 index 00000000..8923f326 --- /dev/null +++ b/BodMeetingSummaries-08-08-2006.mdwn @@ -0,0 +1,62 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon August 8, 2006 + +Present: +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim Gettys (JG) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics: +======= + +1. Khronos/VESA Membership +2. Status of Corporation +3. Status of bylaws +4. Election Process +5. Next X Developers conference. + +1. Khronos/VESA Membership + It was suggested (and discussed among X developers attending DDC) that + it may be worthwhile for X.Org to become a member of Khronos the + organization that is currently steering OpenGL and related standards. + Standards passed by Khronos and technologies developed by X.Org may + directly affect each other, therefore it is desirealbe that X.Org + participates in the discussion of standards early. + It was decided to assing to KM and SK the taskt to explore on what + terms and conditons X.Org can cooperate with Khronos. + Furthermore it was briefly discussed if X.Org should become a member + of VESA or if it was sufficient for X.Org to have funds to purchase + relevant specifications: although there may not be a reason for X.Org + to actively drive standards it may be importand to know early in advance + what technologies to expect. SK and EE were assigned the task to explore + this issue further. + +2. Status of Corporation + LS reported on the progress of the status of the filing of the + incorporation: LS is closely working together with our legal counsel + to work out the details and obtain documents that are still missing. + +3. Status of bylaws + After receiving a reply from the lawyer the bylaw committee will + meet this week. It hopes to be able to draft a final version avaliable + before the next call. + +4. Election Process + As the election schedule is closely tied to the bylaw process + the election subcommittee will draft a schedule once the bylaw + subcomittee has completed its work. + +5. Next X Developers conference. + SK reported that he would be happy to organize another X developers + conference hosted by SUN Microsystems. + It was also noted that X.Org should to foster more local X developers + conferences in different parts of the world - like this year on FOSDEM + in Brussels by providing financial and logistical support and encourage + local community members to step up and organize such an event. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-08-15-2006.mdwn b/BodMeetingSummaries-08-15-2006.mdwn new file mode 100644 index 00000000..ab1df70b --- /dev/null +++ b/BodMeetingSummaries-08-15-2006.mdwn @@ -0,0 +1,38 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon August 15, 2006 + +Present: +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics: +======= + +1. Publication of Bylaws for Public Review +2. Members Mailing List + +1. Publication of Bylaws for Public Review + The bylaw subcommittee has finished the bylaw rewrite. The + board has approved the latest version to be publisehd for + public review and discussion pending a last legal review. + For public discussion a list bylaws_at_x_dot_org will be + created. Subscription to this list is open to the public + (not just members). The members as well as other mailing + lists will be notified of this list and people will be invited + to subscribe themselves to participate in the discussion. + The election schedule will be updated accordingly. + The revised Membership Agreement will be published to the + board after review by the counsel. + Once the board has approved it will be published for public + discussion on the same forum. + +2. Members Mailing List + SA will reinstate the members mailing list. The list will + have the name members_at_x_dot_org. instead of xf_members_at_. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-08-22-2006.mdwn b/BodMeetingSummaries-08-22-2006.mdwn new file mode 100644 index 00000000..19cf6906 --- /dev/null +++ b/BodMeetingSummaries-08-22-2006.mdwn @@ -0,0 +1,34 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon August 22, 2006 + +Present: +======== + +Stuart Anderson (SA) +Jim McQuillan (JQ) +Kevin Martin (KM) +Leon Shiman (LS) +Stuart Kreitman (SK) +Egbert Eich (EE) + +Topics: +======= + +1. Bylaw discussion and Election Schedule + +1. Bylaw discussion and Election Schedule + The results from the call from the previous week were rehashed + together with the proposed schedule. It was made clear that + the membership registration process will be opened before the + nominations for board members start so that people interested + in nominating a candidate or running can apply for membership. + + The bylaw discussion will open to everyone - if presently member + or not. + The secretary will prepare a public announcement as soon as + possible as we have already lost a week since this procedure + was agreed upon. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-08-29-2006.mdwn b/BodMeetingSummaries-08-29-2006.mdwn new file mode 100644 index 00000000..a712345a --- /dev/null +++ b/BodMeetingSummaries-08-29-2006.mdwn @@ -0,0 +1,78 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon August 29, 2006 + +Present: +======== + +Stuart Anderson (SA) +Jim McQuillan (JQ) +Jim Gettys (JG) +Kevin Martin (KM) +Leon Shiman (LS) +Stuart Kreitman (SK) +Egbert Eich (EE) + +Topics: +======= + +1. Official Financial Statement for IRS/Incorporation Filings +2. Trademark issues +3. Public By-Law Draft Discussion Announcement +4. Membership Management Infrastructure +5. Membership Application Review +6. Nomination Statements +7. Electronic Election Infrastructure +8. Administrative Issues: Mailinglist Infrastrucutre + +1. Official Financial Statement for IRS/Incorporation Filings + The board approved USD 2500 for an official financial statement + required for IRS and Incorporation filings. Our legal advisor + has (SFLC) has recommended a company to us which will provide + these services for a favorable rate. The amount is below of what + had been budgeted. + +2. Trademark issues + The letter 'X' and the term 'X11' is used in numerous contexts in + the IT world. The board needs to schedule a meeting with out legal + advisors so that we can discuss any legal implications on us. + +3. Public By-Law Draft Discussion Announcement + LS reported that the announcement for the bylaw discussion has been + sent to xorg@freedesktop.org (via Daniel Stone) as well as to the + members, the board and the sponsors. Only a few email addresses + of members were not available and bounced. + +4. Membership Management Infrastructure + SA reported that his work on the membership management infrastructure + is making progress. Some pieces are in place already and have been + made available to the board members for testing. + +5. Membership Application Review + The new board will have to extablish procedures for membership + application review. A possible solution would be to have a membership + review WG that doesn't consist of board people only but of members + who are not on the board also. + Since there is not enough time to establish this group in time before + the upcoming election the board will serve as an application review + board until the new board has constituted istself. + +6. Nomination Statements + The election subcommittee will work out the details and send out + make an announcement on Sept. 4th. This will be published to xorg@, + the the members and the board. + +7. Electronic Election Infrastrucutre + Likewise the election subcommittee will research software for an + electronic interface. It will report its findings to the board. + LS had prepared the frist electronic election and was involved in + the preparation of the election last year. He will recollect issues + that came up and note down his experience and publish this information + to the election subcommittee. + +8. Administrative Issues: Mailinglist Infrastructure + The issues mailman had with the security list are not related to + a lack of administration but to a bug in mailman. The issues will + be reported to the mailman maintainers. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-09-05-2006.mdwn b/BodMeetingSummaries-09-05-2006.mdwn new file mode 100644 index 00000000..d8202c2a --- /dev/null +++ b/BodMeetingSummaries-09-05-2006.mdwn @@ -0,0 +1,43 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon September 5, 2006 + +Present: +======== +Leon Shiman (LS) +Kevin Martin (KM) +Stuart Kreitman (SK) +Jim McQillan (JQ) +Egbert Eich (EE) + +Topics: +======= + +1. Public By-Law Review +2. X.Org Trademark Issues +3. Membership Management + +1. Public By-Law Review + Resonance on the public bylaw review has not been very big. + One issue broad up was that the new bylaws have a one minimum + year membership requirement for people who whould like to run + for the board. People found this not very realistic as they feel + that many individuals who have been active in the community may not + bother to become members until shortly before the election. + One possible solution may be to + * require membership only at the time of the election + * base eligibility on active participation (that would qualify + for membership) + * reduce the period to 6 month. + KM will draft and publish an updated wording. + +2. X.Org Trademark Issues + The discussion on this topic continued. + +3. Membership Management + SA has added some more pieces to the membership management + infrastructure. + The board would like to express its appreciation for his effords. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-09-26-2006.mdwn b/BodMeetingSummaries-09-26-2006.mdwn new file mode 100644 index 00000000..c1a20910 --- /dev/null +++ b/BodMeetingSummaries-09-26-2006.mdwn @@ -0,0 +1,56 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon September 26, 2006 + +Present: +======== +Leon Shiman (LS) +Kevin Martin (KM) +Stuart Kreitman (SK) +Stuart Anderson (SA) +Jim McQillan (JQ) +Egbert Eich (EE) + +Topics: +======= +1. Membership Applications +2. Status of IRS Filings and Incorporation +3. Debate over LS's Request for Travel Funding for LWE, Colone, Germany. + +1. Membership Applications + The new system for Membership Renewal and Application has been set up. + Requests for Renewal as well as new applications are coming in. Debate + sparked on the issue which criteria to apply to new applications. To + meet the requirements for non profit the organization may not be able + to apply too strict rules. + It was pointed out that it should be left to the Committee which decides + over the applications to determine the policies and reevaluate them from + time to time. + It was decided that the Board Members who are up for reelection this + year should not participate in the decisions over the acceptance or + rejection of applications. + +2. Status of IRS Filings and Incorporation + LS waiting for the legal counsel to finish the work and get back to him. + +3. Debate over LS's Request for Travel Funding for LWE, Colone, Germany. + LS had requested USD 500 to cover the costs for his accomodation at + Colone. + Objections were raised: X.Org did not have a sponsorship program. + Without that Board Members were at an advantage when applying for + sponsorship as they knew about this opportunity and had direct + access to the Board. + EE proposed to instead set aside a fund of USD 1000 for travel + sponsorship and advertise the sponsorship opportunity to the + community. Furthermore to bring in as many people as possible + the focus of funding should be on the local community. + LS pointed out that LWE had approached him about the booth but time + to accept the offer was running out. Therefore there wasn't enough + time to wait for the Board to decide over the distribution of the + funds. + No resolution was reached. + SK will submit an alternative motion to the BoD mailing list which + would allow to award USD 500 to LS in advance distributing the rest + to other applicants. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-10-03-2006.mdwn b/BodMeetingSummaries-10-03-2006.mdwn new file mode 100644 index 00000000..3bddcd07 --- /dev/null +++ b/BodMeetingSummaries-10-03-2006.mdwn @@ -0,0 +1,48 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon October 3, 2006 + +Present: +======== +Stuart Kreitman (SK) +Kevin Martin (KM) +Jim McQuillan (JQ) +Jim Gettys (JG) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics: +======= +1. Unified Copyright Clause +2. Progress on Election Process +3. Trademark Issues + + +1. JG broad up the issue that X.Org should: + a. come up with a unified author neutral license clause. + b. unify all license clauses of copyrights it owns. + c. should work with companies that have donated code to + the X Window System to get their consent to change or + subsume their license clauses under the common form. + d. resolve the issue with the non-GPL compatible SGI license + e. advicate that all contributors use the same license clause. + To do this a public discussion on this issue ought to be + started to come to a consenus among a. individual contributors + b. corporations that contribute or have contributed code. + JG will kick this off. + It was noted that several files still seem to contain reference + to 'The Open Group'. LS reported that all those copyrights should + have been changed to X.Org when X.Org was created as a subgroup + of X.Org. EE will reasearch which files still contain TOG copyright/ + license clauses, LS will contact TOG to confirm their consent. + +2. Progress on Election Process + By-Law committee reported that it is about to schedule a last + meeting to review results from consulting our legal counsel. + Also the outcome of the public review needs to be discussed. + A meeting will be scheduled by the By-Laws committee for later + in the same week. + +3. The Board continued discussion on issues around trademarks. +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-10-10-2006.mdwn b/BodMeetingSummaries-10-10-2006.mdwn new file mode 100644 index 00000000..39f330f3 --- /dev/null +++ b/BodMeetingSummaries-10-10-2006.mdwn @@ -0,0 +1,57 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon October 10, 2006 + +Present: +======== + +Stuart Kreitman (SK) +Stuart Anderson (SA) +Kevin Martin (KM) +Jim McQuillan (JQ) +Jim Gettys (JG) +Leon Shiman (LS) +Egbert Eich (EE) + +Topics: +======= + +1. By-Laws/Membership Agreement final version + +1. By-Laws/Membership Agreement final version + The Membership Agreement has not received any public review, therefore + it is urgent to get this out to the voters. The subcommittee has met + again and incorporated the results of the public discussions into the + By-Laws and completed the rewrite of the Membership Agreement + incorporating the results from legal review and sentiments expressed + during the By-Law public review. + Some minor issues were noted by Board Members: + 1. Minor grammar glitches were noted in the By-Laws. + 2. Grammer in section 2 of the Membership Agreement needs to be improved. + 3. The Membership Agreement doesn't mention explicitely that Members + are allowed to chair committees (as it is expressed in the By-Laws). + This will be added. + 4. Section 5a was unclear to some Board Members. It was decided to + take it to the lawyer for a rewording. Also it was expressed that + the second sentence should probably be removed as the first one + only refers to X.Org related activeties and does not touch other + contractual relationships between Members. + Since time is short it was agreed to fix points 1-3 and publish this + version for review noting that it is still preliminary and section + 5a is still under review. + +2. Incorporation Issues + LS reported that he is still waiting for the accounting data from + our treasurer. EE has agreed to work with the treasurer to help + converting it into the right format. + Furthermore it was pointed out that former Board Members need to + return their Membership Certificates. A discussion came up around + the meaning of this certificate and how it should be stored. + It was pointed out that this certificate is comparable to a share + as it certifies that one is the owner of part of the organization. + It was agreed upon that after all paperwork about registration + is done it needs to be investigated how to record this ownership + in a way that doesn't require such documents. + +"""]]
\ No newline at end of file diff --git a/BodMeetingSummaries-10-17-2006.mdwn b/BodMeetingSummaries-10-17-2006.mdwn new file mode 100644 index 00000000..641eea64 --- /dev/null +++ b/BodMeetingSummaries-10-17-2006.mdwn @@ -0,0 +1,52 @@ + + +[[!format txt """ +Notes from X.Org BoD telecon October 17, 2006 + +Present: +======== +Stuart Kreitman (SK) +Stuart Anderson (SA) +Kevin Martin (KM) +Jim McQuillan (JQ) +Jim Gettys (JG) +Leon Shiman (LS) +Egbert Eich (EE) + +1. Missed Nominee for BoD Meeting. +2. Status of Membership and By-Laws Document +3. Copyright/License Consolidation +4. Financial Reporting + +1. Nominee Missed + The Election Committee has checked log files and archives but was + not able to find any indication of a nomination of Christophe Suter + by Paul Schenker. The investigations will continue and the committee + will work with Paul Schenker to resolve the issue. It was further + noted that Christope Suter is not yet a member. Should this nomination + have been lost, the candidate will be given the opportunity to + register. + EE replied to the notification on the members mailing list asking + for more details however no answer has been received, yet. + +2. Status of Membership and By-Laws Document + The public review of the By-Laws have been completed and the text + has been amended. Public review of the Membership document is + still under way. Some clauses raised questions. Since SA is currently + involved with election preparation EE has contacted the legal counsel + about these. + The results will be posted directly to the bylaws mailing list. + +3. Copyright/License Consolidation + Questions have come up among the board about the skope of this. + It was made clear that there is no intention to change any + Copyrights which wuld not be possible. + The intention is to consolidate the different MIT license texts + that are contained in one single source file into one worded + vendor neutrally. JG has made a proposal for this. + +4. EE has reviewed the books. Since these are done in Gnucash it is + a rather tedious undertaking to generate reports. LS needs to + clearify what information is required for the incorporation. + He will communicate with EE in private. +"""]]
\ No newline at end of file diff --git a/BrianCameron.mdwn b/BrianCameron.mdwn new file mode 100644 index 00000000..513826cd --- /dev/null +++ b/BrianCameron.mdwn @@ -0,0 +1,5 @@ + + +## Brian Cameron + +[[https://live.gnome.org/BrianCameron|https://live.gnome.org/BrianCameron]] diff --git a/BuildingXtest.mdwn b/BuildingXtest.mdwn new file mode 100644 index 00000000..1db794fa --- /dev/null +++ b/BuildingXtest.mdwn @@ -0,0 +1,112 @@ + + +## Check out the XTS code + +The XTS uses autotools and can be obtained with: + + +[[!format txt """ +$> git clone git://anongit.freedesktop.org/git/xorg/test/xts +$> cd xts +$> ./autogen.sh +$> make +$> make run-tests +"""]] +The first "make" command builds the sources, "make run-tests" executes all the tests. Results are stored in the results/ directory under the current timestamp (e.g. results/2010-04-19-18:19:08/). Note that XTS does not need to be installed, if you do want to do so you're encouraged to pick the appropriate installation prefix for your distribution. + +For more information, see the README in the xts repository. + + +## Running a subset of tests + +The tests are divided into protocol tests, Xlib (per chapter) and extension tests. Each of these subsection can be run separately with the _make test-<section>_ command. e.g. make test-Xlib13 will only run the Xlib13-related tests. + + +## CVS version of the XTS + +_The following information refers to the CVS, non-autotooled version of the XTS. We do not recommend using this version._ + +Anonymous CVS is available from: +[[!format txt """ +cvs -z3 -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/xtest login +cvs -z3 -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/xtest co xtest +cd xtest +export TET_ROOT=`pwd` +export PATH=$TET_ROOT/bin:$TET_ROOT/xts5/bin:$PATH +make +cd xts5 +"""]] +(This won't install anything outside of the checkout tree.) This creates an assortment of journal files with the output from the various build commands. Hopefully that will go away eventually, but in the meantime look in xts5/results. Use `CFLOCAL=<cflags>` to set local C compiler flags (for example `-g`) (**NOTE:** this is only supported for xts5 not for tet). + + +### Additional Requirements + +The XTS code uses a call to `_XConnectDisplay`. This function is provided by libX11, but only if libX11 was compiled **without** XCB support (`--with-xcb=no`). + + +## Build the supporting libraries and binaries + +Make sure you have a fonts.dir in your fonts directory. Which format the fonts need to be in depends on which X server you're using. If you don't know what to pick, this command will probably take care of everything for you: +[[!format txt """ +make -C fonts comp_pcf +"""]] +(I had to edit out the *.bdf entries of the fonts.dir to make Xfake happy. With other X servers, YMMV.) + + +## Running the test cases + +Start an X server to run the tests against. Remember that if you have an X server running on :0, you'll need to pick another display for this test server: let's assume you picked :1. It's also easiest to disable access control with the -ac flag. Note that you may want to run the tests with multiple screens, which can be easily accomplished using Xvfb or Xfake. Here are a few sample X server invocations: +[[!format txt """ +Xvfb -screen 0 640x480x24 -screen 1 640x480x8 -ac :1 +Xfake -screen 640x480x16 -screen 640x480x16 -ac :1 +"""]] +Now you need to make sure that tetexec.cfg matches your test X server. The xts-config script can fill in most values automatically by querying the running X server. Anything it can't handle it leaves unchanged, so you can intersperse xts-config runs with hand-edits safely, and comments are preserved as well. +[[!format txt """ +DISPLAY=:1 xts-config tetexec.cfg +"""]] +You still need to review tetexec.cfg after running xts-config, because if your xdpyinfo and xset binaries use the same Xlib that you want to test, or your X server is reporting weird values, the test suite may report PASS on tests that should have FAILed. In other words, if you don't review the resulting tetexec.cfg file, your test results may be _invalid_. + +Assuming that your X server is running locally, the default delays in tetexec.cfg are much higher than they need to be. On local tests you can safely set XT_SPEEDFACTOR and XT_RESET_DISPLAY to 1 instead of the default 5. This will make the test suite run somewhat faster. + +Finally, you can run the test suite using +[[!format txt """ +tcc -e +"""]] +You can run subsets of the test suite by picking a subset from the tet_scen file, and then passing the subset name as a parameter +[[!format txt """ +tcc -e xts5 <subset> +"""]] +A (re)build of all scenarios can be started with +[[!format txt """ +tcc -b +"""]] + +## Running and Debugging Individual Test Cases + + +[[!format txt """ +run_assert XGetGeometry 4 +"""]] + +[[!format txt """ +cd tset/Xlib5/gtgmtry +TET_CONFIG=tetexec.cfg gdb Test +"""]] +alternatively, one can run +[[!format txt """ +cd xtest/xts5/tset/path/to/testcase +xtest/xts5/src/bin/scripts/pt -i 3 # run testcase t003() of the Test binary. +"""]] + +## Reviewing the Results + +Use the vswrpt command (which should now be in your path) to see the results of the test run. + + +## Cleaning the test cases + + +[[!format txt """ +tcc -c +make clean +"""]]
\ No newline at end of file diff --git a/BylawReview.mdwn b/BylawReview.mdwn new file mode 100644 index 00000000..52379962 --- /dev/null +++ b/BylawReview.mdwn @@ -0,0 +1,29 @@ + +The X.Org Foundation has been operating under a set of Provisional By-laws since it's formation. Recently, these By-laws have undergone a thorough review, which has resulted in a major revision that better reflects the organization and how it operates. + + +## By-Laws + +The Board of Directors is pleased to present these revised By-laws for public comment and discussion. All discussion shall take place on the [[bylaws@x.org|mailto:bylaws@x.org]] mailing list, which is open to everyone. Anyone interested in commenting on these By-laws is asked to join the mailing list at [[http://x.org/cgi-bin/mailman/listinfo/bylaws|http://x.org/cgi-bin/mailman/listinfo/bylaws]]. + +The discussion period for this review shall run through 10 September 2006. The By-laws will be submitted to the members for approval in the upcoming election which will be held later this year. + +* [[ProposedBylaws.pdf|ProposedBylaws.pdf]] +Revisions to the By-laws have been made as a result of the public review. The revised version is available here + +* [[ProposedBylawsRevised20061009.pdf|ProposedBylawsRevised20061009.pdf]] +* [[ProposedBylawsRedlinedvs20060811.pdf|ProposedBylawsRedlinedvs20060811.pdf]] +Unless there a critical issue, this will most likely be the version that will be put up for ratification as part of the upcoming election. + +A couple of very minor editorial and formatting changes have been made. The version that will appear on the ballot is here + +* [[ProposedBylawsRevised20061029.pdf|ProposedBylawsRevised20061029.pdf]] +_**This version was approved on 14 November 2006**_ + + +## Membership Agreement + +The Board of Directors is also ready to present a revised Membership Agreement for public review. The discussion period for the Membership Agreement will end 20 October 2006. Discussion shall take place on the bylaws mailing list described above. + +* [[ProposedMembershipAgreement.pdf|ProposedMembershipAgreement.pdf]] +Discussion is still ongoing for the Membership Agreement, so a seperate ballot will be opened for it once the discussion and review have concluded. diff --git a/BylawReview/ProposedByLawsRevised20061029.pdf b/BylawReview/ProposedByLawsRevised20061029.pdf Binary files differnew file mode 100644 index 00000000..d33ba841 --- /dev/null +++ b/BylawReview/ProposedByLawsRevised20061029.pdf diff --git a/BylawReview/ProposedBylaws.pdf b/BylawReview/ProposedBylaws.pdf Binary files differnew file mode 100644 index 00000000..9624b72b --- /dev/null +++ b/BylawReview/ProposedBylaws.pdf diff --git a/BylawReview/ProposedBylawsRedlinedvs20060811.pdf b/BylawReview/ProposedBylawsRedlinedvs20060811.pdf Binary files differnew file mode 100644 index 00000000..62bdd6f4 --- /dev/null +++ b/BylawReview/ProposedBylawsRedlinedvs20060811.pdf diff --git a/BylawReview/ProposedBylawsRevised20060811.pdf b/BylawReview/ProposedBylawsRevised20060811.pdf Binary files differnew file mode 100644 index 00000000..9624b72b --- /dev/null +++ b/BylawReview/ProposedBylawsRevised20060811.pdf diff --git a/BylawReview/ProposedBylawsRevised20061009.pdf b/BylawReview/ProposedBylawsRevised20061009.pdf Binary files differnew file mode 100644 index 00000000..02fba4ce --- /dev/null +++ b/BylawReview/ProposedBylawsRevised20061009.pdf diff --git a/BylawReview/ProposedBylawsRevised20061029.pdf b/BylawReview/ProposedBylawsRevised20061029.pdf Binary files differnew file mode 100644 index 00000000..d33ba841 --- /dev/null +++ b/BylawReview/ProposedBylawsRevised20061029.pdf diff --git a/BylawReview/ProposedMembershipAgreement.pdf b/BylawReview/ProposedMembershipAgreement.pdf Binary files differnew file mode 100644 index 00000000..3695f7a7 --- /dev/null +++ b/BylawReview/ProposedMembershipAgreement.pdf diff --git a/CarPoolInfo.mdwn b/CarPoolInfo.mdwn new file mode 100644 index 00000000..f3ff6f5c --- /dev/null +++ b/CarPoolInfo.mdwn @@ -0,0 +1,44 @@ + +Drivers willing to carpool, please add your name here on this page, include your seating availability, arrival time, departure time, and hotel + +For coordinating Car Pool Information please sign up for a driver here. + +Matthew Tippett + + * [[!table header="no" class="mointable" data=""" +Seats | 3 (4 if you don't mind being squashed) +Arrive | 8:30 PM, Tuesday, 15th April +Depart | 10:30 PM, Friday, 18th April +Hotel | [[Hotel Zico|http://maps.google.com/maps?f=q&hl=en&geocode=&q=200+E+El+Camino+Real,+Mountain+View,+CA&sll=37.378768,-122.069221&sspn=0.007392,0.013475&ie=UTF8&ll=37.379553,-122.070873&spn=0.118265,0.215607&z=13]] +Passengers | +"""]] + +Matthias Hopf + + * [[!table header="no" class="mointable" data=""" +Seats | 2-3, depending on the type of car I'll get +Arrive | 1:05 PM, Tuesday, 15th April +Depart | Sunday, 20th April +Hotel | [[Best Western Mountain View Inn. 2300 W El Camino Real|http://maps.google.com/maps?f=l&hl=en&geocode=6913274534084284730,37.423398,-122.086507&q=hotels&near=2300+El+Camino,+Mountain+View,+CA+94043+(Google)&sll=37.423398,-122.086507&sspn=0.101701,0.129776&ie=UTF8&ei=Hzb-R9aMG5GC3ALsxZ26CQ&cd=1&cid=37397187,-122105003,17748288625363885143&li=lmd&z=14&t=m]] +Passengers | +"""]] + +Jerome Glisse + + * [[!table header="no" class="mointable" data=""" +Seats | 2-3, depending on the type of car I'll get +Arrive | 2:00 PM, Tuesday, 15th April +Depart | Early in the morning,Saturday, 19th April +"""]] +[[!table header="no" class="mointable" data=""" +Hotel | [[Best Western Mountain View Inn. 2300 W El Camino Real|http://maps.google.com/maps?f=l&hl=en&geocode=6913274534084284730,37.423398,-122.086507&q=hotels&near=2300+El+Camino,+Mountain+View,+CA+94043+(Google)&sll=37.423398,-122.086507&sspn=0.101701,0.129776&ie=UTF8&ei=Hzb-R9aMG5GC3ALsxZ26CQ&cd=1&cid=37397187,-122105003,17748288625363885143&li=lmd&z=14&t=m]] +Passengers | Stefan Dösinger(Best Western, 4:30 PM) +"""]] + +Stuart Kreitman + + * [[!table header="no" class="mointable" data=""" +Seats | 3 + I'm local to the area, so can help out in a pinch + [[stuart.kreitman@sun.com|mailto:stuart.kreitman@sun.com]] +"""]] diff --git a/CategoryCategory.mdwn b/CategoryCategory.mdwn new file mode 100644 index 00000000..c832b9cc --- /dev/null +++ b/CategoryCategory.mdwn @@ -0,0 +1,8 @@ + +A category is a [[WikiName|WikiName]] that exploits [[!c2 WikiWiki desc="WikiWiki"]]'s reverse linking. If you click on the title of a category page, you'll get a list of pages belonging to that category. To get a list of all categories, click above on the Category****Category title. + +Here is a list of all categories known to this wiki: [[!inline pages="link(CategoryCategory)" quick feeds="no" archive="yes"]] + +Here is a list of all pages containing the CategoryCategory wiki tag: + +To be consistent with the C2 category scheme, all categories start with the word "Category". For more information, see [[!c2 AboutCategoriesAndTopics desc="AboutCategoriesAndTopics"]]****. diff --git a/CategoryHomepage.mdwn b/CategoryHomepage.mdwn new file mode 100644 index 00000000..2045d34c --- /dev/null +++ b/CategoryHomepage.mdwn @@ -0,0 +1,15 @@ + +A category for [[WikiHomePage|WikiHomePage]]****s. + +Note that such pages are "owned" by the respective person, and should not be edited by others, except to leave a message to that person. To do so, just append your message to the page, after four dashes like so: + + +[[!format txt """ +---- +Just saying Hi! -- JürgenHermann +"""]] + + +--- + + [[CategoryCategory|CategoryCategory]] diff --git a/CategoryServerInternals.mdwn b/CategoryServerInternals.mdwn new file mode 100644 index 00000000..2fce4a29 --- /dev/null +++ b/CategoryServerInternals.mdwn @@ -0,0 +1,12 @@ + +The following pages describe internals of the server in some detail. + +To add a page to this category, add a link to this page on the last line of the page. You can add multiple categories to a page. + +**List of pages in this category:** [[!inline pages="link(CategoryServerInternals)" quick feeds="no" archive="yes"]] + + + +--- + + [[CategoryCategory|CategoryCategory]] diff --git a/ChrisBall.mdwn b/ChrisBall.mdwn new file mode 100644 index 00000000..58f34439 --- /dev/null +++ b/ChrisBall.mdwn @@ -0,0 +1,13 @@ + + +## Chris Ball + +Email: chris-xorg AT SPAMFREE printf DOT net + +[[http://printf.net/|http://printf.net/]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/CodingStyle.mdwn b/CodingStyle.mdwn new file mode 100644 index 00000000..7d351c39 --- /dev/null +++ b/CodingStyle.mdwn @@ -0,0 +1,22 @@ + +This page describes the X server's current coding style. While the server was recently reformatted to fit this style, most modules have varied and disparate coding styles. Above all, the cardinal rule is to fit in: make sure your changes reflect the coding style of the surrounding code. + +We use the `indent` command line in this script here: [[http://cgit.freedesktop.org/xorg/util/modular/tree/x-indent.sh|http://cgit.freedesktop.org/xorg/util/modular/tree/x-indent.sh]] with manual editing afterwards to fix the cases where indent gets hopelessly confused. + +* Four-space indents (no tabs, not even if your editor wants to collapse eight consecutive spaces down to a single tab) +* 78-column limit +* Function return type (and any modifiers, eg `static`) on a line by itself +* Opening curly brace on the same line as the control construct: `if (foo) {` + * Closing braces aligned with the keyword that opened them (K&R not GNU) + * `else` on a new line from the closing } of the preceding `if` (i.e. not cuddling) +* Opening curly brace for functions in column 0 +* Keywords punctuated like `if (x >= 0)` +* Functions punctuated like `doSomethingClever(a, b, c);` +* `case` aligned in the same column as the `switch` +* If wrapping is required, function arguments to be aligned to the opening parenthesis of that column +* Wrap structs in typedefs +* C-style <span style="display:none">foo</span> comments, rather than C++/C99-style // foo +* C89 + some extensions, see [[http://cgit.freedesktop.org/xorg/xserver/tree/doc/c-extensions|http://cgit.freedesktop.org/xorg/xserver/tree/doc/c-extensions]] +Notable objectionable things in the current coding style: + +* Most structs have a typedef both for the struct and for a pointer to the struct.
\ No newline at end of file diff --git a/ConfigurationHelp.mdwn b/ConfigurationHelp.mdwn new file mode 100644 index 00000000..485d61d8 --- /dev/null +++ b/ConfigurationHelp.mdwn @@ -0,0 +1,30 @@ + + +# Configuration Help + +If you are using a vendor-supplied Xorg (like on a Linux distribution) please follow your vendor's instruction on how to install and configure Xorg. Your vendor may have provided proprietary configuration tools. **Please consult your vendor's documentation/support** for information on how to use these tools: + +* [[Debian (wiki)|http://wiki.debian.org/Xorg]] +On how to download and install Xorg from the X.Org ftp server please check the [[Installation Instructions|http://www.freedesktop.org/~xorg/current/doc/Install.html]] on the X.Org web site. + +[[!toc ]] + + +## Configuring Xorg + +Xorg provides two ways to configure the Xserver: + +1. Autoconfiguration - Xorg probes the hardware, and if built with HAL support (default in Xorg 1.4 and later) asks HAL to provide input device configuration. +1. Xorg -configure - which can create a skeleton configuration file which should get you started if you need to change a configuration option from the autoconfigured default. + +### Xorg -configure + +The Xserver is capable of creating its own configuration file. As root just run: `X -configure`. The Xserver will then load each driver module, probe for the driver and create a configuration file. The configuration file will be stored in the home directory of the user who started the Xserver (usually `/root`). It's called `xorg.conf.new` so another config file that may exist in this directory will be overwritten. + +You may edit this file by hand to suit your needs. Generally you don't have to modify the mouse type, as the `auto` protocol should suit most needs. If your monitor is DDC capable you don't need to set up monitor ranges. This may not be true for some older cards which don't have DDC support, or if your monitor connection doesn't pass thru DDC information which is the case for some KVMs. + +In case you need to set additional driver options, all available driver options are already listed in the config file. Go to the device section and remove the `'#'` mark at the beginning of the line. If the option requires an additional argument, the type of argument is specified at the end of the line: + +* `[<bool>]` means a boolean argument. Uncommenting the option implicitly means 'True'. To disable the option you can add the string `"0"`, `"no"`, `"false"` or `"off"`. Likewise to enable the option you may use `"1"`, `"yes"`, `"true"` or `"on"`. +* Any integer `[<int>]`, float `[<float>]` value or string `[<str>]` needs to be quoted in double quotes. +* Frequencies `[<freq>]` contain a float value followed by the unit, i.e. `Hz`, `kHz` or `MHz`. Option names and values are case insensitive. For more information please consult `man 5 xorg.conf`.
\ No newline at end of file diff --git a/CorbinSimpson/KillItWithFire.mdwn b/CorbinSimpson/KillItWithFire.mdwn new file mode 100644 index 00000000..8f68d629 --- /dev/null +++ b/CorbinSimpson/KillItWithFire.mdwn @@ -0,0 +1,18 @@ + +I scrapped the talk before I learned that I couldn't show up, as I didn't think it was really that important. There's not a lot left to torch. Still, I did want to talk about a couple points in the graphics stack where the code in question is just rotting away slowly. + +I was going to talk about XAA and EXA, but that's already been done on the [[ML|http://lists.x.org/archives/xorg-devel/2010-September/012844.html]] prior to XDS. The consensus was pretty simple: XAA is still needed for older chipsets. EXA makes two demands that older chipsets can't satisfy: Heavily variable-stride allocations, and lots of compositing with alpha, using 3D engines. Also, XAA still does lots of CPU->GPU stuff, while EXA does GPU->GPU stuff. (Un)surprisingly, XAA comes out ahead in a lot of tests. Even worse, things like UXA may be necessary in order to squeeze the most out of any given chipset family, meaning that we may have to splinter the acceleration hooks in order to get good performance from each driver. Things like Gallium may save the day here; Gallium can plug in EXA from a pipe driver, and (at least according to the Gallium devs that have tested it) it kicks the crap out of the handwritten EXA code for i915 and r300. + +So, summary: Nothing to nuke there. + +The Mesa driver cleanup from last year appears to have been completely successful. There are a couple drivers still not under active management (mach64, mga, tdfx, and savage, IIRC) but that's alright, because they appear to still get tree-wide build fixes and that's apparently enough to keep them working. The radeon team would love to remove r300 and r600 from the classic DRI driver selection once we're sure that there's nothing left that hasn't been picked up in r300g and r600g, but this is complicated by the distros which have deployed r300 and r600 widely already. We'll need to coordinate with them for this. Main Mesa probably should drop whatever legacy GLSL parsing code still remains in favor of the new compiler, which is really maturing into a complete replacement. Gallium's growing pains make it essential that we drop dead code as soon as possible; there are a few auxiliary modules that go unused, and the failover driver is starting to rot. + +Incidentally, there's some code I wanted to bring *into* the Mesa tree, from the various projects that have started to use Gallium in their OS offerings. AROS, Haiku, and Syllable all have patches that I'd like to pick up at some point. + +Summary: We could probably remove a couple things from Mesa. Old GLSL code, r300 and (soon) r600; and failover. + +On the kernel side, there are craploads of FB drivers. Most of them don't have dedicated maintainers and don't really get much love. Bringing them over to KMS would be great, and result in a lot of code cleanup, but the costs are pretty evident: (1) Code has to be written, in non-trivial amounts (2) Nobody has the hardware for some of these old chipsets (3) Deprecation times mean that the old FB drivers have to stay for a long time (4) Nobody really wants any improvements in this area, because status quo works well (5) Since nobody has the hardware, nobody's going to pay for this, so it will have to be driven by amateurs and Copious Spare Time. Things like radeonfb *still* are better than radeon at doing PPC-based stuff. KMS is most useful for the chipsets that have unconsolidated or buggy-by-design code. For example, mga (Matrox G-series) has code for dual-head. Except it's not in the X driver, or in the FB driver. No, it's in *mplayer*. A KMS mga driver that correctly sets up both heads, and handles the weird tiling setup, would be an instant win for all twelve of us in the world with these chipsets. tdfx can't do DRI on a default-depth X server. Some intrepid soul could remedy this with DRI2. (This stuff is all written down at [[http://corbinsimpson.com/cst|http://corbinsimpson.com/cst]], by the way.) + +Summary: OH GOD KILL IT WITH FIRE but not now, how about in a few months when I have some time? + +I think that's just about it. There might have been something else, but I can't remember what it was. diff --git a/CrossCompilingXorg.mdwn b/CrossCompilingXorg.mdwn new file mode 100644 index 00000000..554984be --- /dev/null +++ b/CrossCompilingXorg.mdwn @@ -0,0 +1,96 @@ + +[[!toc ]] +## Introduction + +This page is an attempt to describe the process require to build the modular X.org tree using a crosscompiler. The majority of this document will assume that the reader already has a fully functioning crosscompiler on the _build_ system that can create binaries for the _host_ system. _Build_ and _host_ are the standard terms used by autoconfig to describe the system where the programs will be built (build) and the system where the programs will run (host). It would seem that the system where the programs will run should be called _target_, but that term carries a different meaning in autoconfig. _Target_ is the system for which a compiler (e.g., your crosscompiler) will generate code. Correct use of this terminology will help the process, trust me! + +For crosscompilers targeting Linux systems, [[crosstool|http://www.kegel.com/crosstool/]] is a good choice. + + +## Additional Requirements + +In addition to a crosscompiler, some libraries and headers for the host system must also be available. These can either be crosscompiled or copied from the host system. At a minimum, the following are required: + +* zlib +* libpng +* expat +* freetype +* fontconfig +* libdrm +* openssl (for SHA1) +For at least libdrm, PKG_CONFIG_PATH will need to be set to the location of that library's .pc file. Some configurations are known to build using the default system pkgconfig and simply over-ride the PKG_CONFIG_PATH. However, it may be necessary in some cases to build a "cross" pkgconfig. + + +## Cross compiling dependencies + +The below instructions assume CROSS_COMPILE is set to your toolchain (e.g. export CROSS_COMPILE=arm-none-linux-gnueabi- ) and DISCIMAGE is set to where you want to install. They also assume a Debian/Ubuntu based system - update as appropriate. + +Install zlib +[[!format txt """ + mkdir ~/sources; cd ~/sources + apt-get source zlib + cd zlib* + AR=${CROSS_COMPILE}ar CC=${CROSS_COMPILE}gcc RANLIB=${CROSS_COMPILE}ranlib ./configure --prefix=$DISCIMAGE/usr/local/ + make + make install +"""]] +Install libpng +[[!format txt """ + cd ~/sources + apt-get source libpng + cd libpng* + LDFLAGS="-L$DISCIMAGE/usr/local/lib" CPPFLAGS="-I$DISCIMAGE/usr/local/include" ./configure --prefix=$DISCIMAGE/usr --host=${CROSS_COMPILE%-} + make + make install +"""]] +Install expat +[[!format txt """ + cd ~/sources + apt-get source expat + cd expat* + AR=${CROSS_COMPILE}ar CC=${CROSS_COMPILE}gcc ./configure --prefix=$DISCIMAGE/usr/local/ --host=${CROSS_COMPILE%-} + make + make install +"""]] +Install openssl(For SHA-1) +[[!format txt """ + cd ~/sources + wget http://www.openssl.org/source/openssl-0.9.8h.tar.gz + tar -zxvf openssl-0.9.8h.tar.gz + cd openssl* + ./Configure dist --prefix=$DISCIMAGE/usr/local + make CC="${CROSS_COMPILE}gcc" AR="${CROSS_COMPILE}ar r" RANLIB="${CROSS_COMPILE}ranlib" + make CC="${CROSS_COMPILE}gcc" AR="${CROSS_COMPILE}ar r" RANLIB="${CROSS_COMPILE}ranlib" install +"""]] +Install jhbuild, on build machine (This isn't needed, but makes life easier) +[[!format txt """ + svn co http://svn.gnome.org/svn/jhbuild/trunk jhbuild + cd jhbuild + ./autogen.sh + make -f Makefile.plain install +"""]] +TODO: Other dependencies are needed depending on what you are doing. Please update these instructions if you need to install them. + + +## Using jhbuild to compile + +Copy and modify the example ~/.jhbuildrc file at [[CrossCompilingXorgJhbuild|CrossCompilingXorgJhbuild]] and then run +[[!format txt """ + jhbuild xserver +"""]] +X should now cross compile. General Jhbuild instructions are given at [[JhBuildInstructions|JhBuildInstructions]]. Feel free to mention any problems that you've come across here, along with solutions if you have them. + + +## Compiling without JHBuild + +This is not necessary if you use JHBuild to build. However if you do not want to, you will have to configure and build manually. Below are some general instructions to help you. + +To enable crosscompiling the _--host_ and _--build_ flags must be passed to configure. If the _build.sh_ script is being used, this can be done by setting CONFFLAGS. Both of these flags take a standard autoconfig system description. For example, to build on an x86-64 system running Linux for a PowerPC system running also running Linux, CONFFLAGS should be set to "--build x86_64-unknown-linux-gnu --host powerpc-unknown-linux-gnu". Based on these settings, the configure scripts will assume that the crosscompiler is named powerpc-unknown-linux-gnu-gcc and is in the path. If the compiler named something different, the name must be providied via the CC environment variable. The C++ compiler (CXX), linker (LD), ranlib (RANLIB), and ar (AR) must also be provided in this manner. + +Some components need to build and run programs on the build system that generate output used in the build process. For this compnents, CC_FOR_BUILD must be set to the name of the compiler that targets the build system. The majority of these components do not correctly use CC_FOR_BUILD, but there is a patch (see below) available. + +A number of steps in the autoconfig process implicitly assume that the build system and the host system are the same. For example, library components want to build and run test programs to determine the behavior of certain host system elements. This is clearly impossible when crosscompiling. To work around these issues, the --enable-malloc0returnsnull (or --disable-malloc0returnsnull, depending on the host system) must be passed to configure. + +In addition, the configure scripts for the video drivers use methods for detecting the availability of DRI that are incompatible with crosscompiling. Until a fix is provided, drivers must either be built on the host system or --disable-dri must be provided to their configure scripts. The issue in the drivers' configure scripts does _not_ effect the core X server. + +The -h and -b options to build.sh supply the --host and --build options to the configure scripts automatically. In addition, the value passed to -h is used in operation system and processor architecture based determinations of which drivers to build. The modifications to build.sh are based on the build.sh script that I use, but they have not been completely tested. If you encounter problems, please post to the xorg mailing list. diff --git a/CrossCompilingXorgJhbuild.mdwn b/CrossCompilingXorgJhbuild.mdwn new file mode 100644 index 00000000..30a1d3a8 --- /dev/null +++ b/CrossCompilingXorgJhbuild.mdwn @@ -0,0 +1,77 @@ +Below is a sample `~/.jhbuildrc` file to cross compile build X. Replace arm-none-linux-gnueabi with your toolchain. It assumes that you have export'ed `DISCIMAGE` to where you want to install to.
+
+ #!python
+ #######################################################################################
+ # This is a checkout and build configuration for building Xorg
+ #
+ # This can be copied to ~/.jhbuildrc and then run 'jhbuild build xserver'
+ #
+ #######################################################################################
+
+ moduleset = 'http://cgit.freedesktop.org/xorg/util/modular/plain/xorg.modules'
+ checkoutroot = '~/sources/xorg/git'
+ modules = [ 'xorg' ]
+ prefix = os.environ['DISCIMAGE'] +'/usr/local'
+
+ autogenargs = ' --disable-static'
+ autogenargs += ' --disable-dri2 --with-driver=dri'
+ autogenargs += ' --cache-file=' + checkoutroot + '/autoconf-cache'
+ # lots of people really like to always look in /var/log, but change if
+ # you want the log files out of place
+ autogenargs += ' --with-log-dir=/var/log'
+ autogenargs += ' --with-mesa-source=' + checkoutroot + '/mesa'
+ autogenargs += ' --enable-malloc0returnsnull'
+
+ os.environ['ACLOCAL'] = 'aclocal -I ' + prefix + '/share/aclocal/'
+ os.environ['INSTALL'] = os.path.expanduser('~/bin/install-check')
+
+ # Enabled debugging for xserver
+ os.environ['CFLAGS'] = '-g'
+ os.environ['CPPFLAGS'] = '-g'
+
+ # Setup environment for cross compiling
+
+ os.environ['BUILD'] = 'i686-pc-linux-gnuaout'
+ os.environ['HOST'] = 'arm-none-linux-gnueabi'
+ os.environ['TARGET'] = 'arm-none-linux-gnueabi'
+
+ cross_compile_prefix = os.environ['CROSS_COMPILE']
+ tools = {'ADDR2LINE': 'addr2line',
+ 'AS': 'as', 'CC': 'gcc', 'CPP': 'cpp',
+ 'CPPFILT': 'c++filt', 'CXX': 'g++',
+ 'GCOV': 'gcov', 'LD': 'ld', 'NM': 'nm',
+ 'OBJCOPY': 'objcopy', 'OBJDUMP': 'objdump',
+ 'READELF': 'readelf', 'SIZE': 'size',
+ 'STRINGS': 'strings', 'AR': 'ar',
+ 'RANLIB': 'ranlib', 'STRIP': 'strip'}
+
+ tools_args = str()
+ for tool in tools.keys():
+ fullpath_tool = cross_compile_prefix + tools[tool]
+ os.environ[tool] = fullpath_tool
+
+ autogenargs += ' --build='+os.environ['BUILD']
+ autogenargs += ' --host='+os.environ['HOST']
+ autogenargs += ' --target='+os.environ['TARGET']
+
+ for tool in ('AR', 'RANLIB', 'STRIP', 'AS', 'OBJDUMP', 'NM'):
+ autogenargs += ' '+tool+'="'+os.environ[tool]+'" '
+
+ module_autogenargs['libGL'] = autogenargs + ' --without-demos --with-dri-drivers="swrast" --disable-glw'
+ module_autogenargs['libXt'] = autogenargs + ' --disable-install-makestrs'
+ module_autogenargs['xserver'] = autogenargs + ' --enable-debug'
+ module_autogenargs['pixman'] = autogenargs + ' --disable-gtk'
+ module_autogenargs['hal'] = autogenargs + ' --disable-pci-ids'
+ module_autogenargs['libXfont'] = autogenargs + ' --disable-freetype'
+
+ # For expat and zlib
+ os.environ['CFLAGS'] += ' -I' + os.environ['DISCIMAGE'] + '/usr/local/include/'
+ os.environ['CPPFLAGS'] += ' -IHello -I' + os.environ['DISCIMAGE'] + '/usr/local/include/'
+ os.environ['LDFLAGS'] = ' -L' + os.environ['DISCIMAGE'] + '/usr/local/lib/'
+ os.environ['LDFLAGS'] += ' -Wl,--rpath -Wl,' + '/usr/local/lib/' #rpath is relative to where it is run from - DISCIMAGE
+
+ # Just in case zlib or expat were installed here
+ os.environ['CFLAGS'] += ' -I' + os.environ['DISCIMAGE'] + '/usr/include/'
+ os.environ['CPPFLAGS'] += ' -I' + os.environ['DISCIMAGE'] + '/usr/include/'
+ os.environ['LDFLAGS'] += ' -L' + os.environ['DISCIMAGE'] + '/usr/lib/'
+ os.environ['LDFLAGS'] += ' -Wl,--rpath -Wl,' + '/usr/lib/'
diff --git a/DanielStone.mdwn b/DanielStone.mdwn new file mode 100644 index 00000000..ee57e3c0 --- /dev/null +++ b/DanielStone.mdwn @@ -0,0 +1,12 @@ + + +## Daniel Stone + +[[daniel@fooishbar.org|mailto:daniel@fooishbar.org]] + [[http://fooishbar.org|http://fooishbar.org]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/DanielVetter.mdwn b/DanielVetter.mdwn new file mode 100644 index 00000000..fcc8d3f7 --- /dev/null +++ b/DanielVetter.mdwn @@ -0,0 +1,15 @@ + + +## Daniel Vetter + +Email: daniel AT SPAMFREE ffwll DOT ch or daniel DOT vetter AT SPAMFREE ffwll DOT ch + +IRC: danvet (that's also my user name on fd.org) + +Blog: [[http://blog.ffwll.ch|http://blog.ffwll.ch]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/DeprecatedInX11R7.mdwn b/DeprecatedInX11R7.mdwn new file mode 100644 index 00000000..553639c4 --- /dev/null +++ b/DeprecatedInX11R7.mdwn @@ -0,0 +1,14 @@ + +The following modules are formally deprecated in the 7.0 release, and will not be added to the modular tree: + +* Display PostScript +* Speedo font module & fonts (disabled by default in 6.8 and 6.9) +* The wacom(4) input driver; the [[linuxwacom|http://linuxwacom.sf.net/]] project provides a superior replacement. +The following modules will not be included in the 7.0 release if no maintainer is forthcoming: + +* Xsun and XsunLynx DDXes. +The following subsystems are scheduled to be removed after the 7.0 release: + +* All module loader backends besides the libdl backend. +* The "Keyboard" driver (deprecated in 6.8 in favor of "kbd" driver on platforms that support it) + * "kbd" doesn't work on 2.4-kernel sparcs, apparently because of some kernel keymap problems. And 2.6 kernels aren't working well on sparcs yet for other reasons.
\ No newline at end of file diff --git a/DevPrivates.mdwn b/DevPrivates.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/DevPrivates.mdwn diff --git a/DeveloperStart.mdwn b/DeveloperStart.mdwn new file mode 100644 index 00000000..3974c629 --- /dev/null +++ b/DeveloperStart.mdwn @@ -0,0 +1,72 @@ + + +## Information for developers + +* Start reading the [[Development|Development]] page. +* Read the [[Developer's FAQ|DevelopersFAQ]] and the [[ModularDevelopersGuide|ModularDevelopersGuide]]. +* Read the [[ToDo|ToDo]], and add to it if you think it's lacking. +* [[RepoPolicy|RepoPolicy]] covers the general commit rules. +* [[CodingStyle|CodingStyle]] gives a guideline for the general coding style in X. +* [[XorgTriage|XorgTriage]] outlines our bugzilla workflow. + +## Module-specific information + +* [[XServer|XServer]] +* [[IntelVideoDriver|IntelVideoDriver]] +* [[Driver for Nvidia chips|http://nouveau.freedesktop.org/]] +* [[Driver for ATI/AMD Radeon chips|radeon]] +* [[Drivers for VMware virtual graphics|vmware]] + +## X.Org Foundation Workgroups + +* [[Architecture Working Group|ArchitectureWorkingGroup]] +* [[Modularization Working Group|ModularizationWorkingGroup]] +* [[Release Wranglers|ReleaseWorkingGroup]] +* [[Testing Working Group|TestGroup]] + +## Source Code + +Virtually all the source code of the server, the drivers and the default applications is hosted on the git server of freedesktop.org. It can be browsed on-line via the [[cgit interface|http://cgit.freedesktop.org/]]. For more details, refer to the [[git|http://www.freedesktop.org/wiki/Infrastructure/git]] page. + +Alternatively, all the most recent released packages can be found as tarballs at [[http://ftp.x.org/pub/individual/|http://ftp.x.org/pub/individual/]] . + + +## Specifications and reference manuals + +A lot of specifications can be found in the git tree, in [[doc/xorg-docs|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/]]. Short documents are in plain text format, while bigger ones tends to be in troff or [[DocBook|DocBook]] format, and will therefore need to be compiled to be read easily. + +The documentation of each component is gradually split out into their respective modules. In particular: + +* [[XRandR|http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt]] +* [[DRI2|http://cgit.freedesktop.org/xorg/proto/dri2proto/tree/dri2proto.txt]] +* [[XML-XCB|http://cgit.freedesktop.org/xcb/proto/tree/doc/xml-xcb.txt]] +* [[Render|http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt]] +* [[DAMAGE|http://cgit.freedesktop.org/xorg/proto/damageproto/tree/damageproto.txt]] +* [[XFIXES|http://cgit.freedesktop.org/xorg/proto/fixesproto/tree/fixesproto.txt]] +* [[VAAPI|http://cgit.freedesktop.org/libva/tree/src/va.h]] +You might also be interested by the [[list of specifications|http://www.freedesktop.org/wiki/Specifications]] available at freedesktop.org. + + +## Fixing bugs + +Bugs assigned to the [[freedesktop bugzilla|http://bugs.freedesktop.org]] pseudo-user [[xorg-team@lists.x.org|mailto:xorg-team@lists.x.org]] need someone to take ownership of them. If you feel qualified to fix the bug, feel free to take ownership of the bug by reassigning it to yourself. + + +## Submitting patches + +Please read the [[patch submission guidelines|http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches]] + + +## Requesting features + +Please remember that X is just one component of the overall free desktop and that therefore future X enhancements should be thought through with this perspective. Also remember that the folks here are massively overloaded---by far the most reliable way to get a feature in is to put it there yourself. + + +## To Do + +See the [[ToDo|ToDo]] page for a list of tasks that need to be done specific to Xorg. A more comprehensive list [[of unfinished X related projects|http://www.freedesktop.org/wiki/FreedesktopProjects]] (not necessarily involving working on the server itself) is also available. Both of these lists may be a bit out-of-date, so do hit the email lists once you've gotten yourself oriented. + + +## The X.Org Endless Vacation of Code + +A special program to provide financial support for student contributors who are unable to participate in the bigger (and better known) program of this type, Google Summer of Code. Open all-year round. Look at [[ToDo|ToDo]] page for project ideas, and at [[the EVoC rules|XorgEVoC]], and see if you can help. diff --git a/DevelopersFAQ.mdwn b/DevelopersFAQ.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/DevelopersFAQ.mdwn diff --git a/DevelopersPages.mdwn b/DevelopersPages.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/DevelopersPages.mdwn diff --git a/Development.mdwn b/Development.mdwn new file mode 100644 index 00000000..1a52f3fd --- /dev/null +++ b/Development.mdwn @@ -0,0 +1,54 @@ + +This page has general information on X development, including how to get started. + +A common misconception is that developers need to understand all of X to get started. This is not true, and even of the "core" developers, only few actually know all the pieces that put X together. The best way to get started is to simply pick a problem and give it a try. + +There is also a new book in the Amazon Kindle format, [[Hands-on Projects for the Linux Graphics Subsystem|http://www.amazon.com/dp/B007QJKOGS/ref=rdr_ext_sb_ti_hist_1]]. This includes a number of original projects on the X.Org implementation of the Linux graphics subsystem. The book is aimed for instructors, students and any other OS internals enthusiasts. + + +## Documentation + +* [[Glossary|Development/Documentation/Glossary]]: Various terms used in X, and what they mean. +* [[Modular Developers Guide|ModularDevelopersGuide]]: For builders and developers working on the modular X.Org source tree +* [[Submitting patches|Development/Documentation/SubmittingPatches]]: How to submit a patch to an Xorg project. +* [[Making a release|Development/Documentation/ReleaseHOWTO]]: How to make an individual module release. +* [[Writing documentation|Development/Documentation/WritingDocumentation]]: How to document your work in X. +* [[Documentation being converted to DocBook|Development/Documentation/DocBookConversion]]: What needs to be converted and what is being converted +* [[X server source layout|Development/Documentation/XserverSourceLayout]]: A map to the different directories in the X server source +* [[The devPrivates system|Development/Documentation/DevPrivates]]: All about the private storage system in the server. +* [[Wrapping functions|Development/Documentation/WrappingFunctions]]: How to add hooks to functions in the server. +* [[Grab processing|Development/Documentation/GrabProcessing]]: How input grabs are dealt with in the server. +* [[Cursor handling|Development/Documentation/CursorHandling]]: Introduction into DIX cursor handling. +* [[Input event processing|Development/Documentation/InputEventProcessing]]: How input events are dealt with in the server. +* [[Security|Development/Documentation/Security]]: How to make use of the security facilities within X. +* [[Performance|Development/Documentation/Performance]]: A fairly detailed document explaining what our performance problems actually are, and things that aren't performance problems at all. +* [[Xorg input driver HOWTO|Development/Documentation/XorgInputHOWTO]]: How to write an input driver for X.Org. +* [[How video cards work|Development/Documentation/HowVideoCardsWork]]: A conceptual overview. +* [[Xorg video driver HOWTO|Development/Documentation/XorgVideoHOWTO]]: How to write a basic video driver for X.Org. +* [[Kdrive Drivers|Development/Documentation/KdriveDrivers]]: notes for making new kdrive video drivers +* [[Dri Wiki|http://dri.freedesktop.org/wiki/]]: Information about using the Direct Rendering Infrastructure (DRI) with X. +* [[Multiseat|Development/Documentation/Multiseat]]: Various informations about how to obtain and develop such model. +* [[Deprecated and obsolete|Development/Documentation/Obsolescence]]: Notes on deprecated and obsolete extensions and server-side stuff. +* [[More Xorg Documentation|XorgDeveloperDocumentation]]: Some pointers from deep in the Wiki. This page should possibly be moved into Development/Documentation. +* [[Pointer acceleration|Development/Documentation/PointerAcceleration]]: information on the pointer accel mechanism. + +#### Tools + +* [[Using git|Development/Documentation/git]]: Information on using git. +* [[Server debugging|Development/Documentation/ServerDebugging]]: How to debug the X server with gdb. +* [[Server profiling|Development/Documentation/ServerProfiling]]: How to profile the X server. +* [[Using ctags to find functions|Development/Documentation/UsingCtags]]: Some tips to find a function in vim. +* [[Using Eclipse|Development/Documentation/UsingEclipse]]: Some tips to use Eclipse to develop X.Org. + +#### Various Projects + +* [[PciReworkHowto|PciReworkHowto]]: How to fix a video driver to use libpciaccess +* [[VgaArbiter|VgaArbiter]]: Routing VGA instructions correctly. +* [[Xv2, Render API|Development/Xv2]]: a long rambling discussion about giving Pictures GCs, and moving Xv to Render + RandR. +* [[X12|Development/X12]]: a list of things we'd fix if we ever get around to a new version of the core X protocol + +## Helping out + +* [[ContributionHOWTO|Development/ContributionHOWTO]]: How to get started contributing bug reports, patches, fixes, or even entire drivers. +* [[ToDo|ToDo]]: Things that need doing. +* [[Janitor|Development/Janitor]] Xorg Janitor project page
\ No newline at end of file diff --git a/Development/BuildingX.mdwn b/Development/BuildingX.mdwn new file mode 100644 index 00000000..218b61ad --- /dev/null +++ b/Development/BuildingX.mdwn @@ -0,0 +1,504 @@ + +**This page contains some outdated information. To get an up-to-date description of how to build the packages, please take a look at [[ModularDevelopersGuide|ModularDevelopersGuide]].** +# Modular X development using the git trees + +Since it's fairly common to do development that touches several layers of the graphics stack, this guide will cover building the whole thing, from the DRM up through the X server and drivers. We'll install the whole stack into a separate directory, just to keep things separated from the distribution packages we (presumably) want to keep working as we break things in our sandbox. + +On a basic level, you'll need to build things in roughly this order: + +1. kernel +1. Dependencies +1. DRM (both libdrm & the DRM modules for non-intel) +1. Mesa +1. X server +1. X drivers +An alternate method of building the packages in a more automated fashion using the jhbuild utility can be found in the [[JhBuildInstructions|JhBuildInstructions]]. + +Everything described underneath is also available as a pre made script, located at the bottom of this page. + + +## Minimum requirements + +Basically, Linux 2.6.x, Free/Net/OpenBSD, OpenSolaris/Solaris 10, Hurd, OS X 10.5, and Cygwin systems should work fine on any architecture these are likely to run on. Compiler-wise, gcc 3.x, Intel icc, Sun Studio, and llvm-clang are generally known to work. See below if you're looking at a port: + + +[[!format txt """ +So, here's the assumptions I've been working from: + +The X server core and software DDXes should build and work on basically +all of the free BSDs (not counting Darwin), Solaris 10+ and OpenSolaris, +Linux, Hurd, and some versions of SCO, on any CPU architecture they +support. Kdrive's hardware servers - basically just Xfbdev at this +point - is Linux-only; the rest should work anywhere. The Xorg DDX +could probably be built for just about any architecture, but it doesn't +really make sense to do so in all cases; s390 doesn't have a PCI bus, so +it'd be a bit silly. But the bus support code is in some sense +optional, an arm port wouldn't necessarily need PCI support, etc. The +Xorg DDX does assume a vaguely ELF-like linking environment and a +libdl-like interface to it; this isn't a problem for any of the +currently supported ports, but anyone trying to port it to OSX, AIX, or +ancient HP/UX would probably have issues. + +Obviously, the xwin and quartz DDXes are platform-specific. + +The server's compiler needs to be C89 plus a few common C99 extensions. +Don't say "requires C99"; no compiler completely supports C99 yet, as +far as I'm aware. Yes, even gcc: + +http://gcc.gnu.org/c99status.html + +Most of the client libs and apps should work on pretty much any vaguely +modern unix; there's generally no compelling need to break them, and +indeed most of the apps should be left the hell alone because they're +not things we want to encourage people to use. xtrans is sort of a +special case because it's so deeply tied to the X server, it should be +considered as portable as the server is. + +Non-server compiler pretty much just needs to be C89 or better. + +- ajax +"""]] + +## Kernel + +As of linux 2.6.28, the canonical upstream for the Intel DRM (direct rendering manager) code is the linux kernel, and replaces the linux-core build below for other chipsets. There are plenty of instructions on building your own kernel out there, but the quick summary is: +[[!format txt """ +git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git +cd linux-2.6 +make menuconfig +# Choose CONFIG_AGP=y +# Choose CONFIG_AGP_INTEL=y +# Choose CONFIG_DRM=m +# Choose CONFIG_DRM_I915=m +make +sudo make install modules_install +sudo update-grub +sudo reboot +"""]] + +## Building Dependencies + +Autoconf (part of the autotools system X uses for its build system) likely needs macros defined by X. These are included in the util/macros package: + +* macros - _git://git.freedesktop.org/git/xorg/util/macros_ +Once you've installed the macros, you need to let the other packages use them: + +1. `export ACLOCAL="aclocal -I /opt/gfx-test/share/aclocal"` +Mesa and the X server proper have several dependencies, and depending on your distribution you may need to update some of the libraries, headers, and prototypes it depends on before configuring the build. Common examples include: + +* libx11proto - _git://git.freedesktop.org/git/xorg/proto/x11proto_ +* libxtrans - _git://git.freedesktop.org/git/xorg/lib/libxtrans_ +* libX11 - _git://git.freedesktop.org/git/xorg/lib/libX11_ +* libXext - _git://git.freedesktop.org/git/xorg/lib/libXext_ +* dri2proto - _git://git.freedesktop.org/git/xorg/proto/dri2proto_ +* glproto - _git://git.freedesktop.org/git/xorg/proto/glproto_ +* pciaccess - _git://git.freedesktop.org/git/xorg/lib/libpciaccess_ +* pixman - _git://git.freedesktop.org/git/pixman_ +The usual _git clone path; cd package; ./autogen.sh --prefix=/opt/gfx-test; make; make install_ sequence should build these modules. + +Once the build & install has completed, you'll need to set your PKG_CONFIG_PATH environment variable, so subsequent configurations will pick up your new bits. + +1. `export PKG_CONFIG_PATH=/opt/gfx-test/lib/pkgconfig` + +## Building DRM + +See [[http://dri.freedesktop.org/wiki/Building|http://dri.freedesktop.org/wiki/Building]]. In short: + +The DRM (Direct Rendering Manager) provides kernel and library interfaces to clients wanting access to kernel managed resources like interrupts, buffer swaps, DMA memory mapping and graphics memory management. Building it is fairly straightforward: + +1. `git clone git://git.freedesktop.org/git/mesa/drm` +1. `cd drm` +1. `./autogen.sh --prefix=/opt/gfx-test` _# or wherever you want to install it._ +1. `make` +1. `make -C linux-core` _# assuming you're on Linux, otherwise use bsd-core. Don't bother for intel._ +1. `make install` _# with new drm gem, like Intel. On make install try don't overwrite drm kernel headers with this drm headers of libdrm. _ + +## Building Mesa + +See [[http://dri.freedesktop.org/wiki/Building|http://dri.freedesktop.org/wiki/Building]]. In short: + +The Mesa package contains the GL stack and its associated chip specific drivers, which provide direct and indirect rendering acceleration. Note that to build some of the test programs there is a dependency on the development packages for GLUT. You'll have to ensure those development packages have been installed, or you can disable building the GLUT programs by adding_ --disable-glut_ to the autogen line below. You will still be able to build the common demo programs such as glxgears without GLUT, though. + +1. `git clone git://git.freedesktop.org/git/mesa/mesa` +1. `cd mesa` +1. `./autogen.sh --prefix=/opt/gfx-test --with-driver=dri --disable-glut` +1. `make` +1. `make install` +1. `mkdir -p /opt/gfx-test/bin` +1. `install -m755 progs/xdemos/{glxinfo,glxgears} /opt/gfx-test/bin/` + +### Gallium build instructions + +Gallium is an alternative architecture for hardware acceleration in mesa. It is currently a branch in the official mesa tree. + +1. `git clone git://git.freedesktop.org/git/mesa/mesa` +1. `cd mesa` +1. `git checkout origin/gallium-0.1` +1. `make` with whatever target you want (the list of targets is in mesa/configs/, common targets are linux, linux-dri, linux-dri-x86 and linux-dri-x86-64) + +## Building the X Server + +* Here we build the X server with builtin fonts so we don't have to do too much configuration later. Note if you're building DMX or Xgl for example you need the `--with-mesa-source` option. +* `git clone git://git.freedesktop.org/git/xorg/xserver` +* `cd xserver` +* `./autogen.sh --prefix=/opt/gfx-test --enable-builtin-fonts` +* `make` +* `make install` +* `chown root /opt/gfx-test/bin/Xorg; chmod +s /opt/gfx-test/bin/Xorg` _# assuming you don't run as root_ + +### Making the keyboard work + + +#### Using disto setup + +If you have a non qwerty keyboard, and don't want to install XKeyboardConfig, you might want to add the following flag to the autogen.sh script, when building the X server : + +* `--with-xkb-path=/usr/share/X11/xkb` +(You may need to adjust the path depending on your distribution). + +Also the X server will search for the xkbcomp program in `/opt/gfx-test/bin`. So you will need to create a symbolic link to your distribution xkbcomp : + +* `cd /opt/gfx-test/bin` +* `ln -s /usr/bin/xkbcomp xkbcomp` + +#### From scratch + +Or you can install the XKeyboardConfig definitations + +* git clone git://anongit.freedesktop.org/git/xkeyboard-config +* cd xkeyboard-config/ +* ./autogen.sh --prefix=$PREFIX +* make +* make install And the xkbcomp tool +* git clone git://git.freedesktop.org/git/xorg/app/xkbcomp +* cd xkbcomp/ +* ./autogen.sh --prefix=$PREFIX +* make +* make install + +## Building X drivers + +Presumably you'll want a video driver and a couple of input drivers at a minimum. We'll do xf86-input-mouse, xf86-input-keyboard, and xf86-video-intel here. + + +### xf86-input-mouse + +1. `git clone git://git.freedesktop.org/git/xorg/driver/xf86-input-mouse` +1. `cd xf86-input-mouse` +1. `./autogen.sh --prefix=/opt/gfx-test` +1. `make` +1. `make install` + +### xf86-input-keyboard + +1. `git clone git://git.freedesktop.org/git/xorg/driver/xf86-input-keyboard` +1. `cd xf86-input-keyboard` +1. `./autogen.sh --prefix=/opt/gfx-test` +1. `make` +1. `make install` +You possibly will want the evdev driver, especially if your distro uses the evdev system + + +### xf86-input-evdev + +1. `git clone git://git.freedesktop.org/git/xorg/driver/xf86-input-evdev` +1. `cd xf86-input-evdev` +1. `./autogen.sh --prefix=/opt/gfx-test` +1. `make` +1. `make install` + +### xf86-video-intel + +1. `git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel` +1. `cd xf86-video-intel` +1. `./autogen.sh --prefix=/opt/gfx-test` +1. `make` +1. `make install` + +## Running your new stack + +Now that your development environment is set up, you can try running it (as root). + +This first 4 steps are no longer need, for the drives which use new drm gem, which is the case of Intel. + +1. `rmmod i915` _# assuming you're using Intel_ +1. `rmmod drm` +1. `insmod `_<path_to_drm_tree_above>_`/linux-core/drm.ko` +1. `insmod `_<path_to_drm_tree_above>_`/linux-core/i915.ko` +1. `export LD_LIBRARY_PATH=/opt/gfx-test/lib` +1. `startx -- /opt/gfx-test/bin/Xorg -verbose` _# make sure you have a ~/.xinitrc with what you want to run_ +And there you have it, a fresh stack ready for tracking & doing upstream development. Enjoy! + + +## Troubleshooting + +If you can't install the drm kernel module with the message (can't allocate memory), you perhaps set the virtual size in xorg.conf higher than your graphic memory size. + + +## Quick and easy way to install a development build + +on debian/ubuntu this script depends on the following packages: build-essential git-core autoconf automake sudo libtool pkg-config xsltproc xcb-proto libfreetype6-dev libexpat1-dev libssl-dev +[[!format txt """ +# !/bin/bash + +## X.org development build script +## @author Łukasz Jernaś - original version +## @author legolas558 - some improvements +# + +PREFIX="/opt/gfx-test" +PKG_CONFIG_PATH=/opt/gfx-test/lib/pkgconfig + +# Attempt to detect proper concurrency level +CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//` +CONCURRENCY_LEVEL=$(( $CPU_CORES + 1 )) + +MAKE="make" +MAKEINST="sudo make install" + +## the freedesktop git server +GFDR="git://git.freedesktop.org/git" + +REPOS="\ +$GFDR/xorg/util/macros \ +$GFDR/xorg/proto/x11proto \ +$GFDR/xorg/proto/damageproto \ +$GFDR/xorg/proto/xextproto \ +$GFDR/xorg/proto/fontsproto \ +$GFDR/xorg/proto/videoproto \ +$GFDR/xorg/proto/renderproto \ +$GFDR/xorg/proto/inputproto \ +$GFDR/xorg/proto/xf86vidmodeproto \ +$GFDR/xorg/proto/xf86dgaproto \ +$GFDR/xorg/proto/xf86driproto \ +$GFDR/xorg/proto/xcmiscproto \ +$GFDR/xorg/proto/scrnsaverproto \ +$GFDR/xorg/proto/bigreqsproto \ +$GFDR/xorg/proto/resourceproto \ +$GFDR/xorg/proto/compositeproto \ +$GFDR/xorg/proto/fixesproto \ +$GFDR/xorg/proto/evieproto \ +$GFDR/xorg/proto/kbproto \ +$GFDR/xorg/lib/libxtrans \ +$GFDR/xorg/lib/libX11 \ +$GFDR/xorg/lib/libXext \ +$GFDR/xorg/lib/libXi \ +$GFDR/xorg/lib/libxkbfile \ +$GFDR/xorg/lib/libfontenc \ +$GFDR/xorg/lib/libXfont \ +$GFDR/xorg/lib/libXfixes \ +$GFDR/xorg/lib/libXdamage \ +$GFDR/xorg/lib/libXv \ +$GFDR/xorg/lib/libXvMC \ +$GFDR/xorg/lib/libXxf86vm \ +$GFDR/xorg/lib/libXinerama \ +$GFDR/xorg/proto/dri2proto \ +$GFDR/xorg/proto/glproto \ +$GFDR/xorg/lib/libpciaccess \ +$GFDR/pixman \ +$GFDR/xcb/proto \ +$GFDR/xcb/pthread-stubs \ +$GFDR/xorg/lib/libXau \ +$GFDR/xcb/libxcb \ +$GFDR/xorg/proto/randrproto \ +$GFDR/mesa/drm \ +$GFDR/mesa/mesa \ +$GFDR/xorg/xserver \ +$GFDR/xorg/driver/xf86-input-mouse \ +$GFDR/xorg/driver/xf86-input-keyboard \ +$GFDR/xorg/driver/xf86-video-intel" + +modules="\ +fontsproto \ +x11proto \ +xextproto \ +videoproto \ +renderproto \ +inputproto \ +damageproto \ +xf86vidmodeproto \ +xf86dgaproto \ +xf86driproto \ +xcmiscproto \ +scrnsaverproto \ +bigreqsproto \ +resourceproto \ +compositeproto \ +resourceproto \ +evieproto \ +kbproto \ +fixesproto \ +proto \ +pthread-stubs \ +libxcb \ +libXext \ +libxtrans \ +libX11 \ +libXau \ +libXi \ +libxkbfile \ +libfontenc \ +libXfont \ +libXv \ +libXvMC \ +libXxf86vm \ +libXinerama \ +libXfixes \ +libXdamage \ +dri2proto \ +glproto \ +libpciaccess \ +pixman \ +randrproto" + +init() +{ + for repo in $REPOS; do + echo "Cloning $repo" + git clone $repo + done + cd macros + echo "Building macros" + ./autogen.sh --prefix="$PREFIX" + ($MAKE) && \ + $($MAKEINST) + cd .. +} + +update_modules() +{ + for module in $modules; do + echo "Updating $module" + cd $module + git pull || return $? + cd .. + done +} + +configure () +{ + export ACLOCAL="aclocal -I $PREFIX/share/aclocal" + export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig" + ## configure all modules + for i in $modules; do + cd $i + echo ====================== + echo configuring $i + echo ====================== + ./autogen.sh --prefix="$PREFIX" + if [ $? -ne 0 ]; then + echo "Failed to configure $i." + if [[ "$i" == "libX11" ]]; then + echo "If you are getting a libX11 error related to xtrans, install xtrans package into your system" + fi + exit -1 + fi + cd .. + + done + # build drm + cd drm + ./autogen.sh --prefix="$PREFIX" + if [ $? -ne 0 ]; then + echo "Failed to configure DRM." + exit -2 + fi + # assuming you're on Linux, otherwise use bsd-core + cd .. +## configure mesa + cd mesa + ./autogen.sh --prefix=$PREFIX --with-driver=dri --disable-glut --with-state-trackers="egl dri" + if [ $? -ne 0 ]; then + echo "Failed to configure Mesa." + exit -3 + fi + cd .. +## configure xserver + cd xserver + ./autogen.sh --prefix=$PREFIX --enable-builtin-fonts + if [ $? -ne 0 ]; then + echo "Failed to configure X server." + exit -4 + fi + cd .. +## mouse, keyboard and intel video + for MYM in "xf86-input-mouse xf86-input-keyboard xf86-video-intel"; do + cd $MYM && \ + ./autogen.sh --prefix=$PREFIX + if [ $? -ne 0 ]; then + echo "Failed to configure $MYM." + exit -5 + fi + cd .. + done +} + +build () +{ + export ACLOCAL="aclocal -I $PREFIX/share/aclocal" + export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig" + for i in $modules; do + cd $i + echo ====================== + echo building $i + echo ====================== + ($MAKE) && \ + ($MAKEINST) || return $? + cd .. + + done + # build drm + cd drm + ## commented because not working - legolas558 + # assuming you're on Linux, otherwise use bsd-core +## make -C linux-core + ($MAKE) && \ + ($MAKEINST) || return $? + cd .. +## build mesa + cd mesa + ($MAKE) && \ + ($MAKEINST) && \ + mkdir -p $PREFIX/bin && \ + sudo install -m755 progs/xdemos/{glxinfo,glxgears} $PREFIX/bin/ || return $? + cd .. +## build xserver + cd xserver + ($MAKE) && \ + ($MAKEINST) && \ + sudo chown root $PREFIX/bin/Xorg && \ + sudo chmod +s $PREFIX/bin/Xorg || return $? + cd .. +## build mouse, keyboard and intel video driver + for MYM in "xf86-input-mouse xf86-input-keyboard xf86-video-intel"; do + cd $MYM && \ + ($MAKE) && \ + ($MAKEINST) + if [ $? -ne 0 ]; then + echo "Failed to build&install $MYM." + return -5 + fi + cd .. + done && \ + echo "All OK" +} + +case "$1" in + init) + init + ;; + configure) + configure + ;; + build) + build + ;; + update) + update_modules + ;; + *) + echo "Usage: $0 init | update | configure | build " + exit 3 +esac + +"""]]
\ No newline at end of file diff --git a/Development/Documentation/BuildingDocumentation.mdwn b/Development/Documentation/BuildingDocumentation.mdwn new file mode 100644 index 00000000..f9f8c052 --- /dev/null +++ b/Development/Documentation/BuildingDocumentation.mdwn @@ -0,0 +1,91 @@ + + +### Things to keep in mind + +1. Multiple ways X is built: + 1. Distros have their own way (What does this mean because most build from release tarballs.) + 1. Some people pull straight from git + 1. build.sh xjhbuild +1. No hard coded paths: + 1. Each distro installs X docs in a different place that other distros + 1. xorg.css may not be installed + 1. xorg-sgml-doctools can be required at build time but not at runtime (?) + 1. the use of --docdir or --datadir during install + +### Linking between documents + +A new feature we're putting into the documentation system is the ability to easily link between documents, herein called crosslinking. This uses the docbook [[olink|http://www.sagehill.net/docbookxsl/Olinking.html]] feature. Please read that link because it does a better job describing the process that I can here. This works in both .html and .pdf but I'll just use .html below for examples. + +To create the links, the xslt processor uses two text files; the master database and the target database. + +The master db: + + 1. contains references to the targetdatabases and their locations + 1. created by hand (or script) + 1. contains the BASEURI of the link that is used to generate the final link. +The target db: + + 1. contains references to all ids an anchors within the document. + 1. is specific to _one_ document. + 1. is generated by the xslt processor, currently xsltproc. + 1. contains the anchor of the link (the '#' in the url) +xsltproc uses both files to construct the link. The masterdb contains the URL and the targetdb contains the anchor, the place within the document being linked to. + +Example: bigreqproto has this line: Please refer to the <olink targetdoc='libX11' targetptr='overview'>X11 documentation</olink> for further help. + +When xsltproc, processes that olink tag, it scans the master database, finds the target database associated with 'libX11'. It then scans the libX11 target database for th 'overview' tag. It then creates this in the bigreqsproto.html. + +<a href="/path/to/libX11.html#overview" class="olink">X11 documentation</a>. + +Since the target db is required, for this example to work, libX11 needs to be built before bigreqsproto. What if libX11 also links to bigreqsproto? Whichever is built first will fail to have working crosslinks. The build will not fail or stop if the databases are missing, + +We therefore need to build all necessary target databases before building the document of interest. X consists of ~240 modules; how do we do this? + +Possible approaches: + +1. two-pass building + * Two passes are required to build. The first pass generates all the target databases. The second pass actually builds the documents. + * Pros: + * Links are real, no possibility of stale target databases + * Cons: + * Two passes are required to build modules. + * Significant Makefile work to run only certain targets + * External scripts to drive the process + * No longer follows the installation instructions in the INSTALL file of each package +1. two-pass building (variation) + * Two passes are required to build all links. The first pass generates both the target databases and the docs. Links for which the database is available will be correct. A second build pass _make clean install_ will resolve all links because all databases are now available. + * Pros: + * Links are real, no possibility of stale target databases + * No extra scripts or makefile work required (compared to above) + * Cons: + * Two passes are required to build modules. + * No longer follows the installation instructions in the INSTALL file of each package +1. keep copies of all the targetdbs in xorg-sgml-doctools. When a document is updated, the target databases are copied to and checked in to xorg-sgml-doctools. + * Pros: + * No extra build passes are needed. + * Cons: + * Need to maintain copies of target databases. + * Some scripts/makefile work to automate maintenance +1. Both two-pass and check-in dbs in sgml-doctools. A utility to report broken links would be useful. Links can be broken for reasons other than the build process. The installed dbs from proto/libs packages overwrite the installed checked-in dbs from sgml-doctools. That would correct older dbs. + * Pros: + * Two-pass build is optional if no broken links + * Two-pass build is now just a quick way of fixing things rather than an obligation + * Provides both flexibility and reliability based on your quality needs (distros vs developers) + * It's virtually fool proof for distros. + * Cons: + * Need to maintain copies of target databases. Still, a db is just a document. + * Some scripts/makefile work to automate maintenance + +### Profiling (Conditional Text) + + * Docbook supports conditional text, known as [[Profiling|http://www.sagehill.net/docbookxsl/Profiling.html]] +. This allows the writer to insert multiple versions of a paragraph and then decide at runtime which version to output. This feature also allows putting in phrases and chunks of text that at runtime is decided to output or not. + +Currently there are only 2 documents in the tree known to use profiling. xorg-docs/Release Notes, xorg-docs/README and + +* Pros: + * Easy management of those files, saving effort during release time. +* Cons: + * requires additions to the xorg.xsl file as well as using + * currently doesn't work on all systems + * one-pass builds generates a warning: "WARNING: cannot add @xml:base to node set root element. Relative paths may not work." This requires full paths to images used in docs.
\ No newline at end of file diff --git a/Development/Documentation/ClientSideThreads.mdwn b/Development/Documentation/ClientSideThreads.mdwn new file mode 100644 index 00000000..f7c8de9a --- /dev/null +++ b/Development/Documentation/ClientSideThreads.mdwn @@ -0,0 +1,63 @@ + + +# Handling of client-side multi-threading in X + + +## Locking in X libraries + +[Describe here what kind of locking is needed by X libs and how it's implemented] + + +## Configure options + + +### libX11 + +* --disable-xthreads disables threads support in libX11 (default: enabled). + +## Pre-processor symbols + +Defined and used by X: + +* XTHREADS defined whenever libX11 is built with threads support. +* XUSE_MTSAFE_API defined if libc has `getpwuid_r()` and `getpwnam_r()` +Used by OS headers and set by X: + +* _POSIX_THREAD_SAFE_FUNCTIONS +* _REENTRANT + +## Header Files + +There are several X headers related to threads + + +### Xos_r.h + +[Describe here the role of <X11/Xos_r.h> and when it needs to be included.] + + +### Xthreads.h + +[Describe here the role of <X11/Xthreads.h> and when it needs to be included.] + + +## Threads libraries + +Xlib and the associated libraries can support various threading libraries from the operating system they run on. + +* POSIX pthreads +* Microsoft Windows threads +* DEC Threads + +## Support for both threaded and non threaded applications + +Since not all systems support threads by default in their basic C libraries, Xlib has some support for _emulating_ threads support when it's not present in libc, so that the same library can be used in applications built with or without thread support. + +This support is provided throught a set of _weak symbols_ function pointers that define stub implementatons of the threading functions that may be called by thread-aware code. When a real theading implementation is present, the weak definitions are ignored, and the code will call the real functions from the system's threading library. If on threading implemnentation the stubs functions pointed at by the weak symbols will be called. Those stubs are no-op that only make sense in a thread-less environment of course. + +Those stubs are implemented for various systems in `UIThrStubs.c` + + +## XCB Support + +[Describe here how using XCB alone or XCB -enabled libX11 changes things] diff --git a/Development/Documentation/CursorHandling.mdwn b/Development/Documentation/CursorHandling.mdwn new file mode 100644 index 00000000..0ee8e688 --- /dev/null +++ b/Development/Documentation/CursorHandling.mdwn @@ -0,0 +1,48 @@ + +This is documentation about the cursor handling, not about the cursor rendering! + +Generally, a _[[CursorRec|CursorRec]]_ gets allocated only once and used multiple times to save memory. Two functions are responsible for allocating cursors: _AllocCursorARGB()_ and _[[AllocGlyphCursor|AllocGlyphCursor]]()_. The matching Xlib functions would be _XCreateCursor()_ and _XCreateGlyphCursor()_. + +The [[CursorRec|CursorRec]] contains a number of things, we will focus on the _refcnt_ here. The _refcnt_ is used to track how many instances of the cursor are used and to avoid freeing memory too early. The _refcnt_ is increased when + +1. a client gets a reference to a cursor +1. a window uses the cursor +1. a pointer uses the cursor +1. a pointer uses the cursor as part of a grab. +When you create a cursor, it will have a _refcnt_ of 1 (the client has a reference to it after all). Each time you use Xlib's _XDefineCursor()_ or _XChangeWindowAttributes()_, the window obtains a reference to the cursor and increases the _refcnt_. And each time the pointer passes into a window that has a cursor set, _[[ChangeToCursor|ChangeToCursor]]()_ will change the pointer's cursor and increase the _refcnt_. Using the cursor for a sprite does NOT change the _refcnt_! + +The _refcnt_ is decreased in _[[FreeCursor|FreeCursor]]()_. When the _refcnt_ hits 0, the memory for the cursor is freed. Make sure that when you call _[[FreeCursor|FreeCursor]]()_, nothing in your codepath references the address anymore. The usual way to do this is something like +[[!format txt """ + CursorPtr pOldCursor = device->spriteInfo->sprite->current; + device->spriteInfo->sprite->current = NULL; + FreeCursor(pOldCursor, 0); +"""]] +The value of _pOldCursor_ is undefined after _[[FreeCursor|FreeCursor]]()_. + +_[[FreeCursor|FreeCursor]]()_ is called from several points. Each time the cursor leaves a window, _[[CheckMotion|CheckMotion]]()_ call _[[PostNewCursor|PostNewCursor]]()_, which may call _[[ChangeToCursor|ChangeToCursor]]()_. When the client issues a _[[FreeCursor|FreeCursor]]_ request. Each time a window changes the cursor (_[[ChangeWindowAttributes|ChangeWindowAttributes]]()_). When a grab with a cursor is deactivated. And on _[[CloseDownClient|CloseDownClient]]()_, when all the resources are freed for the client. And quite a few more. + + +### Animated cursors + +Animated cursors are part of the XRender extension. All they are is a list of standard cursors with a delay between them. The memory is a standard _[[CursorRec|CursorRec]]_, with an _[[AnimCursorRec|AnimCursorRec]]_ and several _[[AnimCursElt|AnimCursElt]]_ attached to the end of the struct. The latter two contain the _[[CursorRec|CursorRec]]_ that make up the animated cursor's frames. Animated cursors are identified with a special pattern in the _[[CursorRec|CursorRec]]_s _bits_ field. See _[[AnimCursorCreate|AnimCursorCreate]]()_. + +So for an animated cursor with 3 frames, the memory looks something like this. +[[!format txt """ +[ CursorRec ][ AnimCursorRec ][AnimCursElt][AnimCursElt][AnimCursElt] + | | | +[ CursorRec ] <------------------- | | +[ CursorRec ] <--------------------------------- | +[ CursorRec ] <---------------------------------------------- +"""]] +Each cursor that is used in an animated cursor has the _refcnt_ increased, and likewise decreased via _[[FreeCursor|FreeCursor]]()_ when the animated cursor is deleted. If a window or pointer uses a animated cursor, they use the animated cursor struct, never directly any of the cursors that make up the frames. + +X uses a _[[BlockHandler|BlockHandler]]_ to do stuff when nothing else needs to be done. Such as redrawing mouse cursors. The animated cursor code adds itself to the block handler and _[[AnimCurScreenBlockHandler|AnimCurScreenBlockHandler]]()_ is called regularly. + +Display of an animated cursor uses set of static variables in _animcur.c_. The currently displayed animated cursor is saved, and each time the block handler is called, it checks + +* whether the current cursor is an animated cursor. +* if so, if the timeout for the next frame has passed already +* if so, display the next frame +* if so, save the timeout for the next frame in the static struct +* update wakeup handler to wake up for next timeout. +--- [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/DevPrivates.mdwn b/Development/Documentation/DevPrivates.mdwn new file mode 100644 index 00000000..3235c070 --- /dev/null +++ b/Development/Documentation/DevPrivates.mdwn @@ -0,0 +1,100 @@ + +devPrivates are a way to store information in a struct without modifying the header for the struct, thus keeping the ABI. + +Each major struct ([[ScreenRec|ScreenRec]], [[DeviceIntRec|DeviceIntRec]], [[WindowRec|WindowRec]], [[ClientRec|ClientRec]]) has a pointer to it's devPrivates as part of the struct. The usage of the devPrivates is as follows: + + +[[!format txt """ +#include <privates.h> + + +DevPrivatesKey myKey = &myKey; + + +void store_private(ClientPtr client) +{ + MyStruct *a = xalloc(sizeof(MyStruct)); + + /* do stuff with a */ + + dixSetPrivate(&client->devPrivates, myKey, a); +} + +void retrieve_private(ClientPtr client) +{ + MyStruct *a; + + a = (MyStruct*)dixLookupPrivate(&client->devPrivates, myKey); + + /* do stuff with a */ +} + + +/* The following will free _ALL_ devPrivates on the given client. Not just yours! */ +void delete_private(ClientPtr client) +{ + dixFreePrivates(client->devPrivates); + +} + +"""]] +devPrivates are more fully documented in the _Definition of the Porting Layer for the X v11 Sample Server_ document, sources of which are in [[xorg-docs/sgml/core/Xserver-spec.sgml|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/sgml/core/Xserver-spec.sgml]] + + +# Deprecated information + +The following is a description of the devPrivates system before the serious overhaul. It is now outdated. + +Client devPrivates are similar to those of the [[ScreenRec|ScreenRec]] and [[DeviceIntRec|DeviceIntRec]] structures, but those have their own API to initialize and access them. Please note that there a overhaul of the devPrivates system in progress and this information may be out of date soon [[http://lists.freedesktop.org/archives/xorg/2007-March/022212.html|http://lists.freedesktop.org/archives/xorg/2007-March/022212.html]]. + +Need to be initialised at start time, as each time a client is allocated. The devPrivates are an array of [[DevUnions|DevUnions]] that are allocated when the client starts and released when the client finishes. Each client has the same size allocated for devPrivates and at the moment there are no methods to resize the array at a later point in time. Better make sure you allocate everything on server startup before the first client connects. + +_[[AllocateClientPrivatesIndex|AllocateClientPrivatesIndex]]()_ gives you an index into the array. Each time you need to access your data, access it with `client->devPrivates[MyIndex].ptr` and cast it to your specific data information. Immediately after retrieving your index, call _[[AllocateClientPrivate|AllocateClientPrivate]]([[MyIndex|MyIndex]], size)_, where size is the number of bytes you need for your private struct in bytes. You can now assume that every client that connects will have enough space for your data. + +Finally, you will probably want to add a callback to reset the data when a client starts up. Use _[[AddCallback|AddCallback]]()_ to register your function and then do stuff. The first argument is always the same (_[[ClientStateCallback|ClientStateCallback]]_), the second your callback proc and the third one some pointer data which will get passed into the callback function (argument {{closure]] in example below). Most extensions just pass in 0. You need to check the state of the client in the callback function. If client->state is [[ClientStateRunning|ClientStateRunning]] then the client has just started up, [[ClientStateGone|ClientStateGone]] or [[ClientStateRetained|ClientStateRetained]] means it has been shut down. There are a few other states. (comment by Eamon Walsh) + +I recommend looking at damageext/damageext.c, it has a low signal-to-noise ratio. The full code you need: + + +[[!format txt """ +int myIndex = AllocateClientPrivateIndex(); /* check myIndex > 0 */ +AllocateClientPrivate(myIndex, sizeof(MyStruct)); /* has to return true */ +AddCallback(&ClientStateCallback, MyCallbackProc, 0); + +static void MyCallbackProc(CallbackListPtr *list, pointer closure, pointer data) +{ + NewClientInfoRec* clientinfo = (NewClientInfoRec*)data; + ClientPtr client = clientinfo->client; + MyStruct mystruct = (MyStruct*)client->devPrivates[myIndex].ptr; + + /* do stuff */ + +} +"""]] +Finally, you want to add a _[[DeleteCallback|DeleteCallback]]()_ call to remove your callback when the extension resets. + + +## Notes + +The client that owns the root window is `serverClient` and will be created before extensions initialize. It will (most likely) not have devPrivates set to what you added, so make sure you cater for this. + + +### Window DevPrivates + +The devPrivates of a [[WindowRec|WindowRec]] are stored after the struct's memory. Each screen keeps a totalWindowSize for the memory that is to be allocated per screen. The memory for a [[WindowRec|WindowRec]] with 4 devPrivates entries looks approximately like this: + + +[[!format txt """ + ___________________________________________________________________________ +| | | | | | | | | | +| WindowRec | 1 | 2 | 3 | 4 | A | B | C | D | +|___________dP__|___|___|___|___|__________|_____________|___|______________| + | ^ | | | | ^ ^ ^ ^ + |__| | | | |__|__________|_____________|___| + | | |______|__________|_____________| + | |__________|__________| + |______________| +"""]] +With `1 = &A, 2 = &B, `etc. Before you allocate a window, you need to call _[[AllocateWindowPrivate|AllocateWindowPrivate]]()_ with the size you need for your entry. A, B, C, D have the sizes that were specified for _[[AllocateWindowPrivate|AllocateWindowPrivate]]_ + +--- [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/DocBookConversion.mdwn b/Development/Documentation/DocBookConversion.mdwn new file mode 100644 index 00000000..0402471b --- /dev/null +++ b/Development/Documentation/DocBookConversion.mdwn @@ -0,0 +1,23 @@ + + +## Tools + +What is needed to convert troff documents from [[DocBook|DocBook]]: + +* [[DocLifter|DocLifter]] ([[+patches|http://lists.freedesktop.org/archives/xorg/2008-June/035967.html]]) +* Time +* Luck + +## To Do + +List the document that have yet to be converted here. + +* [[XKB|XKB]] specs (xorg-docs/specs/XKB/Proto & xorg-docs/specs/XKB/XKBlib): these are in Frame``Maker format. [[AlanCoopersmith|AlanCoopersmith]] used Frame``Maker's Export options to produce several more convertible formats from them: XML (with unknown DTD), HTML & MIF - available at [[http://people.freedesktop.org/~alanc/xkb/|http://people.freedesktop.org/~alanc/xkb/]] - but someone needs to finish converting to DocBook/XML. + +## Ongoing + +There has been an interest in converting the parts of the Xorg documentation written in troff to [[DocBook|DocBook]] (or any other generic format). In order not to duplicate efforts, here is the list of what is being done and by whom. + +* [[PeterHutterer|PeterHutterer]] has converted the XInput documentation to [[DocBook|DocBook]] +* [[FrancoisDenisGonthier|FrancoisDenisGonthier]] and [[MichaelVerret|MichaelVerret]] are trying to convert from XProtocol from troff to [[DocBook|DocBook]] using doclifter. +* [[GüntherBrammer|GüntherBrammer]] is converting documentation in the Xext directory.
\ No newline at end of file diff --git a/Development/Documentation/Glossary.mdwn b/Development/Documentation/Glossary.mdwn new file mode 100644 index 00000000..17efb4cd --- /dev/null +++ b/Development/Documentation/Glossary.mdwn @@ -0,0 +1,16 @@ + +* <a name="DDX"></a>DDX: Device Dependent X. The part of X that interacts with the hardware. There have been many of these over the years:`xfree86`, `kdrive`, `xwin` (for Windows), `darwin` (for OS X), [[xgl|Development/Documentation/Glossary]], `vfb`, `xnest`, and so forth. In the X server code, each directory under [[hw|http://cgit.freedesktop.org/xorg/xserver/tree/hw]] corresponds to one DDX. One DDX may have one or more device drivers. In the `xfree86` DDX, each driver is a separate loadable module; in most of the other DDXes, each driver is compiled to its own server binary. Contrast: [[DIX|Development/Documentation/Glossary]]. +* <a name="DIX"></a>DIX: Device Independent X. The part of X that interacts with clients and implements software rendering. Basically everything in the [[server|http://cgit.freedesktop.org/xorg/xserver/tree]] except for the `hw/` directory. The event delivery is part of the DIX. +* <a name="DMX"></a>DMX: Distributed Multihead X, which allows combining several backend X servers into a single virtual X server. +* <a name="DRI"></a>DRI: Direct Rendering Infrastructure. A way for X clients to send commands directly to the graphics card. Primarily used to make [[GLX|Development/Documentation/Glossary]] go fast, but also involved in accelerating [[XvMC|Development/Documentation/Glossary]]. All the open drivers, and many of the closed drivers, use the DRI to accelerate [[GLX|Development/Documentation/Glossary]]. +* <a name="EGL"></a>EGL: Embedded-System Graphics Library. The interface between rendering APIs such as OpenGL ES and the underlying native platform window system, such as X. +* <a name="EXA"></a>EXA: Acceleration architecture with no well-defined acronym. Based on the kdrive acceleration architecture ([[KAA|Development/Documentation/Glossary]]) but with some additional features and cleanups, and designed to be used within the `xfree86` [[DDX|Development/Documentation/Glossary]]. +* <a name="git master"></a>git master: A term to refer to the master branch in the X server's git repository (see [[http://cgit.freedesktop.org|http://cgit.freedesktop.org]]). The master branch is the default when you get the X server sources, and it is where most of the development happens. +* <a name="GLX"></a>GLX: OpenGL extension for X. Provides a way to do OpenGL drawing into a window managed by the X server. Almost always available in software. The open drivers use the [[DRI|Development/Documentation/Glossary]] to accelerate GLX. +* <a name="KAA"></a>KAA: kdrive acceleration architecture. Used in the `kdrive` [[DDX|Development/Documentation/Glossary]] to accelerate core X drawing and [[Render|Development/Documentation/Glossary]]. Much simpler than [[XAA|Development/Documentation/Glossary]], but with fewer restrictions on the use of offscreen memory, which is important for effectively accelerating [[Render|Development/Documentation/Glossary]]. +* <a name="MI"></a> MI: machine independent. Routines that should run on pretty much any hardware +* <a name="OpenGL"></a>OpenGL: Open Graphics Library. The standard cross-platform API for 2D and 3D rendering. OpenGL needs a binding layer to the window system to actually display anything; relevant ones to X are [[GLX|Development/Documentation/Glossary]] and [[EGL|Development/Documentation/Glossary]]. +* <a name="Render"></a>Render: An extension to the X protocol that exposes the Porter-Duff image compositing model. Unlike the core X drawing requests, the Render extension is capable of doing alpha blending. Primarily used right now to implement antialiased fonts, but is also used by the `xcompmgr` demo to implement drop shadows and translucency. +* <a name="XAA"></a>XAA: XFree86 Acceleration Architecture. Used in the `xfree86` [[DDX|Development/Documentation/Glossary]] to accelerate core X drawing requests and [[Render|Development/Documentation/Glossary]]. Not really suitable for modern desktop usage anymore. Intended to be replaced by [[EXA|Development/Documentation/Glossary]] in the `xfree86` [[DDX|Development/Documentation/Glossary]], or by the [[XGL|Development/Documentation/Glossary]] [[DDX|Development/Documentation/Glossary]]. +* <a name="XGL"></a>XGL: X on OpenGL. A [[DDX|Development/Documentation/Glossary]] that uses an OpenGL stack to do its rendering. The XGL DDX has several drivers: Xglx to display on a [[GLX|Development/Documentation/Glossary]] surface, a la Xnest; Xegl, to display an native [[EGL|Development/Documentation/Glossary]] screen; and potentially also Xwgl and Xagl to display on win32 and OSX windows. Xgl was removed from git master on the 12 June 2008 after having been orphaned for years. +Another, larger but more X Protocol oriented glossary can be found at [[http://www.rahul.net/kenton/xglossary.html|http://www.rahul.net/kenton/xglossary.html]] diff --git a/Development/Documentation/GrabProcessing.mdwn b/Development/Documentation/GrabProcessing.mdwn new file mode 100644 index 00000000..e194d49b --- /dev/null +++ b/Development/Documentation/GrabProcessing.mdwn @@ -0,0 +1,32 @@ + + +# X Server Input Device Grabs + +Grabs are a way of forcing devices to only report to a specific client (the grabbing client). There are two different types of grabs: core grabs and device grabs (X input extension). + +Core grabs are fairly simple: when a client issues a request (e.g. [[GrabPointer|GrabPointer]]), the server takes the core pointer and initializes a [[GrabRec|GrabRec]] structure to be put in the grab field of the [[DeviceIntRec|DeviceIntRec]]. Each time the device now emits an event, it is delivered only to the client that owns the grab. Grabs are resources and thus the owner of the grab can be looked up using the rClient(grab) macro. A typical event flow would be mieqProccessInputEvent -> [[CoreProcessPointerEvent|CoreProcessPointerEvent]] -> [[DeliverGrabbedEvent|DeliverGrabbedEvent]] -> [[TryClientEvents|TryClientEvents]]. + +Device grabs are the same but require some knowledge about the role of the core pointer. Each time the client issues a [[GrabDevice|GrabDevice]] request, a grab is initialized in the same way to the core grab. The grab is stored in the device itself. + +But here is the important bit about event generation: Each time a device emits an event, it creates a device event and (maybe) a core event. The device event is put on the event queue and processed with a reference to the original device. The core event however is processed with the core pointer. After [[GetPointerEvents|GetPointerEvents]], all core events appear to have originated from the core pointer and all device events from their device. + +And suddenly all the bits with grabs fall into place. If we have a core grab, we have it on the core pointer, thus all core events, no matter which device caused them, belong to us. A device grab will only send us the Xi events, while the core events still go wherever they are supposed to. As a result, we can have multiple device grabs but only ever one core grab. This is probably also the reason why the core pointer and core keyboard could not be configured to send Xi events. + +There are always two core devices: [[VirtualCorePointer|VirtualCorePointer]] and [[VirtualCoreKeyboard|VirtualCoreKeyboard]] were added by Daniel Stone when he wrote [[InputHotplug|InputHotplug]]. Reason being is that the X server always has to have at least one keyboard and one mouse. But with hotplugging, you should be able to start X without any devices. So the solution was to add virtual devices that aren't connected to real ones and make sure they are always there. That way you can add and remove physical devices without breaking anything. They aren't physical devices! But with the event delivery described above, they still emit core events. + + +# Passive grabs + +Passive grabs are a different matter. A client can create multiple passive grabs ([[GrabButton/GrabKey|GrabButton/GrabKey]]), and they become active whenever the specified button/key is pressed, until it is released again. The server has two kinds of passive grabs, explicit and implicit ones. Explicit ones are the one requested by the client, they are stored as _[[GrabRec|GrabRec]]_ in the window's resource system. + +An implicit passive grab is activated only if there is no active grab on the device and no passive grab has been activated either. In this case, the server creates a new grab, fills it with data and sets it on the device. The purpose of the grab is to ensure that a [[ButtonRelease|ButtonRelease]] event is delivered to the same client as the [[ButtonPress|ButtonPress]] event. This grab is deactivated when the button is released again. + +There can only be one grab on a device, so the check for the activation of passive grabs only happens when the first button is pressed. Further buttons are not checked. + +A passive grab is only created once, when the client requests it. When it is activated, the grab is _copied_ into the device. Thus modifying a passive grab will not actually modify a grab that is currently active on a device. + + + +--- + + [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/HowVideoCardsWork.mdwn b/Development/Documentation/HowVideoCardsWork.mdwn new file mode 100644 index 00000000..80c98605 --- /dev/null +++ b/Development/Documentation/HowVideoCardsWork.mdwn @@ -0,0 +1,290 @@ + + +# Video Cards + +[[!toc ]] + +So you want to know how modern video cards work. Here goes... + +Modern video cards usually have several common features: + +* Video Ram +* Display control +* 2D engine +* 3D engine +* Overlay +* HW sprites (cursor, icon, etc.) +* AGP/PCI/PCIE +* Apertures (registers, framebuffer) + +## Video Ram + +Basically a large chunk of fast ram. This memory is used for all sorts of things: + +* Scan-out buffers (what you see on your monitor) +* Offscreen rendering buffers +* Cursor images +* Command buffers +* Vertex data +* Textures +Buffers in video ram generally have a stride (also called pitch) associated with them. The stride is the width of the buffer in bytes. For example, if you have a 1024x768 pixel buffer at 16 bits/pixel (2 bytes/pixel), your stride would be: + + +[[!format txt """ +1024 pixels * 2 bytes/pixel = 2048 bytes +"""]] +At 32 bits/pixel (4 bytes/pixel), your stride would be: + + +[[!format txt """ +1024 pixels * 4 bytes/pixel = 4096 bytes +"""]] +Stride is important as it delineates where each line of the buffer starts and ends. With a linear buffer format, each line of the buffer follows the previous linearly in video ram: + + +[[!format txt """ +framebuffer address +0 2048 4096 +|---------------|---------------|---------------| ... |---------------| +"""]] + +### Tiled framebuffers + +The above layout is called "linear", because the layout of pixels in memory is like that on the screen: the pixel to the right of the current one on the screen is the one at the next highest address in memory. Tiling is a common variation where pixel layout in memory is not linear, but instead laid out in small squares. For example, a 4x4 tile would look like: + + +[[!format txt """ + 0 1 2 3 + 4 5 6 7 + 8 9 10 11 +12 13 14 15 +"""]] +In other words, the 4th (zero-based) pixel in memory would be at screen coordinate (0, 1), whereas in linear memory it would be at screen coordinate (4, 0). The pattern then continues: the 16th (zero-based) pixel is screen coordinate (4, 0) instead of (16, 0). The reason for this alternate layout is it makes pixels that are adjacent on the screen also adjacent in memory, which improves cache locality. + +Some hardware has multiple levels of tiling. For example, Radeon hardware can have microtiles composed of pixels, and macrotiles composed of microtiles. Sometimes the GPU can hide tiling from the CPU (ie, make tiled regions appear linear to PCI bus accesses). + + +## Display control + + +### Overview + +The display cell on most video cards controls the size, timing, and type of signal sent to the monitor. There are 3 elements involved in this: + +1. CRTC or Display Controller +1. PLLs (pixel clock) +1. Outputs + +### CRTCs + +CRTC is a jargon term for "CRT controller", and CRTs are those big bulky glass things with pictures on them you see in old movies. Practically speaking, they define a region of pixels you can see. + +The crtc controls the size and timing of the signal. This includes the vertical and horizontal sizes and blanking periods. Most cards have 2 or more crtcs. Each crtc can drive one or more outputs. Generally, each crtc can have it's own set of timings. If that crtc is driving more than one output, each output is driven at the same timings. Crtcs can also scan out of different parts of the framebuffer. If you have more than one crtc pointing at the same framebuffer address you have "clone" modes. Clone modes can also be achieved by driving more than one output with one crtc. If you point the crtcs to different parts of the framebuffer, you have dualhead. + +On VGA-like signalling, this signal includes sync signals so the monitor can find the edges of the image. A modeline contains the timings (in pixels) where these sync signals are generated, relative to the active pixel times. (For the rest of this discussion we'll use "pixel" to mean "pixel interval" for brevity.) For example: + + +[[!format txt """ +Modeline "1680x1050R" 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync +"""]] +Here, 1680 of 1840 total pixel in each horizontal interval contain actual pixel data, and the horizontal sync pulse runs from pixel 1728 to pixel 1760. 1050 of the 1080 total lines contain actual pixel data, and the vertical sync pulse runs from line 1053 to line 1059. The interval between the end of the active region and the beginning of the sync pulse is called the front porch; the interval between the end of the sync pulse and the end of a line or frame is called the back porch. Sync polarity is set by convention, so the monitor can know which timing formula is in use. Normal modes generated by the GTF or CVT timing formulas are -hsync +vsync. Modes generated by the CVT reduced-blanking formula or by GTF when using a secondary curve are +hsync -vsync. Other polarity combos are occasionally seen for various historical modes. + +The stride of a crtc is set to the stride of the buffer it is scanning out of. The stride of the buffer does not have to correspond the size of the crtc mode. This allows you to implement things like virtual desktops (1024x768 mode scanning out of a 2048x2048 pixel virtual desktop) or have multiple crtcs scan out of different parts of the same buffer (two 1024x768 crtcs scanning out of a 2048x768 pixel buffer). + + +### PLLs + +The PLLs controls the pixel/video clock. This is the rate at which pixels are sent to the monitor. The higher the vertical refresh rate or resolution of your screen the higher the pixel clock. + +The pixel clock is usually generated using the following formula: +[[!format txt """ +pixel clock = (ref freq) * (m/n) * (1/(1 + r)) + +ref freq = the base clock frequency provided by the hardware +m = clock multiplier +n = clock divider +r = clock post divider +"""]] + +### Outputs + +The outputs convert the data stream sent from the crtc into something the monitor understands. For example a DAC (Digital Analog Converter) converts the digital data stream into an analog signal for your monitor. Some other examples include TMDS ([[Transition Minimized Differential Signaling|http://en.wikipedia.org/wiki/TMDS]]) transmitters (converts to the digital format used by DVI and some other connectors), LVDS ([[Low Voltage Differential Signaling|http://en.wikipedia.org/wiki/LVDS]]) transmitters (commonly used to connect local flat panels like LCDs on laptops), and TV encoders (converts to an analog TV signal often with image scaling). Outputs can be integrated into the graphics chip or provided as external components (usually connected via a standard interface like DVO (Digital Video Out) or SDVO (Serial Digital Video Out)). + + +### Driver Examples + +In most Xorg drivers there are 3 sets functions (usually found in chipname_driver.c) associated with configuring the display controllers: + +* Save() - Saves the current hardware state of the output registers +* Init() - Initializes the hardware register data structures for the requested output configuration +* Restore()/Write() - Writes the initialized register values set up in the Init() functions to the hardware + +#### Radeon + +Save: + +* RADEONSaveMemMapRegisters() - saves memory map register state +* RADEONSaveCommonRegisters() - saves common register state +* RADEONSaveCrtcRegisters() - saves the registers for the primary crtc +* RADEONSaveFPRegisters() - saves the registers for the panel outputs (RMX, TMDS, LVDS) +* RADEONSaveCrtc2Registers() - saves the registers for the secondary crtc +* RADEONSavePLLRegisters() - saves the registers for the primary (crtc1) pixel clock +* RADEONSavePLL2Registers() - saves the registers for the secondary (crtc2) pixel clock +* RADEONSavePalette() - saves the palette/CLUT registers +* RADEONSaveMode() - calls the above functions +Init: + +* RADEONInitOutputRegisters() - Initializes registers for outputs and sets up the crtc to output mapping. Calls output init functions +* RADEONInitCrtcRegisters() - Initializes registers for crtc1. Calls RADEONInitOutputRegisters() to initialize the outputs driven by crtc1 and RADEONInitPLLRegisters() to set up the pixel clock. +* RADEONInitCrtc2Registers() - Initializes registers for crtc2. Calls RADEONInitOutputRegisters() to initialize the outputs driven by crtc2 and RADEONInitPLL2Registers() to set up the pixel clock. +* RADEONInitPLLRegisters() - initialize the pixel clock for crtc1 +* RADEONInitPLL2Registers() - initialize the pixel clock for crtc2 +* RADEONInit2() - calls the above functions +Restore/Write: + +* RADEONRestoreMemMapRegisters() - restore memory map register state +* RADEONRestoreCommonRegisters() - restore common register state +* RADEONRestoreCrtcRegisters() - restore the registers for the primary crtc +* RADEONRestoreFPRegisters() - restore the registers for the panel outputs (RMX, TMDS, LVDS) +* RADEONRestoreCrtc2Registers() - restore the registers for the secondary crtc +* RADEONRestorePLLRegisters() - restore the registers for the primary (crtc1) pixel clock +* RADEONRestorePLL2Registers() - restore the registers for the secondary (crtc2) pixel clock +* RADEONRestorePalette() - restore the palette/CLUT registers +* RADEONEnableDisplay() - enables/disables outputs +* RADEONRestoreMode() - calls the above functions + +## 2D Engine + + +### Overview + +The 2D engine (often called a blitter) basically moves data around in video ram. There are generally 4 operations done by the 2D engine: blits (copying data from one place to another), fills (draw a solid color), lines (draws lines), and color expansion (convert mono data to color data; e.g. convert monochrome font glyphs to the depth of your screen: usually 16 or 24 bit color). Logical operations (rops -- raster operations) can also be performed on the data. You have a source and destination buffers (often called surfaces) and these operations will use one or more surfaces. Some, like solid fills, only use a destination (where do I draw the red rectangle). Others like blits require a source and destination (copy this rectangle from address A to address B). Surfaces can (and often do) overlap. Because of this, blitting also has the concept of direction: if you are copying data from overlapping source and destination regions you need to make sure you copy the right data (e.g., top to bottom, right to left, etc.). Data from system memory can also be the source of these operations. This is referred to as a hostdata blit. With hostdata blits, host data is copied into a special region of video ram or into the command queue depending on the chip and from there it is copied to the destination in the framebuffer via the blitter. + +2D engines are usually either controlled via direct MMIO access to the relevant registers or via a command queue. With direct MMIO, the appropriate values are written the relevant registers and then the command is usually executed when the last reg in the series is written or when the command register is written (depends on HW). With a command queue, part of the framebuffer is reserved as a command queue (FIFO). Commands and associated data are written sequentially to the queue and processed via the drawing engine. + + +### Solid example + +Draw a solid red 200x400 pixel rectangle on the screen at (x,y) location (25, 75). + +1. Set the pitch of your destination surface to the pitch of the screen and set the offset to the offset in video ram where your screen buffer is located. +1. Set the rop you want to use +1. Set the color you want +1. Set the destination rectangle width and height and (x,y) location relative to the surface + +### Blit Example + +Copy a 200x400 pixel rectangle on the screen from (500, 400) to (25, 75). + +1. Set the pitch of your source surface to the pitch of the screen and set the offset to the offset in video ram where your screen buffer is located. +1. Set the pitch of your destination surface to the pitch of the screen and set the offset to the offset in video ram where your screen buffer is located. +1. Set the rop you want to use +1. Set the source rectangle width and height and (x,y) location relative to the source surface +1. Set the destination rectangle width and height and (x,y) location relative to the destination surface + +### Xorg Acceleration Examples + +* Blits: XAA [[ScreentoScreenCopy|ScreentoScreenCopy]]; EXA Copy +* Hostdata Blits: XAA [[ImageWrite|ImageWrite]], CPUToScreen functions; EXA [[UploadToScreen|UploadToScreen]] +* Solid Fills: XAA [[SolidFillRect|SolidFillRect]]; EXA Solid +* Lines: XAA [[SolidBresenhamLine|SolidBresenhamLine]], [[SolidTwoPointLine|SolidTwoPointLine]] +* Color Expansion: XAA CPUToScreenColorExpandFill + +### Driver Examples + + +#### Radeon + +EXA Solid Fill: + +* RADEONPrepareSolid() - Sets up the hardware state for the solid fill +* RADEONSolid() - Draws a solid rectangle of size w x h at location (x,y) +EXA Blit: + +* RADEONPrepareCopy() - Sets up the hardware state for the copy +* RADEONCopy() - Performs a copy of a rectangle of size w x h from (x1,y1) to (x2,y2) + +## 3D Engine + + +### Overview + +The 3D engine provides HW to build and rasterize a 3 dimensional scene. Most fixed function hardware has the following layout: + +* Small set of 3D state registers. These control the state of the 3D scene: fog, mipmapping, texturing, blending, etc. +* 3D engine offset registers. Controls where in the framebuffer the 3D engine renders to +* Texture control and offset registers. Control texture format and size and where the textures are located +* Depth buffer control and offset registers. Controls depth buffer layout and location +* Vertex registers. Used to specify the location and format of the vertexes which make up the 3D scene. + +### Buffers + +Generally 3 buffers are required for 3D: + +1. Front buffer. This is usually the buffer that is scanned out for the user to see. +1. Back buffer. This is the buffer that is rendered to while that front buffer is being scanned out. +1. Depth buffer. Also called z-buffer. This buffer is used to determine the relative depth of different object in the 3D scene. This is used to determine which elements are visible and which are obscured. +[[ToDo|ToDo]]: give driver examples + + +## Overlay + + +### Overview + +The overlay provides a mechanism for mixing data from multiple framebuffers automatically. It is most often used for mixing YUV (video) and RGB data. Most overlays contain special filtering and scaling hardware along with a colorspace converter. The streams are mixed or blended in several ways (depending on the hardware): + +* Colorkey. Overlay data is overlaid on the primary data stream where the color of the primary stream matches the colorkey RGB color. Generally used to overlay YUV or RGB data on an RGB surface. +* Chromakey. Same as colorkey but the key is a YUV value rather than RGB. Generally used to overlay RGB or YUV data on a YUV surface. +* Position/Offset. Overlay data appears at specified position in the scan out buffer. +When an overlay is enabled, data from the overlay framebuffer is automatically mixed into the output stream during the scanout of the visible framebuffer. For example, with colorkeying, the crtc scans out of the primary framebuffer until it hits a region with a color matching the colorkey. At this point, the hardware automatically scans the data out of the overlay buffer. + +Most hardware only has one overlay which is often tied to a crtc or can only be sourced to one crtc at a time. + +Overlays are most commonly used for video playback and scaling. See Xv. + + +### Driver Examples + + +#### Radeon + +* RADEONPutImage() - Prepares and copies overlay data to video ram, then calls RADEONDisplayVideo(). +* RADEONDisplayVideo() - Write the overlay configuration to hardware to display the overlay data. + +## HW sprites + + +### Overview + +HW sprites are small buffers that get blended with the output stream during scan out. The most common examples are HW cursors and HW icons. Sprites are usually limited to small sizes (64x64 or 128x128 pixels) and on older hardware they are limited to 2 colors (newer hardware supports 32 bit ARGB sprites). The cursor image is written to a location in video ram and that image is mixed into the output stream at a particular location during scan out. + +[[ToDo|ToDo]]: give driver examples + + +## PCI + +PCI is by now the standard bus for connecting video cards to computers. AGP and PCIE merely look like enhanced versions of PCI, as far as the host software is concerned. + +PCI devices can present various resources to the host, along with a standardized way of discovering and accessing them. The important ones as far as video is concerned are BARs, or bus address ranges. Each device can present up to 6 BARs, which can function as video memory or register banks. BARs can be either memory or I/O ranges, but are usually memory. There is also an optional "7th BAR", the option ROM, which most video devices support. This is used to support multiple video cards, since the ROM contains the initialization code for the chip, and most system BIOSes will not attempt to initialize more than one card at boot time. + +PCI also provides a mechanism for supporting the legacy VGA address space and I/O ports, by allowing the host software to route this space to individual PCI cards. Again, this is mostly used for multi-card setups. + + +## AGP + +[[ToDo|ToDo]]: fill me in. + + +## PCIE + +[[ToDo|ToDo]]: fill me in. + + +## Apertures + +[[ToDo|ToDo]]: fill me in. + +[[ToDo|ToDo]]: indexed vs. direct access registers + +-- Main.[[AlexDeucher|AlexDeucher]] diff --git a/Development/Documentation/InputEventProcessing.mdwn b/Development/Documentation/InputEventProcessing.mdwn new file mode 100644 index 00000000..92b275de --- /dev/null +++ b/Development/Documentation/InputEventProcessing.mdwn @@ -0,0 +1,112 @@ + +[[!toc ]] + +This is a puny attempt to explain how the X Server generates and processes input events. This document was created as part of the development for [[MPX|Projects/MPX]], the Multi-Pointer X Server. This document does not replace a good look at the source code. It just helps understanding what happens and what order functions are called. And it gives a general overview on how events are born and sent to the client. + +We do not give any warranty that the information here is complete and/or accurate. The information here concentrates on pointer events but some is the same for keyboard events. + +**Updated 17.06.2010. Reflects input processing in X servers 1.7 through to including 1.9** + + +## Overview + +Generally, input events live through two stages: Event generation and event processing. In the event generation stage, input is gathered from the connected devices and transformed into abstract input events, the so-called [[InternalEvents|InternalEvents]]. In the processing stage, these [[InternalEvents|InternalEvents]] events are converted to protocol events, depending on the event masks of the windows. An [[InternalEvent|InternalEvent]] may be converted into a core event, an XI 1.x event or an XI2 event. More events such as enter and leave events are generated during the processing stage as well. + +The event generation stage is part of the interrupt handling. The event processing stage is part of the processing loop (_Dispatch()_). + +In between those two stages, there is the event queue. Events are put on the event queue after the creation stage and taken off again at the start of the processing stage. Only [[InternalEvents|InternalEvents]] are ever on the event queue. + +There are only a few directories that are interesting for all that: + + * _xserver/dix_ ... device independent X. The events.c file is handling most of the events. + * _xserver/mi_ ... machine independent X. Mouse cursor rendering stuff. + * _xserver/hw/xfree86/common_ ... some additional stuff, especially the driver interface. + * _xserver/Xi_ ... X Input Extension protocol stuff. +The method the server spends the most time in is _Dispatch()_, and in this method the server mostly waits in _[[WaitForSomething|WaitForSomething]]()_ for requests from the clients and to send off accumulated input events from the input devices to the clients. + +Lots and lots of functions are called using function pointers. Finding them can be very frustrating. See [[how to set up ctags|Development/Documentation/UsingCtags]] to jump around in the source and find functions easier. + + +### The DESIGN document + +There is a document that describes the design of the X server. Depending on where you have the source tree the document is in xserver/hw/xfree86/doc/DESIGN.sgml or if you have the xserver-xorg package installed you should have it in /usr/share/doc/xserver-xorg/DESIGN.gz. + +It's worth a read but I did not find a lot of information about how input events are handled. + + +### An important requirement to understand events + +X has the concept of core devices. These are the devices that are visible in the core protocol (i.e. whenever a client issues a [[GrabPointer|GrabPointer]] request, the core pointer is picked). + +With the introduction of X Input in 1994, the definition of an extension device was added. These devices could also send XI events (e.g. [[DeviceMotionNotify|DeviceMotionNotify]]). A device could only be either an XI or a core device, not both - hence the need for the [[ChangePointerDevice|ChangePointerDevice]] and [[ChangeKeyboardDevice|ChangeKeyboardDevice]] requests. However, an extension device what was configured to "[[SendCoreEvents|SendCoreEvents]]" would cause both XI events on the device and core events on the core pointer device. + +X server 1.4 introduced the notion of a "virtual core pointer" and "virtual core keyboard" (VCP and VCK, respectively). These devices are hardcoded to be the core devices with all physical devices now being extension devices. This obsoleted the [[ChangePointerDevice|ChangePointerDevice]] and [[ChangeKeyboardDevice|ChangeKeyboardDevice]] request, the core devices were always the virtual ones. A device configured to "[[SendCoreEvents|SendCoreEvents]]" would send cause the VCP or VCK to generate a core event as well as the extension event on the device itself. + +X server 1.7 introduced XI2 and the master/slave device hierarchy. VCP and VCK are the first two "master devices", with all physical devices being "attached" to either one. These physical devices are referred to as "slave devices". Events are generated by the slave devices and then move up to the respective master device. A slave device may only generate XI 1.x or XI2 events, a master device may generate core events as well. With MPX, there may be more than one pair of master device but the principle remains the same. + +All event generation is in _dix/getevents.c_, see _[[GetPointerEvents|GetPointerEvents]]()_ and _[[GetKeyboardEvents|GetKeyboardEvents]]()_ as starting points. + + +## Event creation + +When a device emits events, a SIGIO is fired and the _xf86SIGIO()_ handler is called which in turn calls the _xf86SigioReadInput()_ for the given socket. The latter in turn calls the read input function for the pointer provided. For the mouse driver, this function is _[[MouseReadInput|MouseReadInput]]()_. The evdev driver has it own handler (_[[EvdevReadInput|EvdevReadInput]]()_) and so do all other drivers. + +_[[MouseReadInput|MouseReadInput]]_ is one of the functions in the _[[InputInfoPtr|InputInfoPtr]]_ of the mouse driver. It is set when the input driver is initialised and _[[MousePreInit|MousePreInit]]()_ is called (see section 5.6 in the DESIGN doc). _[[MouseReadInput|MouseReadInput]]()_ does all the processing for the different mouse protocols and then posts the event via _[[MousePostEvent|MousePostEvent]]()_ (again a function pointer in the _[[InputInfoPtr|InputInfoPtr]]_) into _[[MouseDoPostEvent|MouseDoPostEvent]]()_. + + * So, if you are using the mouse, the sequence executed on the driver's side is: _[[MouseReadInput|MouseReadInput]]()_, _[[MousePostEvent|MousePostEvent]]()_, _[[MouseDoPostEvent|MouseDoPostEvent]]()_; + * The generic sequence is _Driver-specific [[ReadInput|ReadInput]]_, _driver-specific processsing_, _xf86Post{Motion|Button|Keyboard|Proximity}Event()_ +For a motion event, the driver calls now _xf86PostMotionEvent()_ and we are back on the server's side. For button events it is _xf86PostButtonEvent()_. Those in turn call _[[GetPointerEvents|GetPointerEvents]]()_ (_[[GetKeyboardEvents|GetKeyboardEvents]]()_ for keyboard events) which creates the necessary number of events and returns them to the caller. _[[GetTimeInMillis|GetTimeInMillis]]()_ is called inside _[[GetPointerEvents|GetPointerEvents]]()_ and timestamps the OS time on the event. Inside the same function, _miPointerSetPosition()_ is called to re-paint the mouse on the screen. It calls _miPointerMoved()_. The _miPointerMoved()_ decides to **start the hw or the sw management/rendering of the cursor** (see section _Cursor rendering_). After this choose the events are put - one by one - onto the event queue using _mieqEnqueue()_. + +Note that all this is inside the SIGIO handler, this is important as you may not allocate of free memory at any time in this stage. + +_[[GetPointerEvents|GetPointerEvents]]()_ will generate a number of [[InternalEvents|InternalEvents]], for this tutorial the interesting onces are the [[DeviceEvents|DeviceEvents]] which represent physical input (motion, button, key events) + +**To sum it up in short: each time a interrupt happens on one of the sockets to an input event, the device driver reads the data, hands it back to the X Server which constructs one or more _[[InternalEvents|InternalEvents]]_ and puts it onto the event queue.** + + +## Event processing + +The event processing stage is the stage where the events are taken off the event queue, individually processed and then sent to the client. Also, more abstract input events (enter and leave notifies) are generated synthetically here. + +All input are processed in the DDX _[[ProcessInputEvents|ProcessInputEvents]]()_. The actual processing is done in _mieqProcessInputEvents()_ which runs through the event queue from beginning to end. Main entry point for DIX-specific processing is _[[ProcessOtherEvent|ProcessOtherEvent]]()_, all events pass through here. Note at this point that the XKB extension wraps _[[ProcessOtherEvents|ProcessOtherEvents]]()_ and is called before we get to POE. XKB is not subject to this tutorial. + +_[[ProcessOtherEvent|ProcessOtherEvent]]()_ does a few things. It updates the DIX-internal device state with the information from the event, then gathers some state required for the event itself. For example it grabs the modifier state from the keyboard to be put into mouse events as additional info. Finally, it calls down into the delivery paths that eventually write the protocol event onto the wire. At this point, we're still dealing with [[InternalEvents|InternalEvents]] only. + +_[[ProcessOtherEvents|ProcessOtherEvents]]()_ also calls _[[CheckMotion|CheckMotion]]()_. This function updates the cursor sprite's position and then sets the event's coordinates to the new sprite positions. Finally, we compare the window the updated sprite is over with the previous one and call _[[DoEnterLeaveEvent|DoEnterLeaveEvent]]()_ if necessary. If the window has changed, we also issue a call to _[[PostNewCursor|PostNewCursor]]()_ which basically changes to the updated cursor shape. + +Let us see what _[[DoEnterLeaveEvent|DoEnterLeaveEvent]]()_ does. If the old window is a parent of the new window, we issue a _[[LeaveNotify|LeaveNotify]]_ to the old window, then recursively send _[[EnterNotify|EnterNotify]]_ events to the ancestors of the target window (this is done in _[[EnterNotifies|EnterNotifies]]()_) and then finally a _[[EnterNotify|EnterNotify]]_ to our new window. If the old window is a child of the new window, we do the same but with the leave and enter notifies swapped around. Finally, if the window are not related, we send a _[[LeaveNotify|LeaveNotify]]_ to the old window and then recursively to its parents (using _[[LeaveNotifies|LeaveNotifies]]()_), then recursively send _[[EnterNotify|EnterNotify]]_ events (using _[[EnterNotifies|EnterNotifies]]()_ again) to the new window's parents and finally a _[[EnterNotify|EnterNotify]]_ to the new window. Remember that there are multiple types of _[[EnterNotify|EnterNotify]]_ and _[[LeaveNotify|LeaveNotify]]_ events. The ones sent to the parents are all of type _[[NotifyVirtual|NotifyVirtual]]_ (or _[[NotifyNonlinearVirtual|NotifyNonlinearVirtual]]_ if the windows are unrelated). The ones sent to the old and the new window are of types _[[NotifyAncestor|NotifyAncestor]]_ or _[[NotifyInferior|NotifyInferior]]_ for related windows and _[[NotifyNonlinear|NotifyNonlinear]]_ for unrelated windows. All enter and leave events are constructed in _[[EnterLeaveEvent|EnterLeaveEvent]]()_. A _xEvent_ is created, filled with values and then sent to the window using _[[DeliverEventsToWindow|DeliverEventsToWindow]]()_. Again, rootX and rootY is taken from the sprite coordinates. This is the simple explanation, the real implementation is somewhat more difficult as we need to synchronise Enter/Leave events to be protocol-correct even if there are multiple master devices present. + +So now that we have finished the enter/leave events we concentrate on what the final event processing consists of. The rule here is: an [[InternalEvent|InternalEvent]] may be delivered as exactly one protocol type, but possibly to multiple clients. So if two clients both selected for core events, both will get the core event. If one client selected for core events and one for XI events, only the XI event is delivered. In the final event delivery path, the client masks are checked on each window in the delivery path and the [[InternalEvent|InternalEvent]] is converted to the respective protocol event. + +The event is adopted to the window in _[[FixUpEventFromWindow|FixUpEventFromWindow]]()_ and then delivered to the window with _[[DeliverEventsToWindow|DeliverEventsToWindow]]()_. _[[FixUpEventFromWindow|FixUpEventFromWindow]]()_ adopts the window specific values to the event's window (the child, eventX and eventY values). If the delivery failed to a given window, the parent is tried until we run out of parent windows. _[[DeliverEventToWindow|DeliverEventToWindow]]()_ calls _[[TryClientEvents|TryClientEvents]]()_ to write the events to the client. If the event is a button press event, _[[DeliverEventToWindow|DeliverEventToWindow]]()_ also activates the implicit pointer grab (a grab that is deactivated automatically on the next button release event). + +Now we have completed event processing, all the events were written to the client and we jump back to the last lines of _[[ProcessInputEvents|ProcessInputEvents]]()_. What is left now is cursor rendering (if applicable), called with _miPointerUpdateSprite()_. + +**Again, a short summary of the event processing stage: the server takes the events off the queue, fills them with the right variables, generate enter and leave notifies if necessary and writes them to the client.** + + +## Cursor rendering + +Cursor rendering is a bit complicated to understand and hard to debug. It is a layered architecture to do as much in hardware as possible and pretty much everything is called via function pointers. Some need for function pointers has been removed with 1.9, but the basic priniciple is the same. + + +### hw cursor + +If the cursor is fully rendered in hardware, _xf86CursorMoveCursor()_ and _xf86MoveCursor()_ are the two first functions called. These functions are called just after the _miPointerMoved()_, the function that decides if the render will be in sw or hw, on the event creation stage. _xf86MoveCursor()_ will call the video driver function desired to take care of the hw rendering. On my case, _ATIMach64SetCursorPosition()_ is called. It do the calculations and paint the sprites on the memory mapped directly to the output stream. In other words, **exactly on this moment the mouse is moved on the screen**. + + +### sw cursor + +If it is done in sofware, the cursor has to be back-buffered. Every time it moves we restore the previous image, save the window at the target position, then render the cursor into the stream. + +We start with everything at the end of _[[ProcessInputEvents|ProcessInputEvents]]()_ and the call to _miPointerUpdateSprite()_. Here we grab the current coordinates of the pointer (remember, they were set when we called _miPointerMove()_ in the event generation stage) and call the _[[MoveCursor|MoveCursor]]_ function in the _spriteFuncs_ of the _miPointerScreenRec_ struct. Of course, if the cursor has changed screen or the shape has changed, this needs to be taken care of too. The _[[MoveCursor|MoveCursor]]_ function is set to _miSpriteMoveCursor()_ which just calls _miSpriteSetCursor()_. This function first checks whether the cursor has changed at all and then the new positions of the cursor. The cursor is then removed with _miSpriteRemoveCursor()_ and then restored at the new position with _miSpriteRestoreCursor()_. _miSpriteRemoveCursor()_ is fairly simple, it just calls the restore function _miDCRestoreUnderCursor()_, which then calls the next layer (damage) to copy the saved area into the window at a given position. _miSpriteRestoreCursor()_ saves the area under the cursor (_miDCSaveUnderCursor()_) into the buffer and then puts up the cursor again (_miDCPutUpCursor()_). If, as mentioned before, the new position is insided the saved buffer, a call to _miDCChangeSave()_ updates the saved region and a call to _miDCMoveCursor()_ will move the cursor. This moving doesn't cause any flickering, the remove and restore procedure may flicker. + +As easy as this sounds, there is more to cursor rendering. Quite a fair bit of work is done outside this explicit rendering calls that are issued when all input events have been processed. Interestingly, pretty much all other function that handle sprite rendering (everything with _miSprite..._) basically remove the cursor from the screen if necessary (i.e. when the window is moved). The one exception is the block handler function (called when there's nothing else to do and the server would block while waiting for input). _miSpriteBlockHandler()_ checks if the cursor was previously removed but should be visible and renders it to the screen again if necessary. + +**What must be clear on the cursor rendering is: hw cursor is rendered before the event be enqueued (i.e., on the event creation stage) and sw cursor is rendered after the _[[ProcessInputEvents|ProcessInputEvents]]()_ (i.e., after the event creation and after the event processing stage).** + + + +--- + + [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/KdriveDrivers.mdwn b/Development/Documentation/KdriveDrivers.mdwn new file mode 100644 index 00000000..4c63eaf3 --- /dev/null +++ b/Development/Documentation/KdriveDrivers.mdwn @@ -0,0 +1,10 @@ + +# moved from [[http://www.freedesktop.org/wiki/Software/KdriveDrivers|http://www.freedesktop.org/wiki/Software/KdriveDrivers]] + + * pScreenPriv->fb[] is an array of 1 or 2 KdFrameBuffers. fb[0] is primary, while fb[1] is only set up if you have an overlay. fb[0]->depth is the color depth (1, 4, 8, 15, 16, 24) for that framebuffer, while fb[0]->bitsPerPixel is how many bits are taken up for storage (?, 8, 16, 24, 32). + * The depth and bitsPerPixel won't change between the card's initAccel and finiAccel -- it was decided depth changes were too costly to do. + * If your hardware doesn't support acceleration for the 24 bitsPerPixel case, one way to get around this is to put the accelerator in 8-bit mode and multiply X coordinates by 3. However, if you do this you need to make sure for Solid fill that the pixel's values are the same for each of the bytes, and return FALSE from PrepareSolid if not (unless your hardware has ability to rotate the pixel data, as in the mach64 driver). Also make sure the planemask won't have problems with rotation, and return FALSE if so. + * Many things are not available at initScreen and scrInit time. It's okay, because almost all setup/teardown for your device should be done in initAccel/finiAccel. These two are called on entering and exiting the server's VT. Things that can be done include but are not limited to initializing extensions and allocating window/pixmap/screen/etc. privates. + * If your driver uses hw/kdrive/vesa or hw/kdrive/fbdev for card initialization and mode setting, your driver's card and screen private records must begin with the fbdev or vesa card and screen private structs, because vesa and fbdev will use the kdrive card->driver and screen->driver pointers to get at their private data. + * should kaaDrawFini() be called in the accelDrawFini() function? +-- Main.[[EricAnholt|EricAnholt]] - 20 Nov 2003 diff --git a/Development/Documentation/MPX.mdwn b/Development/Documentation/MPX.mdwn new file mode 100644 index 00000000..8da5294b --- /dev/null +++ b/Development/Documentation/MPX.mdwn @@ -0,0 +1,58 @@ + +This page lists the differences between X servers with MPX support and previous servers (in terms of input processing only). MPX is the in-server implementation to support multiple simultaneous input devices. The protocol-specific parts to MPX are included in the X Input Extension 2.0 (XI2). + + +## Device hierarchy + +MPX features a two-layer device hierarchy. Any physical device is a "slave device", does not have a cursor and can only send XI events. Then there are "master devices", virtual devices that are represented by a cursor and a keyboard focus. MDs always come in pairs, one pointer, one keyboard. An SD can be attached to a MD. In this case any event by the SD is routed through the MD. To the client it appears that events come from the SD and from the MD (a client should never listen directly to SDs). + +MDs generates core events and XI events. Creating a master device ([[ChangeDeviceHierarchy|ChangeDeviceHierarchy]] request) creates a master pointer and a master keyboard. By default, two MDs exist: the virtual core pointer and the virtual core keyboard. All physical devices are attached to either of these to but this attachment can be changed. + + +## Input events + +In earlier servers, all core events come from the virtual core pointer (VCP) or the virtual core keyboard (VCK). All device events from the device. It is not possible to XOpenDevice() the core pointer/core keyboard. + +In MPX, SDs send XI events and MDs send core and XI events. + + +## ClientPointer + +Each client can have one (master) pointer explicitly assigned. Each time pointer data is needed for request/reply handling, this [[ClientPointer|ClientPointer]] is chosen (e.g. XQueryPointer() will return the [[ClientPointer|ClientPointer]]'s coordinates). The master keyboard paired with the [[ClientPointer|ClientPointer]] will be used for request/reply handling (e.g. XGetInputFocus()). + +The [[ClientPointer|ClientPointer]] should only be used by the window manager to set the CP setting for traditional X applications. If you ever use XSetClientPointer() in your standard GUI application, you're most likely doing something wrong. + +The general rule is that the [[ClientPointer|ClientPointer]] will work just as the traditional pointer in the given client. All other pointers interacting with the same client may experience difficulties (see [[GrabOwnership|GrabOwnership]]). + +Inside the DIX, the [[ClientPointer|ClientPointer]] is realised with the [[PickPointer|PickPointer]]() and the [[PickKeyboard|PickKeyboard]]() functions (events.c). Both of which check the device list for available devices. If there is a physical device attached, then it is chosen as the [[ClientPointer|ClientPointer]] and returned. If no physical device is available, then the VCP is returned. A call to [[PickPointer|PickPointer]]() also _sets_ the [[ClientPointer|ClientPointer]], so subsequent calls to [[PickPointer|PickPointer]]() return the same pointer, unless changed by the client. + +The [[ClientPointer|ClientPointer]] can be set with XSetClientPointer(). + + +## Grabs + +Each device can only be grabbed by one client at a time. If a client core-grabs the device, the [[ClientPointer|ClientPointer]] will be grabbed. Until the core grab is removed, no other client can grab this device (even XGrabDevice() will fail). + +It works the other way around too. If a client uses XGrabDevice(), any XGrabPointer/Keyboard() on the same device will fail with [[AlreadyGrabbed|AlreadyGrabbed]]. + +While a grab is active, other clients may still get events from the other devices. The difference between core grabs and device grabs can be expressed as: + +* A core grab guarantees a client that it doesn't get events from any other device. +* A device grab guarantees that no other client gets events from this device. + +### Grab ownership + +If a client core-grabs a device, no other device will send events to this client while the core grab is active. This is called grab ownership and was necessary to not confuse standard X apps. + +This can be annoying, as clients usually grab the pointer for popup menus. Which in turn means that each time you get a popup, all other devices are deactivated until the popup is gone. Even worse, if you are not the [[ClientPointer|ClientPointer]], you won't even be able to use the popup and the [[ClientPointer|ClientPointer]] has to click on it. Use XSetClientPointer() to avoid this. + +Grab ownership works different for passive grabs. A passive grab is stored on the window with the client's [[ClientPointer|ClientPointer]], but when the grab is activated (by pressing a button/key) the grab device is switched to the device that caused the grab to activate. The device now stays the same as long as the grab is active. If the client now starts an active grab, this active grab is put on the already grabbed device, not on the [[ClientPointer|ClientPointer]]. + +Grab ownership does not apply to device grabs. + + +### XGE + +XI2 requires [[XGE|http://wiki.x.org/wiki/Development/Documentation/XGE]] for its events. + +--- [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/Multiseat.mdwn b/Development/Documentation/Multiseat.mdwn new file mode 100644 index 00000000..65d3d3ce --- /dev/null +++ b/Development/Documentation/Multiseat.mdwn @@ -0,0 +1,47 @@ + + +# Multiseat + +[[Multiseat|http://en.wikipedia.org/wiki/Multiseat]] is a model of computing that supports multiple local users using their sessions in a totally independent way. This looks quite similar to the old mainframe computer model, but with the "terminals" connected directly to single PC box. There's a lot of people that use and sell multiseat Linux systems due its low cost which qualifies it as a wonderful "techno-social" model of computing. With the current version of X (1.7.6) and wisely chosen hardware, is it possible to get working multiseat configuration by just editing few configuration files as documented for example on [[Ubuntu MultiseatX page|https://help.ubuntu.com/community/MultiseatX]] + +In this sense, the intention of this page is the following: + +* to collect all spare documentations and give a guidance to users that want to deploy such model, and; +* to help its development. + +## Information to Users + +There are different solutions to setup a multiseat system. The old -- but still used -- way is through HOWTOs, that show how to configure the xorg.conf, the display manager (e.g. gdm, kdm) and the association of devices to seats. There are a huge pile of HOWTOs in the Web. Basically the HOWTOs show two different approach of configuration: + +* multiple Xephyr servers (or Xnest) over a host Xorg, and +* multiple instances of Xorg. +The Xephyr's approach is known to work with "any" video card vendor but lacks some extensions (3D, OpenGL) and has the latency for being nested servers. The "multiple Xorg" approach is "right way", but it only work with a limited video cards. + +When each seat is just a collection of USB devices (including USB graphics, input, etc.), this multiple xorg approach works (because there are no VGA arbitration issues, etc), and multiseat has the potential to be plug and play via udev rules. Instructions and current limitations for this type of implementation on recent versions of Ubuntu are at [[http://libdlo.freedesktop.org/wiki/MultiSeatTerminal|http://libdlo.freedesktop.org/wiki/MultiSeatTerminal]]. + +The [[Multiseat Display Manager|http://wiki.c3sl.ufpr.br/multiseat/index.php/Mdm]] (MDM) tool help to automatize the process of installation and configuration for multiple PCIe graphics cards. Despite its name, MDM is actually a wrapper on the real display manager. It is used to configure multiseat environments, allowing users to change a normal machine into a multiseat machine by just installing a package. The current version of MDM is only configuring the Xephyr's based solution. + +* [[http://userful.com|http://userful.com]] (commercial solution, but [[free for personal use|http://www2.userful.com/products/downloads/free-2-user]]. Single virtualized xServer, high performance approach and widely used, over 400,000 seats deployed, supports single-chip dual-head video cards) +* [[http://en.wikibooks.org/wiki/Multiterminal_with_Xephyr|http://en.wikibooks.org/wiki/Multiterminal_with_Xephyr]] (slower performance as it relies on nested Xservers, but supports broader hardware than the MSS approaches below, over 40,000 seats deployed) +* [[http://wpkg.org/Configuring_multiseat_X_workstation|http://wpkg.org/Configuring_multiseat_X_workstation]] (Multiple Simultaneous xServers (MSS), less dependable hardware support) +* [[http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html|http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html]] (MSS) +* [[http://wiki.debian.org/Multi_Seat_Debian_HOWTO|http://wiki.debian.org/Multi_Seat_Debian_HOWTO]] (MSS) +* [[https://fedorahosted.org/multiseat/|https://fedorahosted.org/multiseat/]] (MSS) +* [[https://help.ubuntu.com/community/MultiseatX|https://help.ubuntu.com/community/MultiseatX]] (MSS) +* [[http://www.linuxtoys.org/multiseat/multiseat.html|http://www.linuxtoys.org/multiseat/multiseat.html]] (MSS) +* [[http://netpatia.blogspot.com/2006/09/multiseat-computer-with-ubuntu.html|http://netpatia.blogspot.com/2006/09/multiseat-computer-with-ubuntu.html]] (MSS) +* [[http://www.automation.dn.ua/linux/3d-multiseat_en.html|http://www.automation.dn.ua/linux/3d-multiseat_en.html]] (MSS) +* [[http://www.gentoo-wiki.info/HOWTO_Multiseat_X|http://www.gentoo-wiki.info/HOWTO_Multiseat_X]] +* [[http://vignatti.wordpress.com/2008/09/23/multiseat-roadmap/|http://vignatti.wordpress.com/2008/09/23/multiseat-roadmap/]] +Users are also encouraged to read the [[Wikipedia's article|http://en.wikipedia.org/wiki/Multiseat]] about multiseat. + + +## Development + +* [[Wikipedia's article|http://en.wikipedia.org/wiki/Multiseat]] (nice historical references) +* [[Multiseat's roadmap|http://vignatti.wordpress.com/2008/09/23/multiseat-roadmap/]] (Set 2008). +* [[VgaArbiter|VgaArbiter]] +* Integration with the rest of the system: + * [[ConsoleKit|ConsoleKit]] + * [[PulseAudio|PulseAudio]] + * hal/udev
\ No newline at end of file diff --git a/Development/Documentation/Multitouch.mdwn b/Development/Documentation/Multitouch.mdwn new file mode 100644 index 00000000..d2c26c4a --- /dev/null +++ b/Development/Documentation/Multitouch.mdwn @@ -0,0 +1,115 @@ + +[[!toc ]] + +This page describes the server internals of multitouch event processing for XI 2.2. Documentation may get out of date, assume that the final reference is always the code. In order to understand this text, you need to be familiar with the [[XI 2.2 protocol specification|http://cgit.freedesktop.org/xorg/proto/inputproto/tree/specs/XI2proto.txt?h=multitouch-devel]]. Many of the terms used here will not make sense otherwise. + + +# Basics + + +## Pointer emulation + +Pointer emulation is the most complicated part of the code since it needs to transparently work around pointer grabs in all three protocols (core, xi2, xi). + +Pointer emulation is decided on in the event generation code: if a new [[TouchBegin|TouchBegin]] is submitted and no other emulating touchpoint is currently active, the new touchpoint becomes the emulating touchpoint. This code has a few corner cases that will be buggy. E.g. two touch device submitting their first event through the master, both will assume pointer emulation. Furthermore, the events the server deals with internally are always touch events. If a pointer-emulating touch should send pointer events, this conversion happens quite late and only for the wire protocol. The reason is simple - if an event is replayed, we need to know that the original event was a touch event to make sure we deliver the right type to the next client. + + +# Driver API + +The driver API consists of one new call to set up the device: _[[InitTouchClassDeviceStruct|InitTouchClassDeviceStruct]]_. For the actual valuators, the drivers should use the existing API _xf86InitValuatorAxisStruct_, just as they did before. + +Touch events can be submitted to the server with _xf86PostTouchEvent()_. Each touch event must have touch ID unique for the duration of the touch. Touch IDs must be new for _XI_[[TouchBegin|TouchBegin]]_ events and one of the currently used ones for _XI_[[TouchUpdate|TouchUpdate]]_ or _XI_[[TouchEnd|TouchEnd]]_ events. Once a touchid is used for a _XI_[[TouchEnd|TouchEnd]]_ event, the driver can re-use it. + + +# Event generation + +The xfree86 input API has a single call for drivers to submit touch events: _xf86PostTouchEvent()_. This is a wrapper around the DIX' _[[GetTouchEvent|GetTouchEvent]]()_ which is the main event generation function. Driver events are usually submitted in a SIGIO handler, valuator data is converted into an _[[InternalEvent|InternalEvent]]_ (_[[DeviceEvent|DeviceEvent]]_) and appended to the event queue. During event processing time the events come out of the event queue, where they affect the logical state of the device and are sent to the clients. This is the same process as for other input events. + +Drivers cannot generate [[TouchOwnership|TouchOwnership]] events, they are generated in the server only. + + +## DDX TouchPoints + +Each touch-capable device has a number of DDX touchpoints which represent the physical touchpoints as seen by the driver. DDX touchpoints are the equivalent to last.valuators. These touchpoints are not affected by grabs, they begin on a driver-submitted [[TouchBegin|TouchBegin]] and end on a driver-submitted [[TouchEnd|TouchEnd]] event. Each DDX touchpoints has two touch IDs, the driver's touch ID and the protocol-visible client ID. Either must be unique but they are unlikely to ever be identical. The driver's touch ID is irrelevant outside the event generation code, it is only used for matching [[TouchUpdate/TouchEnd|TouchUpdate/TouchEnd]] events to the matching touch points. Once that's done, the (server-assigned) client ID is the only one that matters. + +Pointer emulation is decided on DDX touchpoint creation - if the touchpoint is the first one on the device pointer emulation is enabled. Otherwise, or if the device is a [[DependendTouch|DependendTouch]] device, pointer emulation is disabled. DDX touchpoints are separate from the DIX, so pointer emulation and other information is transferred via event flags. + +Note that due to the grab semantics, touch events may be submitted from the DIX with the client-ID as identifier. This is indicated with a flag. + + +## Raw touch events + +Raw touch events are virtually identical to pointer/keyboard raw events and do not require specific handling. Assume that raw events are handled like pointer events. For pointer-emulating touches, no raw events are generated. + + +# Event processing + +In event processing, the touch events are passed from the event queue into _[[ProcessTouchEvents|ProcessTouchEvents]]_. The master/slave device hierarchy is handled identical to other input events. Touch events are delivered to a bunch of listeners that are established on [[TouchBegin|TouchBegin]]. Event mask changes during touch sequences have no effect on the listeners, and the listener list is static, listeners may not be added after the [[TouchBegin|TouchBegin]]. Listeners may be removed if they will not receive further events for this touch sequence. + +All listeners have a state that specifies the next event that listener expects to receive. + +* _LISTENER_AWAITING_BEGIN_: the listener has not received the [[TouchBegin|TouchBegin]] yet. Listeners not supporting ownership will be in this state until they become the owner. +* _LISTENER_AWAITING_OWNER_: the listener has received a [[TouchBegin|TouchBegin]] but is not yet the current owner. It must receive a [[TouchOwnership|TouchOwnership]] event first. +* _LISTENER_IS_OWNER_: the listener has received the [[TouchBegin|TouchBegin]] and, if applicable, a [[TouchOwnership|TouchOwnership]] event. If the listener is a grab, it must now accept/reject the touch +* _LISTENER_HAS_END_: the listener has received the [[TouchEnd|TouchEnd]] event but the server is still waiting for a accept/reject. +Listeners also have a type and the input level they work on. The level is one of XI2, XI or CORE, with the latter two only being available to pointer emulation. The type is one of + +* _LISTENER_REGULAR_: window event mask selected for touch events, type always XI2 +* _LISTENER_GRAB_: passive grab selected for touch events, type is always XI2 +* _LISTENER_POINTER_REGULAR_: window event mask selected for pointer events, any type +* _LISTENER_POINTER_GRAB_: passive grab selected for pointer events, any type. +**A note on the code: listeners states and types were introduced quite late and the earlier MT patches do not make use of them. This history may be squashed out** + + +## TouchBegin + +On the initial [[TouchBegin|TouchBegin]] event, a DIX touchpoint is generated. This touchpoint is re-used for future [[TouchUpdate/TouchEnd|TouchUpdate/TouchEnd]]; it is a bug if a touchpoint cannot be found for a TouchUpdate/End event. A touchpoint has a number of listeners (recipients for events). The current position of the sprite identifies the window trace. This trace is traversed root-to-bottom for any touch grabs and then again bottom-to-root for the _first_ applicable touch event selection. Any matching grab or client is added to the listeners list. This listener list is static, listeners may not be added after the [[TouchBegin|TouchBegin]]. Listeners may be removed if they will not receive further events for this touch sequence. If any of the listeners does not support touch ownership events, a touch history is allocated and all touch events are stored for replaying on reject. Listeners not supporting touch ownership that are not the current owner do not receive the [[TouchBegin|TouchBegin]] event until the current owner has _rejected_ the touch. + +The [[TouchBegin|TouchBegin]] event is sent to the owner of the touch (top-most grab or the window if no grab is active), and to any listener that supports ownership events. + + +### Pointer emulation for TouchBegin + +If a touch emulates pointers, a [[MotionNotify|MotionNotify]] event is generated and sent before the [[TouchBegin|TouchBegin]] is processed. In addition to touch event masks, grabs and windows are also checked for an applicable pointer event mask. Each grab or window is first checked for a touch mask, then for XI2, XI, core pointer events (in that order) before the traversal moves to the next grab/window. Thus, a pointer selection on a window will prevent a touch selection on a higher window. + +A [[ButtonPress|ButtonPress]] is sent only if the touch is emulating and the current owner of the touch requires button events. + +On the intial [[TouchBegin|TouchBegin]], the device state is updated and the device appears with one button logically down. + + +## TouchUpdate + +[[TouchUpdate|TouchUpdate]] events are sent to the current owner and all listeners that support touch ownership. + + +### Pointer emulation for TouchUpdate + +A [[MotionNotify|MotionNotify]] event is generated and sent exclusively to the current owner if applicable. + + +## TouchEnd + +A driver-generated [[TouchEnd|TouchEnd]] event is sent exclusively to the current owner. If any other listener supports touch ownership, the event is sent as [[TouchUpdate|TouchUpdate]] with the pending flag to all these listeners. If no grab is active, the [[TouchEnd|TouchEnd]] finalises the touch, otherwise the current owner must accept or reject the touch. + +If the touch is accepted, a new [[TouchEnd|TouchEnd]] is generated and sent to all listeners supporting ownership (those not supporting ownership have never seen the [[TouchBegin|TouchBegin]]). If the touch is rejected, a [[TouchEnd|TouchEnd]] event is generated and sent to the current owner unless that owner is in LISTENER_HAS_END. That owner is removed from the listeners. + +If the next listener is in state LISTENER_AWAITING_BEGIN, the event history is replayed for that listener (i.e. the [[TouchBegin|TouchBegin]] and all [[TouchUpdate|TouchUpdate]] events). The listener moves to state LISTENER_IS_OWNER. + +If the next listener is in state LISTENER_AWAITING_OWNER, a [[TouchOwnership|TouchOwnership]] event is generated and sent to the that listener. The listener moves to state LISTENER_IS_OWNER. + +It is now the new owner's job to accept or reject the touch. A event history may be replayed multiple times. + + +### Pointer emulation for TouchEnd + +A [[MotionNotify|MotionNotify]] event is generated and sent to the current owner if applicable before the [[TouchEnd|TouchEnd]] event is processed. + +On the final [[TouchEnd|TouchEnd]] event, the device state is updated and the device appears with the button logically up. + +Replaying the event history on a reject causes the respective pointer events to be delivered to the current listener. + + + +--- + + [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/Obsolescence.mdwn b/Development/Documentation/Obsolescence.mdwn new file mode 100644 index 00000000..6fac304c --- /dev/null +++ b/Development/Documentation/Obsolescence.mdwn @@ -0,0 +1,714 @@ + + +# Notes on the status of X.Org technologies + +Jim Gettys has kindly contributed the attached long-running draft document describing the status of various X.Org technologies. This draft is from October 2008, and much of its content is from 2004, so it is a bit old. However, it still contains much useful information. If someone wants to take over its maintenance and put it up on the wiki, let me (bart at cs dot pdx dot edu) know. No fair making fun of it or critiquing it; it was very kindly donated and is known to need work. + +[[roadmap-2-clean.pdf|roadmap-2-clean.pdf]] + + +# Open Source Desktop Technology Road Map + +Jim Gettys, Version 2.0, October 23, 2008 + + +## Abstract + +Navigating the myriad technologies that comprise the desktop (and palmtop) on open source systems is daunting to say the least, for newcomers of all sorts, open source developers, developers in companies using the technologies internally, and commercial ISVs, and even difficult to navigate for those immersed in open source systems on a day to day basis. + +This document attempts to give a sketch of the names and relationships of these technologies and projects, and a glimpse into their status and development. Some technologies have never proved themselves, and/or have been rendered obsolete by later development and are available primarily for legacy code. This document attempts to clarify much of this natural evolution and market selection. Ultimately, some technologies become so rare as to enable their interment into the strata of software history, and it can be important to know which technologies are in such a fossil state, or stuck in the Labrea Tar Pits and possibly doomed to extinction, if not yet dead. A few may manage to struggle their way out of the tar to safety on dry land again. + +Some indication of the licensing terms is made. For commercial software, make sure you understand the differences between licenses. For example, GPL and LGPL'ed libraries have very different consequences; one requires that source code of applications linked against them be made available, and the other does not require such disclosure. It is also possible for software to be available simultaneously under multiple licenses, sometimes allowing the implementer to choose which applies. See the Open Source Initiative for an explanation of these licenses. + +Where known, approximate dates of expected completion are included, but there is no guarantees made. If you would like to ensure the timely completion of technologies under development, you should work with the community to determine if further resources are needed, and if so, to contribute the talent, resources and funding to do so. + +Note that this document is still a bit weak in futures and I plan further work in this area. As in a map of a physical area, having information about current areas and how they interrelate was the first goal. + + +## Acknowledgments + +This document is the work primarily of its author, and the opinions here are my own; blame me for any errors and biases. Please let me know of any inaccuracies, and in particular, pointers to road maps of projects mentioned here. I would much prefer to have good pointers to similar project road maps than my current (mis) understanding of their time lines and development state, which is, of course, in a constant state of flux. + +Similarly, if you believe I have overlooked some key piece of open source desktop middleware technology (as opposed to end user applications which are too numerous to list), please let me know. + +My thanks to Keith Packard, Jamey Sharp, Kevin Whitwell, Waldo Bastian, and Eric Raymond, Zenaan Harkness, David Alan Gilbert, Maarten Stolte, Maarten Stolte, Kurt Pfeifle, Brenda J. Butler, Zenaan Harkness, Eero Tamminen, Brian Gallaway Sergey V. Oudaltsov, John Smirl, and Vincent for constructive comments and feedback on Version 1 of this document. + + +## Table of contents + +Open Source Desktop Technology Road Map + +1. Abstract +1. Acknowledgements +1. Table of contents +1. Introduction +1. Specifications + 1. ICCCM + 1. Freedesktop specifications +1. X Window System + 1. Key protocol extensions/libraries + 1. Xlib - basic X library + 1. 3D libraries + 1. Mesa - The 3D Graphics library + 1. Direct Rendering Infrastructure (DRI) + 1. XInputExtension + 1. SHAPE + 1. XSYNC + 1. XVideo + 1. DOUBLEBUFFER + 1. The X Resize and Rotate Extension (RandR) + 1. Security + 1. Record + 1. XTest + 1. Render + 1. Xft2 library + 1. Xinerama + 1. Xnest + 1. X extensions under active development + 1. Obsolete X extensions + 1. X libraries under active development + 1. X toolkits + 1. GTK+ toolkit + 1. Qt toolkit + 1. Other toolkits + 1. Moribund X toolkits + 1. Motif + 1. TK + 1. Other key libraries + 1. Fontconfig - font configuration library + 1. Freetype 2 - font rendering + 1. Cairo - vector graphics library + 1. Hardware Abstraction Layer (HAL) + 1. DBUS - message bus system + 1. XML libraries + 1. Pkgconfig + 1. Zeroconf + 1. Multimedia + 1. Multimedia frameworks + 1. Helix community + 1. aRts + 1. Gstreamer + 1. Mplayer + 1. VideoLAN + 1. Xine and Xinelib + 1. Audio + 1. Advance Linux Sound Architecture (ALSA) + 1. Audio servers + 1. aRtsd + 1. Enlightened Sound Daemon (ESD) + 1. Jack + 1. MAS + 1. Microsoft interoperability + 1. SAMBA + 1. File systems + 1. File formats + 1. WINE + 1. Winelib + 1. DOS emulation + 1. .Net and Mono + 1. Displaying Windows applications on Open Source systems + 1. X implementations for Windows + 1. Cygwin and Cygwin/X + 1. Cygwin/X + 1. Commercial X implementations + 1. Fonts + 1. Printing + 1. Postscript and PDF + 1. Common Unix Printing System (CUPS) - print spooling system + 1. Thin clients + 1. Linux Terminal Server Project (LTSP) + 1. Athena Computing Environment + 1. Java + 1. VNC + +## Introduction + +The most visible desktop projects are the KDE and Gnome desktop projects. These projects provide the basic toolkits, window managers, menu systems and control panels found in modern user interfaces along with many end user applications. It is important to note that the work of freedesktop.org is to ensure that applications and infrastructure can be shared between projects, and to enable this sharing in a way that end users do not know or care what environment these applications may be "native" to. In large part, this goal of freedesktop.org is being met, though there is more work to be done. The Gnome project's roadmap covers its next few releases. + +Other major applications projects, which themselves may be platforms on which other applications are being built include the Open Office project (Sun's [[StarOffice|StarOffice]] suite is based on [[OpenOffice|OpenOffice]]), providing a entirely free office suite, and their plans can be found in their road map. Better integration with other applications on the desktop is high on that list; Open Office has used their own toolkit and needs better integration with Gnome and KDE. + +The Mozilla project is also of special mention, who have built a world class free web application suite supporting all the widespread Web technologies (e.g., CSS, Javascript, etc.), including browser, mail client, bug tracking system, and other technology, used not only in their applications but also by other applications in the open source desktop. Mozilla's road map covers both its recent history and current plans. Another implementation of web technologies underlies the KHTML Rendering engine of the KDE project and Apple in Mac OS X, and is now called webkit; it may be becoming a viable alternative to the Firefox gecko rendering engine. Firefox has the distinction of having seriously undermined Microsoft's control of the web; its 20% market share (along with the additional marketshare of webkit, most notably in Mac OSX Safari) has wrested back control to web standards from their proprietary technologies. + +Native plugins exist, often many, for most of the commonly used web datatypes (e.g., flash, [[RealPlayer|RealPlayer]], PDF). There are a few reasonably common datatypes for which there is no good native plugin available (fewer and fewer as the months go by). Windows plugins can often then be used via WINE. One of the interesting problems is in fact, too many plugins for a given datatype. Better user interfaces to invocation of plugins have helped ameliorate this problem in current desktops, and Linux distributions have matured and reduced the number of options presented to a naive user to a reasonable defaults to help with this embarrassment of riches. A few datatypes remain difficult, but great strides have been made since V1 of this document. + +The desktop applications themselves are far too numerous to begin to mention. A (large) subset of open source applications of all sorts numbering in the many thousands can be discovered on the Freshmeat web site, in addition to the KDE and Gnome desktop projects. All of these projects build on the technologies covered in this road map (and sometimes additionally run on Windows and Mac OS X, most particularly the X Window System, but attempting to provide a road map to those projects is outside of the scope of this document. + + +## Specifications + +Historically, the X specifications were developed and ratified in the MIT X Consortium, and its successor organization, X.org. X.org has morphed successfully from an industry consortium to an organization in which individuals, both at a personal level and as part of work they do for their companies have voice, working as part of the larger freedesktop.org and free standards community. Current X.org releases form the core of the free desktop. + +As discussed below, the X Window System was designed to allow for extension, and many extensions as outlined above have been developed, deployed, and sometimes discarded over the years. Note that an API is just one binding to the specific protocol; there are and have been multiple such APIs and implementations at times to the same underlying set of protocols. + +Besides the APIs and protocols mentioned below, there are a set of other protocols and (sometimes multiple) implementations of APIs that are involved in the overall open source desktop. Most of these are primarily of interest to toolkit, window manager, and desktop environment programmers rather than directly to most application programmers. This section attempts to outline the most important of these, and their current status. + + +### ICCCM + +The original "Inter-Client Communications Conventions Manual" outlines the original set of conventions required of applications (mostly implemented in toolkits rather than directly by applications) to "play well" in the modular environment of the X architecture, allowing for interchangable window managers, and other facilities. It was (mostly) sufficient to implement the CDE desktop, but insufficient for more modern environments. These (along with the EWMH (extended window manager hints) are built on top of the X11 core protocol using its general atom and property mechanism. + + +### Freedesktop specifications + +Freedesktop.org was founded to foster the discussions between the Gnome and KDE desktop projects to extend the ICCCM in ways required for more modern environments. It now often hosts core desktop infrastructure projects (e.g., X, dbus, etc.). + +Areas needing work to ensure further interoperability of applications build in one toolkit framework to be fully usable in others has included drag-and drop, window manager extensions, desktop entry files that describe information about applications, application embedding, UTF-8 support, bookmark exchange, menus, mime database, desktop settings, to name a few. Descriptions of the status of these specifications along with the specifications themselves are available and I recommend you look there for more information. + + +## X Window System + +The X Window System, Version 11, or X11, or most commonly called X, is the network transparent window system used on Linux, UNIX, and other platforms including Macintosh OS/X, and Microsoft Windows. It provides the basic infrastructure from which graphical user interfaces are built on Linux and UNIX. X11 was first released in 1988, and has an unrivaled reputation for stability; applications running on a MicroVAX of that era will interoperate against the latest X implementations across today's network, unchanged. This stability has been ensured by a careful, extensible protocol design framework, and attention to detail in the addition of new features. + +I gave a USENIX talk on open source software development using the X Window System history that may be of interest. + +New X extensions have been defined in recent years to bring X's original capabilities up to (and in some cases well beyond) the proprietary state of the art. Whenever possible, these programmer's APIs have been built to allow even downwards compatibility to ease deployment of modern applications to older X server implementations. A good example of this is the Xft2 library, which, while performing best on X implementations where the X Render extension is present, will in fact provide high quality anti-aliased text on old X servers. In some areas X still needs work; much of this work is underway as described below and in more detail elsewhere. + +In the X environment GUIs are built using Toolkit libraries, of which the most common at this date are Qt and GTK+. Motif based applications from the earlier generation of development on UNIX are now extremely rare (except as legacy applications inside and of corporate environments). + +A component of an X Window System based environment not found as an independent component in other window systems is the external "window manager", which allows users to control the size, location and decoration of application's windows on the screen. They are, in fact, applications like any other application in X11, though you can generally only run one window manager at a time. Window managers are, for the most part, interchangeable components, and the standards defined originally by the X Consortium such as the ICCCM, and its successor X.org, along with the new specifications developed on freedesktop.org govern the protocols between applications and window managers. Window managers in common use today include KDE's window manager, Compiz Fusion or Metacity used by Gnome, and many, many others. Those that have been kept up to date with the freedesktop.org specifications are generally interchangeable and a matter of personal taste, though both major desktop projects have window managers they prefer, and which may integrate best into that environment. Some of these (e.g., Compiz Fusion) provide amazing visual eye-candy if requested, though mercifully, its default behavior is now sane. + +Other components, such as panels, start buttons, file managers, and many basic applications are provided by the desktop systems. The largest and most well known of these projects are the Gnome desktop project, the KDE desktop project, and the CDE desktop previously used on UNIX systems. CDE is dead. A detailed road map of these projects is outside the scope of this document. The projects have a life of their own, and you are best consulting them as to their plans. They encompass many thousands of open source applications at this date. + +There are multiple implementations of the X Window System which share code, both open source and provided by commercial vendors. The commonly deployed implementation on open source systems is currently provided by X.org which hosts its development here at freedesktop.org. XFree86, while still existing, has become a relic of the past, triggered by its license change and general disgust with its policies. + +There is much mythology of X's size; this is mostly an artefact of how memory usage is reported on systems (the entire frame buffer, off screen memory and any register space is reported against the X server's process's size, even if X itself is only consuming a megabyte or two of space itself). Similarly, some applications request X to save large amounts of pixels on their behalf, when other implementation approaches often easily avoid such memory usage. X is being successfully used on systems from IBM's Linux watch with 8 megabytes of compressed flash and 8 megabytes of RAM with a tiny 96×120 screen, to current PDAs like HP's iPAQ, to DMX based projector walls containing tens of millions of pixels. With recent work, the minimal X footprint (X server and cut down Xlib) is currently just over 1 megabyte of code (uncompressed), excluding toolkits that are typically much larger, and could be cut smaller. After all, X11 was developed on VAX 11/750s that had less than one MIP with 2 megabytes of RAM. + + +### Key protocol extensions/libraries + +These protocol extensions generally come with a C language library, that is often just a wrapper around the protocol, but sometimes includes additional functionality. + +The Freedesktop.org X server and the XFree86 X server along with all base protocol libraries are MIT licensed, Commercial vendors of X technology may have additional restrictive licenses placed on their implementations as allowed by the MIT license. + + +#### Xlib - basic X library + +This library provides the basic protocol bindings and client side support for extensions, as well as a number of other facilities, some of which are useful, and some of which do not or have not seen serious use recently. The Motif toolkit uses more of these features than more modern toolkits such as GTK+ or Qt, which, for example, have found Xlib's facilities inadequate in a number of areas (e.g., internationalization). As the basic library for the X protocol, its API is very stable. + +Several sections of the Xlib API are seldom used in modern practice, either because the facilities never achieved widespread acceptance (as in the X Color management part of the API), or because modern toolkits have found that they needed more advanced facilities (as in the Locale section of the Xlib API), where the modern toolkits provide better facilities. + +A replacement for Xlib's protocol bindings called Xcb can offer better performance by making it easier to avoid round trip messages to the window system in some areas. It has recently been deployed underneath the Xlib bindings to allow a migration strategy for applications that use plug-ins. The Xlib interface remains exactly API compatible with the old implementation. Work can now begin to take advantage of this in toolkits. Xcb was also carefully designed for thread safety, which was very difficult indeed in the old Xlib implementation. + +Some work was underway to enable applications to be properly notified of connection failure with the X server (often seen when X is used over wireless networks, and sometimes over the wired internet) and allow for graceful shutdown. It was put on hold in favor of Xcb and would be nice to resurrect now that this work is maturing. This will enable the migration of running applications between X displays and movement of sessions. You would like to be able to go home and (securely) retrieve the applications running on your desktop at work. The GTK+ toolkit already has support for migration of applications, except for proper shutdown in the case of failure, and architecturally, this should be true for Qt as well. We hope that this will become usable during 2004, and widely deployed during 2005. + + +#### 3D libraries + +3D is provided in the open source environment by industry standard OpenGL. Both closed source commercial and open source implementations of OpenGL are available. With the increasing industry cooperation in providing documentation and programming resources, the open source implementations are rapidly becoming truly competitive, and may reach parity or exceed proprietary implementations during 2009 and 2010. A few vendors (e.g., Nvidia) still do not provide documents or resources for supporting their hardware and should be avoided whenever possible. + + +##### Mesa - 3D graphics library + +Mesa is an open source 3-D graphics library with an API which is very similar to that of OpenGL. Mesa is used as the core of many hardware OpenGL drivers for XFree86 within the DRI project. Software only implementations of Mesa are generally available even if hardware accelerated versions are not, but such implementations of Mesa will not be sufficient for more than very simple applications. + +GLX is the binding of OpenGL to the X protocol, to allow for network transparent OpenGL applications. Mesa has been a project for more than 10 years, and various parts of it are available under a number of open source licenses. + + +##### Direct Rendering Infrastructure (DRI) + +DRI is the direct rendering infrastructure for the X server for OpenGL direct rendering, and provides the device driver and coordination with the window system to allow 3D applications direct access to the display hardware. The DRI does not assume or require that the drivers be based on Mesa. Several non-Mesa, closed source drivers have used the DRI. + +The DRI provides direct access to graphics hardware in a safe and efficient manner. It includes changes to the X server, to several client libraries, and to the kernel. The first major use for the DRI is to create fast OpenGL implementations. + +It has been in use for a number of years, and is widely deployed with drivers for much of the common 3D hardware. DRI2 has started deployment. + + +#### MPX + +Peter Hutterer has done amazing work called "MPX", or Multi-Pointer X, enabling multiple input devices and multiple cursors in the X Window System. Part of this work has just been released in the X.org 7.5 release. + + +#### XInputExtension + +XInput provides support for "non-core" input devices, such as trackballs, dial boxes, tablets, etc. It provides adequate facilities for these devices, but work continues to extend XInput to support "hot-plug" input devices. Addition of new input devices may still require manual configuration of the X server, but probably not by the end of 2009. Work is also needed to aid use of new facilities provided by the base operating system (e.g., /dev/input) in Linux. + +This area needs some serious work. GTK+ application migration can already be demonstrated, and what is there is only adequate for session migration. Shared displays (e.g., a projector being simultaneously used by multiple users) bring to fore another issue: that of network transparent access to input devices. If I have an application I have migrated to a remote display, I may want my keyboard, mouse and other input devices to follow. While X applications like x2x help, this is really just a bandaid, and a more generic network input event mechanisms are needed, with good integration into the environment. You should be able to use devices anywhere in your environment. With hotplug a reality, building such a network environment is now possible and awaits eager hackers. + +Xinput V2 and a revision of the X keyboard extension are planned for the next year. + + +#### SHAPE + +The Shape extension provides non-rectangular windows in the X environment, and is universally deployed in X implementations. + + +#### XSYNC + +The X Synchronization Extension provides facilities for applications to synchronize with each other, and with real time. XSYNC is widely deployed and in its current form, very stable. + +Facilities to allow XSYNC to synchronize with video vertical retrace, audio sample clocks and other time bases are easy to add (and were the original intent of XSYNC), but while some work has been done to do this on Linux systems, it is not yet available in production X servers. It is also used by toolkits to synchronize repainting with the compositing manager. + + +#### XVideo + +The XVideo extension provides support for video overlays, and similar facilities desired for video playback. It is commonly available on displays with hardware support for video playback. It provides facilities for the scaling and conversion of HSV data. + +The better implementations no longer use chroma keying for display of video data, so that video can be composited as a first class citizen in the new world order. + + +#### DOUBLEBUFFER + +The DOUBLEBUFFER extension provides double-buffering facilities. It is widely available and supported. + + +#### The X Resize and Rotate Extension (RandR) + +Randr provides facilities for resizing, rotating, and reflecting the screen. It may also report root window size changes to (interested) clients. + +RandR's support depends upon the state of driver support for RandR. The XFree86 server only has support for size changes in XFree86 4.3. The Kdrive server provides full support for the extension. It is relatively new and not universally available. Applications can usually be oblivious to its existence, though window managers and toolkits should consider support. Both Gnome/GTK+ and KDE/Qt have good support for RandR at this date. + + +#### Security + +The Security extension was introduced to address the security issues of mixing trusted and untrusted clients on a single X server, according to compartmented mode workstation thinking of the early 1990s. + +The old X security extension does no serve sany useful purpose in most of today's environments, however, different facilities are needed, particularly for shared displays. Work done by Eamon Walsh of the NSA has provided X with a generic security framework into which different policies can be plugged (their plan is an SELinux like model; but others may be more usable for other environments); while this work is not quite complete, it is maturing rapidly. Our thanks for the efforts. + + +#### Record + +The Record extension provides facilities for recording the operation of the X server, and is often used in concert with the XTest extension for window system and application testing. It is stable and widely deployed. + + +#### XTest + +The XTest Extension is primarily intended to allow for pretty thorough testing of the X server, by synthesizing input. As such, it is also used in some other situations when synthetic input to the window system is needed (e.g., stroke recognition). + +There are two extensions by this name (cool, huh?). + +The small XTEST extension was developed by Unisoft as a part of their Xlib test suite development to test pieces of the system which are otherwise unreachable.It is widely deployed and very stable. The larger XTestExtension1 was developed by HP to help produce automated application testing mechanisms. This is not deployed and an architectural nightmare and can be considered extinct. Everyone uses XTEST to synthesize input instead of XTestExtension1. + +It is widely deployed and stable. + + +#### Render + +The largest visible change in X is recent, with the addition of the X Render Extension, which provides Porter-Duff image compositing to the graphics capability of the X Window System. It is now widespread and used by most modern toolkits particularly for text, which is now rendered as alpha-composited, anti-aliased glyphs cached in the X server, completely supplanting the "core" text facilities of the original X11 protocol. The old "core" text facilities (bitmaps only) are still supported for backwards compatibility, but the Xft2 library and Cairo allows for reasonably painless updating of applications to support full AA text, even on X servers that do not support the Render extension. + +The last facility of Render, not yet universally deployed, is support for AA trapezoids. Much device driver work remains to optimize the extension and use the facilities provided by modern graphics accelerators. Even so, the current usually software only implementation of Render, is fast enough for most applications. + + +#### Xft2 library + +Xft2 provides a client-side font API for X applications. It uses Fontconfig to select fonts, Freetype 2 for rendering the fonts and the X protocol for drawing them on the screen. When available, Xft uses the Render extension to accelerate text drawing. When Render is not available, Xft uses the core protocol to draw client-side glyphs. This provides completely compatible support of client-side fonts for all X servers, enabling application developers the benefits of anti-aliased, sub-pixel decimated text on all X implementations. This backward compatibility is seldom needed now, but was essential for its success. + +Xft1 is obsolete and should not be used; it did not provide AA text on old X servers, and combined this functionality with what is now Fontconfig, which has been made a separate library usable by all applications, not just X applications. Both Qt and GTK+ in versions since mid 2002 have used Xft2 for their text rendering. + +Xft2 is stable, and now widely available and deployed on open source systems. + + +#### Xinerama + +Xinerama allows multiple screens to be combined into one larger virtual X screen, mostly invisibly to most applications. + +Its major liability is that merging screens of different types force the least common denominator behavior of the capabilities of the screens. In practice, this is not a serious limitation for casual use. The new extensions under active development may allow for a more flexible Xinerama like system without its liabilities to be built. + +Xinerama is widely available and deployed, though not all X drivers are implemented to allow it. + + +#### Xnest and Xephyr + +These is not an X extensions, but an X server running in an window. This can be very useful not only for server debugging, but ensuring that your applications work well on different size X displays, for example the small screens found on PDAs. + +Xnest is widely available and deployed, though some extensions may not be present. Xephyr is more likely to be of use on today's systems and supports modern X extensions such as composite, and we recommend using Xephyr under most circumstances. + + +#### X extensions under active development + +These simple extensions together enable very sophisticated visual effects to be created by window level image compositing, along with other needed facilities such as screen magnifiers, thumbnailers, and integration of applications into 3D immersive environments. + +These are under active development and will change before completion. + +* The X Fixes extension "fixes" some problems in the X core protocol, for application embedding, cursor tracking and naming, and introduces regions as a first class resource type for general use, for example, by the X Damage extension. +* The X Damage Extension allows applications to track modified regions of drawables, useful for compositing or applications such as VNC. +* The Composite extension causes a entire sub-tree of the window hierarchy to be rendered to an off-screen buffer. Applications can then take the contents of that buffer and do whatever they like. The off-screen buffer can be automatically merged into the parent window or merged by external applications. + +#### Obsolete X extensions + +A number of X extensions have been found to be useless or so difficult to use that they never achieved serious use over the last 15 years. These extensions, while possibly present in an X server implementation, should be considered obsolete and deprecated, and cannot be relied upon being present. Some of these include: + +* PEX - the Phigs extension to X. OpenGL won the 3D war; PEX is no longer even built in current X servers. +* XIE - the X Image Extension was an attempt to turn the X server into general purpose image processing. It failed due to excessive complexity and lack of a good implementation. A simple image transport extension may still make sense in the future. The goal of XIE was "image transport and display" with the requirement that it accept arbitrary JPEG images and perform all necessary manipulation (including unsharp masking, color space conversion, gamma correction, affine transformation) in the X server. That slope wasn't just slippery, it was a grease-covered cliff ending in a complete programmable image processing system within the X server. The implementation suffered from being done under contract by the lowest bidder, and being done after the standard was ratified with no feedback loop possible to fix the worst of the problems. Bad spec., Bad process, Bad engineering, Bad standardization process. What's not to hate? +* Multibuffer extension - an early extension providing multi-buffering. Included stereo, which the double buffer extension does not have. Some sort of separate stereo extension has been needed by several projects which have ended up using Multibuffer lacking a better mechanism. On the other hand, double buffer is now almost universally implemented by allocating off-screen pixmaps and using bitblt, so it may be all we need is a stereo extension. +* LBX, while often present in current implementations, is almost always a bad idea to use, and may vanish entirely soon. SSH typically works as well or better while providing the authentication and security that LBX lacks. See "X Window System Network Performance" for more information and discussion. +* XPrint, which has seldom been seen to work, tries to turn the X server into a printing device. This is conceptually a bad idea, as, for exampe, to get document portability, the outlines of gyphs of fonts must be embedded into documents so that they scale properly across the resolution of different printers. + +#### X libraries under active development + +Xlib has been the standard C binding for the X Window System protocol for many years now, and is in need of serious rewrite in some areas. It was written before shared libraries and threading were commonly available on UNIX, and several parts of Xlib should have been implemented as fully independent libraries.Work is essentially complete to engineer replacements for the old implementation and allow for better modularity and size. + +The new basic protocol library is called XCB that has potentially very good performance properties in that it is much easier to use to avoid round trips to the X server, and is carefully written from scratch. + + +#### X toolkits + +In the X architecture, user interface elements used by applications are provided by "toolkits". There have been many X toolkits over the years (and on other systems, such as Microsoft Windows, similarly there are multiple toolkit APIs). The most well known are GTK+, [[TrollTech|TrollTech]]'s Qt, and the older Motif library. GTK+ is used as the basis of the Gnome desktop project, Qt underlies the KDE desktop project, and Motif is used in the CDE desktop commonly found on UNIX systems. New open source development generally uses either Qt or GTK+ for toolkits. Additionally, the Mozilla project has a cross platform toolkit used by its applications, though on Linux and UNIX, this work is based on top of the GTK+ library. + +At this date, the major projects including Gnome and KDE have good facilities for internationalization (I18N) and localization (L10N) of applications, and many languages are already well supported. How comprehensive the localization is will depend upon the desktop and application, and the passion of the translators; complete coverage exists for many languages. Wider and wider localization is occuring, and is a way that motivated people from around the world can make a significant contribution, even for languages not spoken by many people. Even if you are a non-programmer but are a fluent speaker of a language not well covered, you can make a difference, and I encourage your involvement. Modern UNIX and Linux systems provide facilities for shared libraries that allow multiple versions of a toolkit to be installed simultaneously without introducing problems with applications. For example, applications based on GTK+1.x can coexist comfortably with GTK+-2.x based applications. Both GTK+ and Qt allow customizing much of their look and feel via "themes". There are of themes that provide a largely similar look and feel across both toolkits. Themes can be changed while applications are running. Also of note is Winelib, which is a major aid in porting programs written to the Win32 API to X. A notable closed source, free as in beer application using these libraries is Google Earth. + + +#### GTK+ toolkit + +What is typically called GTK+ in common usage is actually a set of three libraries. Glib is a low level library used by GTK+ and Gnome to provide a portability layer and other common functions. Pango provides for very sophisticated internationalized text layout, for a very wide range of languages including Arabic and Indic languages, generally difficult for most applications to do on their own. ATK is an accessibility toolkit. By supporting the ATK interfaces, an application or toolkit can be used with such tools as screen readers, magnifiers, and alternative input devices, and with the related applications and facilities, working toward full U.S. Section 508 accessibility conformance. + +GTK+-2.x is now widely deployed, has Xft and XRandR support, and is actively maintained and developed. GTK+ is written in C, and there are bindings for GTK+ for just about all commonly (and some uncommonly) used programming languages. For more detail and future plans, see the GTK+ web site. All applications in active use have been updated to GTK2 at this date, and it provides a stable, widely deployed base for new applications development. GTK+-2 is not expected to change in incompatible ways. It has language bindings for all common (and some uncommon) programming languages. While GTK+ development is primarily X based on UNIX and Linux on desktops and PDAs (e.g., there has been work to target it at other platforms, including frame buffers and Windows. GTK+ runs on Mac OS X via that platform's support for X, now standard in the lastest version of OS X. + +GTK+-1.x is obsolete, and no longer being developed, having inadequate I18N facilities. + +GTK+ is LGPL licensed. + + +#### Qt toolkit + +The Qt library, actively developed and maintained by Trolltech, has Xft and XRandR support, and is the toolkit used by the KDE desktop project. It is a modern toolkit primarily targeted towards C++ development, although bindings have been developed by the KDE project and others including support for Perl, Python, Ruby, [[JavaScript|JavaScript]], Java, C#, Objective-C, and C. + +A main feature of Qt is its strong cross-platform support (X11, Windows, Mac OS X, Linux frame buffer on PDAs). In addition to user interface APIs, Qt provides APIs for various platform-specific tasks such as file-handling, networking, process-handling, threading, database access, etc. Qt 3.2 also has strong support for internationalization including support for Arabic, Asian, Cyrillic, Greek, Hebrew, Indic, Latin and Persian languages as well as general Unicode support. Qt 3 supports accessibility features on Windows/Mac with the rudiments of support existing for X11. Full accessibility support under X11 will be available in Qt 4. Qt 3 is the current version used on the desktop, although QtE 2 is still widespread in Qtopia PDA applications. + +Qt is available under the GPL and under a variety of licenses under different terms for commercial and non-commercial use. + + +#### Other toolkits + +Other toolkits seeing significant development that may be interesting for particular purposes include FLTK, GNUstep, and wxWindows. Fltk is cross platform and quite small and fast, (hence its name), GNUstep is Objective C based and implements much of the original [[OpenStep|OpenStep]] specifications and may be useful in porting Apple [[MacIntosh|MacIntosh]] applications, and wxWindows is an open source, cross platform C++ GUI framework. On Linux, wxWindows is GTK+ based, and will be able integrate quite well into the current desktop (when its port to GTK+ 2 is complete). + + +#### Moribund X toolkits + + +##### Motif + +Motif (now called [[OpenMotif|OpenMotif]]) is the toolkit used in the CDE desktop found on most UNIX systems, though KDE and Gnome are often also available for those UNIX systems. A clone of it, called Lesstif, was developed while Motif remained fully proprietary. No new open source applications are now being developed by open source developers using Motif, though Motif may be used in corporations. As Motif currently lacks theming support, Motif applications often look out of place on current desktops, but will continue to work into the indefinite future, and is still seen used in some older commercial UNIX and Linux applications. + +I believe that Motif/Lesstif are obsolete, but it is still used extensively in commercial settings, even if relatively little new code is written to it. It is based on a library called Xt, which attempted to define a policy free toolkit framework. In retrospect, this was a mistake. Other toolkits widget sets were built on Xt, including Xaw (the Athena Widgets), Xaw3d, and the like. I don't know if it has been ported to Windows or not (possibly via cygwin), but would still be running under X. + +Lesstif is LGPL licensed. Motif has a unique license, with different terms for commercial and non-commercial use on open source or proprietary platforms. + + +##### TK + +The TK toolkit distributed as part of the cross platform TCL/TK system has some very substantial ongoing applications built with it, particularly some commercial CAD applications (e.g., Magic). It preserved some of the original ideas of Joel Bartlett's ezd's program canvas to have been adopted by other toolkits, including GTK+. I would not currently recommend it for new applications, as TK applications do not integrate very well into today's desktops (e.g., lack of theme support, and modern window manager hint support). Similar scripting language/toolkits that do integrate well are available, for example, in PyGTK (Python bindings to the GTK toolkit), to name one of several recent options. TK's most widely visible application has been the "make xconfig" program used for configuring Linux prior to Linux 2.6, and some git applications. There are some signs that the Tcl/TK community understands that it has fallen behind the times and some steps are underway to rectify the issues, but these plans are not yet far enough along for me to believe TK will extricate itself from the tar. If you value TK, then now would be the time to aid that effort. + + +### Other key libraries + + +#### Fontconfig - font configuration library + +Fontconfig will discover new fonts when installed automatically, removing a common source of configuration problems, perform font name substitution, so that appropriate alternative fonts can be selected if fonts are missing. Fontconfig will identify the set of fonts required to completely cover a set of languages. It will efficiently and quickly find the fonts you need among the set of fonts you have installed, even if you have installed thousands of fonts, while minimizing memory usage. Fontconfig can be used in concert with the X Render Extension and [[FreeType|FreeType]] to implement high quality, anti-aliased and subpixel rendered text on a display. It is believed to be "best in class" of equivalent facilities on other operating systems. Fontconfig does not render the fonts hemselves (this is left to [[FreeType|FreeType]] or other rendering mechanisms) or depend on the X Window System in any fashion, so that printer only applications do not have such dependencies. + +Fontconfig is stable, and available on all current Linux distributions. Note that the obsolete X core font mechanism does not (yet) use fontconfig for its configuration mechanism, which is a source of configuration confusion we hope to see remedied during 2004-2005. + +Fontconfig is MIT licensed. + + +#### Freetype 2 - font rendering + +[[FreeType2|FreeType2]] is a software font engine that is designed to be small, efficient, highly customizable and portable while capable of producing high-quality output (glyph images). It can be used in graphics libraries, display servers, font conversion tools, text image generation tools, and many other products as well. Note that [[FreeType|FreeType]] 2 is a font service and doesn't provide APIs to perform higher-level features, like text layout or graphics processing (e.g., colored text rendering, "hollowing", etc..). However, it greatly simplifies these tasks by providing a simple, easy to use and uniform interface to access the content of font files. Freetype's features list is very long: in short, Freetype supports most types of fonts used to date. Freetype 2 is stable, actively developed and maintained, and available on all current systems. + +Freetype 1 is obsolete and should no longer be used. + +[[FreeType|FreeType]] 2 is released under two open-source licenses: its own BSD-like [[FreeType|FreeType]] License and the GPL. + + +#### Cairo - vector graphics library + +Cairo is a cross platform vector graphics library with cross-device output support. Cairo is designed to produce identical output on all output media while taking advantage of display hardware acceleration when available (e.g., through the X Render Extension or the platform's native interfaces on Windows and Mac OSX). Cairo fills a missing piece of the unification of graphics between the window system and printing system. + +Cairo provides a statefull user-level API with capabilities similar to the PDF 1.4 imaging model. Cairo provides operations including stroking and filling Bezier cubic splines, transforming and compositing translucent images, and antialiased text rendering. It is believed to be second to none in its intended purpose. Currently supported output targets include the X Window System, in-memory image buffers and Postscript, PDF and SVG (structured vector graphics). Similarly as with Xft2, the X back end for Cairo is engineered to be able to draw on X servers that do not support the X Render extension, to enable applications to use its API everywhere. Bindings for many languages are already available, and Cairo is being used for applications. It underlies the GTK+ library, and is used by Firefox 3 on all platforms (Linux, Mac, Windows). Cairo is a free software library available under the MIT license. + + +#### Hardware Abstraction Layer (HAL) + +HAL is the infrastructure that deals with how to enable the good integration of devices into the desktop environment, so that when you plug in a new device, it "just works" in sensible ways for users. Linux 2.6 has extensive support for "hotplug" devices of all forms, not just PCMCIA and USB, and this provides the desktop integration to go with the base operating system support. + + +#### DBUS - message bus system + +D-BUS is a message bus system, a simple way for applications to talk to one another. There are bindings for multiple toolkits (e.g., Qt, GTK+). It is in common use and widespread deployment. + + +#### XML libraries + +XML is increasingly used in free software, not only for document and information markup but other related uses such as configuration files (e.g., fontconfig). Libxml2 is the XML C parser and toolkit; . It and a several other XML libraries (e.g., expat) are commonly used as the basis of XML related applications. LibXML2 is available under the MIT License, stable, very fast, and widely deployed in many applications. + + +#### Pkgconfig + +Not directly part of desktop software, but being increasingly used as part of the build environment of desktop software is the pkgconfig system. + + +#### Zeroconf + +The zeroconf work in the IETF is key to good user experience in network configuration. First to support zeroconf well is Apple Rendesvous on the [[MacIntosh|MacIntosh]]; UNIX and Linux support is well underway and beginning to ship in vendor's Linux distributions. + + +### Multimedia + +Multimedia is still in a great state of flux on open source systems. It is, however, to the point that serious applications exist and work well; the impetus is more around how to better integrate this to improve the user experience. As you will see, there is much available, and the community and users will decide which are of greatest importance, and it is probably the area of greatest ferment in desktop development. + + +#### Multimedia frameworks + + +##### Helix community + +[[RealNetworks|RealNetworks]] has made their Helix community multimedia framework that underlies their product suite and under multiple licenses, depending upon commercial or non-commercial use. Not all codecs are available open source. + + +##### aRts + +ARts is the multimedia framework used by the KDE project, is stable and is maintained by the KDE project, but has not seen much recent development. + + +##### Gstreamer + +The multimedia framework used by the Gnome project is Gstreamer. It is still working toward its first 1.0 release, but is in use in some applications. + +It is LGPL licensed. + + +##### Mplayer + +Mplayer is a movie player for LINUX and runs on many other UNIXs, and non-x86 CPUs and is being ported to Windows. It has support for a very wide variety of codecs and output devices. Multiple user interfaces have been built using Mplayer. + +It is now very stable and very capable and at its 1.0 stable release. + +Mplayer is available under the GPL. + + +##### VideoLAN + +The VideoLAN project targets multimedia streaming of MPEG-1, MPEG-2, MPEG-4 and DivX files, DVDs, digital satellite channels, digital terrestial television channels and live videos on a high-bandwidth IPv4 or IPv6 network in unicast or multicast under many OSes. VideoLAN also features a cross-plaform multimedia player, VLC, which can be used to read the stream from the network or display video read locally on the computer under all GNU/Linux flavours, all BSD flavours, Windows, Mac OS X, BeOS, Solaris, QNX, Familiar Linux... + +It is available under the GPL. + + +##### Xine and Xinelib + +Xinelib is the library underlying the Xine multimedia player. It has been so successful that many user interfaces have been built on top, and has support for a huge variety of audio and video codecs natively and provisions for use of binary commercial codecs from Windows on x86 platforms. It is very stable and very capable, and runs on Linux and most UNIX platforms and is being ported to other platforms as well. + +Xine is available under the GPL. + + +##### Totem + + +#### Audio + +Audio in open source systems is in a funny state. Amazing tools, applications, and codecs have been and continue to be developed, primarily on Linux systems, and you will find substantial parts of the computer music and audio research community using Linux. On the other hand, the tools and applications aren't all well plugged together for casual desktop use. So the good news is you'll probably find more software than you can make heads or tails of, and the bad news is you'll have to fuss with it to get it running, and may have problems when different applications need to be used simultaneously. This is not a good situation, and needs serious improvement. + +One issue for some audio applications has been latency, and particularly variance of latency. Low latency and good synchronization facilties are required by both professional audio work but even more for telephony and teleconferencing applications. Much work has gone on over the last several years to work on the Linux scheduler and get a good upper bound on latency in the system, in support of audio and other real time applications. Latency in Linux 2.4 is greatly improved over previous Linux releases, and is now quite good, and Linux 2.6 is outstanding. + +Linux has transitioned from the old OSS interface to the new, much improved ALSA driver infrastructure and implementation. + + +##### Advance Linux Sound Architecture (ALSA) + +The Advanced Linux Sound Architecture (ALSA), provides audio and MIDI functionality to the Linux operating system. It boasts: efficient support for all types of audio interfaces, from consumer soundcards to professional multichannel audio interfaces, fully modularized sound drivers, SMP and thread-safe design, user space library (alsa-lib) to simplify application programming and provide higher level functionality, support for the older OSS API, providing binary compatibility for most OSS programs. This has put the Linux audio driver interface on a very firm footing. + + +##### Audio servers + +But X is a network transparent window system, and, particularly in LTSP environments, applications need network transparent access to audio services. As yet, open source systems have not settled on a standard sound server, which with luck will happen over 2004; several earlier sound servers such as AF or NAS are no longer widely used. The AF audio server was notable in that it shows that it is possible to design network transparent audio servers with no inherent latency and with tight synchronization facilities. As AF lacked sample rate conversion (machines weren't fast enough in 1992), it is inadequate on that and other grounds for today's use. + + +##### aRtsd + +The aRts sound daemon used and maintained by the KDE project. It is also stable and not undergoing further development. + + +##### Enlightened Sound Daemon (ESD) + +ESD is widely available, maintained as part of the Gnome project, and is stable but is not undergoing further development. While adequate for routine use, it is very insufficient for advanced applications or those with demanding latency or synchronization requirements (e.g., video playback). + + +##### Jack + +JACK, the Jack Audio Connection Kit, provides low latency, high efficiency inter-process audio connectivity, as well as audio device sharing, suitable for pro-audio applications. While an audio server, it is not a network transparent server at this date, and therefore unsuitable for LTSP or other distributed X deployments. On single systems it has much to offer. + +It is under active development, not yet API stable (though may become so during 2004), and available under the GPL (server) and LGPL licenses (libraries). + + +##### Media Application Server (MAS) + +MAS, by Shiman and Associates, is a very ambitious audio server and multimedia framework. If it can be made to meet the needed latency (required by telephony and teleconference applications) and synchronization requirements (of video playback), it may be a viable contender to replace the current relatively poor audio servers. + +MAS is under active development and evaluation. + +The core of the MAS system recently became available under the MIT license. + + +#### Microsoft interoperability + + +##### SAMBA + +Samba enables UNIX and Linux systems to provide high performance file and print services to Microsoft Windows clients, and to gateway these services to open source desktops (via CUPS). + + +##### File systems + +Linux is able to read and write FAT file systems of all types, and read NTFS file systems. Read/write of NTFS file systems is in an experimental stage. + +Linux systems can mount Microsoft SMB file shares and read and write them. The desktop file browsers for Gnome and KDE have improving support for enabling browsing of a Microsoft file share network and browsing of file shares. + +Further polish of this work can be expected during 2004. + + +##### File formats + +The Microsoft file formats are a challenge, but open source programmers appear to be up to the challenge. The latest version of [[StarOffice/OpenOffice|StarOffice/OpenOffice]] can import and export Microsoft office file formats (along with many others) most of the time with great success. Generally, open source applications are moving toward XML based representations of documents, such as that used by [[OpenOffice|OpenOffice]]. + +For perfect interoperability, many releases of Microsoft Office are now running very successfully using the Wine technology. + +There will be continued incremental improvements; of course, since Microsoft is a moving target this will continue to challenge the community. + + +##### WINE + +Wine provides a Microsoft Windows execution environment on Linux and x86 based UNIX. Many key "shrink wrap" applications written for Microsoft Windows including Microsoft Office, Lotus Notes, Adobe Photoshop, Intuit Quicken can run on x86 based Linux systems using Wine. Commercial versions of Wine that provide support and easy installation and configuration are available from Codeweavers for commercial applications and Transgaming for games. The applications in general are well integrated into the open source desktop, though in this environment, certain Windows peculiarities (e.g., MSDOS drive letters and file name paths) show through. + +Your exact mileage will vary, but many of these applications (e.g., Microsoft Office) now run extremely well and stably. More and more applications will become usable with time. + +Wine is distributed under the LGPL license. + + +##### Winelib + +Winelib provides Microsoft Windows compatible APIs as an aid to porting applications, and is the underpinnings of the Wine execution environment. As such, it can be viewed as yet another toolkit. Applications for which source is available may be able to be recompiled and relinked against Winelib as a way of porting the application to become a native application on UNIX and Linux systems. + +While tracking the evolution of Microsoft APIs is a perpetual, thankless task, a higher and higher fraction of applications will find that Winelib covers their needs with time. The fact that many major Microsoft Windows applications run well under Wine shows that the coverage is actually quite good over the APIs actually used by Windows applications. + +As a porting tool of applications built to Win32 APIs, it can't be beat. + +Winelib is distributed under the LGPL license. + + +##### DOS emulation + +An easy, portable way to run old Microsoft DOS software is to use Dosbox It emulates enough of DOS to be able to run most of scripts and can automatically mount a directory as it were a DOS drive. The current 0.60 version can run (e.g., most of the older DOS games); just extract program to a directory and use 'dosbox <directory>'. + +The harder, x86 and Linux specific way is to use Dosemu and install a real MS-DOS on a disk image. Dosemu is faster than Dosbox. (The Dosemu page claims that MS-DOS is not needed, but in practice [[FreeDos|FreeDos]] is not compatible enough.) + + +##### .Net and Mono + +The Mono project is an effort to create an open source implementation of the .NET Development Framework, some of which involve desktop technologies. + +Mono includes: a compiler for the C# language, a runtime for the Common Language Infrastructure (also referred as the CLR) and a set of class libraries. The runtime can be embedded into your application. It implements of both ADO.NET and ASP.NET. It is adopting Cairo for its 2D graphics. + +Mono's licenses are GPL for tools and LGPL for Mono libraries. + +Mono's expected 1.0 release is Q2 2004, according to its road map. + + +#### Displaying Windows applications on Open Source systems + +There are both commercial and open source RDP cients for Linux available, that enable remote Windows applications usiing Windows Terminal Server to be displayed on open source desktops. + + +#### X implementations for Windows + +There are X Window System implementations for Windows. X applications can run on Windows and use X servers on any operating system (UNIX, Linux, Mac OS X, etc.) for their display, and if an X server is running on Windows, X applications on UNIX, LInux, MacOS X can be used on those Windows machines. Tools like Cygwin are make it very easy to develop cross platform tools that can be used on both Windows and UNIX/Linux/MacOSX. + +There are both commercial and non-commercial X implementations for Windows. + + +##### Cygwin and Cygwin/X + +Cygwin is a Linux-like environment for Windows, allowing for use of much Linux software on Windows. It consists of two parts: 1) A DLL (cygwin1.dll) which acts as a Linux emulation layer providing substantial Linux API functionality, 2) A collection of tools, which provide Linux look and feel. A large collection packages of software available. + +The Cygwin DLL works with all non-beta, non "release candidate", ix86 versions of Windows since Windows 95, with the exception of Windows CE. + +Cygwin is actively maintained and developed, and has been making regular releases,. Various packages are, of course under their own license terms. + + +##### Cygwin/X + +Cygwin/X is a port of the X Window System to the Microsoft Windows family of operating systems. Cygwin/X runs on all recent consumer and business versions of Windows; as of 2002-05-12 those versions are specifically Windows 95, Windows 98, Windows Me, Windows NT 4.0, Windows 2000, and Windows XP. + +Cygwin/X consists of an X Server, Xlib, and nearly all of the standard X clients, such as xterm, xhost, xdpyinfo, xclock, and xeyes. Cygwin/X, as the name implies, uses the Cygwin project which provides a UNIX-like API to Xlib and X clients, thereby minimizing the amount of porting required. + +Cygwin/X is licensed under an X style license; Cygwin is licensed under a modified GNU General Public License that specifically allows libcygwin1.a to be linked to programs that are licensed under an Open Source compliant license without such linking requiring that those Open Source programs be licensed under the GNU General Public License (see the Cygwin licensing page for more information). Source code and binaries for both projects are freely available. + +Cygwin/X is actively maintained, developed and enhanced and has been making regular releases. + + +##### Commercial X implementations + +There are a number of commercial X Window System implementations for Windows, for example, Hummingbird's Exceed. + + +#### Fonts + +Freetype 2, Fontconfig, and client side fonts have taken open source desktops from worst in class to best in class in basic font and internationalization at the core technology level, and at the toolkit level, GTK+'s Pango and recent work in Qt have finally brought X desktops from the 1980s to the modern world, with good Internationalization support, and first class linguistic layout and font rendering. + +Essentially any [[TrueType|TrueType]] or [[OpenType|OpenType]] fonts are usable. Additionally, the Postscript 35 Type1 fonts are now also available universally, courtesy a donation from URW four years ago. + +A further issue issue that most people are not familiar with is that of "metric compatibility". Unless fonts with very similar metrics are available, documents will not lay out identically across platforms. So without compatible fonts, typical documents in Microsoft format will not appear the same on open source platforms. This is a serious inhibitor to complete interoperability with Microsoft. + +The Microsoft Web fonts are available on the Internet, but their license does not permit bundling for commercial sale, which means that users have to find and install them. This has meant that when open source systems are first turned on, and until and unless the users understand how to locate and install them or other fonts, we have had a major "out of the box" problem. + +Bitstream's wonderful donation in April 2003 of the Vera font family for open source use has helped greatly in making open source systems presentable "out of the box". But the international coverage of these fonts is insufficient for the global nature of open source, and the fonts are not metric compatible with Microsoft fonts. + +So, while the open source community has spawned decent graphics artists and GUI designers, to date we have failed to establish a serious culture of font design and hinting of fonts, so fonts, particularly high quality hinted fonts for screen use, remain in short supply that can be "preinstalled" so that things "just work" in routine use. The projects building fonts seem to be are pretty fragmented and uncoordinated at the moment. Tools are available for font design and editing on Linux (and commercial tools are available on other platforms), but hinting of fonts for screen use is just slow, painful, repetitive work. Work by John Hobby a decade ago shows it may be possible to do good automatic hinting of fonts now that systems are so fast, but implementations of those algorithms are not currently available (another potential project for mathematically inclined open source programmers). Fonts require ongoing maintenance and enhancement, as language coverage and/or entirely new characters need to be added to fonts. In principle, this effort should be a lot of fun for the right person/people, involving as it does so many languages and cultures over the world. Further donations of fonts and/or funding for further font development would be greatly appreciated along with someone with the passion and ability to lead such efforts. + +Availability of high quality fonts, particularly for screen use, is therefore a significant issue. A second issue has been that Apple asserts two patents on how certain hints are implemented in [[TrueType|TrueType]]; these patents are only valid in the U.S. and Great Britian. + +As a result, commercial Linux or application distributions for desktop use now often bundle other high quality proprietary fonts with them as well, so this is less an inhibitor than one might first expect. But as this means that applications have not been able to rely on the availability of a metric compatible set of fonts, we may end up paying multiple times for the same fonts (from both application and base Linux system vendors). Better would be for the commercial open source vendor community to pool their efforts and "buy out" a set of such fonts. + + +#### Printing + +Printing has been a difficult problem on UNIX and Linux systems, but a number of changes during 2002 and 2003 are turning this from poor to quite usable. It is a very large topic, requires a document of this size to sketch, so this is just a 20,000 foot overview. Much additional information about printing on open source systems can be found on the Linux Printing web site. Open source printer drivers for almost all HP and Epson printers are available, with more spotty coverage for other vendors, and commercial support and more drivers available and tools from Easy Software Products, CUP's creator. + +UNIX/Linux printing in the past been badly hobbled by the lack of a good spooling system, which is now on its way to solution with the increasing deployment of CUPS and other developments. Berkeley lpr/lpd was really lame, System V lp similarly lame. Lprng was an improvement, but at this date, all Linux distributions, at least, are using CUPS as their default spooling system + +Desktop applications were badly hobbled by the original X Window System font design (for which I am partially to blame), which denied easy access to font files needed by applications which did anything sophisticated with text. Keith Packard's font related work has been outstanding, and the Fontconfig/Xft2/Freetype/Render combination takes us from poorest to best in class, both in quality of rendering and in internationalization on the screen, but some more work is needed in applications for printing to catch up. The widespread deployment of client side fonts using Fontconfig, Xft2, Freetype the X Render extension during 2003 marks a sea change in enabling good desktop display and printer integration. Additional work to complete integration of printer selection and management of small to moderate CUPS installations into the desktop environments is well underway. KDE's support has been complete for a while and Gnome projects and will be substantially complete in 2003, with [[StarOffice|StarOffice]] and Mozilla the remaining major application suites needing update. + +The expected uptake of Cairo in these projects during 2004 should significantly improve the generation of high quality 2D graphics for screen and printing, and allow for embedding of font information into print files that has been lacking (with the notable exception of [[StarOffice/OpenOffice|StarOffice/OpenOffice]], which has internal PDF generation already). + + +##### Postscript and PDF + +The fundamental "Lingua Franca" of printing on open source and UNIX systems has always been postscript, and there are open source and closed source PDF utilities. + + +##### Common Unix Printing System (CUPS) - print spooling system + +CUPS is now "standard" on all major currently shipping Linux distributions, Mac OS X, and available for all UNIX systems. It provides an IETF IPP (Internet Printing Protocol) print spooling system with provisions for fail-over, printing of many MIME types (though PDF and Postscript are by far the most common). Microsoft Windows XP has IPP support, but as it involves running IIS currently not typically used. CUPS makes all printers postscript capable that are not already Postscript capable, by using either Aladdin or the free versions of ghostscript, as a "Raster Image Processor". + +CUPS uses industry standard PPD files for printer descriptions, for all printers, not just Postscript printers, providing a uniform printer capabilities mechanism. CUPS provides for dynamic discovery of printers, and fail-over between printers. + +One of CUPS's other major strengths is that it has back ends for Microsoft SMB printers via SAMBA, Berkeley LPD protocols, [[JetDirect|JetDirect]] from HP, and so on, providing a fully uniform access method for applications to use for printing. Additionally SAMBA can be configured so that CUPS printers are available to Microsoft Windows desktop users. + +CUPS will continue to spread rapidly into the remaining environments. More work is needed in the management of CUPS environments, but the basic needs are now met in the latest versions of KDE and Gnome applications and those provided by Linux distributions. Commercial large enterprise management software is available from Easy Software. Integration of CUPS into desktop applications is well underway, and should be substantially complete by the end of 2003, and entirely complete by mid 2004. + +CUPS is GPL (the CUPS server itself) and LGPL licensed (the CUPS libraries). + + +#### Thin clients + +The X Window System, arguably, invented thin client computing. In their heyday, there were a significant number of hardware companies offering what were called "X Terminals" (e.g., NCD). Most/all of these are defunct, as they became less economic than commodity PC hardware, but the concept still has serious validity to reduce system management costs. Some thin client hardware for sale today can be used with X and X based applications as well, particularly since they make machines interchangable, have lower CPU and memory requirements, and can easily eliminate the disk and fans of conventional desktop machines at a somewhat lower price point. The combination can result in a much lower TCO, particularly using Linux, since Microsoft's pricing of its software licenses actively discriminates against this computing model. Also note the availability of RDP clients for open source systems as mentioned above, which allow Windows applications to display on X desktops via Windows Terminal Server. + + +##### Linux Terminal Server Project (LTSP) + +The Linux Terminal Server Project is building "thin client" versions of Linux. Most applications are run remotely on servers (via X's network transparency), but there are also provisions for locally run clients. This provides much better manageability of desktops and is very cost effective in many environments, making machines truly interchangable and obviating the need for "sneaker-net" system management. One view is that this is a reinvention of X terminals, but as there is provision for local clients it goes beyond that, and can take advantage of commodity PC hardware, thin client hardware, and old systems you thought were just junk. The K12LTSP makes a version specifically targeted toward use in schools. + +LTSP is in widespread use, has been through four major releases, and has an active developer and user community, and supports multiple Linux distributions. + + +##### Athena Computing Environment + +A similar style of not-quite-so thin computing is typified by the Athena computing environment at MIT (where both the X Window System and Kerberos have their roots). In this model, machines are also interchangable, but rely on distributed file systems and good authentication to keep any permanent data off the local machine. Local disks are used as caches for files and for swap, but never for long term data storage. As an integrated whole, this is not seen much outside of MIT, though X11 and Kerberos are reasonably widespread. As a interesting historical note, Athena's "Zephyr" system was arguably the first instant message system. + + +#### Java + +Java is available from Sun for Linux, and there are several static Java compilers (e.g., GCJ, part of the GCC compiler suite and Jikes from IBM), and may be preinstalled. The Blackdown project provides community source distributions of Sun's Java for additional platforms that Sun may not. Java release 1.4.2 introduces Swing support based on GTK2 look and feel, which aids in the natural integration of GUI applications built with Java on the open source desktop. As this deploys widely over 2004, Java applications using Sun's VM will share the look and feel of Gnome desktops. + + +#### VNC + +VNC stands for Virtual Network Computing. It is remote control software which allows you to view and interact with one computer (the "server") using a simple program (the "viewer") on another computer anywhere on the Internet. The two computers don't even have to be the same type, so for example you can use VNC to view an office Linux machine on your Windows PC at home. VNC is freely and publicly available and is in widespread active use by millions throughout industry, academia and privately. Note that VNC can be trivially replaced with a simple X application along with "ssh -X -C" in concert with the Damage extension. diff --git a/Development/Documentation/Obsolescence/roadmap-2-clean.pdf b/Development/Documentation/Obsolescence/roadmap-2-clean.pdf Binary files differnew file mode 100644 index 00000000..14b34db3 --- /dev/null +++ b/Development/Documentation/Obsolescence/roadmap-2-clean.pdf diff --git a/Development/Documentation/Performance.mdwn b/Development/Documentation/Performance.mdwn new file mode 100644 index 00000000..e4c2e23c --- /dev/null +++ b/Development/Documentation/Performance.mdwn @@ -0,0 +1,125 @@ + +[[!toc ]] + +X performance is extremely difficult to quantify, and there is a large amount of work to be done in this space. The following are some collected notes on what needs doing. + +Discussion and questions about work in these areas should be held on the [[xorg mailing list|http://lists.freedesktop.org/mailman/listinfo/xorg]]. + + +## Transport Performance + + +### In General + +X is a fairly compact protocol, with the exclusion of image transport which is done uncompressed. The dominating factor in many aspects of X performance is transport latency - how long it takes for a response to make a round trip. This is exacerbated by the design of Xlib, which is effectively synchronous for most of its operation. + +[[XCB|http://xcb.freedesktop.org/]] is an effort to rearchitect the network layer of X to hide latency by providing an asynchronous interface to the protocol. The effort is stabilising rapidly, and needs both wider testing and for toolkits to be ported to it. + + +### Over the Network + +While [[XCB|http://xcb.freedesktop.org/wiki/xcb]] addresses the latency requirements of X, there is no great solution to the bandwidth requirements. Several good (and not so good) solutions do exist. + +* The [[SSH|http://www.openssh.com]] suite allows for tunnelling X sessions over a secure channel, which can also be compressed. This is adequate for technical users, but it is suboptimal for terminal servers and novice users. +* The [[LBX|http://keithp.com/~keithp/talks/lbxpost/index.html]] protocol is generally inadequate for modern X usage. See the linked paper for details. LBX is no longer built by default in 7.1. +* [[Xpra|http://xpra.org/]] acts as compositing window manager to forward individual windows from a virtual server to the client that connects to it (over sockets, tcp or ssh). +* [[NX|http://www.nomachine.com/]] is a software compression suite based on the earlier [[DXPC|http://www.vigor.nu/dxpc/]] protocol. It also leverages ssh to provide security services. There are open issues regarding integrating it into the base suite - licensing being among them, as much of NX is LGPL, version 4 is now closed-source. + +### On the Local Machine + +Several commercial X servers use shared memory transports on the local machine to improve performance. Rik Faith [[researched shared memory transports|http://dri.freedesktop.org/wiki/SharedMemoryTransport]] for the DRI project several years ago. The conclusion then was that it would improve performance for those operations where the time to render the request was dominated by the transport latency, and then by less than 10%. + +This may not be true anymore. The balance of the typical machine's memory architecture has shifted, and many operating systems provide advanced high performance synchronization primitives (like futexes on Linux) that may address some of the sync overhead he experienced. This would be an excellent research project. + + +## Driver Performance + + +### 2D Rendering + + +#### The Important Bits + +Most of the core X protocol's rendering routines simply do not get used very often. This is not so much because they are slow, but because they aren't useful on the modern desktop. Empirically, better than 90% of the drawing operations that X sees today are solid fills, blits, and Render operations. Attempting to accelerate 2D operation outside this set is very likely a waste of effort. + + +#### XAA + +XAA is largely inadequate for accelerating modern desktop usage. + +* XAA goes to great lengths to accelerate operations like patterned fills and Bresenham lines, which are rarely used. +* XAA's support for accelerating the Render extension is poor, because the design of XAA's memory manager only allows for offscreen pixmaps that are exactly the format of the displayed screen. +* Render acceleration in XAA only works when the source image is in host memory and the destination is in card memory; to be truly performant it needs to be able to handle the case where both source and destination are in card memory. This is the reason xcompmgr is slow; it uses Render heavily, and XAA simply can not make Render go fast. + +#### EXA/UXA + +XAA is really not worth fixing. The better approach is to start from the lessons learned from [[KAA|http://www.anholt.net/papers/kdrive-2004/]], the kdrive acceleration architecture, and port drivers over to that (leaving XAA in place for old or unmaintained drivers). + +As of about Xorg 6.8.99.14, there is a new acceleration architecture called EXA that achieves this. EXA is derived from the KAA code, but has been ported to the loadable server design and includes some additional features for improved performance. UXA is a variation on the EXA theme that assumes a unified memory architecture and kernel memory management support. + +The [[ExaStatus|ExaStatus]] page contains the current driver support status. + +EXA continues to be tuned for performance. In particular, the pixmap scoring and migration algorithm is still fairly naive. The lessons learned from tuning EXA will apply to Xgl servers as well in the future. + + +#### Framebuffer Layout + +Most modern graphics cards can be run in either linear or tiled framebuffer modes. Linear modes are simple, you start in the top-left corner and move to the bottom-right, all the way across a single row before changing rows. In tiled modes the framebuffer is broken up into a series of small tiles, usually 8x8 or so, and memory is laid out such that the first 64 pixels belong to the first tile, then the next 64 to the second tile, etc. You can think of linear framebuffer being a tiled framebuffer where each tile is 1x1. + +Tiled framebuffers have a performance benefit because they better model the layout of objects on the screen. They give better locality of reference because each tile is packed tightly in memory, where in a linear framebuffer you might have to skip a thousand pixels ahead to get to the same horizontal offset one line down. Since your spatial locality is better with a tiled framebuffer, your working set fits in your cache better. + +Despite this, X's framebuffer cores use linear modes, even if the framebuffer appears to be tiled from the GPU's perspective. There may be a performance benefit to making the system framebuffer shadow match the GPU's tile layout. The wfb software renderer is designed to allow this, but no (open) driver is seriously using it at the moment. + + +#### Framebuffer Access + +In general, framebuffer reads absolutely kill performance. Any XAA replacement should do as much work as possible in the write direction only. For the cases where framebuffer reads are unavoidable, the new acceleration architecture should make it possible to use DMA to transfer data out of the framebuffer. EXA has hooks for DMA support. + +Even when DMA is unavailable, it is usually more performant to tranfer large blocks of data in and out of framebuffer memory rather than operating on single pixels at a time. + +Thrashing can occur when mixing operations that the hardware can accelerate with ops it can't. It remains an open question as to how to best deal with this. EXA/UXA take the attitude that the card can accelerate pretty much anything you throw at it, which seems pretty reasonable. + + +#### Algorithmic Issues + +EXA's Render acceleration is adequate, but lacks support for a few things. Source-only pictures (solids and gradients) are currently not accelerated in hardware. Source IN Mask OP Dest combination could be implemented in multiple passes for cards that only have one texture image unit. External alpha is basically unaccelerated. + +Trapezoid rasterisation in Render is not hardware accelerated. It's not even clear that it can be. The software implementation has been reasonably well tuned, but could certainly be better. + + +### 3D Rendering + + +#### DRI Drivers + +TODO: Fill me in. + + +#### Mesa Core + +The observation about tiling for 2D also applies to Mesa's software rasteriser. + + +## Interactive Performance + +Because the X server is single-threaded, any operation in the server that takes a significant amount of time to complete will make the server feel laggy. This is common for the Mesa software renderer and the software Render code, but any part of the server could trigger this in theory. While we should work to maintain fast execution of all code paths, there may be significant benefit to reworking the server to be multithreaded. + +One of the worst performance issues X has is making opaque resizes fast. Since the window manager is in a separate process from the application, there are two round trip cycles involved, which makes the latency issues described above worse. There are several possibilities for working around this. One is to move responsibility for window decorations into the client. Another would be to load some portion of the window manager in-process with the X server. + + +## Perceptual Performance + +Most X drivers do not synchronize their drawing to the vertical retrace signal from the monitor. (To be fair, very few windowing systems do this consistently, even MacOS X.) This leads to a tearing appearance on some drawing operations, which looks slow. If the vertical retrace signal could be exposed through the SYNC extension, applications could defer their rendering slightly and reduce or eliminate tearing. This requires extending each driver to support this, as well as adding a little support code to the server itself. + +The un-Composited model of X operation requires many round trip operations to redraw areas when they are exposed (window move, etc.). It is important that X be able to make Composited operation fast in the future. + + +## Platform and Operating System Support + +On x86 hardware, MTRRs are used to specify the memory access policy for ranges of memory. Setting the framebuffer to write-combining has a significant performance benefit. However, on PCIE systems, there are more memory ranges than MTRRs. PAT stands for Page Attribute Table, which allows you to specify the access policy for individual pages at a time. + +Other platforms may have similar memory access mechanisms. + +As mentioned above, OS-specific synchronization primitives could have significant performance benefit for shared memory transports. These include futexes on Linux and possibly doors on Solaris. + +High performance graphics increasingly requires some kernel support for synchronization and security reasons. The DRM provides this support for Linux and BSD systems, but it could reasonably be ported to other suitable platforms like Darwin and Solaris. diff --git a/Development/Documentation/PointerAcceleration.mdwn b/Development/Documentation/PointerAcceleration.mdwn new file mode 100644 index 00000000..7e5df56b --- /dev/null +++ b/Development/Documentation/PointerAcceleration.mdwn @@ -0,0 +1,488 @@ + +**Index** [[!toc 3]] + + +## Introduction + +The predictable pointer acceleration code is an effort to remove the deficiencies of the previous acceleration code. It is intended as a drop-in replacement. Most users probably won't note it, which is ensured by reusing existing controls and aligning closely to them. + +It provides nice features like downscaling (constant deceleration) independent of the device driver, adaptive deceleration, different acceleration profiles, and more. + +However, the main difference is _predictability_. See [[Postulate|Development/Documentation/PointerAcceleration]] for an explanation. + +The behaviour of the code can be configured on a per-device basis in xorg.conf, HAL fdi's or at runtime. A user may also choose to use the previous method or no pointer acceleration at all. + +It also features an optional interface to device drivers to coordinate on acceleration, should one provide its own. + +See [[here|Development/Documentation/PointerAccelerationAsOf16]] for notes regarding Server 1.6 + +<a name="Postulate"></a> +### Postulate + +When the pointer gets accelerated with respect to device motion, it becomes important for the user to be able to predict the acceleration. Without this, the user is unable to intuitively use his device. + +Predictability depends on knowledge. The primary information the user's brain has to build its knowledge about the applied translation from hand (device) to eye (screen) is the velocity of motion. In order to not disturb this feedback loop, it is anticipated that the most critical part is doing a sophisticated estimate for the velocity of the device in the users hand. + +Based on a good estimate, acceleration profiles can be easily learned by the brain and thus be predicted. Because this is an intuitive process, easing it just 'feels better'. + + +### Intent + +Focus was given to the following aspects: + +* improving heavy-load behaviour (no overshooting pointer) +* enabling accuracy and fluid motion with a wide range of pointing devices +* providing a better 'feel' for pointing devices +* similarity in behaviour to the previous code +* don't introduce any lag in the process + +### Basic concepts + +The code serves 3 complementary functions: + +1. provide a sophisticated ballistic velocity estimate to improve the relation between velocity (of the device) and acceleration + +2. make arbitrary acceleration profiles possible + +3. decelerate by two means (constant and adaptive) if enabled + +Important concepts are: + +* **Scheme** + * which defines the basic algorithm. It can be summarized as 'means of translating relative device valuators in-place'. 'Predictable' refers to the new method (discussed here), 'lightweight' to the old one, and there's 'none'. +* **Profile** + * which returns an acceleration _factor_ (not to be confused with the acceleration _control_) for a given velocity estimate. Users are expected to choose the one they can work best with. +The point of profiles is in the following issue: There is a single 'profile' that is the easiest for all users to learn: _unaccelerated_. + +However this isn't too helpful; many people prefer an accelerated pointer. X has traditionally had acceleration activated by default, presumably for this reason. Since there is no single 'best' accelerated profile, this is a very individual option. + +Therefore, having a variety of profiles is essential. 5 of them are currently implemented (one can't really count 'classic' or 'device-dependent' since they are not profiles themselves). + +The 'classic' profile (default) is intended to perform old-style function selection (threshold =/!= 0) so most users won't note a difference. There is a special 'device dependent' profile (Nr. 1) reserved should drivers want to specify one. See [[here|Development/Documentation/PointerAcceleration]] for a short overview. + + +### Problems of the previous method + +The previous method ('lightweight scheme') did not have a velocity concept. It is based directly on the motion report's values ('mickey'), which at best correlates to velocity. Since the brain knows about velocity, not mickeys, this is disturbing. + +For polynomial acceleration: On slow movements, this code infers 3 'velocities': 1, 1.41, and 2. As 1 remains unaccelerated (or is even slowed down), we're left with just two acceleration levels. It is hard to foresee what exactly will happen. + +Worse when using the simple accelerated/unaccelerated function: Acceleration either comes to effect or it doesn't, providing no predictability around the threshold. The higher acceleration, the less predictability you get. + +If a system is under load, a device (or the driver/kernel) may accumulate its movement delta while the system does not query the device. This invalidates the assumed mickey-velocity relationship, causing irrational high cursor movement subsequently. This is particularly annoying when caused by focus changes during a mouse stroke (modern toolkits luckily don't exhibit this behaviour anymore). + +Some people own very responsive devices, creating a need to reduce speed on precise tasks or even in general. This often required driver-side or hardware support which was missing. + +With the simple acceleration scheme, acceleration is more sensitive on diagonal movements than on axis-aligned ones. + +These problems result in a reduced ability for our intuition to predict a matching hand movement for desired screen movement, thus causing more correctional moves than necessary. Put simply, the mouse 'feels bad'. + + +### Benefits of the new code + +Mostly, the polynomial acceleration becomes more usable. It can be used with higher acceleration coefficients (acc > 2), still providing enough control. But also the classic acceleration should become less jumpy since it now ascends softly towards accelerated motion. + +Users with too precise (or fast) devices can slow them without losing precision, independent of hardware driver support. Also, an acceleration function may decelerate on slow movements, giving (sub)pixel precision without sacrificing on pointer speed. + +The code is more robust towards different devices: One could imagine a mouse reporting very often, but only 1 dot per event. Old code would not accelerate such a device at all. While this is a theoretical case, there is robustness against jitter in device event frequency (as could be caused by system load, for example). In general, the number of problematic devices (wrt acceleration) is expected to shrink significantly. + +A driver which wants to roll its own acceleration now can do so without risk of distributing stale data along the event chain. See 'Driver side' below. + +Users disliking all this can switch it off. + + +### Basic useage + +Type e.g. + + +[[!format txt """ +xset m 18/10 0 +"""]] +to set a moderate polynomial acceleration (threshold = 0, acceleration = 1.8). The **xinput** tool has equivalent functionality to _xset m_: + + +[[!format txt """ +xinput set-ptr-feedback <device> 0 18 10 +"""]] +would be the equvalent to the xset example. This works without the patch too, but the previous acceleration scheme is not very nice. + +More features are available via device properties or config files. + + +## Configuration + +The defaults should suffice if you had no problems before, and feel quite similar. The settings discussed here are the coarse and the very subtle settings, not the usual xset or GUI panel controls you might know. + +Because this is a drop-in enhancement, the usual threshold and acceleration controls work as expected and are not planned to be replaced. However, different profiles might react different to them. + +The settings described below are all device-specific. You may set them in an appropriate HAL file (typically /etc/hal/fdi/policy/10-x11-input.fdi) using +[[!format txt """ +<match key="info.capabilities" contains="input.mouse"> + <merge key="input.x11_options.AdaptiveDeceleration" type="string">2</merge> +</match> +"""]] +or similar. Type 'string' is required, since the server won't accept others. + +If you still use a xorg.conf, add options in the approriate "[[InputDevice|InputDevice]]" section in xorg.conf. Usually it looks like: +[[!format txt """ +Section "InputDevice" + Identifier "Mouse0" + Driver "mouse" + [...] +EndSection +"""]] +For example to enable the adaptive deceleration feature, put in a line reading +[[!format txt """ + Option "AdaptiveDeceleration" "2" +"""]] +or similar. + +Some options are runtime-adjustable. The _xinput_ tool can change them: +[[!format txt """ +xinput set-prop "My Mouse" "Device Accel Profile" 2 +"""]] +activates profile 2 on a device named "My Mouse". xinput is quite self-explanatory; however device properties have different names than options, and not all options are available as device properties. This is available in the X.org server 1.7 and higher. + + +### Scenarios + +If _your mouse moves far too fast_, [[ConstantDeceleration|ConstantDeceleration]] is your friend. Set to 2 or higher to divide speed accordingly. This will not discard precision (at least only on nv-reset, see Velocity approximation or below). + +If your _high-performance device does not repond well to acceleration_, you might need to reduce [[velocity scaling|Development/Documentation/PointerAcceleration]] first. + +If you like the speed but need some _more control at pixel-level_, you should set [[AdaptiveDeceleration|AdaptiveDeceleration]] to 2 or more. This allows to decelerate slow movements down to the given factor. You might want to keep nv-resets away by setting [[VelocityReset|VelocityReset]] to e.g. 500 ms, and maybe tweak [[velocity scaling|Development/Documentation/PointerAcceleration]] to tune results. + +If you want _only adaptive deceleration_ and have the default profile (or simple, for that matter), the easiest way is '> xset m 1 1'. + +If you are picky about a _smooth kick-in of acceleration_, for example to ease doing art, I suggest using profile 2 or 3 (the latter being equivalent to xset m x/y 0), enabling adaptive deceleration and tweaking [[VelocityScale|Development/Documentation/PointerAcceleration]] (in that order). Maybe playing with velocity [[AbsDiff/RelDiff|AbsDiff/RelDiff]] also yields some improvement. + +If you want _no acceleration_, use the 'None' profile. You can set it live in xinput or via static configuration. + +If you're _not even willing the spend CPU cycles on this_, set the [[AccelerationScheme|AccelerationScheme]] to none. + + +### Options + + +#### AdaptiveDeceleration [integer] + +_device property: Device Accel Adaptive Deceleration_ + +Allows the acceleration profile to actually decelerate the pointer by the given factor. Adaptive deceleration is a good tool allowing precise pointing, while maintaining pointer speed in general. A good thing even if you don't need it badly. + +Note however that for some profiles and/or acceleration control settings, adaptive deceleration may not come to effect. For example, the polynomial profile with an acceleration control setting of 1.0 will neither accelerate nor decelerate. Thus, there is no deceleration that could be allowed for. + +Default is 1 (no deceleration), mainly not to impose changes on unaware users. + + +#### ConstantDeceleration [integer] + +_device property: Device Accel Constant Deceleration_ + +Constantly decelerates the mouse by given factor. + +Using [[ConstantDeceleration|ConstantDeceleration]] should be preferred over corresponding device driver options (if any) since these retain data which could worsen the prediction of device velocity. An exception is the case where device data contains some error, which you may not want to affect velocity estimation. + +Implemetation note: This factor is applied onto the device velocity estimate, so the actual acceleration relates more to unaccelerated on-screen motion than to device motion. + +<a name="AccelerationProfiles"></a> +#### AccelerationProfile [integer] + +_device property: Device Accel Profile_ + +Select the acceleration profile by number. Default is 0, except if the driver says otherwise (none currently does). + +In this section, _threshold_ and _acceleration_ specify the corresponding X controls (xset m acc_num/acc_den thres). + +0. **classic** (the default) similar to old behaviour, but more predictable. Selects between 'polynomial' and 'simple' based on threshold =/!= 0. + +-1 **none** + + * no velocity-dependent pointer acceleration or deceleration. If constant deceleration is also unused, motion processing is suppressed, saving some cycles. +1. **device-dependent** + + * available if the hardware driver installs it. May be coming for synaptics. +2. **polynomial** + + * Scales polynomial: velocity serves as the coefficient, acceleration being the exponent. Very useable, the recommended profile. +3. **smooth linear** + + * scales mostly linear, but with a smooth (non-linear) start. +4. **simple** + + * Transitions between accelerated/unaccelerated, but with a smooth transition range. This has the fundamental problem of accelerating on two niveaus, on which acceleration stays independent of velocity. Traditionally the default however. +5. **power** + + * accelerates by a power function. velocity is the exponent here. Adheres to threshold. Will easily get hard to control, so it is important you have properly tuned your velocity estimation. +6. **linear** + + * just linear to velocity and acceleration. Simple and clean. +7. **limited** + + * smoothly ascends to acceleration, maxing out at threshold, where it becomes flat (is limited). +<a name="VelocityScale"></a> +#### VelocityScale [real] or + + +#### ExpectedRate [real (Hz)] + +_device property: Device Accel Velocity Scaling_ + +In short, this controls sensitivity of acceleration. + +It is **not** a direct speed control like constant deceleration. It scales the velocity estimate, which may or may not have an effect. That depends solely on the profile. + +This setting is designed to be device-dependent, i.e. you set it once to match your device, then modify behaviour using the established X controls (e.g. xset m nom/den thr) or the profile. + +It is important to note there is no 'correct' factor, just one that bears the nice property of matching to X controls just like the old code did. The [[ExpectedRate|ExpectedRate]] option can be used to set velocity scale according to this criteria. Be aware that this is not a good criteria for high-rate (>500hz) devices. + +You may need this setting if you find it hard to use even moderate acceleration settings/profiles (indicates scale is too high) or you don't seem to get any acceleration (indicates scale is too low). + +Default is 10, which is suitable for devices reporting at approximately 100hz. The relation between the two ways to set scaling is: +[[!format txt """ +VelocityScale = 1000/ExpectedRate +"""]] +Currently, no attempt is made to guess the rate. Thus, high-rate (i.e. gaming) devices _may_ be problematic to accelerate without this tweak. See [[below|Development/Documentation/PointerAcceleration]] for some background info. + +Be aware that constant deceleration is also multiplied into the velocity estimate, so avoid to mess with both at once. + + +### Advanced options + +The following options affect how the velocity estimate is calculated and require some understanding of the algorithm. + + +#### VelocityTrackerCount [integer] + +The number of mickeys tracked. Most likely won't buy you anything to tweak it, but if, you'd best stay between 4 and 40. Default 16. + + +#### VelocityInitialRange [integer] + +The initial velocity is comprised of results up to this offset. 1, the default, means initial velocity will be calculated from the first two mickeys for the most time. 0 may buy you a tiny bit of response, but increases the likelihood of jumps in acceleration. For mice reporting very often (>250 hz), larger values may make sense. + + +#### VelocityAbsDiff [real] + +The absolute difference between an initial velocity and the resulting velocity allowed. Default 1. + + +#### VelocityRelDiff [real] + +The relative difference between an initial velocity and the resulting velocity allowed. Default 0.2. + + +[[!format txt """ +fabs(resulting_velocity - tracker_velocity) <= ((resulting_velocity + tracker_velocity) * relative_difference) +"""]] + +#### VelocityReset [integer] + +Specifies after how many milliseconds of inactivity non-visible state (i.e. subpixel position) is discarded. This affects three issues: + +1) Two mouse strokes do not have any effect on each other if they are + + * [[[VelocityReset|VelocityReset]]] miliseconds from each other. This would be neglible though. +2) Velocity estimate remains correct within this time if the pointer/X is + + * stuck for a short moment, not querying the moving device. +3) slow movements are guessed correctly if all device movement events are + + * inside this time from each other. An increment might be neccessary to fully take advantage of adaptive deceleration. +Default 300 ms. + + +#### Softening [boolean] + +Tweaks motion deltas from device before applying acceleration to smooth out rather constant moves. Tweaking is always below device precision to make sure it doesn't get in the way. Also, when [[ConstantDeceleration|ConstantDeceleration]] is used, Softening is not enabled by default because this provides better (i.e. real) subpixel information. + + +#### AccelerationProfileAveraging (boolean) + +By default, acceleration profiles are averaged between the previous event's velocity estimate and the current one. This is meant to improve predictability. However it has only small impact (practically zero for linear profiles), and can be viewed as inceasing response times, so you can save some cycles if you care. + + +#### AccelerationScheme [string] + +Select Scheme. All other options only apply to the predictable scheme (default). +predictable +: + * the scheme discussed here (default) + +lightweight +: + * previous scheme (i.e. exactly as in X server 1.5 and before). If you prefer saving some cycles over increased useablilty, choose this. + +none +: + * disable acceleration/deceleration + + + +## Technical details + + +### Acceleration profiles (for the inclined programmer) + +Acceleration profiles translate device velocity into an acceleration to be imposed on the pointer. X.Org previously offered two functions: A simple accelerated/unaccelerated switch and polynomial. They are selected somewhat strange through the threshold control: threshold = 0 means polynomial, simple otherwise. + +The simple acceleration function is now continuous, and the polynomial maintains f(1) = 1. They are designed to mimic previous behaviour, so they are wrapped in the classic profile which does the above selection. Just copying old functions would not provide much benefit: The patch would make the point when acceleration is performed be more predictable, but not cause the pointer to cease jumping around that point. In other words, _predictability depends on the profile a lot._ + +If you like to play with the functions, a few nice properties are: + +1. _f(1) ~ 1_ + + * a fixed point, to enable exchanging functions +2. _continuous_ + + * very nice-to-have since we would otherwise throw away our estimate (probably causing jumps) +3. _continuous over derivative(s) or Cn_ + + * nice to have for smoothness. +4. _f'(min_acceleration) = 0_ + + * Ensures a soft kick-in of acceleration +5. _f( < 1) < 1_ + + * enables adaptive deceleration +* although it is possible to hold all of the properies, included functions + * only hold (1), (2), (5), and some also (3). +* acceleration profiles are not meant to enforce constant or adaptive + * deceleration. This is done in a separate step. +* notwithstanding the former, functions might adapt to min_acceleration + * in order to uphold (4). +* In X an acceleration coefficient of 1 is unaccelerated, not 0. + * It can be specified a a rational but we convert it to float. +* usual control values should not make your fn go havoc. See [[PowerProfile|PowerProfile]]() + * for a measure one can take. +If you want to do freaky new functions, you best put them in an own profile. Add your function to [[SetAccelerationProfile|SetAccelerationProfile]](), along with init/uninit code, and you're done. + +Profiles are meant to be exchanged arbitrarily. There are some parts of the code assuming you use profiles solely for acceleration, and not to scale the device in general (or whatever else). Be nice and it will work. Probably. + +While tempting, runtime-defined profiles are currently not possible. This may come with input properties. + + +### Driver side API + +In general, a driver does not need to act in any way. The acceleration is initialized during dix's [[InitValuatorClassDeviceStruct|InitValuatorClassDeviceStruct]], user settings on acceleration are loaded when a driver calls xf86InitValuatorDefaults. These are already called by about every driver. In general, driver-specific interaction should be before xf86IVD, so user settings take precedence. + +But of course it depends on what you want. This small API essentially lets the driver have its say on acceleration and scaling related issues. Proper use could improve the user experience, e.g. by avoiding to double-accelerated synaptics pads. + +The relevant header is _ptrveloc.h_. Most interaction requires a [[DeviceVelocityPtr|DeviceVelocityPtr]]. Use +[[!format txt """ + GetDevicePredictableAccelData(DeviceIntPtr) +"""]] +to obtain it (may return null). After xf86IVD, this may be used as an indicator on whether the predictable scheme is in effect. + + +#### Reporting rate + +If a driver knows the anticipated reporting rate of the device in advance, it might choose to override the default [[VelocityScaling|VelocityScaling]] to improve velocity estimates: +[[!format txt """ + your_velocityPtr->corr_mul = 1000/rate; +"""]] +This is especially worth the effort when the rate differs significantly from the default 100hz. + + +#### Scaling issues + +Also, if your device has very high precision, you can postpone downscaling: +[[!format txt """ + your_velocityPtr->const_acceleration *= 0.5f; +"""]] +This makes the full device precision available to guess velocity, and has potentially more benefits (like not distributing stale remainders all along the event loop). Plus, you don't have to do downscaling yourself :) + +Caveat: Since there is no error correction on dix side, a driver whose device has some error in the signal (like synaptics, on my laptop at least) should downscale just enough for the error to become insignificant. Any surplus scaling might still be done in dix then. + + +#### Device-specific profile + +A hardware driver may use its knowledge about the device to create a special acceleration profile. This can be installed using +[[!format txt """ + SetDeviceSpecificAccelerationProfile() +"""]] +In order to make it the default for the device, simply call +[[!format txt """ + SetAccelerationProfile(velocityPtr, AccelProfileDeviceSpecific); +"""]] +The user may always select it using profile 1. + + +#### Leave me alone + +If you ultimately want no server-side acceleration to be performed, call +[[!format txt """ +InitPointerAccelerationScheme(dev, PtrAccelNoOp). +"""]] +This disables constant deceleration too. + + +### Velocity approximation + +Device velocity, the only dynamic profile input, determines the amount of pointer acceleration. Getting that right thus is crucial to actually improve the state of affairs. + +The velocity discussed here is: +[[!format txt """ +(device_units / milliseconds) * velocity_scale / constant_deceleration +"""]] +By pre-multiplying constant deceleration, the velocity is expected to be comparable across devices. This intends to ease fine-tuning profiles to your likes. + + +#### How it works + +The algorithm keeps a record of (by default) 16 trackers. Each 'knows' a relative device position and when it was in effect. It's a short motion history. So when the user moves the mouse, the accumulated motion of up to 16 mickeys may be used in a distance by time velocity calculation. + +Of course, there are many reasons to not use such a large amount. Using a common 100hz device, this would add ~ 1/8th seconds of delay. For this and other reasons, a few common-sense heuristics are applied. Most importantly, a tracker must be on a roughly linear motion segment towards the current position. Also, trackers mustn't be too old ([[VelocityReset|VelocityReset]]) or result in a velocity too much off the initial velocity (which, by default, is made up from the two latest mickeys). + + +### Other things to ensure predictability + + +#### Continuous profiles + +Acceleration functions, called profiles, are made continuous. That avoids sudden jumps in the amount of acceleration, thus enhancing intuitivity. + +Continuous profiles are complemented by averaging profiles over the interval between the previous and current event's velocity estimate. This exploits the assumption that the real velocity also happened to fall in this range (and went somewhat linear). Not guaranteed, but a very likely case. + + +#### Mickeys are slightly flattened + +This aims to improve evolving-speed movements such as 'painting' with a mouse typically requires. To not get in the way, it happens just below device precision, only if acceleration is actually performed (that is, the profile returned an acceleration greater 1), and not on insignificant mickeys. It can be turned off (Softening option). + +It works simply by comparing previous and current mickey per-axis, and shifting current by 1/2 towards the previous - given they are different and the above conditions are met. + +Example (for one axis only): +[[!format txt """ +1 2 3 2 3 1 +"""]] +would become +[[!format txt """ +1 1.5 2.5 2.5 2.5 1 +"""]] +That's arguably smoother. + + +### Rationale for velocity scaling + +<a name="VelocityScalingRationale"></a> Device motion deltas are being divided by delta milliseconds before being filtered, so they are about _n_ times smaller than the raw input of a device reporting every _n_ ms. Because the reporting rate is usually unknown in advance, this is the only way to scale up to 'normal' values. + +Normalized values are required to sensibly compare against the _threshold_ control, which is an integer. This fact is the main reason for [[VelocityScale|VelocityScale]] to exist - the acceleration control is a rational, so it would in priciple bear enough precision by itself. + +There is, however, one rather soft figure: A velocity estimate of 1.0 should correspond to a rather slow move, which you want to be neither accelerated nor decelerated. _When untranslated_, this corresponds to a move of 100 pixels per second. So for some devices, you may want to set velocity scaling or constant deceleration to keep the estimate in check. + + +## Final notes + + +### Interaction with synaptics / about any smart driver + +I noticed two important things to consider when using the synaptics driver (or any other driver doing substantially more than decoding mickeys): + +It seems synaptics driver implements its own acceleration, which can be switched off. Two ways of accelerating the pointer certainly don't do good. This can be accomplished by setting 2 options, '[[MaxSpeed|MaxSpeed]]' and '[[MinSpeed|MinSpeed]]' to the same. + +I chose [[MaxSpeed|MaxSpeed]] = [[MinSpeed|MinSpeed]] = 1, which seemingly made the native touchpad resolution available to X, which in turn was far too responsive. I had to apply a [[ConstantDeceleration|ConstantDeceleration]] of 8 to work with it. This also makes the full device precision available to guess velocity. + +A good compromise is thus to downscale only so much in the driver as to make the contained error insignificant, and leave the rest to dix. + +As said, you have the choice on who scales down, and the driver could well be the better choice because it knows its stuff. But if it isn't better, choosing X to scale down will result in better velocity approximation, which may be advantageous. diff --git a/Development/Documentation/PointerAccelerationAsOf16.mdwn b/Development/Documentation/PointerAccelerationAsOf16.mdwn new file mode 100644 index 00000000..12a7d94e --- /dev/null +++ b/Development/Documentation/PointerAccelerationAsOf16.mdwn @@ -0,0 +1,247 @@ + + +## Introduction + +This documents the differences of the pointer acceleration in the X Server 1.6 vs. current (git master), and also serves to keep some info about this specific implementation, since some things changed substantially. The following holds for server 1.6: + +1. There are no device properties for pointer acceleration + +2. velocity approximation is done using a superseded algorithm + +This mainly means the only way to fine-tune pointer acceleration is via xorg.conf or hal. However, classic X controls do apply: + + +[[!format txt """ +xset m 18/10 0 +"""]] +or equivalent + + +[[!format txt """ +xinput set-ptr-feedback <device> 0 18 10 +"""]] +The same goes for velocity scaling, profile, and the other basic options described in the main document. + + +## Fine-tuning velocity approximation + +The following options affect how the velocity estimate is calculated and require some understanding of the algorithm. + + +#### FilterHalflife [real] + +The halflife of the weighting applied in order to approximate velocity. Higher values exhibit more integrating behaviour, introducing some lag but also may feel smoother. Less is more responsive, but less smooth. Higher values may need to be accompanied by a looser coupling, or it won't come to effect. Default: 20 ms. + + +#### FilterChainProgression [real] + + +#### FilterChainLength [integer] + +You can use this for high-quality velocity estimates. In a few tests, this approach made the other OS's acceleration feel jerky :) + +If you want to try a filter chain, set [[FilterHalflife|FilterHalflife]] to some small value. For example, for a device reporting every 10 ms, 5 to 10. The first filter will use this halflife, which should be very responsive. The next [[ChainLenght|ChainLenght]] -1 filters will be progressively more integrating (thus less responsive). The progression should be high enough so the last filter can average some motion reports. Up to ~300 ms is sensible. You may want to tighten coupling in such a setup. + +Example filter chain halflifes for length 4, halflife 5, progression 2: + + * 5 10 20 40 +Of course, more filters are computationally more intensive. Up to 8 are allowed. + + +#### VelocityReset [integer] + +Specifies after how many milliseconds of inactivity non-visible state (i.e. subpixel position) is discarded. This affects three issues: + +1) Two mouse strokes do not have any effect on each other if they are + + * [[[VelocityReset|VelocityReset]]] miliseconds from each other. This would be neglible though. +2) Velocity estimate remains correct within this time if the pointer/X is + + * stuck for a short moment, not querying the moving device. +3) slow movements are guessed correctly if all device movement events are + + * inside this time from each other. An increment might be neccessary to fully take advantage of adaptive deceleration. +Default 300 ms. + + +#### VelocityCoupling [real] + +Specifies coupling, a feature ensuring responsivity by determining if the filter's velocity estimate is a valid match for the current velocity. The weighted estimate is deemed valid if it differs from current below this factor. Precisely: +[[!format txt """ +fabs(cur_velocity - fitered_velocity) <= ((cur_velocity + fitered_velocity) * coupling) +"""]] +Should it be deemed invalid, velocity will be overridden by the current velocity and filter data is discarded. + +Higher values mean it is more likely that filtered velocity is deemed valid. IOW: a lower value tightens coupling, a higher value loosens coupling. + +Default is 0.25, or 25%. + + +#### Softening [boolean] + +Tweaks motion deltas from device before applying acceleration to smooth out rather constant moves. Tweaking is always below device precision to make sure it doesn't get in the way. Also, when [[ConstantDeceleration|ConstantDeceleration]] is used, Softening is not enabled by default because this provides better (i.e. real) subpixel information. + + +#### AccelerationProfileAveraging (boolean) + +By default, acceleration profiles are averaged between the previous event's velocity estimate and the current one. This is meant to improve predictability. However it has only small impact (practically zero for linear profiles), and can be viewed as inceasing response times, so you can save some cycles if you care. + + +#### AccelerationScheme [string] + +Select Scheme. All other options only apply to the predictable scheme (default). +predictable +: + * the scheme discussed here (default) + +lightweight +: + * previous scheme (i.e. exactly as in X server 1.5 and before). If you prefer saving some cycles over increased useablilty, choose this. + +none +: + * disable acceleration/deceleration + + + +## Technical details + + +### Driver side API + +In general, a driver does not need to act in any way. The acceleration is initialized during dix's [[InitValuatorClassDeviceStruct|InitValuatorClassDeviceStruct]], user settings on acceleration are loaded when a driver calls xf86InitValuatorDefaults. These are already called by about every driver. In general, driver-specific interaction should be before xf86IVD, so user settings take precedence. + +But of course it depends on what you want. This small API essentially lets the driver have its say on acceleration and scaling related issues. Proper use could improve the user experience, e.g. by avoiding to double-accelerate synaptics pads. + +The relevant header is _ptrveloc.h_. Most interaction requires a [[DeviceVelocityPtr|DeviceVelocityPtr]]. Use +[[!format txt """ + GetDevicePredictableAccelData(DeviceIntPtr) +"""]] +to obtain it (may return null). After xf86IVD, this may be used as an indicator on whether the predictable scheme is in effect. + + +#### Reporting rate + +If a driver knows the anticipated reporting rate of the device in advance, it might choose to override the default [[VelocityScaling|VelocityScaling]] to improve velocity estimates: +[[!format txt """ + your_velocityPtr->corr_mul = 1000/rate; +"""]] +This is especially worth the effort when the rate differs significantly from the default 100hz. + + +#### Scaling issues + +Also, if your device has very high precision, you can postpone downscaling: +[[!format txt """ + your_velocityPtr->const_acceleration *= 0.5f; +"""]] +This makes the full device precision available to guess velocity, and has potentially more benefits (like not distributing stale remainders all along the event loop). Plus, you don't have to do downscaling yourself :) + +Caveat: Since there is no error correction on dix side, a driver whose device has some error in the signal (like synaptics, on my laptop at least) should downscale just enough for the error to become insignificant. Any surplus scaling might still be done in dix then. + + +#### Device-specific profile + +A hardware driver may use its knowledge about the device to create a special acceleration profile. This can be installed using +[[!format txt """ + SetDeviceSpecificAccelerationProfile() +"""]] +In order to make it the default for the device, simply call +[[!format txt """ + SetAccelerationProfile(velocityPtr, AccelProfileDeviceSpecific); +"""]] +The user may always select it using profile 1. + + +#### Leave me alone + +If you ultimately want no server-side acceleration to be performed, call +[[!format txt """ +InitPointerAccelerationScheme(dev, PtrAccelNoOp). +"""]] +This disables constant deceleration too. + + +### Velocity approximation + +Velocity determines the amount of acceleration. Getting that right is crucial to actually improve things. Moreover, the general algorithm has a lot of corner cases that work out poor. Of course there are fixes, so in the end, it's a bit complicated: + +Given available data, we calculate dots per millisecond. A correction is applied to account for slow diagonal moves which are reported as alternating horizontal/vertical mickeys. These would otherwise be guessed 41% too fast. + +Dots per millisecond is quite intractable in integers. X controls are integer in part, and changing that would break too much. Thus, we multiply by a configurable factor to arrive at values where the usual X controls can be applied. + +Also, constant deceleration is multiplied into the current velocity. This intends to make acceleration depend on (unaccelerated) on-screen velocity, so one doesn't need to accomodate for different constant decelerations later in the acceleration controls (basically for laptops). + +This velocity is then fed into a chain of filters. Well, by default, it is one filter, at max there are 8. This means the velocity is tracked by potentially several filters, each with different response. + +After that, the most integrating filter response in range with the current velocity is selected. This ensures good responsivity and a likely precise velocity estimate. + +However, even the one filter used by default is enough for most people/devices. The reason: Typically during begin and end of a mouse stroke, filtering is simply not appropriate. Therefore, a coupling is employed to override velocity if filter responses seem inappropriate. Basically, you can either rely on coupling to provide good responsivity or have a filter suited to every phase of a stroke and loosen coupling. + + +#### Additional trickery + +After some short inactivity time (300 ms by default), the background data is discarded (called non-visible state (reset) in the patch). This is to ensure no two distinct strokes affect each other. + +When this happens, the velocity estimate is usually too low. To fix this, the acceleration performed is always evaluted as unity (IOW, the profile is skipped). This intends to make sure the mickey isn't being scaled to near-zero, so it is actually reflected on the screen. This does not override constant deceleration. + +One event after a non-visible state reset, the current velocity is 'stuffed' into the filter chain. Stuffing means every filter stage is overridden. Since this is the first time within a stroke we have a reasonable velocity, this is expected to somewhat increase precision. + + +#### Filter design + +_This section might be inaccurate due the author's limited math vocabulary in english. I apologize should this cause inconveniences._ + +To aid in velocity approximation, the input report's velocity is filtered. This section describes the filter design, how it is driven is described above. + +First off, we're not talking about a digital filter in the sense of signal theory. Signal theory doesn't apply here mainly because there is no constant amount of time between two reports. There is no such thing as a frequency response. + +The filtering is organized into one (by default) to a maximum of 8 _stages_. At higher levels they are expected to be in order least to most integrating. + +Each stage can _roughly_ be compared to an IIR filter of first order: +[[!format txt """ +current = v0 * a0 + v1 * a1 +"""]] +where v0 is the current velocity (this is, delta way by delta time), and v1 the previous current. + +However, we vary the coefficients by delta t using a power-law function. To do so, each stage consists of the current and an additional half-life. The half-life is used to derive the coefficients: +[[!format txt """ +a1 = 0.5 ^ (delta_t / half_life) +a0 = 1 - a1 +"""]] +The a1 function is in fact the integral of our true weighting function +[[!format txt """ +w = 0.693... * 0.5 ^ (delta_t / half_life) +"""]] +whose integral from zero to infinity is unity. Therefore, a0 is trivial to obtain. + +Obviously this is, in filter speech, BIBO-stable (at least for delta t > 0 and a sane halflife). IOW, filter output is stable as long as its input is, nothing lost. + +Another way of saying it: After half-life passed, the filter current will be determined 50% by current velocity and 50% by what was before. Since power functions exhibit scale invariance, this actually yields an equivalent result to weighting the individual values over their valid range (which is, from the corresponding mickey's time to the next) by the function _w_ above. + +In most cases, this boils down to + +* 1 lookup +* 1 sub +* 2 mul +* 1 add +per filter. + +The net effect is that the filter current will always draw towards the current velocity. It will do so more with + +* higher delta t +* lower halflife +When employing a chain of such filters, there is likely always one that has a good match to the device's actual current velocity. The matter becomes deciding which. + + +### Interaction with synaptics / about any smart driver + +I noticed two important things to consider when using the synaptics driver (or any other driver doing substantially more than decoding mickeys): + +It seems synaptics driver implements its own acceleration, which can be switched off. Two ways of accelerating the pointer certainly don't do good. This can be accomplished by setting 2 options, '[[MaxSpeed|MaxSpeed]]' and '[[MinSpeed|MinSpeed]]' to the same. + +I chose [[MaxSpeed|MaxSpeed]] = [[MinSpeed|MinSpeed]] = 1, which seemingly made the native touchpad resolution available to X, which in turn was far too responsive. I had to apply a [[ConstantDeceleration|ConstantDeceleration]] of 8 to work with it. This also makes the full device precision available to guess velocity. + +Also, I found increasing [[WeightingDecay|WeightingDecay]] on the touchpad to feel more comfortable. This is indicative of a small problem: the velocity estimation has no means of error correction, it basically requires the driver to deliver error-free data. A good compromise is thus to downscale only so much in the driver as to make the contained error insignificant, and leave the rest to dix. + +As said, you have the choice on who scales down, and the driver could well be the better choice because it knows its stuff. But if it isn't better, choosing X to scale down will result in better velocity approximation, which may be advantageous. diff --git a/Development/Documentation/Protocol/OpCodes.mdwn b/Development/Documentation/Protocol/OpCodes.mdwn new file mode 100644 index 00000000..0a0d9e82 --- /dev/null +++ b/Development/Documentation/Protocol/OpCodes.mdwn @@ -0,0 +1,19 @@ + +Every request sent from an X client to the X server in the X11 protocol is identified by an opcode. Opcodes 0-127 are reserved for the core X11 protocol. Opcodes 128-255 are used by extensions. + +For the core protocol request opcodes, you can find their definitions in any of these places: + +* the `X_*` defines at the end of [[/usr/include/X11/Xproto.h|http://cgit.freedesktop.org/xorg/proto/xproto/tree/Xproto.h]] +* the `XRequest.*` lines in [[/usr/share/X11/XErrorDB|http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/XErrorDB]] +* the `R* X11:*` lines in [[/usr/lib/xorg/protocol.txt|http://cgit.freedesktop.org/xorg/xserver/tree/dix/protocol.txt]] +* the X protocol specs at [[http://www.x.org/releases/current/doc/index.html|http://www.x.org/releases/current/doc/index.html]] +Opcodes 128-255 are dynamically assigned to X extensions, depending on which are supported and active in your current X server version/configuration. To see which are which in your currently running X server, run: +[[!format txt """ + xdpyinfo -queryExt | grep opcode +"""]] +Each extension is assigned a single opcode from that range, also known as it's “major opcode.” For each operation provided by that extension, typically a second byte is used as a “minor opcode.” Minor opcodes for each extension are defined by the extension. For definitions of those, see any of these: + +* the headers for that extension in [[/usr/include/X11/extensions/|http://cgit.freedesktop.org/xorg/proto/]] +* the `XRequest.<extension>.*` lines in [[/usr/share/X11/XErrorDB|http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/XErrorDB]] +* the `R* <extension>:*` lines in [[/usr/lib/xorg/protocol.txt|http://cgit.freedesktop.org/xorg/xserver/tree/dix/protocol.txt]] +* the X extension protocol specs at [[http://www.x.org/releases/current/doc/index.html|http://www.x.org/releases/current/doc/index.html]]
\ No newline at end of file diff --git a/Development/Documentation/ReleaseHOWTO.mdwn b/Development/Documentation/ReleaseHOWTO.mdwn new file mode 100644 index 00000000..b14e9a3d --- /dev/null +++ b/Development/Documentation/ReleaseHOWTO.mdwn @@ -0,0 +1,54 @@ + +This page is about how to make a module release, for maintainers. If you are wondering about where to download the latest release of X.Org, please see [[XorgReleases|XorgReleases]]. + + +## Packages needed for releases + +Make sure you have up-to-date **released** versions of these packages before making module or katamari releases. + +* util/macros +* util/modular +* doc/xorg-sgml-doctools +* lib/libxtrans (when building modules such as libX11 or xserver that rely on it) + +## Making module releases + +You **must** make a release if you have changed the ABI or API of your module and other modules rely on it. Likewise, the module to be released must not depend on unreleased code changes in any of its dependencies. Assuming the development and test (including _make distcheck_) have completed successfully and all commits have been pushed to the remote repository, the following steps will perform a _version bump_. + +* Pick a suitable version number, according to the [[X.org version number scheme|Development/Documentation/VersionNumberScheme]]. +* Apply that version number to configure.ac. +* For the xserver module, update RELEASE_DATE variable as well. +* Commit and push your _version bump_ to the remote repository. +Repeat the above steps for each module you wish to release. The module source from the repository is now ready to be released, meaning the _version bump_ commit is to be tagged, a set of tarballs is to be created and uploaded to the X.Org web site and an announce mail template is to be created which you can send to the xorg-announce mailing list. + +The script `util/modular/release.sh` will perform those steps for each module to be released. Invoke the `release.sh` script from any parent directory where the git modules to be released can be reached. +[[!format txt """ +util/modular$ ./release.sh --help + +Usage: release.sh [options] path... +Where "path" is a relative path to a git module, including '.'. +"""]] +* For a single module this would typically be `../../util/modular/release.sh .`. +* For multiple modules, this could be `util/modular/release.sh app/xfs app/xdm`. +* The tarballs are created by _make dist_ or _make distcheck_. +* The tag name is computed by the script as it is different for each module. +* The tarballs are uploaded to the X.Org web site in the appropriate section. +* The annotated tag is pushed to the remote repository. +* The announce e-mail template with check-sum is created. +Consult the help text for the available options. Consider running with `--dry-run` first. +## Making katamaris + +How to make badged semi-annual rollup releases, for release managers. This is basically what happened for 7.3, only that involved more flailing around. + +* on annarchy: + * create /srv/xorg.freedesktop.org/archive/X11R7.x/src + * $EDITOR ~/util/modular/module-list.txt to update the list of modules for this release + * cd /srv/xorg.freedesktop.org/archive/X11R7.x/src + * ~/util/modular/roll-it-up.sh < ~/util/modular/module-list.txt + * cp [[../X11R7|Development/Documentation/X11R7]].3/index.html [[../X11R7|Development/Documentation/X11R7]].3/logo.png . + * $EDITOR index.html + * mkdir doc + * $EDITOR doc/RELNOTES.txt +* update [[http://wiki.x.org/wiki/Releases/7.x|http://wiki.x.org/wiki/Releases/7.x]] +* update [[http://wiki.x.org/wiki/|http://wiki.x.org/wiki/]] to point to the new release +* send mail to the list
\ No newline at end of file diff --git a/Development/Documentation/Security.mdwn b/Development/Documentation/Security.mdwn new file mode 100644 index 00000000..b6fc99cd --- /dev/null +++ b/Development/Documentation/Security.mdwn @@ -0,0 +1,32 @@ + +This page describes access control and authentication mechanisms in X - and how you can implement your own. + +This page does not describe security advisories. For that, see the [[SecurityPage|SecurityPage]]. + +[[!toc ]] + + +## Server Authentication + +The core X protocol includes simple, host-based authentication. The familiar "xhost" client program is used to manipulate the list of allowable hosts. + +The server supports a variety of additional authentication methods as add-ons. Authentication data is delivered to the server in the initial data that is sent by the connecting client. A string identifies the authentication method being used. The authentication methods currently supported in the X.Org xserver are: + +* MIT-MAGIC-COOKIE-1: The most popular scheme, in which a certain string of bytes (the "cookie") must be presented. The server is started up with a file that contains the cookies, and Xlib reads cookies from a file, typically ~/.Xauthority. The "xauth" client program can be used to manipulate the cookies. Most desktop distributions make use of this method. +* XDM-AUTHORIZATION-1 +* SUN-DES-1 +* MIT-KERBEROS-5 +* XC-QUERY-SECURITY-1: A pseudo method used to find out whether the server supports certain extensions in trusted mode or "site policy" strings. This method is unused in all X implementations that this author is aware of (if you know otherwise, please make a note here - deprecation is being considered). +The authentication code is located in the os directory of the xserver, in auth.c and other files. An update being considered would move the authentication methods out of the xserver and implement them as PAM modules (libraries). + + +## Server Access Control + +The X server has long included an extension, SECURITY, which provides support for a simple trusted/untrusted connection model. Untrusted clients are restricted in certain ways to prevent them from reading window contents of other clients, stealing input events, etc. Documentation for this extension is located in the xorg-docs package. This extension has several limitations: + +* X server extensions are not well protected. They can only be turned off entirely. +* Creating untrusted clients is cumbersome since cookie authentications must be "generated" using a protocol request. However, recent version of ssh do make use of this functionality. +* Some portions of the extension, including the property configuration file and the query security authentication method described above, remain unused. +Starting with release 7.2 the X server includes a general framework for building security extensions, the X Access Control Extension. The best place to start if you are a security extension writer is with the XACE documentation, which can be found in the xorg-docs package. XACE inherits from the SECURITY extension and has the same coverage problems, but work is ongoing to verify its coverage and extend it to new places, such as protocol extensions. + +--- [[CategoryServerInternals|CategoryServerInternals]] diff --git a/Development/Documentation/ServerDebugging.mdwn b/Development/Documentation/ServerDebugging.mdwn new file mode 100644 index 00000000..d21853a5 --- /dev/null +++ b/Development/Documentation/ServerDebugging.mdwn @@ -0,0 +1,220 @@ + + +# Debugging the Xserver + +[[!toc ]] + +This minihowto attempts to explain how to debug the X server, particularly in the case where the server crashes. It assumes a basic familiarity with unix and a willingness to risk deadlocking the machine. + +Just as a warning, if you try this with a closed-source driver, the output is not likely to be very useful. + + +## Prerequisites + +You'll really want to have a second machine around. It's very difficult to debug the X server from within itself; when it stops and returns control to the debugger, you won't be able to send events to the xterm running your debugger. ssh is your friend here. If you don't have a second machine, see the [[Debugging with one machine section|Development/Documentation/ServerDebugging]], and good luck. + +Your gdb needs to be reasonably recent, 5.3 or better is probably good. + +And of course, you'll need a reproduceable way of crashing the X server, but if you've read this far you've probably got that already. This is your testcase. + + +### Debug support + +If you're debugging with a modern distribution, then they probably already have 'debuginfo' packages available. These packages (usually quite large) include the debugging symbols for the software you have installed, which makes tools like gdb much more useful. Refer to your distro's documentation for details on how to install these. You'll probably want at least the debuginfo for the X server itself, and for the video driver you're using. For example, on a Fedora machine, you'd say: + + +[[!format txt """ +debuginfo-install xorg-x11-server-Xorg xorg-x11-drv-ati +"""]] +On Debian or Ubuntu you'd say +[[!format txt """ +apt-get install xserver-xorg-core-dbg xserver-xorg-video-ati-dbg +"""]] +Otherwise, if you're building X yourself, you'll need to have built X with debugging information. To pass compiler flags in at build time, say: +[[!format txt """ + CFLAGS='-O0 -g3' ./configure --prefix=... +"""]] +All the normal configure options should work as expected. You may want to put your debuggable server in a different prefix. Be careful of `ModulePath` and other such path statements in your `xorg.conf`. + +Remember that if you're trying to debug into a driver, you'll want to repeat this step for the driver as well as for the server core. + + +## The basics + +Start the server normally. Go over to your second machine and ssh into the first one. `su root`, and type +[[!format txt """ +gdb /opt/xorg-debug/Xorg $(pidof Xorg) +"""]] +or +[[!format txt """ +gdb /usr/bin/Xorg $(pidof X) +"""]] +depending on your setup. + +Note that even when running with a ssh, X might cripples the console. You can avoid this by passing this option: +[[!format txt """ + -keeptty don't detach controlling tty (for debugging only) +"""]] +gdb will attach to the running server and spin for a while reading in symbols from all the drivers. Eventually you'll reach a `(gdb)` prompt. Notice that the X server has halted; type `cont` at the gdb prompt to continue executing. + +Go back to the machine running X, and run your testcase. This time, instead of the server crashing, it should freeze, and gdb should tell you the server got a signal (usually SIGSEGV), as well as the function and line of code where the problem happened. An example looks like: + + +[[!format txt """ + Program received signal SIGSEGV, Segmentation fault. + 0x403245a3 in fbBlt (srcLine=0xc1a1c180, srcStride=59742, srcX=0, + dstLine=0x4240cb6c, dstStride=1152, dstX=0, width=32960, height=764, + alu=-1046602744, pm=1111538028, bpp=32, reverse=0, upsidedown=0) + at fbblt.c:174 + 174 *dst++ = FbDoDestInvarientMergeRop(*src++); +"""]] +This by itself is pretty helpful, but there's more info out there. At the gdb prompt, type `bt f` for a full stack backtrace. (Warning, this will be long!) This dumps out the full call chain of functions from `main()` on down, as well as the arguments they were called with and the value of all local variables. Keep hitting enter until you get back to the gdb prompt. + +Get your mouse out, copy all the output from "Program received..." on down, and paste it into a file on your second machine. Type `detach` at the gdb prompt to detach gdb from the server and let it finish crashing. Go to [[http://bugs.freedesktop.org/|http://bugs.freedesktop.org/]] and file a new bug describing the testcase. Attach the gdb output to the bug (please don't just paste it into the comments section). + + +## All the gdb commands you'll ever need + +For any gdb command, you can say "help <command>" at the (gdb) prompt to get a (hopefully informative) explanation. + + * `bt` - Prints a stack backtrace. This shows all the functions that you are currently inside, from `main()` on down to the point of the crash, along with their arguments. Appending the word `full` (or just the letter `f`) also prints out the value of all the local variables within each function. + * `list` - Prints the source around the current frame. When invoked multiple times, it will print the next lines, making it useful for quick code inspection. "`list -`" prints the source code backwards (starting from the current frame). This is useful to inspect the lines of code that led to an error. + * `break` / `clear` - `break` sets a breakpoint. When execution reaches a breakpoint, the debugger will stop the program and return you to the gdb prompt. You can set breakpoints on functions, lines of code, or individual instructions; see the help text for details. `clear`, naturally, clears a breakpoint. + * `step` / `next` - `step` and `next` allow you to manually advance the program's execution. `next` runs the program until you reach a different source line; `step` does the same thing, but also descends into called functions. + * `continue` - continue the program normally until the next breakpoint is hit. + * `print` - Prints the expression. You can specify variable names, registers, and absolute addresses, as well as more complex expressions (`help print` for details). Variable names have to be resolveable, which means they either have to be local variables within the current stack frame or global variables. Register names start with a `$` sign, like `print $eax`. Addresses are specified as numbers, like `print 0xdeadbeef`. + * Expressions can be fairly complex. For example, if you have a pointer to a structure named `foo`, `print foo` will print the memory address that foo points to, `print *foo` will print the structure being pointed too, and `print foo->bar` will print the bar member of the foo structure. + * `handle` - Tells the debugger how to handle various signals. The defaults are mostly sensible, but there are two you may wish to change. SIGPIPE is generated when a client dies, which you may not always care about, and SIGUSR1 is generated on VT switch. By default, the debugger will halt the running process when it receives these signals; to change this, say `handle SIGPIPE nostop` and `handle SIGUSR1 nostop`. (Note: Don't use `handle SIGUSR1 ignore` or you can confuse things quite badly---for example, having multiple X servers simultaneously active on the same VT can be very confusing.) + * `set environment` - Sets environment variables. The syntax is `set environment name value`; don't use an = sign like in bash, it won't do what you expect. + * `run` - Runs the program. If you only specify a program name on the command line (and not a process ID or a core file), gdb will load the program but not start running it until you say so. Arguments to `run` are passed verbatim to the child process, eg `run :0 -verbose -ac`. + * `kill` - Kills the program being debugged. Not always useful, you'd often rather say... + * `detach` - which detaches the debugger from the running program, which can then shut down gracefully. + * `disassemble` - Prints the assembly instructions being executed, starting at the current source line. You can also specify absolute memory references or function names to start disassembly somewhere other than the default. Only useful if you can read the assembly language of your CPU. + * `finish` - Continue until exit of current function. Will also print the return value of the function (if applicable).\ +Note that most commands can be used in an abbreviated version (e.g. `n` instead of `next`). Just try it yourself! + + +## Things that can go wrong + +The biggest thing to watch out for is attempting to print memory contents when that memory is located on the video card. It won't work, on x86 anyway, for some not-very-interesting reasons. You'll know when you did it because the machine will deadlock and you'll have to reboot. See the Debugging``Hints file (below) for workarounds. + +Some issues with running X under gdb may be resolved by passing the `-dumbSched` option to the X server. This worked for me to resolve crashes of gdb 6.3 and strange loops in gdb 5.3. You'll know if you need this option because gdb will get very confused by SIGALRM. Even if gdb isn't misbehaving, the -dumbSched option can be very helpful to avoid the SIGALRM peridocially interrupting your debugging session. + +Likewise, some gdb versions crash when starting the X server when attempting to run xkbcomp. This is, amazingly enough, a bug in the kernel's DRM code for suppressing some signals; it should be fixed in 2.6.28 if not earlier. You can disable XKB by passing the `-kb` option on the server's command line; obviously if you're trying to debug XKB this may cause you some problems and you're probably better off attaching gdb to a running X instead. Alternatively, disable DRI, but again, if DRI is the thing you're trying to debug, that won't help. + +When you compile with optimization, the values printed by bt can sometimes be confusing. Some variables can get optimized out of existance, some variables occupy the same position on the stack during different parts of a function's execution, and some functions might not show up on the stack at all. Also, single-stepping can be confusing because the function might get executed in a different order than listed in the source if the compiler determines that's safe to do. gcc 4.0 seems to be **much** more aggressive at confusing the debugger than earlier versions, although it does emit more debugging information such that you'll at least know when variables have been optimized away. As always, lowering the optimization level improves debuggability. + + +## Further information + +There is a Debugging``Hints file available [[online|http://freedesktop.org/cgi-bin/viewcvs.cgi/*checkout*/xorg/xc/programs/Xserver/hw/xfree86/DebuggingHints]]. It contains a lot of helpful (if slightly dated) information on how to debug the server, including how to dump PCI memory without deadlocking the machine. In particular, you'll want to read this if you're trying to debug a server older than 6.9. + +<a name="OneMachine"></a> +## Debugging with one machine + + +### Version 1 + +The script below allows you to run the server in gdb and catch the gdb output in a file. You cannot interactively control gdb, however the Xserver should not hang gdb by stopping inside the debugger while you cannot control it from a terminal. Store the following script in some file (for example: `/tmp/Xdbg`: +[[!format txt """ +#!/bin/sh + +#GDB=... +#XSERVER=... + +ARGS=$* +PID=$$ + +test -z "$GDB" && GDB=gdb +test -z "$XSERVER" && XSERVER=/usr/bin/Xorg + +cat > /tmp/.dbgfile.$PID << HERE +file $XSERVER +set confirm off +set args $ARGS +handle SIGUSR1 nostop +handle SIGUSR2 nostop +handle SIGPIPE nostop +run +bt full +cont +quit +HERE + +$GDB --quiet --command=/tmp/.dbgfile.$PID &> /tmp/gdb_log.$PID + +rm -f /tmp/.dbgfile.$PID +echo "Log written to: /tmp/gdb_log.$PID" +"""]] +Then (as root) do: +[[!format txt """ +chmod u+x /tmp/Xdbg +mv /usr/X11R6/bin/X /usr/X11R6/bin/X.org +ln -sf /tmp/Xdbg /usr/X11R6/bin/X +"""]] +If you are using a module aware debugger you should remove the comment sign `#` form the line starting with `#GDB` and add the full path to your debugging gdb. You can now start your Xserver like normal. Note, that if you use `startx` you should do so as root. When the Xserver crashes the output of the server should have been written to `/tmp/gdb_log.<number>` together with a backtrace. If your Xserver resides at some other place you can use the `XSERVER` environment variable to specify the path. To restore the previous setup do: +[[!format txt """ +mv /usr/X11R6/bin/X.org /usr/X11R6/bin/X +"""]] + +### Version 2 + +If you only have one machine available, you might be able to pry some useful information from the server when it crashes. The downside is that it will probably halt your machine entirely rather than just crashing X. + +Edit your xorg.conf file and find the [[ServerFlags|ServerFlags]] section. Uncomment the +[[!format txt """ + Option "NoTrapSignals" +"""]] +line (or add it if it doesn't exist). This will prevent the server from catching fatal signals, which should cause core dumps instead. (You need to make sure you have core dumps enabled for the server by removing the appropriate ulimit; see the `ulimit` command in the bash man page for details.) + +The problem here is the same as mentioned earlier; the core dump will attempt to included mmap()'d sections of card memory, which will make the machine freeze. Usually the core dump is informative enough to at least give a partial backtrace. + +Once you've crashed the machine, find the core file and load it in gdb: +[[!format txt """ + gdb `which Xorg` /path/to/core/file +"""]] +and try to `bt f` like normal. Fortunately at this point you can't make the machine crash again. + +<a name="GdbServer"></a> +## Debugging with gdbserver + +Run X on the target using gdbserver, listening on (for example) port 2500: +[[!format txt """ + gdbserver :2500 /usr/bin/X +"""]] +Attach to the running process from gdb, running it from an environment in which you have Xorg installed. In my case, this is a chroot environment. If I try to debug the program from the host environment, without chrooting into my Xorg build environment, gdb cannot find the symbols correctly. + + +[[!format txt """ +root:/usr/src/xc-build# gdb +GNU gdb 6.3 +Copyright 2004 Free Software Foundation, Inc. +GDB is free software, covered by the GNU General Public License, and you are +welcome to change it and/or distribute copies of it under certain conditions. +Type "show copying" to see the conditions. +There is absolutely no warranty for GDB. Type "show warranty" for details. +This GDB was configured as "i686-pc-linux-gnu". +(gdb) file programs/Xserver/Xorg +Reading symbols from /usr/src/xc-build/programs/Xserver/Xorg...done.Using host libthread_db library "/lib/libthread_db.so.1". +(gdb) target remote 192.168.0.134:2401 +Remote debugging using 192.168.0.134:2401 +0xb7fed7b0 in ?? () +(gdb) c +Continuing. + +Program received signal SIGSEGV, Segmentation fault. +0xb7a92524 in GXDisplayVideo (pScrni=0x828bd38, id=0xb7aa9490, offset=0x17, + width=0x82a, height=0xe730, pitch=0xb7aa946c, x1=0x8289920, y1=0x0, + x2=0x0, y2=0x0, dstBox=0x82ae680, src_w=0x82a, src_h=0xe794, drw_w=0x828, + drw_h=0x8638) at amd_gx_video.c:849 +849 GFX(set_video_enable(1)); +(gdb) +"""]] +Note in this example that I specify the program to be debugged with a gdb command to read the Xorg symbols: +[[!format txt """ + (gdb) file programs/Xserver/Xorg +"""]] +This is simply an alternative to running gdb like this: +[[!format txt """ + gdb programs/Xserver/Xorg +"""]]
\ No newline at end of file diff --git a/Development/Documentation/ServerProfiling.mdwn b/Development/Documentation/ServerProfiling.mdwn new file mode 100644 index 00000000..88150518 --- /dev/null +++ b/Development/Documentation/ServerProfiling.mdwn @@ -0,0 +1,22 @@ + +If you're on a Linux system, sysprof is your best friend. First, make sure you've got the kernel development headers, and debugging information for the things you're trying to profile. On a Fedora system, that looks like: + + +[[!format txt """ +% sudo yum -y install kernel-devel +% sudo debuginfo-install -y xorg-x11-server-Xorg xorg-x11-drv-savage +"""]] +Then, build sysprof: + + +[[!format txt """ +% git clone git://git.gnome.org/sysprof +% cd sysprof +% ./autogen.sh +% make +% sudo make install +% sudo sysprof & +"""]] +Click "Start", do some stuff, click "Profile", and revel in the glorious CPU time accounting. + +Note that sysprof is itself an X application, so you may want to run it forwarded to another display so it doesn't end up profiling its own animation. diff --git a/Development/Documentation/SubmittingPatches.mdwn b/Development/Documentation/SubmittingPatches.mdwn new file mode 100644 index 00000000..c56c419e --- /dev/null +++ b/Development/Documentation/SubmittingPatches.mdwn @@ -0,0 +1,199 @@ + +X.Org uses patches to do code development. This page describes the required format of a patch as well as the workflow to create, send and apply it. We assume you have a git cloned repository and are familiar with making code changes and commits. + +Take a look at this [[example commit|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9fe9b6e4ef669b192ee349e3290db5d2aeea273c]] from which this [[patch|http://lists.freedesktop.org/archives/xorg/2009-February/043171.html]] has been created. Open them in separate browser windows and refer to them while you read the rest of the page. + + +# Workflow overview + +**Note:** This workflow illustrates the lifecycle of a patch and does not constitute a development process. If you intend to develop patches for the X Server, consult their [[development process|http://www.x.org/wiki/XServer]]. + +The patch submitter does the following: + +* Commit code changes to the local repository using the [[git-commit|http://www.kernel.org/pub/software/scm/git/docs/git-commit.html]] command +* Create a patch using the [[git-format-patch|http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html]] command +* E-mail the patch to the xorg-devel list using the [[git-send-email|http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html]] command +The xorg-devel list reviewers do one of the following: + +* Signify their approval or disapproval (Acked-by or Nacked-by) +* State an opinion about the appropriateness of the patch (Reviewed-by) +* Test the patch (Tested-by) +The module maintainer does the following: + +* Obtain the patch from the bug report or from the xorg-devel list +* Apply the patch to a local repository using the [[git-am|http://www.kernel.org/pub/software/scm/git/docs/git-am.html]] command +* Push the patch to the git remote repository using the [[git-push|http://www.kernel.org/pub/software/scm/git/docs/git-push.html]] command + +# Making code changes + +This is where it all starts. Think about the reviewers when you are organizing code changes. Focus on one issue and change one or more files to resolve the issue. In our [[example patch|http://lists.freedesktop.org/archives/xorg/2009-February/043171.html]], the code change only deals with fixing the wrong behavior of the mouse buttons reported by the user. + +Changes should follow the [[coding style guidelines|CodingStyle]]. + +Before creating a commit, ensure your git user name and e-mail is configured correctly using the [[git-config|http://www.kernel.org/pub/software/scm/git/docs/git-config.html]] command. Use your real name as opposed to a nickname as you will be signing off your patches, indicating that you are able to release the patch under the licensing terms of the module. +[[!format txt """ +$> git config --global --get user.name +$> git config --global --get user.email +"""]] + +# Creating a commit + +Once the code changes are implemented and tested on your local repository, they must be _committed_. A _commit object_ is created which wraps your code changes with various git information. It is included in the patch you will create later. Nothing is sent to the remote git repository on the freedesktop.org server. + +You tell git to add the files you changed using the [[git-add|http://www.kernel.org/pub/software/scm/git/docs/git-add.html]] command. You then commit the changes using the [[git-commit|http://www.kernel.org/pub/software/scm/git/docs/git-commit.html]] command. +[[!format txt """ +$> git add mipointer.c # file changed to fix the bug +$> git commit -s # -s adds the sign-off tag in the commit text +"""]] +The git commit command raises the nano editor for you to enter the _commit message_ that is describe in the next section. When you exit the editor, the _commit object_ is created. Monitor the changes to the local repository using the [[git-status|http://www.kernel.org/pub/software/scm/git/docs/git-status.html]] command and the [[git-show|http://www.kernel.org/pub/software/scm/git/docs/git-show.html]] command. + + +## Commit message format + +Begin the commit message with a single short (less than 78 character) line summarizing the changes, followed by a blank line and then a more thorough description. Tools that turn commits into email, for example, use the first line on the _Subject:_ line and the rest of the commit in the body. + +When referencing a reported bug, use the bug number from [[FreeDesktop Bugzilla|https://bugs.freedesktop.org/]]. If there is no corresponding bug, you should upstream the bug from your distribution to freedesktop.org. + +An example of how to reference a reported bug in the commit message: +[[!format txt """ +Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29049 +"""]] + +### Subject line + +The subject line summarizes the code changes contained in the patch. For large components such as the X Server, prefix with the subsystem (e.g. dix, Xi, xfree86, kdrive, etc.). Look at the xserver's git log to give you guidance. The subject line should also include the bug number if available. + +The subject line from the example, as it appears in the _commit object_: +[[!format txt """ +mi: don't call UpdateSpriteForScreen if we have Xinerama enabled. #18668 +"""]] +Do not type the word [PATCH] in the subject line, it gets added later when the patch is created. + + +### Message body + +Explain in sufficient detail what the patch does and why this is necessary. This does not mean you need to describe the actual source changes (e.g. "changed x to be 10, then added x to y"). Use common sense and look at git logs for guidance. See also [["on commit messages"|http://who-t.blogspot.com/2009/12/on-commit-messages.html]] + +The message body also contains your sign-off tag, so in our example: +[[!format txt """ +Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> +"""]] +Other tags may be added after the patch review as hinted in the workflow overview. + + +# Creating a patch + +Once the _commit object_ has been created with the proper subject line and message body, you can create a patch for it in order to either attach it to the bug report or e-mail it to the list. + + +[[!format txt """ +$> git format-patch HEAD~1 # create a patch for the last commit +"""]] +This will create a file named "0001-_description-of-my-change_.patch". Git uses the first line of the commit message (massaged for path-name safety) as the file name. + +The subject line of the example patch: + + +[[!format txt """ +[PATCH] mi: don't call UpdateSpriteForScreen if we have Xinerama enabled. #18668 +"""]] +The git format-patch command has prefixed the commit _subject line_ with the word [PATCH] on your behalf. If you haven't signed-off in the commit message body, you can do so with the --signoff option. + +If you are submitting a patch for applications, drivers or libraries to xorg-devel list, you should add the component name next to the PATCH word using the --subject-prefix option. + +Examples: +[[!format txt """ +[PATCH evdev] fix crash on VT switch #12345 +[PATCH libXi] convert to ANSI +"""]] +The reviewers need to know for which component this patch is for when reading the e-mail (there are over 200 of them). You can configure the git format-patch command to always do it for you: + + +[[!format txt """ +$> git config format.subjectprefix "PATCH evdev" +"""]] + +## Extra info + +If you are sending the patch to the list, you may include additional information (benchmark results, a method how to reproduce it) after the -- in the git formatted patch. When the patch is applied, this information is omitted. If you are submitting a patch for a specific server version (not git master), then please note your version here. If this bug affected previous released versions of the X server it helps to say so too. + + +## Plain text format + +Always attach patches as plain text files - if emailed then either attached or in-line. Never attach a zip file, tarball or any other archive with patches. Posting a link to a pastebin is permissible on IRC, don't post links on mailing lists, just attach the patch directly to the email. + +Apply common sense: make it as easy as possible for others to look at the patch. The more steps required to look at your patch and write a review, the more likely it will be ignored. + + +# E-Mailing a patch + +E-mail the patch you have just created to the xorg-devel list for review and approval. Let's use the [[git-send-email|http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html]] command for that. Of course, you can use other e-mail clients to attach your patch. If you decide to use a mailer, make sure your mailer isn't altering the spaces or lines of the patch, or the patch won't work. + +Configure the send-email client using the same git config command we have used so far. The example patch can be e-mailed using this command: +[[!format txt """ +$> git send-email --to xorg-devel@lists.x.org 0001-mi-don-t-call-UpdateSpriteForScreen-if-we-have-Xine.patch +"""]] +You can use the --dry-run option and/or send it to yourself to try it out first. + +Configuring send-email: +[[!format txt """ +git config --global sendemail.confirm always +git config --global sendemail.smtpserver <your mail server> +git config --global sendemail.supresscc self +git config --global sendemail.from "First Last <myself@example.com>" +"""]] +Patches sent to the mailing list are tracked by [[Patchwork|http://ozlabs.org/~jk/projects/patchwork/]] patch tracking system. The [[patchwork.freedesktop.org|http://patchwork.freedesktop.org/]] is now available for general use. + +If you are already subscribed to xorg-devel using the address the patch comes from, and it's smaller than the list's size limit, it should be delivered immediately - otherwise it goes into a moderation queue which is usually manually processed at least once a day. If you send many patches from an address that you don't want all xorg-devel mail to come to, you can subscribe to the list and then go to the list options page in mailman to turn off mail delivery. + + +# Signing off and reviewing + +X.Org developers may use a number of tags to acknowledge patches, both in a commit message and when reviewing patches. Here's a short summary for each tag, please refer to [[the Linux kernel's Documentation/SubmittingPatches|http://lxr.linux.no/linux/Documentation/SubmittingPatches]] file for details. The summaries below are copied from that file. + + * **Signed-off-by:** certifies that you wrote it or otherwise have the right to pass it on as a open-source patch. + * **Acked-by:** If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line. Acked-by: does not necessarily indicate acknowledgement of the entire patch. + * **Tested-by:** A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that some testing has been performed, provides a means to locate testers for future patches, and ensures credit for the testers. + * **Reviewed-by:** A Reviewed-by tag is a statement of opinion that the patch is an appropriate modification without any remaining serious technical issues. Any interested reviewer (who has done the work) can offer a Reviewed-by tag for a patch. +Whenever you review a patch on the mailing list or in a bugzilla, feel free to provide the appropriate tag as a reply email (or a comment on bugzilla). + + +## Getting no response + +We don't have an abundance of developers and sometimes bugs or patches get dropped. If this happens to your patch, ping the list/bug again after a sufficient period (a few days at the very least). CC the [[maintainer|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS]] of the matching subsystem. + + +## Changing a patch + +Likely, a developer will tell you to make some changes to the code or the commit message. Although you have committed your changes locally, you can still edit them. + +_git commit --amend_ lets you edit the last commit. By default, this only edits the commit message (e.g. _git commit --amend -s_ adds the signed-off-by if you've forgotten it). Any code changes you want to incorporate into the commit, use _git add filename_ before amending the commit. Then re-send/attach the new patch. + +If your patch is not the last commit in your local tree, consider using the [[git-rebase|http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html]] command in interactive mode. + + +# Applying a patch + +Although not the subject of this wiki page, it helps making better patches when you understand those on the other side of the fence. You may also want to test your own patch, round trip, by sending it to yourself. + +Download the patch from your favorite e-mail client as plain text file in the appropriate git local repository. Use the [[git-am|http://www.kernel.org/pub/software/scm/git/docs/git-am.html]] command to apply this patch. + + +# Using git + +Always use git to generate a patch. Why? All X.Org developers work with git and a git-formatted patch is easiest to apply and preserves ownership (which is in your interest). If you are working from a tarball or a distribution package, read [[generating git patches from tarballs|http://who-t.blogspot.com/2009/06/git-patches-from-tarballs.html]] to find out how to set up a temporary git repository. + +This summarizes the commands needed to create and e-mail a patch such as the example used: +[[!format txt """ +$> # Edit files to make code changes +$> git add file.c # Add changed files to be committed +$> git commit -s # Sign-off and commit changes, write commit message +$> git format-patch HEAD~1 # create a patch for the last commit +$> git send-email --to xorg-devel@lists.x.org 0001-*.patch +"""]] + +# Further reading + +* [[List of Xorg maintainers|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS]] +* [[Kernel patch submission process|http://kernelnewbies.org/UpstreamMerge/SubmittingPatches]]: details about patch format and contents equally apply to X.Org patches. +* [[Git User's Manual|http://www.kernel.org/pub/software/scm/git/docs/user-manual.html]]
\ No newline at end of file diff --git a/Development/Documentation/UsingCtags.mdwn b/Development/Documentation/UsingCtags.mdwn new file mode 100644 index 00000000..d9b0fdbb --- /dev/null +++ b/Development/Documentation/UsingCtags.mdwn @@ -0,0 +1,30 @@ + + +## Using ctags to find functions + +Finding functions in X is hard. One way to search for the actual definition of a data type is to grep the source directory and then open the file. This can take forever, especially when you don't quite know where to look for. + +However, vim's support for ctags makes it easier. It is possible to create a tags file for the whole system and then just use it from within vim. That way, in vim you only have to go to the occurence of the data type, press CTRL+] and it will open the matching definition. With CTRL+T you jump back to the original file. + +I created my tags file somewhere in my .vim directory. + + +[[!format txt """ +$> mkdir .vim/tags/ +$> cd .vim/tags/ +$> ctags -R /usr/include/* /path/to/X/source/code +"""]] +ctags will create a file "tags" in the current directory ($HOME/.vim/tags in this case). This way I got pretty much all defintions I need at the moment. + +Now you need to tell vim to include this file. Add the following line to your $HOME/.vimrc. +[[!format txt """ +set tags=./tags,tags,/home/username/.vim/tags/tags +"""]] +On your next startup of vim, everything will be available with CTRL+]. If you use tags heavily, you will find CTRL+G helpful. It shows the name of the file in the current buffer. + +A recommendation is to write a little script to update your ctags and run it as a cron job every night. Your computer will not be very responsive while recursively searching for ctags in a multi-GB directory. + + +#### Warning + +This can be a hazardous setup as the ctags are absolute. If you are working on two different source trees (i.e. two releases of the same software), using CTRL+ ] will jump to the functions as defined in ctags. So you might be editing the wrong source tree. diff --git a/Development/Documentation/UsingEclipse.mdwn b/Development/Documentation/UsingEclipse.mdwn new file mode 100644 index 00000000..e2d85d4f --- /dev/null +++ b/Development/Documentation/UsingEclipse.mdwn @@ -0,0 +1,142 @@ + + +# Using Eclipse CDT to develop Xorg + +[[!toc ]] + + +## Benefits + +* **Code Navigation** + * CDT 4.0 includes a fast code indexer and navigator which allows you browse call hierarchy, and quickly jump to the symbol declarations. +* **Debugging** + * acts as an interactive frontend to the GDB debugger + * allows remote debugging via gdbserver +* **It doesn't get in the way** + * it doesn't require any particular directory layout + * it doesn't require any particular build system, i.e., it plays nicely with autotools, hand-written Makefiles, or any build system which can output a build log + * it has a configurable C coding style + * it provides access to the GDB console while debugging + * it has powerful regular expressions searching and replacing abilities + +## Screenshots + +[[!img http://people.freedesktop.org/~jrfonseca/eclipse/eclipse-cdt-main.png] + +[[!img http://people.freedesktop.org/~jrfonseca/eclipse/eclipse-cdt-remote-debug.png] + + +## Installation How-to + +If you're only interested in C/C++ development the simplest option is to download [[Eclipse IDE for C/C++ Developers|http://www.eclipse.org/downloads/moreinfo/c.php]] and extract it into /opt. + +Otherwise, you can always install CDT from the Eclipse Update Manager. + +Then install the [[Eclipse-Autotools integration plugin|http://sourceware.org/eclipse/autotools/]], which provides assistance for projects using autotools. + + +## Introduction + +Eclipse organizes code in _projects_ and _workspaces_. + +* A _project_ is equivalent to a X.Org module. Projects have different build settings and separate source repositories. +* A _workspace_ is a set of related projects. Workspaces have different settings, and a workspace can only be opened by a single instance of Eclipse at any given time. +NOTE: You don't need to create a project for every single X.Org module, and that would be overkill. The modules you are planning to actively develop and debug are perfectly sufficient, as you can still open and debug through files outside the projects. + +Eclipse organizes windows in _views_ and _perspectives_. + +* A _view_ is a display. You can add and re-arrange existing views. +* A _perpective_ is a set of views in a given layout. You can switch perspectives. The most interesting are the C/C++ and the Debug perspective. + +## Xorg How-to + +It is assumed you have installed the xorg development packages from your distribution, or you have built xorg from source as explained in the [[ModularDevelopersGuide|ModularDevelopersGuide]] in /opt/xorg. + +* Initial configuration + * Start eclipse and enter the path to your workspace (it can be an inexistent directory as Eclipse creates one for you) + * You'll be presented with the welcome screen. Click to go to the workbench. + * Switch to the _C/C++ Perspective_ by going to _Window > Open Perspective > Other... > C / C++_ + * In _Window > Preferences > C/C++ > Environment_ dialog set the following environment variables [[!format txt """ +LD_LIBRARY_PATH=/opt/xorg/lib +ACLOCAL="aclocal -I /opt/xorg/share/aclocal" +CPPFLAGS="-I /opt/xorg/include" +CFLAGS="-O0 -g3 -fmessage-length=0" +CXXFLAGS="-O0 -g3 -fmessage-length=0" +"""]] +* Create a project for `xserver` + * In a terminal do: [[!format txt """ +cd /path/to/your/workspace +git clone git://anongit.freedesktop.org/git/xorg/xserver +"""]] + * File > New > GNU C Autotools Project + * Set `xserver` as the project (the same as the git module) + * In _Project > Properties_ dialog, _C/C++ Build > Settings > Tool Settings_ tab + * Under _configure > General > Directory specifiers_ set the installation directory (--prefix) to `/opt/xorg` + * Under _configure > Features and packages_ set _Enable maintainer mode (--enable-maintainer-mode)_ and enter any other configuration options you wish to pass to `configure` + * Press Ctrl+B to build the project. + * To switch between `configure` output and the `make` output go to the _Console_ view, and click on the _Display Selected Console_ button. + * Double-click install target of the _Make Targets_ view. +* Debug Xnest locally + * In the _Debug > Debug settings..._ dialog, under _C/C++ Local Application_ click on the _New_ button + * Set `/opt/xorg/bin/Xnest` as the application path + * Set as arguments `:1` + * Click on the _Debug_ button. + * The gdb console is available from the _Console_ view, _Console_ by clicking on the _Display Selected Console_ button. +* Debug Xorg remotely + * rsync the `/opt/xorg` directory to the remote machine [[!format txt """ +rsync -av --delete /opt/xorg/ your-remote-machine:/opt/xorg/ +"""]] + * in the remote machine run [[!format txt """ +gdbserver :10000 /opt/xorg/bin/Xorg +"""]] + * In the _Debug > Debug settings..._ dialog, under _C/C++ Local Application_ click on the _New_ button + * Set `/opt/xorg/bin/Xorg` as the application path + * Choose gdbserver in the Debugger tab + * Enter the hostname and of the remote machine and the port that gdb is listening to + * Click on the _Debug_ button. +You can add more modules and/or debug targets in a similar fashion. + + +## Code Formatting + +CDT allows to specify the C code style from _Window > Preferences > C/C++ > Code style_ property page. + +You can import [[this profile|http://people.freedesktop.org/~jrfonseca/eclipse/xorg-code-style.xml]], which was made to follow [[these (un)official guidelines|http://lists.freedesktop.org/archives/xorg/2004-October/003673.html]] as close as possible. + +There is also a [[code style for Mesa|http://people.freedesktop.org/~jrfonseca/eclipse/mesa-code-style.xml]]. + + +## Full tree setup + +You can add the whole tree as a project, which is advantageous when cross-module work is done, or you are interested in module interdependecies. However, index generation can get darn slow then. Manually specifying include directories and disabling _automated discovery_ in the project's discovery options may be helpful. + +Also, eclipse prior to ganymede had the tendency to spend a few minutes on collecting the (admittedly huge) index whenever you'd type a member access operator (. or ->). Disabling _Content Assist_ should help that. + + +## Tips + +* To avoid out-of-memory errors change the last lines of `eclipse.ini` to [[!format txt """ +-vmargs +-Xms64m +-Xmx1024m +"""]] +* The autotools plugin simplifies the invocation of autoconf and automake, but it has some bugs that you should watch out for: + * [[https://bugzilla.redhat.com/show_bug.cgi?id=324681|https://bugzilla.redhat.com/show_bug.cgi?id=324681]] +* In _Window > Preferences > General > Keys_ bind Ctrl+B to build the current project, instead of all projects. +* In _Window > Preferences > General_ set to _Always run in background_ +* In _Window > Preferences > Run/Debug > Launching_ set to Launch the previous launched application +Check more tips in: + +* [[http://tkramar.blogspot.com/2007/10/effective-eclipse-i-setup.html|http://tkramar.blogspot.com/2007/10/effective-eclipse-i-setup.html]] +* [[http://dmy999.com/article/29/using-eclipse-efficiently|http://dmy999.com/article/29/using-eclipse-efficiently]] + +## Other plugins + +Must have: + +* [[Extended VS Presentation plugin for Eclipse|http://andrei.gmxhome.de/skins/index.html]] -- this plugin modifies Eclipse's look and feel to make it waste less screen space, and easier to use. +* [[Rectangular edit plugin|http://lunar-eclipse.sourceforge.net/editor-tutorial/index.html]] -- provides rectangular editing abilities, like VIM and Emacs. +Optional: + +* [[Target Management plugin|http://www.eclipse.org/dsdp/tm/]] -- simplifies remote debugging and testing by allowing to seemingly manipulate remote files and shells. +* [[egit|http://git.or.cz/gitwiki/EclipsePlugin]] -- git integration plugin -- is still on early stages of development with very limited functionality and must be compiled from source, but it already provides a visual history viewer similar to gitk.
\ No newline at end of file diff --git a/Development/Documentation/VersionNumberScheme.mdwn b/Development/Documentation/VersionNumberScheme.mdwn new file mode 100644 index 00000000..92b34258 --- /dev/null +++ b/Development/Documentation/VersionNumberScheme.mdwn @@ -0,0 +1,61 @@ + +X.org inherited the XFree86 version numbering scheme: + +The version numbering format is M.m.P.s, where M is the major version number, m is the minor version number, P is the patch level, and s is the snapshot number. Full releases have P set to zero, and it is incremented for each subsequent bug fix release on the post-release stable branch. The snapshot number s is present only for between-release snapshots of the development and stable branches. + + +## Development Branch + +Immediately after forming a release stable branch, the patch level number for the main development branch is bumped to 99, and the snapshot number is reset. The snapshot number is incremented for each tagged development snapshot. The GIT tag for snapshots is "xorg-<module>-M_m_P_s". When the development branch enters feature freeze, the snapshot number is bumped to 900, and a stable branch is created for the next full release. The branch is called "<module>-M_m-branch". The snapshot number is incremented from there until the release is finalised. Each of these snapshots is a "release candidate". When the release is finalised, the minor version is incremented, the patch level is set to zero, and the snapshot number removed. + +Here's an example which shows the version number sequence for the development leading up to version 4.1.0: + +**4.0.99.1** + + * The first snapshot of the pre-4.1 development branch. +**4.0.99.23** + + * The twenty-third snapshot of the pre-4.1 development branch. +**4.0.99.900** + + * The start of the 4.1 feature freeze, which marks the creation of the "xf-4_1-branch" branch. That branch is the "stable" branch for the 4.1.x releases. +**4.0.99.903** + + * The third 4.1.0 release candidate. +**4.1.0** + + * The 4.1.0 release. +**4.1.99.1** + + * The first pre-4.2 development snapshot, which is the first main branch snapshot after creating the 4.1 stable branch. + +## Stable Branch + +After a full release, the stable branch for the release will be maintained with bug fixes and important updates until the next full release. All snapshots on this branch are considered "release candidates", so the first is indicated by setting s to 901. The snapshot number is then incremented for each subsequent release candidate until the update release if finalised. The patch level value (P) is incremented for each update release. + +Here's an example which shows the version number sequence for the 4.1.x stable branch. + +**4.0.99.900** + + * The start of the 4.1 feature freeze, which marks the creation of the "xf-4_1-branch" branch. That branch is the "stable" branch for the 4.1.x releases. +**4.0.99.903** + + * The third 4.1.0 release candidate. +**4.1.0** + + * The 4.1.0 release. +**4.1.0.901** + + * The first pre 4.1.1 snapshot. +**4.1.0.903** + + * The third pre 4.1.1 snapshot, also known as the third 4.1.1 release candidate. +**4.1.1** + + * The 4.1.1 release. +**4.1.1.901** + + * The first pre 4.1.2 snapshot. +**4.1.2** + + * The 4.1.2 release.
\ No newline at end of file diff --git a/Development/Documentation/WrappingFunctions.mdwn b/Development/Documentation/WrappingFunctions.mdwn new file mode 100644 index 00000000..735e1898 --- /dev/null +++ b/Development/Documentation/WrappingFunctions.mdwn @@ -0,0 +1,38 @@ + +# Moved from [[http://www.freedesktop.org/wiki/Software/WrappingFunctions|http://www.freedesktop.org/wiki/Software/WrappingFunctions]] + + +## Wrapping Functions + +_XXX: Add some information about prologues/epilogues_ + +Sometimes you want to override or hook into a certain function and have it do something else. For example, you might want to use an accelerated function for drawing triangles. This is done by replacing the function pointers in the data structures + + +[[!format txt """ +/* Don't forget to save the original function */ +pMyScreenData->CreatePixmap = pSCreen->CreatePixmap; + +/* Replace the function */ +pScreen->CreatePixmap = MyCreatePixmap; +"""]] +Now the function `MyCreatePixmap` will be called instead of the regular `CreatePixmap` function. This is good if we're superstitious: +[[!format txt """ +static PixmapPtr +MyCreatePixmap (ScreenPtr pScreen, int w, int h, int depth) +{ + MyScreenDataPtr pMyScreenData = GET''MY''SCREEN_DATA (pScreen); + + if (w == 13 && h == 13) + { + /* Refuse to create pixmaps with size 13x13 */ + return NULL; + } + + /* Call the original function */ + return (* pMyScreenData->CreatePixmap) (pScreen, w, h, depth); +} +"""]] +(See [[Development/Documentation/DevPrivates|Development/Documentation/DevPrivates]] for information on where the `MyScreenDataPtr` comes from) + +-- [[AndersCarlsson|AndersCarlsson]] - 23 Sep 2003 diff --git a/Development/Documentation/WritingDocumentation.mdwn b/Development/Documentation/WritingDocumentation.mdwn new file mode 100644 index 00000000..ed8882d6 --- /dev/null +++ b/Development/Documentation/WritingDocumentation.mdwn @@ -0,0 +1,189 @@ + +This page describes which tools are available for the various types of documentation one can contribute to. + + +## Doxygen + +If you're describing an API, the best choice is probably [[Doxygen|http://www.doxygen.org]]. Doxygen allows you to comment your C files and headers inline, and later generates documents from same. For a good example of how to use Doxygen, take a look at the X server [[Distributed Multihead X Design|http://cgit.freedesktop.org/xorg/xserver/tree/hw/dmx/doc]]. + + +## DocBook + +Larger documents are maintained in [[DocBook/XML|http://www.docbook.org]] format. As of X11``R7.6, almost all documentation have been converted from DocBook/SGML, Framemaker, troff, Linuxdoc and TeX to DocBook/XML. The doc/xorg-docs module contains general X Window System documentation, anything specific has been moved to the appropriate module. + + +## Man Pages (troff with "man" macros) + +Commands and public API in client-side libraries are documented in the traditional _roff_ man page format which involves a significant learning curve. + + +### Commands: + +* `.\"` Comment: the rest of the line is a comment. +* `.TH` Text Header: This is the header of a line. It contains the name of the page in capital letters followed by the section the page is to be located in. Then it contains `''''vendorversion''''` which is replaced by the vendor version when the system is built. +* `.SH` Section Header: Man pages contain several sections. Some are ordered according to a standard conventions. Their names are capitalized. +* `.B` : Boldface: Print following text in boldface. +* `.I` : Italic: Italic/underline the following text. +* `.P` : Paragraph: Start a new paragraph.`.PP` Double paragraph (?). +* `.br` : Break: insert a linebreak. +* `.R` : Roman: Non-italic non-bold font +* `.BR : alternating bold and regular font +* `.RB : alternating regular and bold font +* `.TP` Tabulator: May optionally be followed by a indentation width. The next line is indented normally, any lines following this line up to the next paragraph command (ie. `.SH`, `.TP`, `.P` are indented according to the number following the command relative to the normal indentation. +* `.fi`: (?) +* `.nf`: (?) +* Characters `.`,`-`, `\` need to be escaped with a `\`. Ie: `\.`,`\-`. + +### Man Page Skeleton + + +[[!format txt """ +.TH THISCOMMAND 1 ''''vendorstring'''' +.SH NAME +thiscommand \- describe this command +.SH SYNOPSIS +.B "thiscommand" +.RB [ -help ] +.SH DESCRIPTION +Here we describe what +.I thiscommand +does. +.PP +.SH OPTIONS +The following options are supported: +.TP +.B \-h +Help. +.SH FILES +.SH KNOWN BUGS +.SH "SEE ALSO" +OTHERCOMMAND(1) +"""]] +One may add additional commands between *DESCRIPTION* and *FILES* section as fit. + + +### Conditional Text + +Just like C code is conditionally included using #ifdef, manual page text can be conditionally included as well. Use _.if_ to test a variable and place the text between _.ig_ and '..'. + + +[[!format txt """ +.if !'x.VARNAME'x.' .ig +If $(VARNAME) is empty, this text is shown +.. +"""]] + +[[!format txt """ +.if 'VARNAME'' .ig +If $(VARNAME) is empty, this text is skipped +.. +"""]] + +## Current Module Documents (June 2011) + +This table summarizes modules with User's documentation, Developer's documentation or functional specifications in DocBook/XML format. The DocBook/XML input format is converted to HTML, PDF, PS and plain text. When installed, the documentation input source (xml) is also installed as it can be read directly by platform help delivery system such as gnome-help. +[[!table header="no" class="mointable" data=""" +Module | Dir | In Fmt | Tool | Out Fmt | Inst Fmt | Dist Fmt | Options +app/xfs | doc | xml | xmlto | txt/ps/pdf/html | not installed | xml | enable-devel-docs +app/xrx | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +app/rstart TBD | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +doc/xorg-docs | general | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +specs | enable-specs +lib/libICE | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +specs | enable-specs +lib/libSM | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +lib/libX11 | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +lib/libXaw | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +lib/libXdmcp | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +lib/libXext | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +lib/libXfont | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-devel-docs +lib/libXi | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +specs | enable-specs +lib/libXmu | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +lib/libXt TBD | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +lib/libxtrans | doc | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-docs +lib/libXtst | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/bigreqsproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/fontsproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/inputproto | specs | txt | asciidoc | txt/html | txt/html | txt | enable-specs +proto/kbproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/recordproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/scrnsaverproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/x11proto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/xcmiscproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +proto/xextproto | specs | xml | xmlto | txt/ps/pdf/html | txt/ps/pdf/html/xml | xml | enable-specs +xserver/doc | xml | xml | xmlto | txt/pdf/html | not installed | xml | enable-devel-docs +xserver/doc | dtrace | xml | xmlto | txt/pdf/html | installed | xml | enable-docs +xserver/hw/dmx | doc | xml | xmlto | txt/pdf/html | not installed | xml | enable-devel-docs +xserver/hw/xfree86 | doc | xml | xmlto | txt/pdf/html | not installed | xml | enable-devel-docs +"""]] + +This table summarizes modules with _man pages_ that are not hand written in the _troff_ format. The input format may be DocBook/XML or asciidoc. The generated man pages files are included in the tarball. +[[!table header="no" class="mointable" data=""" +Module | Dir | In Fmt | Tool | Mid Fmt | Tool | Out Fmt | Inst Fmt | Dist Fmt +lib/libXcomposite | man | xml | N/A | N/A | xmlto | troff | troff | xml+**troff** +lib/libXi | man | txt | asciidoc | xml | xmlto | troff | troff | txt+**troff** +lib/libXtst | man | xml | N/A | N/A | xmlto | troff | troff | xml+**troff** +"""]] + +This table summarizes modules with API Developer's documentation generated from Doxygen format using DocBook/XML as intermediate format. The source for the generated HTML files is the C code which is already included in the tarball. +[[!table header="no" class="mointable" data=""" +Module | Dir | In Fmt | Tool | Mid Fmt | Tool | Out Fmt | Inst Fmt | Options +xserver/hw/dmx | doc | *.[hc] | doxygen | xml | xmlto | html | not installed | enable-devel-docs +"""]] +In Fnt +: the original source format stored in git (xml refers to docbook xml) + +Mid Fmt +: an intermediate format that is sometimes distributed in the tarball with the original source format + +Out Fmt +: the final format generated by the named tool + +Inst Fmt +: the formats in which the documents are installed in $docdir + +Dist Fmt +: the formats in which documents are included in the tarball. May contain generated formats (shown in bold) + +Options +: the name of the (./configure --help) option used to control the generation of documents + +Default +: the default value of the configure option if none is supplied + + + +### Documentation Tooling + +A number of tools are required to generate the documentation. They are not all available on all platforms, and if they are, not always at a recent enough level. It is already common practice to skip the generation process if a tool is missing. In addition, some platforms have asked for a configure option to turn any tool off. This prevents breaking the build when the level of the tool is known to be too old. + +A number of macros have been written in the util-macros package which provide such facility. When used consistently, it makes controlling the documentation build process easier. Some macros can be invoked with a desired minimum version. The documentation will not be generated if the installed tool does not meet this request. Consult util/macros/xorg-macros.m4. + + +[[!format txt """ +XORG_WITH_XMLTO --with-xmlto +XORG_WITH_ASCIIDOC --with-asciidoc +XORG_WITH_DOXYGEN --with-doxygen +XORG_WITH_FOP --with-fop +XORG_WITH_XSLTPROC --with-xsltproc +XORG_CHECK_SGML_DOCTOOLS +"""]] + +### Installing and Distributing + +In the simpler scenario, when a document is generated in it's output format, say pdf, it is installed in a location known by it's makefile variable $docdir. This is done by the makefile target `install`. + +Distributing refers to the creation of a compressed archive file (tarball) containing all the package source suitable to be independently built by a third party. These are published on the X.Org web site. It must contain the documentation input format, so the output can be regenerated and installed on the target computer. + + +### Generated files in the tarball + +As discussed above, some platforms do not have all the documentation tools to generate the documents from a tarball. This prevents them from installing the documents to the target computer. To solve this issue, generated files have been added in the tarball, either in the final output format or in a format for which tools are known to be available on all platforms. + +The makefiles have to tweak the targets to take the availability of the tools into consideration. This is where the macros are useful in providing the necessary makefile variables. It is understood that platforms lacking documentation tools will not be able to create a tarball for distribution, as it would be missing the generated files. + + +#### Directory structure + +The wiki [[New Module Guidelines|NewModuleGuidelines]] describes the directory structure for each module. It generally states that man pages are to be in the `man` directory and that documents of any kind go in the `doc` directory. There are a number of modules where documents and man pages are in the same directory. Sometimes `man` is under `doc`, sometimes `doc` is named `spec` or `specs`. The guidelines should be followed. When multiple documents are to be generated, subdirectories can be used as appropriate. diff --git a/Development/Documentation/XGE.mdwn b/Development/Documentation/XGE.mdwn new file mode 100644 index 00000000..05cd4e56 --- /dev/null +++ b/Development/Documentation/XGE.mdwn @@ -0,0 +1,75 @@ + + +# X Generic Event Extension + +The X Generic Event extension (XGE) grew out of the problem that X only allows 64 event opcodes for all extensions together. Right now, there are only around 15 or so left, depending on how many extensions are enabled in your server. XGE simply defines one new event opcode (35, [[GenericEvent|GenericEvent]]) in the core protocol, and then re-uses this opcode for multiple events. + + +## Event Structure + + +[[!format txt """ +typedef struct +{ + BYTE type; /* Always GenericEvent */ + CARD8 extension; + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 evtype B16; + CARD16 pad2 B16; + CARD32 pad3 B32; + CARD32 pad4 B32; + CARD32 pad5 B32; + CARD32 pad6 B32; + CARD32 pad7 B32; +} xGenericEvent; + +"""]] +The actual type of an event is specified as the combination of _extension_ and _evtype_. _extension_ specifies the matching extension's major opcode. _evtype_ is a static type as defined for this extension. _evtype_ must be unique within the extension. + + +## Long events + +XGE allows events that are longer than the standard X protocol's 32 byte events. The _length_ field of a [[GenericEvent|GenericEvent]] defines the number of bytes after the initial 32 bytes in 4 byte units. + +**Sending long events requires an XGE-aware libX11/libxcb!** The server must not send a long event unless it is sure that the client supports XGE, otherwise the protocol will be unaligned. libX11 without xcb support does **not** support [[GenericEvents|GenericEvents]]. + + +## Requests + +XGE provides a single request: _GEQueryVersion_. + + +[[!format txt """ +/* QueryVersion */ +typedef struct { + CARD8 reqType; /* input extension major code */ + CARD8 ReqType; /* always X_GEQueryVersion */ + CARD16 length B16; + CARD16 majorVersion B16; + CARD16 minorVersion B16; +} xGEQueryVersionReq; + +#define sz_xGEQueryVersionReq 8 + +typedef struct { + CARD8 repType; /* X_Reply */ + CARD8 RepType; /* always X_GEQueryVersion */ + CARD16 sequenceNumber B16; + CARD32 length B32; + CARD16 majorVersion B16; + CARD16 minorVersion B16; + CARD32 pad00 B32; + CARD32 pad01 B32; + CARD32 pad02 B32; + CARD32 pad03 B32; + CARD32 pad04 B32; +} xGEQueryVersionReply; + +"""]] + +## Usage + +As the event selection is specific to the extension, it is (currently) required that each extension provides its own event selection request. For example, in XI this is _[[XiSelectEvent|XiSelectEvent]]_. + +XGE is being used by XI (MPX) to send long events. Much of its current implementation supports device-specific events, but it is intended to be usable by other extensions as well. diff --git a/Development/Documentation/XServerStableBranchManagement.mdwn b/Development/Documentation/XServerStableBranchManagement.mdwn new file mode 100644 index 00000000..f4690dcc --- /dev/null +++ b/Development/Documentation/XServerStableBranchManagement.mdwn @@ -0,0 +1,58 @@ + +This page describes the process used by stable branch maintainers for the [[XServer|XServer]]. + + +## A note to Maintainers + +DONT PANIC! + +As maintainer, you get to decide the schedule of the stable branch series as well as what patches you will accept in the tree. We ask that once you decide on a schedule for the next release, you stick to that schedule (within a reasonable margin). Sometimes things get in the way though. If there is a need for changing the schedule announce it so others are aware of the change. Of course, the further ahead this can be announced the better. An email along the lines of "the 1.x.y+1 release will follow a 8 week release schedule" is perfect. + +Either way, the point of a stable branch is to provide stable fixes. Any scheduling issues are less important. + + +## Patches for the stable branches + +A patch **must** be on the master branch unless the specific issue is either diverged too much from master or only occurs on the stable branch to begin with. If the master branch suffers from the same bug but a different patch is required (due to differences to the stable branch), the bugfix must be on master first. This allows us to detect potential side-effects from fixing a bug. + +Getting a patch onto the stable branch is largely the job of the developers, but they usually need a bit of prodding. As branch maintainer, don't shy away from asking people to send you pull requests or clarify if a specific patch proposed for master is suitable for stable. + + +## git commands + +Creation of the stable branch (only needed once) should be done based on the released tag +[[!format txt """ + git checkout xorg-server-1.13 + git checkout -b server-1.13-branch + git push origin server-1.13-branch +"""]] +The stable branch is now visible on the remote. + +Patches can be cherry-picked onto the branch from master. Always use -x to record the original commit +[[!format txt """ + git cherry-pick -x 1234deadbeef +"""]] +And once the branch is ready to push +[[!format txt """ + git push origin server-1.13-branch +"""]] +Alternatively, in the case of a pull request simply run git pull on the remote (with the branch name) +[[!format txt """ + git pull git://people.freedesktop.org/~jbond/xserver.git server-1.13-fixes +"""]] +Before pushing, the maintainer should ensure that the tree builds and performs adequate on their machine. + + +## Releasing a stable branch update + +See the [[ReleaseHOWTO|Development/Documentation/ReleaseHOWTO]] for instructions on how to invoke the release script. To make releases, the maintainer must have a gpg key to sign tags and announce emails. + +Each release has a version number and a git tag named after the module. The version number is set in configure.ac, the module name (and thus git tag prefix) for the [[XServer|XServer]] is _xorg-server_. + +The patchlevel version increases once with each stable release, release candidates for future stable releases use a trailing 901, 902, etc. Example tag names for the 1.13 stable branch series +[[!format txt """ + xorg-server-1.13.0 # stable release + xorg-server-1.13.0.901 # 1.13.1RC1 + xorg-server-1.13.0.902 # 1.13.1RC1 + xorg-server-1.13.1 # 1.13.1 stable update +"""]]
\ No newline at end of file diff --git a/Development/Documentation/XorgInputHOWTO.mdwn b/Development/Documentation/XorgInputHOWTO.mdwn new file mode 100644 index 00000000..591fecfe --- /dev/null +++ b/Development/Documentation/XorgInputHOWTO.mdwn @@ -0,0 +1,481 @@ + + +## X Input Driver HOWTO + +This is a tutorial to write a new input driver for X. Knowledge of C is a prerequisite, experience with X server development is handy but not required. + +If you're planning to invent a new device, you will most likely also need a matching driver for the linux kernel. This is not covered in this tutorial. Note that if you think about writing a new input driver for a "common" device (e.g. touchscreen, mouse, keyboard, etc.), please don't. Time is much better spent writing a kernel driver instead, and then your device will be picked up automatically. This tutorial is for those seeking to understand input drivers, or having special devices that cannot be used through the kernel's evdev interface. + +This tutorial will explain the "random" driver for a pointing device that feeds from /dev/random. This driver will be useless. It's job is to introduce you to the way how drivers are written, not to provide an actual driver for your device. All this driver will do is randomly move the cursor along the x axis. + +The full source is available from [[git://people.freedesktop.org/~whot/xf86-input-random|http://cgit.freedesktop.org/~whot/xf86-input-random]]. The X server and most of the drivers are kept in git. It is a good idea to familiarise yourself with git when you start developing a new driver. It is recommended that you put your own driver into a git repository, especially if you want to bundle it with the X server distributions. + + +#### Origin + +This document was originally written by Peter Hutterer to have a tutorial that'll teach him how to write an input driver. + +This tutorial is heavily influenced by the evdev codebase, written by Zephania E. Hull and Kristian Hogsberg. + + +#### Amendments + +* 2009-10-26: Use xf86SetStrOption instead of xf86CheckStrOption, update link to git repo (even if repo is MIA right now) + + +### The Directory Setup + +The naming convention for input drivers is xf86-input-devicename. We set the directory up, and provide the minimum amount of files. Our initial directory tree should look like this: + + +[[!format txt """ +xf86-input-random/COPYING + Makefile.am + configure.ac + autogen.sh + man/Makefile.am + man/random.man + src/Makefile.am + src/random.h + src/random.c +"""]] +We don't want to write the automake files from scratch, so we copy them from some other driver, and replace all occurances of the other driver's name with our name. The evdev driver would be a good source for this, as it is very actively maintained. + +If you are compiling input drivers without the full X source tree, instead using your distribution's development libraries, you may need to install the xorg-util-macros to get the automake scripts to work properly. These macros provide the DRIVER_MAN_SUFFIX variable and the PACKAGE_VERSION_* variables amongst others. + +Our source files random.h and random.c will become our driver implementation. The random.man should be your man file. Writing the man page is not covered in this tutorial. + +By the way, now's a good time to init your git repository. + + +### Some basic knowledge + +An X driver has to handle three different entities: modules, drivers and devices. A module is a container for multiple drivers (In fact, our xf86-input-random is actually not a driver, but a module). The driver is responsible for setting up a device. Which driver is picked, depends on the configuration of your X server. Once a device is set up, it is responsible for posting events up to the server. + +In other terms: A module is loaded once. A driver is loaded each time a section in the xorg.conf refers to it. A device is created when the driver is loading. The rest is the device's problem. + +Now let's get down to hacking. + + +### Module information + +Our module needs to provide some basic information to the X server. This information is in the XF86ModuleData (xf86Module.h). + + +[[!format txt """ +typedef pointer (*ModuleSetupProc)(pointer, pointer, int *, int *); +typedef void (*ModuleTearDownProc)(pointer); + +typedef struct { + XF86ModuleVersionInfo * vers; + ModuleSetupProc setup; + ModuleTearDownProc teardown; +} XF86ModuleData; +"""]] +The first field of the struct is the module's version info. I won't go into details explaining it, just copy it from some driver and replace the name. Be reminded that this information has to be available before any of your module's functions are called, so put it as a global static into your file. + +The [[ModuleSetupProc|ModuleSetupProc]] is called when the module is loaded. Any module-specific data initialisation needs to go in here. + +The [[ModuleTearDownProc|ModuleTearDownProc]] will be called when our module is unloaded. Anything ever allocated by our module needs to be freed here. + +With this information, we can write our first few lines of code. (Copyright headers and #includes are skipped for brevity. Please refer to the full source code.) + + +[[!format txt """ +static XF86ModuleVersionInfo RandomVersionRec = +{ + "random", + MODULEVENDORSTRING, + MODINFOSTRING1, + MODINFOSTRING2, + XORG_VERSION_CURRENT, + PACKAGE_VERSION_MAJOR, PACKAGE_VERSION_MINOR, + PACKAGE_VERSION_PATCHLEVEL, + ABI_CLASS_XINPUT, + ABI_XINPUT_VERSION, + MOD_CLASS_XINPUT, + {0, 0, 0, 0} +}; + +_X_EXPORT XF86ModuleData randomModuleData = +{ + &RandomVersionRec, + RandomPlug, + RandomUnplug +}; + +static void +RandomUnplug(pointer p) +{ +} + +static pointer +RandomPlug(pointer module, + pointer options, + int *errmaj, + int *errmin) +{ + xf86AddInputDriver(&RANDOM, module, 0); + return module; +} +"""]] +All the defines in the [[VersionInfo|VersionInfo]] will be replaced by our automake build scripts. + + +### Driver information + +In the previous listing you can see the call to _xf86AddInputDriver()_. This call tells X information about a new available driver. As said before, a module may contain multiple drivers. + +The RANDOM variable we refer simply contains the information we to initialize our driver. Its of type [[InputDriverRec|InputDriverRec]]. + + +[[!format txt """ +typedef struct _InputDriverRec { + int driverVersion; + char * driverName; + void (*Identify)(int flags); + struct _LocalDeviceRec *(*PreInit)(struct _InputDriverRec *drv, + IDevPtr dev, int flags); + void (*UnInit)(struct _InputDriverRec *drv, + struct _LocalDeviceRec *pInfo, + int flags); + pointer module; + int refCount; +} InputDriverRec, *InputDriverPtr; +"""]] +Some of the fields here are important, others aren't quite as important. Identify is never called for input drivers anyway, so none of the X.org input drivers use it. All drivers use a driverVersion of 1. + +Other fields are more important. driverName needs to be substituted with our driver's name. This doesn't have to be the same name as the module. The driver name is what you will need to refer to it in the Section "[[InputDevice|InputDevice]]" in your xorg.conf. [[PreInit|PreInit]] will be called when your device has been added to the server. It will be called once per device and allows you to initialize internal structs you need for your driver to function correctly. [[UnInit|UnInit]] will be called when your device is removed from the server. Clean up your mess here. + +module and refCount are used by the server. Don't touch them. + +For our driver, the code looks like this: + + +[[!format txt """ +static InputInfoPtr +RandomPreInit(InputDriverPtr drv, + IDevPtr dev, + int flags) +{ + return NULL; +} + +static void +RandomUnInit(InputDriverPtr drv, + InputInfoPtr pInfo, + int flags) +{ +} + +_X_EXPORT InputDriverRec RANDOM = { + 1, + "random", + NULL, + RandomPreInit, + RandomUnInit, + NULL, + 0 +}; +"""]] +With all this code in place we already have a driver that compiles and can be loaded up. However, it won't do anything, except wasting a few CPU cycles. And it's not particularly good at that either. + + +### Initialising a new device + +In this section we'll discuss what should happen in the [[PreInit|PreInit]] and [[UnInit|UnInit]]. + +[[PreInit|PreInit]] is called when a new device is added to the server. This can happen at server startup (the device has an entry in the config file) or during runtime (hotplugged). For us as driver developers this doesn't really matter. Note that [[PreInit|PreInit]] will be called for each device using our driver! + +What the [[PreInit|PreInit]] should do: + + * an [[InputInfoRec|InputInfoRec]] needs to be allocated. This struct will contain important information about our device. + * configuration options need to be parsed + * the device should be tested for availability and accessability. + * internal data needs to be initialised, if the driver needs to. +I'll just throw some code at you: +[[!format txt """ +static InputInfoPtr RandomPreInit(InputDriverPtr drv, + IDevPtr dev, + int flags) +{ + InputInfoPtr pInfo; + RandomDevicePtr pRandom; + + if (!(pInfo = xf86AllocateInput(drv, 0))) + return NULL; + + pRandom = xcalloc(1, sizeof(RandomDeviceRec)); + if (!pRandom) { + pInfo->private = NULL; + xf86DeleteInput(pInfo, 0); + return NULL; + } + + pInfo->private = pRandom; + +"""]] +First we let the server allocate information, then we allocate a [[RandomDeviceRec|RandomDeviceRec]] for our own information and attach it to the device's private field. The [[RandomDeviceRec|RandomDeviceRec]] (look at the source) is just the struct we need to store device-internal stuff for our driver. Our driver is so simple, it won't contain much. The more complicated your driver is, the more you will have to store in this private struct. + +If an error occurs, [[PreInit|PreInit]] should clean up and return NULL. + + +[[!format txt """ + pInfo->name = xstrdup(dev->identifier); + pInfo->flags = 0; + pInfo->type_name = XI_MOUSE; /* see XI.h */ + pInfo->conf_idev = dev; + pInfo->read_input = RandomReadInput; /* new data avl */ + pInfo->switch_mode = NULL; /* toggle absolute/relative mode */ + pInfo->device_control = RandomControl; /* enable/disable dev */ +"""]] +Important for us are + + * read_input: will be called when new data is available. + * switch_mode: will be called when a client requests to switch between absolute and relative mode of a device. (Not applicable for our random device). + * device_control: will be called when the device is switched on or off. +Now we need to process some options. +[[!format txt """ + /* process driver specific options */ + pRandom->device = xf86SetStrOption(dev->commonOptions, + "Device", + "/dev/random"); + + xf86Msg(X_INFO, "%s: Using device %s.\n", pInfo->name, pRandom->device); + + /* process generic options */ + xf86CollectInputOptions(pInfo, NULL, NULL); + xf86ProcessCommonOptions(pInfo, pInfo->options); +"""]] +So first we check for a driver-specific options. If the "Device" option is set, we extract it (if not, we use the default provided). The same interface is available to get other data types. xf86Set{Int|Real|Str|Bool}Option(), returns us the value we need (with an optional default provided). Using xf86SetStrOption marks the option as used and also prints it to the log file. + +After we're done processing our special options, we just tell the server to process all generic options (e.g. "[[SendCoreEvents|SendCoreEvents]]"). + +Now we should test if the device is available and accessible. + + +[[!format txt """ + /* Open sockets, init device files, etc. */ + SYSCALL(pInfo->fd = open(pRandom->device, O_RDWR | O_NONBLOCK)); + if (pInfo->fd == -1) + { + xf86Msg(X_ERROR, "%s: failed to open %s.", + pInfo->name, pRandom->device); + pInfo->private = NULL; + xfree(pRandom); + xf86DeleteInput(pInfo, 0); + return NULL; + } + + /* do more funky stuff */ + + close(pInfo->fd); + pInfo->fd = -1; +"""]] +We use SYSCALL to make sure our call isn't interrupted. Once the device is open, you may want to do some additional funky stuff (have a look at evdev) to get information from the device. Finally we close the file again, after all it was just a test to see if it's there. + +Let's set some flags and finish up. Note that if we don't set the XI86_CONFIGURED flag, the server thinks something failed and will clean up our device. +[[!format txt """ + pInfo->flags |= XI86_OPEN_ON_INIT; + pInfo->flags |= XI86_CONFIGURED; + + return pInfo; +} +"""]] +The [[UnInit|UnInit]] is not overly exciting and doesn't need further explanation. + + +[[!format txt """ +static void RandomUnInit(InputDriverPtr drv, + InputInfoPtr pInfo, + int flags) +{ + RandomDevicePtr pRandom = pInfo->private; + + if (pRandom->device) + { + xfree(pRandom->device); + pRandom->device = NULL; + } + + xfree(pRandom); + xf86DeleteInput(pInfo, 0); +} +"""]] +Recap: we now have a driver that initialises and tests for our device on startup. + + +### Starting and stopping our device + +Key to using our device is starting and stopping it when necessary. If your driver does not do this, it may cause havoc when your device is hotplugged or removed at runtime. + +The device_control field in the [[InputInfoRec|InputInfoRec]] is used to notify a device about state changes. It takes two arguments, the first being the device, the second being what the device should do (one out of DEVICE_INIT, DEVICE_ON, DEVICE_OFF, DEVICE_CLOSE). + +Again, here's some code. + + +[[!format txt """ +static int RandomControl(DeviceIntPtr device, + int what) +{ + InputInfoPtr pInfo = device->public.devicePrivate; + RandomDevicePtr pRandom = pInfo->private; + + switch(what) + { + case DEVICE_INIT: + _random_init_buttons(device); + _random_init_axes(device); + break; + +"""]] +DEVICE_INIT is called when the device is added to the server. The server expects the device to allocate all necessary information to figure out what type of device it is. + +Here's the code we use to init a device hardcoded to two buttons. Your device should include some option to switch the button map around, but we don't bother for it here. +[[!format txt """ +static int +_random_init_buttons(DeviceIntPtr device) +{ + InputInfoPtr pInfo = device->public.devicePrivate; + CARD8 *map; + int i; + int ret = Success; + const int num_buttons = 2; + + map = xcalloc(num_buttons, sizeof(CARD8)); + + for (i = 0; i < num_buttons; i++) + map[i] = i; + + if (!InitButtonClassDeviceStruct(device, num_buttons, map)) { + xf86Msg(X_ERROR, "%s: Failed to register buttons.\n", pInfo->name); + ret = BadAlloc; + } + + xfree(map); + return ret; +} +"""]] +And here's the code to init a device hardcoded to two axes. And we're hardcoded to Relative mode too. +[[!format txt """ +static int +_random_init_axes(DeviceIntPtr device) +{ + InputInfoPtr pInfo = device->public.devicePrivate; + int i; + const int num_axes = 2; + + if (!InitValuatorClassDeviceStruct(device, + num_axes, + GetMotionHistory, + GetMotionHistorySize(), + 0)) + return BadAlloc; + + pInfo->dev->valuator->mode = Relative; + if (!InitAbsoluteClassDeviceStruct(device)) + return BadAlloc; + + for (i = 0; i < pRandom->axes; i++) { + xf86InitValuatorAxisStruct(device, i, -1, -1, 1, 1, 1); + xf86InitValuatorDefaults(device, i); + } + + return Success; +} + +"""]] +In general, a driver does not need to act in any way with pointer acceleration. The acceleration is initialized during [[InitValuatorClassDeviceStruct|InitValuatorClassDeviceStruct]], user settings on acceleration are loaded when a driver calls xf86InitValuatorDefaults. But of course it depends on what you want, and a small API is available, as described in [[Pointer acceleration|Development/Documentation/PointerAcceleration]]. + +Back to the device control. We continue with the switch statement. + +DEVICE_ON is the signal that we should open the device now and start sending events. + + +[[!format txt """ + /* Switch device on. Establish socket, start event delivery. */ + case DEVICE_ON: + xf86Msg(X_INFO, "%s: On.\n", pInfo->name); + if (device->public.on) + break; + + SYSCALL(pInfo->fd = open(pRandom->device, O_RDONLY | O_NONBLOCK)); + if (pInfo->fd < 0) + { + xf86Msg(X_ERROR, "%s: cannot open device.\n", pInfo->name); + return BadRequest; + } + + xf86FlushInput(pInfo->fd); + xf86AddEnabledDevice(pInfo); + device->public.on = TRUE; + break; +"""]] +xf86AddEnabledDevice() will add our device's fd to the list of SIGIO handlers. When a SIGIO occurs, our read_input will get called. And of course we need to mark the device as being switched on, so the server knows we're doing our work here. + +DEVICE_OFF should close the device, DEVICE_CLOSE free whatever is left.. +[[!format txt """ + case DEVICE_OFF: + xf86Msg(X_INFO, "%s: Off.\n", pInfo->name); + if (!device->public.on) + break; + xf86RemoveEnabledDevice(pInfo); + close(pInfo->fd); + pInfo->fd = -1; + device->public.on = FALSE; + break; + case DEVICE_CLOSE: + /* free what we have to free */ + break; + } + return Success; +} +"""]] +Note that a client can cause DEVICE_ON and DEVICE_OFF to be called repeatedly. DEVICE_CLOSE however signals that the device is to be removed now and will not be switched on again. + +Well, that's basically it. All we need to do now is read data and post events. + + +### Reading Input + +We know that our read_input will be called when data is available. So that's all we need to do now. + + +[[!format txt """ +static void RandomReadInput(InputInfoPtr pInfo) +{ + char data; + + while(xf86WaitForInput(pInfo->fd, 0) > 0) + { + read(pInfo->fd, &data, 1); + + xf86PostMotionEvent(pInfo->dev, + 0, /* is_absolute */ + 0, /* first_valuator */ + 1, /* num_valuators */ + data); + } +} +"""]] +So each time we get an interrupt, we read one byte of the device and pass it on as a motion event with an attached x value. The pointer will erratically move around on the x-axis (You may need to move your other mouse around, so /dev/random will generate enough data). + +Now of course you need to do error checking, or some more sophisticated event generation. The DDX interfaces for posting events are: xf86PostMotionEvent(); xf86PostButtonEvent(); xf86PostKeyboardEvent(); xf86PostProximityEvent(); xf86PostKeyEvent(); (for key events with attached valuator values) + +You can find them in the xf86Xinput.h. + +When you're posting an event, the server takes care of creating XInput events and puts all events onto the event queue. At a later point in time, the server will take them out and process them. If you're feeding too many events in too short time, the queue might overrun and events will get lost. This is generally not a problem with input drivers, unless the server is really really busy with drawing. Building a /dev/urandom driver may flood the server though. + + +### The Big Picture + +Let's recap. We have modules. Modules can provide multiple drivers, each with their own capabilities. We have drivers. Drivers reside in modules and are responsible for setting up and talking to devices. + +We have devices. Each device should be independent of each other, and they can have different read_input/device_control/etc. procs. The device's read_input will be called when data is available. The device's device_control will be called when the device is activated/deactivated etc. + +A device needs to post events to the DDX, and from then on it's the responsibility of the server to do the right job. + + +### Final words + +That's it. You should now understand how a driver works and be able to write your own. Good luck. diff --git a/Development/Documentation/XorgVideoHOWTO.mdwn b/Development/Documentation/XorgVideoHOWTO.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Development/Documentation/XorgVideoHOWTO.mdwn diff --git a/Development/Documentation/XserverSourceLayout.mdwn b/Development/Documentation/XserverSourceLayout.mdwn new file mode 100644 index 00000000..cd791984 --- /dev/null +++ b/Development/Documentation/XserverSourceLayout.mdwn @@ -0,0 +1,30 @@ + +# Moved from [[http://www.freedesktop.org/wiki/Software/Directories|http://www.freedesktop.org/wiki/Software/Directories]] + + + + +## Xserver Directory Layout + +_XXX: Add more directories, such as miext/ and the hw/kdrive/ subdirectories._ +[[!table header="no" class="mointable" data=""" + *Name* | *Explanation* + dix/ | The device independent parts of X, for example the code used for dispatching requests (see Dispatch() in dix/dispatch.c) and handling resources. main() is located in this directory in main.c. + doc/ | Less documentation than would be expected - contains the X server man page and an explanation of the scheduler. + fb/ | Code for doing graphical operations on framebuffer surfaces, for example blitting and compositing images. + hw/ | Hardware dependent code, driver APIs and configuration file operations. + hw/dmx/ | Distributed Multi-Head X code - well documented in hw/dmx/doc/html/index.html. + hw/kdrive/ | The [[kdrive server|http://en.wikipedia.org/wiki/KDrive]] and associated code. + hw/xfree86/ | Code associated with unix-like OSes, such as Linux or BSD. + hw/xquartz/ | Mac OS X specific code. + hw/xwin/ | Cygwin/X code, for running on Windows machines. + include/ | Xserver include files lie here. + mi/ | Machine independent code, used for things like high-level graphical operations. Makes calls down to the fb/ code through function pointers in screens, windows or gcs. + os/ | Operating system dependent code that does not control hardware, things like authentication, or processing arguments passed to the server (see Process``Command``Line() in util.c for example). + randr/ | Code for the [[RandR|Projects/XRandR]] extension. + render/ | Code for the Render extension. + Xext/ | Code for various extensions, for example Xinerama and Xv. + xtrans/ | Code for handling network connections. +"""]] + +-- Main.[[AndersCarlsson|AndersCarlsson]] - 23 Sep 2003 diff --git a/Development/Documentation/git.mdwn b/Development/Documentation/git.mdwn new file mode 100644 index 00000000..be9a7b8f --- /dev/null +++ b/Development/Documentation/git.mdwn @@ -0,0 +1,11 @@ + +General instructions on using git can be found on fd.o's [[Git pages|http://www.freedesktop.org/wiki/Infrastructure/git]]. + +For a quick getting started guide, there is the [[Everyday Git With 20 Commands Or So|http://www.kernel.org/pub/software/scm/git/docs/everyday.html]] guide from the Git homepage. For more in depth git documentation, see the resources on [[the Git community documentation page|http://git-scm.com/documentation]]. + +A quick [[guide|http://www.x.org/wiki/ModularDevelopersGuide#head-c108c1fd0be50c522e5dd12cf62814cd8d2f7234]] on how to get the complete xorg modular tree. + + +## Branches + +Instead of using a kernel-style personal repository model for long-lived branches, we favour actually using branches (e.g. mpx, input-hotplug, pci-rework, randr-1.2) within the repository. Ideally, these should not be created on a whim, as they will stick around forever once pushed. diff --git a/Development/HelpUs.mdwn b/Development/HelpUs.mdwn new file mode 100644 index 00000000..b77c475e --- /dev/null +++ b/Development/HelpUs.mdwn @@ -0,0 +1,12 @@ + + +## Projects + +* Janitor: + +## TODO + + +## DONE + +* Mesa: Make it possible to build libGLcore from Mesa, instead of having to symlink the source into the server.
\ No newline at end of file diff --git a/Development/InputOverhaul.mdwn b/Development/InputOverhaul.mdwn new file mode 100644 index 00000000..81f91c31 --- /dev/null +++ b/Development/InputOverhaul.mdwn @@ -0,0 +1,25 @@ + + +# Input Overhaul + + +## Why? + +Input is an unmitigated disaster. Aside from the horrific complexity of XKB, it's just a mess. We've already solved one problem (that of bad event generation) with input-hotplug, but we still have a number of fundamental problems. While attempting to make HAL work, it's become increasingly clear that we more or less need to start again. + + +## Now? + +XFree86 and KDrive have their own (bad) input systems, each dealing with options, the need to load an XKB keymap, a bad abstraction around deviceProc, input drivers, and so on, and so forth. [[DeviceIntRec|DeviceIntRec]] is strictly limited to a representation of which devices are in the DIX right now: everything in the DDX uses [[KdPointerInfo/KdKeyboardInfo/KdConfigPointer/KdConfigKeyboard|KdPointerInfo/KdKeyboardInfo/KdConfigPointer/KdConfigKeyboard]] (KDrive), or InputInfoRec/IDevRec (XFree86). These both hold the [[DeviceIntRec|DeviceIntRec]], and pass that to the DIX. + +KDrive's separation of input devices into separate pointers and keyboards is an immense loss. + + +## What? + +Move most of the (common to all implementations) initialization code down to the DIX. Extend [[DeviceIntRec|DeviceIntRec]] to include options, so we can get at these options from the DIX (two primary purposes: first, let HAL know which device is associated with UDI, and secondly, allow a generic property implementation that's better than the current ioctls). Get rid of deviceProc, and replace it with init/enable/disable/fini hooks, because we've never used deviceProc for anything else. + + +## Proposed API + +The proposed API is inspired by the current KDrive and XFree86 interfaces. diff --git a/Development/Janitor.mdwn b/Development/Janitor.mdwn new file mode 100644 index 00000000..06b4161b --- /dev/null +++ b/Development/Janitor.mdwn @@ -0,0 +1,28 @@ + +The aim of this sub-project is to clean up Xorg tree as much as possible in the same way as it is done by the Linux Kernel Janitor project. It is also a good start for newcomers to get more familiar with Xorg development. + + +## Tasks + +It may be good to first read [[Modular Developers guide|http://wiki.x.org/wiki/ModularDevelopersGuide]] in case you still don't have a manually built xorg tree at your disposal. Here is a small list of tasks anyone is encouraged to update : + +* Check for unaudited return codes. There are places where return values for functions like xalloc() & others are not checked. (example [[https://bugs.freedesktop.org/show_bug.cgi?id=12531|https://bugs.freedesktop.org/show_bug.cgi?id=12531]]) +* Code with old C function prototype definitions should be changed. Example : (taken from xcalc.c) + +[[!format txt """ + 114 int + 115 main(argc, argv) + 116 int argc; + 117 char **argv; +"""]] + * should be changed to + +[[!format txt """ + 114 int + 115 main(int argc, char **argv) +"""]] +But be careful when you do make changes that you don't change the types of arguments of functions called from other packages/programs/modules due to different rules applied the to the two types of prototypes - see [[http://invisible-island.net/ansification/index.html|http://invisible-island.net/ansification/index.html]] for more details. + +* Fix compiler warnings : There are many compiler warnings ranging from signedness problems to unused variables waiting to be fixed. It may be helpful to note that an unused variable is not necessarily for removal (as it may just be that a proper #ifdef is missing) - it is therefore wise to check the code, and ask for approval before removing a variable! Another good thing to fix is missing function prototypes. +* See : [[bugzilla Janitor list|http://tinyurl.com/38ws2l]] +* TODO add other tasks here :-)
\ No newline at end of file diff --git a/Development/MemoryUsage.mdwn b/Development/MemoryUsage.mdwn new file mode 100644 index 00000000..b4531cb1 --- /dev/null +++ b/Development/MemoryUsage.mdwn @@ -0,0 +1,54 @@ + +Misc memory-related optimization ideas. See also [[http://elinux.org/Decrease_X.org_XFree86_server_footprint|http://elinux.org/Decrease_X.org_XFree86_server_footprint]] + + +# Server-side optimizations + + +## Modularizing core protocol support + + +[[!format txt """ +00:00 < dottedmag> I had a look at Xfbdev binary - some kind of lazy loading for FbArc and FbPolyline + etc may significantly reduce the main binary size. Given nobody runs really old + applications on embedded stuff remnants of old stuff won't use memory and OTOH it + is still available if needed. +00:01 < dottedmag> Same for e.g. core text handling +00:02 < vignatti> interesting +00:02 < dottedmag> Should be easy to implement using the technique similar to the PLT/GOT tables, + given all requests are called through lookup table anyway. +00:02 < daniels> yeah, that would be neat, though note that if you never reference a page, it's not + going to get loaded +00:03 < daniels> (note also that moving stuff into shared libraries is counterproductive unless your + shared library is exactly aligned to page size) +"""]] + +# Client-side optimizations + + +## libxcb ("many DSO" problem) + + +[[!format txt """ +00:08 < dottedmag> daniels: I have been hit by this already: tons of xcb-util and libxcb libraries + use 300kB per app just for relocation tables. +00:09 < dottedmag> *per process +00:10 < ajax> the xcb libs should be one actual library and a bunch of ELF fitlers +00:11 < ajax> filters, even. +00:11 < ajax> first person to implement that wins a bottle of their whiskey of choice +00:11 < dottedmag> ajax: elf filters? wanna know/read! +00:11 < ajax> man ld, y0 +00:12 < ajax> there's two kinds, but the one i mean here is where the DSO is nothing but a list of + symbols and a reference to a library to source them from. +00:13 < ajax> which means you could have a libxcb-everything.so, and libxcb-randr.so would just + export the randr symbols from libxcb-everything.so +00:13 < ajax> so you only get the namespaces you want +00:13 < dottedmag> ajax: how much memory will the filter take? +00:13 < dottedmag> loaded +00:13 < ajax> but it only loads the DSO once +00:13 < ajax> dottedmag: not a lot? there's not much to it beyond the symbol list, i'd be surprised + if it was more than a page after loading. +00:14 < dottedmag> well, right. There aren't any C++ symbols, so the stuff should be pretty short. +00:14 < ajax> should almost certainly be less memory than the 3+ pages per DSO for each xcb extension + lib +"""]]
\ No newline at end of file diff --git a/Development/Security.mdwn b/Development/Security.mdwn new file mode 100644 index 00000000..35333abe --- /dev/null +++ b/Development/Security.mdwn @@ -0,0 +1,69 @@ + + +# Security Advisories + +This page details security issues that have been found in X.Org, and their remedies. + +Please contact [[xorg-security@lists.x.org]] to report security issues in the X.Org codebase. + + +## X.Org 7.7 + +* May 23, 2013 - Protocol handling issues in X Window System client libraries + * CVE-2013-1981..2005, CVE-2013-2062..2066: X client libraries can overflow buffers or corrupt memory in clients if servers send invalid replies +Please see [[the advisory|Development/Security/Advisory-2013-05-23]] for more information. + +* Apr 17, 2013 - vulnerability in VT-switch on Linux: + * CVE-2013-1940: Xservers receive input from hot-plugged devices when user has switched to another VT on Linux systems. The fix was included in [[xorg-server 1.13.4|http://lists.x.org/archives/xorg-announce/2013-April/002199.html]] and [[xorg-server 1.14.1|http://lists.x.org/archives/xorg-announce/2013-April/002200.html]]. Please see [[http://who-t.blogspot.com/2013/04/cve-2013-1940-vt-switched-servers.html|http://who-t.blogspot.com/2013/04/cve-2013-1940-vt-switched-servers.html]] for more information. + +## X.Org 7.6 + +* Jan 19, 2012 - vulnerability in default keyboard maps: + * CVE-2012-0064: It is possible to bypass a screen locking application when displayed on Xorg 1.11 or later by using the input grab killing keystrokes, which were enabled by default. The fix was included in [[xkeyboard-config 2.5|http://lists.x.org/archives/xorg-announce/2012-January/001797.html]] to not enable those key mappings unless requested. Please see [[http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html|http://who-t.blogspot.com/2012/01/xkb-breaking-grabs-cve-2012-0064.html]] for more information. +* Oct 18, 2011 - 2 vulnerabilities related to X server lock files: + * CVE-2011-4028: File disclosure vulnerability: It is possible to deduce if a file exists or not by exploiting the way that Xorg creates its lock files. + * CVE-2011-4029: File permission change vulnerability: It is possible for a non-root user to set the permissions for all users on any file or directory to 444, giving unwanted read access or causing denies of service (by removing execute permission). This is caused by a race between creating the lock file and setting its access modes. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2011-October/001744.html]] for more information. Patches are available: [[CVE-2011-4028|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6ba44b91e37622ef8c146d8f2ac92d708a18ed34]] [[CVE-2011-4029|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b67581cf825940fdf52bf2e0af4330e695d724a4]] Fixes are included in [[xserver 1.11.2RC2|http://lists.x.org/archives/xorg-announce/2011-October/001747.html]] and later. +* Aug 10, 2011 - CVE-2011-2895: A specially crafted LZW compressed font file may be used by a user who can connect to the X server to overflow a buffer in the X server, possibly leading to a local privilege escalation. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2011-August/001721.html]] for more information. Patch is available: [[CVE-2011-2895|http://cgit.freedesktop.org/xorg/lib/libXfont/commit/?id=d11ee5886e9d9ec610051a206b135a4cdc1e09a0]] Fix is included in [[libXfont 1.4.4|http://lists.freedesktop.org/archives/xorg-announce/2011-August/001722.html]] and later. +* Apr 5, 2011 - CVE-2011-0465: By crafting hostnames with shell escape characters, arbitrary commands can be executed in a root environment when a display manager reads in the resource database via xrdb. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2011-April/001636.html]] for more information. Patch is available: [[CVE-2011-0465|http://cgit.freedesktop.org/xorg/app/xrdb/patch/?id=1027d5df07398c1507fb1fe3a9981aa6b4bc3a56]] + +## X.Org 7.3 + +* Jun 11, 2008 - CVE-2008-1377, CVE-2008-1379, CVE-2008-2360, CVE-2008-2361, CVE-2008-2362: Several vulnerabilities have been found in the server-side code of some extensions in the X Window System. Improper validation of client-provided data can cause data corruption. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000578.html]] for more information. Patches are available: [[CVE-2008-1377|ftp://ftp.freedesktop.org/pub/xorg/X11R7.3/patches/xorg-xserver-1.4-cve-2008-1377.diff]] [[CVE-2008-1379|ftp://ftp.freedesktop.org/pub/xorg/X11R7.3/patches/xorg-xserver-1.4-cve-2008-1379.diff]] [[CVE-2008-2360|ftp://ftp.freedesktop.org/pub/xorg/X11R7.3/patches/xorg-xserver-1.4-cve-2008-2360.diff]] [[CVE-2008-2361|ftp://ftp.freedesktop.org/pub/xorg/X11R7.3/patches/xorg-xserver-1.4-cve-2008-2361.diff]] [[CVE-2008-2362|ftp://ftp.freedesktop.org/pub/xorg/X11R7.3/patches/xorg-xserver-1.4-cve-2008-2362.diff]] +* Jan 17, 2008 - CVE-2007-5760, CVE-2007-5958, CVE-2007-6427, CVE-2007-6428, CVE-2007-6429, CVE-2008-0006: Several vulnerabilities have been identified in server code of the X window system caused by lack of proper input validation on user controlled data in various parts of the software, causing various kinds of overflows. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2008-January/000441.html]] for more information. Patches are available for [[X11R7|X11R7]].2 [[libXfont 1.2.7|http://xorg.freedesktop.org/archive/X11R7.2/patches/xorg-libXfont-1.2.7-pcf-parser.diff]] and [[xserver 1.2|http://xorg.freedesktop.org/archive/X11R7.2/patches/xorg-xserver-1.2-multiple-overflows.diff]] as well as for [[X11R7|X11R7]].3: [[libXfont 1.3.1|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-libXfont-1.3.1-pcf-parser.diff]] and [[xserver 1.4|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-xserver-1.4-multiple-overflows.diff]]. +* **Update** Jan 21, 2008 - The patch for the MIT-SHM vulnerability (CVE-2007-6429) introduced a regression for applications that allocate pixmaps with a less than 8 bits depth. New patches are available for [[xserver 1.2|http://xorg.freedesktop.org/archive/X11R7.2/patches/xorg-xserver-1.2-multiple-overflows-v2.diff]] and [[xserver 1.4|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-xserver-1.4-multiple-overflows-v2.diff]]. MD5: 8e3f74c2cabddd3d629018924140e413 [[xorg-xserver-1.2-multiple-overflows-v2.diff|http://xorg.freedesktop.org/archive/X11R7.2/patches/xorg-xserver-1.2-multiple-overflows-v2.diff]] + SHA1: 38ad95d97e83861c309276a27296787e6d0d1b54 [[xorg-xserver-1.2-multiple-overflows-v2.diff|http://xorg.freedesktop.org/archive/X11R7.2/patches/xorg-xserver-1.2-multiple-overflows-v2.diff]] MD5: ded4bc31104aedada0155514a968b45f [[xorg-xserver-1.4-multiple-overflows-v2.diff|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-xserver-1.4-multiple-overflows-v2.diff]] + SHA1: af92fd389e72a3bb59d25dbf9cbb06e827b75d7d [[xorg-xserver-1.4-multiple-overflows-v2.diff|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-xserver-1.4-multiple-overflows-v2.diff]] +* Oct 2, 2007 - CVE-2007-4568: Multiple vulnerabilities in the X font server can lead to head corruption or overflow from a client. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2007-October/000416.html]] for more information. This is fixed in [[xfs 1.0.5|http://xorg.freedesktop.org/archive/individual/app/xfs-1.0.5.tar.bz2]]. A Patch is available for [[xfs 1.0.4|http://xorg.freedesktop.org/archive/X11R7.3/patches/xorg-xfs-1.0.4-query.diff]]. + +## X.Org 7.2 + +* April 3, 2007 - CVE-2007-1003 CVE-2007-1351 CVE-2007-1352 CVE-2007-1352: Lack of validation of parameters passed to the X server and libX11 by client application can lead to various kinds of integer overflows or stack overflows that can be used to overwrite data in the X server memory. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2007-April/000286.html]] for more information. Patches are available for [[7.2|http://xorg.freedesktop.org/archive/X11R7.2/patches]]. + +## X.Org 7.1 + +* January 9, 2007 - CVE-2006-6101 CVE-2006-6102 CVE-2006-6103: The ProcDbeGetVisualInfo(), ProcDbeSwapBuffer() and ProcRenderAddGlyphs() functions in the X server, implementing requests for the dbe and render extensions, may be used to overwrite data on the stack or in other parts of the X server's memory. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000235.html]] for more information. Patches are available for [[6.8.2|Releases/6.8.2]], [[6.9.0|Releases/6.9]], [[7.0|Releases/7.0]] and [[7.1|Releases/7.1]]. +* September 12, 2006 - It may be possible for a user with the ability to set the X server font path, by making it point to a malicious font, to cause arbitrary code execution or denial of service on the X server. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2006-September/000128.html]] for more information. Patches are available for [[6.8.2|Releases/6.8.2]], [[6.9.0|Releases/6.9]], [[7.0|Releases/7.0]] and [[7.1|Releases/7.1]]. + +## X.Org 6.9.0/7.0 + +* June 20, 2006 - A lack of checks for setuid() failures when invoked by a privileged process (e.g., X server, xdm, xterm, if installed setuid or setgid) may cause the process to execute certain privileged operations (file access) as root while it was intended to be executed with a less privileged effective user ID, on systems where setuid() called by root can fail. This can be used by a malicious local user to overwrite files and possibly elevate privileges in some corner cases. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2006-June/000100.html]] for more information. Patches are available for [[6.8.2|Releases/6.8.2]], [[6.9.0|Releases/6.9]], [[7.0|Releases/7.0]] and [[7.1|Releases/7.1]]. +* May 2, 2006 - A security vulnerability has been found in the X.Org server as shipped with X11R6.8.x, X11R6.9.0 and X11R7.0 (xorg-server 1.0.x) -- this is [[CVE-2006-1526|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1526]]. Clients authorized to connect to the X server are able to crash it and to execute malicious code within the X server. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg/2006-May/015136.html]] for more information. Patches are available for [[6.8.2|Releases/6.8.2]], [[6.9.0|Releases/6.9]] and [[7.0|Releases/7.0]]. +* March 20, 2006 - A security vulnerability has been found in the X.Org server as shipped with X11R6.9.0 and X11R7.0 (xorg-server 1.0.0 and 1.0.1) -- this is [[CVE-2006-0745|http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0745]]. Local users were able to escalate privileges to root and cause a DoS if the Xorg server was installed setuid root (the default). Note that earlier releases are not vulnerable. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg/2006-March/013858.html]] for more information. Patches are available for [[6.9.0|Releases/6.9]] and [[7.0|Releases/7.0]]. If you are running X11R7.0, you can upgrade xorg-server to 1.0.2 or later ([[release announcement|http://lists.freedesktop.org/archives/xorg/2006-March/013993.html]]). + +## X.Org 6.8.2 + +* September 12, 2005 - Due to missing range checks for the pixel size of the pixmap subsequent pixmap read/write functions can access memory outside of the allocated pixmap by any X client that can connect to the affected X server. This way any user having access to the server can access memory that is accessible from within the X server and/or crash the server. The CVE number for these vulnerabilities is [[CAN-2005-2495|http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2495]]. A patch against [[6.8.2|Releases/6.8.2]] is available. + +## X.Org 6.8.1 + +* November 17, 2004 - X.Org was made aware of additional security vulnerability in libXpm, the X Pixmap library, which is shipped as part of the X Window System. The affected library is used in many popular application for image viewing and manipulation. The Common Vulnerabilities and Exposures (CVE) project has assigned the name [[CAN-2004-0914|http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914]] to these issues. Patches are provided for [[6.8.0|Releases/6.8.0]] and [[6.8.1|Releases/6.8.1]]. The problem is fixed in 6.8.2 and later. + +## X.Org 6.8.0 + +* September 15, 2004 - A security vulnerability has been found in libXpm, the X pixmap library which is shipped as part of the X Window System. Please check [[here|http://ftp.x.org/pub/X11R6.8.0/patches/README.xorg-CAN-2004-0687-0688.patch]] for further information. This problem has been fixed in [[6.8.1|Releases/6.8.1]]. We also provide a patch for [[6.8.0|Releases/6.8.0]] and earlier. + +## X11R6.6 and older + +_This is not a complete listing of older security issues, just those discovered more recently_ + +* July 24, 2012 - CVE-2012-1699: A vulnerability has been found in the X11****R6 font server code in the handling of the Set****Event****Mask request in xfs which can lead to either denial of service or a leak of information from the xfs process address space. Please see [[the advisory|http://lists.freedesktop.org/archives/xorg-announce/2012-July/002040.html]] for more information. Patch is included in the advisory. Fix is included in XFree86 3.3.3 and later, and X.Org [[X11R6|X11R6]].7 and later.
\ No newline at end of file diff --git a/Development/Security/Organization.mdwn b/Development/Security/Organization.mdwn new file mode 100644 index 00000000..eaed2941 --- /dev/null +++ b/Development/Security/Organization.mdwn @@ -0,0 +1,20 @@ + + +# Organization of the X.Org security team + + +## How are security issues handled ? + +Generally, security issues are reported to xorg-security@. When CERT, iDefense or one of the other groups reports an issue, someone on the list takes the lead to co-ordinate it (this has typically been Matthieu). The usual procedure follows: agree on an unembargo date, try to get it fixed, etc, etc. + +In particular we work with the vendor-sec list to coordinate issues with various vendors whenever possible. + + +## Handling secrecy + +xorg-security@ is a private list, and security related problems can be marked as private in bugzilla. + + +## How are the fixes tested and by who (before made public)? + +In addition to tests that the people on the xorg_security list can perform, when we are able to share information with vendor-sec, we rely on tests done by vendors. Past experience has shown that they don't test things too much (they do read patches though). diff --git a/Development/X12.mdwn b/Development/X12.mdwn new file mode 100644 index 00000000..6f8c18c7 --- /dev/null +++ b/Development/X12.mdwn @@ -0,0 +1,294 @@ + + +# X12 + +[[!toc ]] + +X11 was defined in the middle of the 1980's. Since then, computers have changed _almost_ beyond recognition; the simple framebuffer model used by computers at the time has been replaced programmable graphics hardware that is both complex and powerful. Not only has graphics hardware changed, but the basic processing model has and continues to change; parallelism in core system design is becoming the norm, rather than a special case for 'large' systems. + +And that's just talking about desktop systems; now there are smart phones, netbooks, tablets and probably will shortly be other device types that this author can't imagine (else I'd be working on them...). + +In short, X11 was designed for a different era of computing. + + +## Requirements for the Successor to the X11 Protocol - "X12" + +This section is a discussion of the broad requirements for X12; discussion of the specific failings of X11 are addressed in later sections. + +To call this subject controversial would be an understatement; there have been and continue to be many attempts to either freeze 'X11' in time or discard it completely. Clearly, this author believes this to be wrong. + + +### What is Good about X11 + +Network transparency. Network transparency rocks! Run a program on a remote system and interact with it on your local terminal; write a program an not **need** to care whether it's going to be run on a full workstation or a dumb terminal. Some may say this is unimportant, but when one looks at the development of Windows and the evolution of RDP, it starts to look a lot more like X in terms of its features. + + +### A Rough List of Requirements + + +#### Security designed-in from the start + +Systems need to be secure. X12 needs to be designed with security in mind. + + +#### Multiple Platform Support + +X12 should be designed with mobile phones, tablets, dumb terminals, netbooks and desktop workstations in mind; if it is to succeed, it must work well on all these systems. + + +#### Maintain Network Transparency + +The future will be more interconnected and network-oriented, not less. Network transparency makes things easier for users and can't be considered an 'optional extra'. + + +#### Support Modern Graphics Hardware and Rendering + +Programmable hardware, composition; all that good stuff. X12 needs to naturally support modern hardware in a way that allows developers to gain access to the hardware without having to completely bypass X (as happens currently). + + +#### The Framebuffer is dead, Long Live the Framebuffer + +For all the talk of modern hardware, let's not forget that the framebuffer concept is still extremely useful in certain situations; killing it off completely is likely to be serious mistake. + + +#### Be as Efficient as Possible + +X has always been a low-level protocol; inefficiencies here will hurt applications. + + +#### Think Parallel + +This is perhaps the hardest part of the design of X12; the approach to computation and rendering is changing with a greater emphasis parallelism. X12 should be sympathetic to being implemented on massively-parallel systems, if not actively support such systems. + +On the other-hand, trying _too_ hard in this regard is likely to be serious cause of difficulties in finalising the design of the protocol; if in doubt, the designers should work to the standards of the day, rather than attempting to predict the future. + + +## Errors, Oversights and Omissions + +This section attempts to document the failings of the X protocol and rendering model. Learn from history, or be doomed to repeat it. + +This is not to say that there's an X12 project. There isn't. But if one day there is... + + +### Object model + + +#### Windows can not be zero-sized + + +#### Color maps are non-obvious + + +#### Grabs can block too much + +Popping up a menu and walking away can leave your screenlock unable to lock the screen since it won't be able to grab the pointer. + +Server grabs are even worse when they lock out all other clients including those necessary for user interaction like compositing managers and accessibility helpers. + +Current theory: Multiple clients can grab; when any grabs are active, only clients with grabs receive events. + + +#### Windows and Pixmaps aren't split correctly + +You can't resize a pixmap in the X11 protocol, because you can't get events on things that aren't windows. Lame. Really a Window should only be an IPC name, with one or more associated pixmaps and etc. + + +#### Fine grained events + +[[PropertyNotify|PropertyNotify]] is a disaster. And we probably want to be able to get events on things other than Windows. + + +#### Infeasible to change color depth with clients running + +Possibly not worth fixing. However, composited by default might make it reasonable. + + +### Rendering model + + +#### Composited by default + +Probably. Note that we can more or less accomplish this within X11, but there are probably simplifications to be had by making this explicit in the protocol. + + +#### No override-redirect + + +#### Core rendering is largely useless + + +#### Wide lines bite + + +#### BackgroundNone makes security geeks cry + +See [[EamonWalsh|EamonWalsh]]'s talk from [[XDevConf 2008|http://wiki.x.org/wiki/Events/XDC2008/Notes]]. + + +#### Borders are stupid + +Which is really a special case of... + + +#### Implicit rendering is stupid + +Borders and window backgrounds and the bg=None trick and backing store and saveunders and all that. + +There's a speed/complexity tradeoff here, of course. Any time that implicit server rendering works, it saves you exposures and round trips. But the implicit mechanisms we have are poor fits for a composited model. Think very carefully about adding implicit rendering to the server process; it's probably a mistake. + + +### Encoding bugs + + +#### Extension space is too small + +The first 128 requests are core protocol; the remaining 128 are single-entry multiplex functions for extensions. It's sort of ridiculous to have XPolyFillArc on the same footing as GLX. + +The minor opcode "convention" should be formalized and made part of the standard. The core protocol should be assigned major number zero and use minor numbers. + + +#### XIDs are too small + +XIDs are 29 bits for some inexplicable lisp-related reason. Client-side allocation seems like a reasonable idea for avoiding round-trips, but the need to slice the 29-bit space into client and resource parts means we have an unpleasant tradeoff. Right now most X servers have a 256 client limit, which is uncomfortably close. + +Should probably just bump this to uint32 for client ID and uint32 for resource ID. + + +#### Sequence numbers are too small + +It's pretty easy to hit 16-bit sequence number wrap without getting any responses from the server, which can make interpreting later events or errors impossible. Although perhaps it would be better to introduce a [[SequenceWrap|SequenceWrap]] event sent every 64k requests than to grow the sequence numbers. + + +#### 15 bit coordinate limit + +Ouch. 32768 pixels at 100dpi is 8.3 meters. + + +#### 64 bit, nanosecond-precision timestamps + +585 years ftw. The server time should be included in every event, reply, and error. It should also be present in every request (but with the "[[CurrentTime|CurrentTime]]" option available). + + +#### Cursor image encoding + +Cursors are encoded as rectangular bitmaps, so a full-screen crosshairs would be a bitmap 4 times the size of the screen. Allowing a more flexible format, such as SVG, would be good, as well as allowing smoother scaling for screen magnifiers. + + +#### ListFontsWithInfo-style requests with multiple replies + +Kill them or standardize them, preferably the former. Note that XCB-style asynchronous requests with replies make some uses of these less important. + + +#### The KeymapNotify event special-case should go away + +All events provide a sequence number, except for the [[KeymapNotify|KeymapNotify]] event which wants the space for more data. + + +#### XGE by default + +Events and errors are a fixed packet size to make parsing easy, but they aren't big enough to convey all the information you want. Some extensions like Xinput literally use every byte, and then some. The X Generic Events (XGE) extension adds a mechanism for larger events. + +XGE should become the default, rather than fixed-size events. + + +#### CHAR2B + +Kill this off. It's only used for core text, which should die. + + +#### Responses should assume less client state + +Replies, and probably errors, should include the major and minor opcode of the request that triggered them, to ease debugging. + + +#### Latin-1 (ISO 8859-1) + +Strings for Atom names and the like are required to be in Latin-1 encoding - should be replaced with UTF-8. + + +#### Length fields require constant conversion + +All requests and replies in X11 have a length field. This is cleverly encoded as number of 32-bit words, since all packets are padded to 32-bit alignment. This annoyingly results in tons of << 2 and >> 2 conversions everywhere to get into useful byte counts for reading & writing across the sockets. + + +### Input + + +#### Core input is useless + +Xi and (at least some elements of) XKB need to be folded in to the core protocol and made mandatory. + + +#### Resource limits + +We need more than 255 keycodes, and more than 4 groups. We also need a better mechanism for expressing state than the current field, which limits us to 5 buttons and 4 modifiers, or so. + + +#### Redirection should be integrated + +The current deep binding of input delivery to window coordinates is garbage. The redirection mesh idea is nice but it should be the only way. + + +#### Keysym names are a mess + +Come up with a vastly more coherent set of keysym names than the current scattergun approach. + + +### Design issues + + +#### Circulation APIs in core protocol are emacs disease + +These are wildly unhelpful. [[CirculateWindow|CirculateWindow]] and [[RotateProperties|RotateProperties]] can taste the curb. + + +#### Screens are not helpful + +(Screens is used in the protocol sense, with displays used in the physical output device sense.) + +This is part intractably large implementation problem (of not allowing resource sharing among screens, nor screen hotplugging), and part protocol problem (screens as defined are static, and there's no expressed relationships). Pushing most of RandR down will help this, as well as rewriting core code. + + +#### Events should always go to a window + +Events should have a fixed destination window field, to support the idea of events delivered to windows, not to clients directly. + + +#### Move stuff from the "random fixes" extensions into core + +Decide what from XC-Misc, MIT-SUNDRY, XFree86-Misc, and XFixes needs to go in core. + + +#### Don't split or duplicate a class of requests across core and extensions + +For instance, the core [[ForceScreenSaver|ForceScreenSaver]] and the MIT-SCREEN-SAVER extension. + + +#### Predefined atoms + +ICCCM gets special pre-defined atoms, but newer standards like EWMH don't. One approach would be to identify a set of predefined atoms by the hash of the names of the atoms, allowing extensibility in which atoms to predefine in the future. The connection setup response could include a list of the atom-sets this server provides, eliminating a round-trip at startup in the common case that all the atoms a client wants are already known. + + +#### Extension initialization + +With XCB we can, in principle, initialize all the extensions a client needs in two round-trips. But there aren't so many extensions in a server that we couldn't just provide the list in the connection setup reply. If that list included all the data that [[QueryExtension|QueryExtension]] returns, that would eliminate one round-trip. If we standardize that every extension has a major and minor version number, and include those in the setup data as well, we can eliminate the other round-trip. + + +### Race Conditions + + +#### Need a basic sync request + +Need a dedicated request that just sends back an empty reply. + + +#### Implement the ICCCM suggestions + +An appendix to the ICCCM lists mostly trivial improvements that would simplify the procedures set forth in that document. + + +## Reference material + +* [[Why X Is Not Our Ideal Window System|http://www.std.org/~msm/common/protocol.pdf]] +* [[Window System Design: If I had it to do over again in 2002|http://hack.org/mc/texts/gosling-wsd.pdf]] +etc. diff --git a/Development/Xv2.mdwn b/Development/Xv2.mdwn new file mode 100644 index 00000000..5d2b1531 --- /dev/null +++ b/Development/Xv2.mdwn @@ -0,0 +1,140 @@ + + +# Xv2 + +Xv2 is a hypothetical family of two updates to support video displaying that isn't Xv. + +* Render: Allow dest-only pictures, add YUV formats +* Randr: Add overlay objects beside CRTCs: enable, disable, property mangling, mandatory formats supported and acceptable CRTC mask properties, as well as a 'current backing Picture' property. +Drivers wrap Render context creation and set ShmPutImage/Composite to their former Xv paths. Port properties become Randr overlay properties. + + +## Rambling IRC braindump + +I should clean this up and summarise, but right now it's here for posterity. Also encompasses server development, future driver API, and future render API discussions. + + +[[!format txt """ +< ajax> exa is giving me vertigo +< daniels> maybe if we do fold the drivers into the server to start smashing up the api, people won't notice drm because it'll still be two steps. win. +* daniels draws for the epsom salts. +< ajax> i think i'm just going to smash the api and tell people to cope +< ajax> doing shatter well essentially requires breaking the ScreenRec +< daniels> ajax: i was thinking more along the lines of actually creating an api first. +< ajax> daniels: madness. +< daniels> as opposed to, y'know, what we have now. +< ajax> yeah we should have one of those, shouldn't we. +< daniels> if we say in advance that 7.6 + 2.0 are going to be this big break and that master may not always be buildable due to active development, then i think we can more than get away with it. +< ajax> i've been hoping to slowly morph towards having something sensible, but i might be losing patience +< daniels> ajax: right, but morphing from here to there essentially requires creating an api, no? +< ajax> daniels: evolving, but yeah. the advantage being that you don't have to hope you design it right up front +< ajax> which we are manifestly shit at +< ajax> HI MEMORY MANAGER HOW ARE YOU +< daniels> of course there are still renovations like the i2c api of shame, but most of it is going to be fbScreenInit + mangle masks + gamma init + picture init + randr init + create visuals list + OH GOD I DON'T CARE -> xorg_create_a_screen_for_the_love_of_god()) +< jcristau> which one? :) +< daniels> ajax: oh god no. it comes organically or it comes xkb. +< daniels> ajax: but i get the sense that a new api is mostly going to look like a new header file with a whole host of new functions which replace almost all the old functions (and then your mode + video + etc helpers) +< ajax> also, you're talking about driver api, and i'm talking about rendering api. they're related but not identical. +< daniels> yes, that also. that's not on my immediate hitlist though. +< daniels> what did you have in mind? +< daniels> (also, our input driver api is, surprisingly crap. need to fix that, and lift a raft of stuff into the dix.) +< daniels> InputDriverRec + IDrvRec + maybe DeviceIntRec if you're lucky -> OH GOD NOT THE FACE +< ajax> we still expose basically the whole gc/picture/xvctx to the driver. drivers shouldn't have to know about the protocol's semantics, we should be giving them a much smaller rendering task. +< daniels> \o/ +< daniels> exa isn't tooo bad in that sense though. +< ajax> it's better but still not good +< ajax> the Picture is a disaster of a struct +< daniels> i don't know if you know, but in x terms, that's called a celebration. +< ajax> the _one_ thing that the core rendering model got right is that the chalkboard is not the chalk +< daniels> the what isn't the what? +< ajax> the GC isn't the Drawable +< ajax> but in the Picture they're bound together +< daniels> yeah, they did get the model right there. +< daniels> heh. progress! +< daniels> hmm, i should fix up render-arg-reduction if we're breaking this api anyway, because seriously. +< daniels> gtkperf got something like 33% in some tests just from fb-internal arg reduction, not even the entire chain. +< ajax> render-argh-reduction +< daniels> (hi! my name is arm! please don't have 12 arguments for deeply-wrapped functions, because it makes me sad.) +< ajax> x86 doesn't like it either, for that matter +< ajax> we just hide it with l1 +< daniels> sure, but the overall performance penalty isn't so bad. +< daniels> right. +< daniels> plus a hojillion more cycles per second. +< ajax> so yeah. render and xv need proper contexts, and so does the Screen for getimage and possibly the implicit window rendering shit. +< ajax> which i'm considering tossing altogether and just forcing CompositeRedirectAutomatic +< ajax> (or equivalent semantics) +< ajax> i hate the window rendering rules so very hard +< daniels> meh, if you're doing that, just add YUV formats to Render and implement Xv as a wrapper for that. +< ajax> it's not clear how you keep the overlay fastpath for that +< daniels> plus, is there any reason _not_ to force automatic redirection? all the consumer-device kids are getting on compositing (including us), so that's the main argument gone ... +< ajax> depends how much memory pressure you're willing to accept, i guess +< daniels> ajax: overlay> how not? +< daniels> i guess you'd need a way to route to ports, but that gives us a one-extension xv. +< daniels> 'bind this render yuv texture to this overlay', which also lets you deassociate. that's grabport and stopvideo in one, and putimage is nothing if not composite dst. +< daniels> dberkholz: oh? +< dberkholz> on one hand, we're assuming people are running distros by defaulting to black +< daniels> s/one-extension/one-request/ +< daniels> okay, listports and port properties. blah blah i'm not listening anymore. +< daniels> or, wait. randr! aha. every gpu gets some overlays, which can have an acceptable crtc mask. so we punt the hard decisions to the client. win. +< daniels> ajax: anyway, so. render gets yuv picture support. randr gets overlays at the same level as crtcs, and behave like them (enable/disable/props), but also have acceptable crtc & format masks. you have one request to bind a picture to a port, and rendering is just composite. sound okay? +< ajax> what do you composite _to_? +< ajax> i guess have an internal picture type that means "overlay port"? +< daniels> well, you've given render a GC, so at context creation time, you set Composite to your overlay path if it's an overlay. +< ajax> heh. dest-only picture. yeah, that sounds plausible +< marcheu> the major difference between xv and yuv render is the semantics. and we need it to optimize the upload +< ajax> you just don't expose that picture type to clients through render +< daniels> you even get to use the general fb code, because dst with no mask is easy. if they want to alpha-blend on the client side, they can cop the slow path. +< ajax> marcheu: ShmPutImage not enough for you? +< ajax> daniels: i guess the one remaining bugbear is "magic encrypted content stream" as a picture format. but that should be fine, just looks like another format. +< daniels> marcheu: i don't see how it's a problem if you have shm and you get a say in ctx creation? if it's on an overlay, wrap ->ShmPutImage and ->Composite and set them to your fastpaths. +< daniels> ajax: PICT_BULLSHIT32 +< marcheu> ajax: getting the best performance is quite card-dependent +< daniels> ajax: specified as always passing through unmolested, and any attempt at manipulation fails. +< daniels> marcheu: ... and? +< daniels> marcheu: i just don't see how this is even remotely different from the Xv api. you could even make it look exactly the same if you wanted. +< marcheu> well then you have to keep the xv api, basically +< daniels> ... why? +< ajax> yeah, i was anticipating leaving Xv in place as the only thing allowed to create dest-only pictures +< marcheu> because if you keep the semantics, you might as well keep the api +< daniels> marcheu: you _can_ keep the semantics. +< ajax> (well, not the only thing, but as an api compat thing it'd be desirable to keep) +< daniels> ajax: i don't see how it's too much different from render, where you already have to pay attention to the format, with the exception of some Pictures being dest-only. i mean, the server implementation of Xv would surely be a tiny shim over render, so why do they have to be so different client-side? +< daniels> ajax: mm, you can do api compat forever by having libXv just call out to libXv2, though yeah, that doesn't solve this whole client<->server issue. +< ajax> i really can't break libXv +< ajax> though lord do i wish +< marcheu> daniels: I'm saying you have to basically keep the xv implementation driver-side anyway... +< daniels> sure, so that can just call out to the new code. nothing saying that libXv has to implement XVIDEO. +< marcheu> yeah, but that's duplication +< daniels> marcheu: true for overlays, but it probably means a lot _less_ duplication for textured video. +< ajax> daniels: there's a small "hard problem" around making sure the XV object types exist in the protocol somewhere and can be passed around between clients, just in case someone did that. +< daniels> ajax: hmm? +< ajax> daniels: it's legal to get an XvPortID from one process and use it in another and expect them to be numerically identical +< ajax> it's crack but it's an XID +< ajax> libXv backending onto this new Render hotness would need to manage that somehow. could be root window properties for all i care, but. +< daniels> atoms. +< daniels> do they share a space with xids? +< daniels> (i should know this.) +< ajax> not sure. doesn't really matter that they be legal XIDs, just that the opaque value mean the same thing in all clients. +< daniels> okay, atom of (int gpuid, int portid) +< ajax> also, as a sloth argument, it's easier to compat it in the server than both: compat on client, rewrite in server +< daniels> sure, but i'm talking new driver api + new render api, not when i'm bored next week. :) +< daniels> i mean, if your argument is that it's a crap api, sure, but if your argument's that someone needs to do it, then i'll do it because i've written an xv implementation and looked into that code. +< ajax> i'm happy to see xv backended on to render, sure. i just don't see a lot of value in moving xv api compat from the server to libXv. +< daniels> assuming that we care about the server codebase being both reasonably sized and mostly decrufted, slicing xv off can't be that bad an idea. +< daniels> and that bitrotting libraries is something no-one really cares about. +< ajax> i suppose i'm being paranoid about xv-on-the-wire mattering for someone +< ajax> but, like you said: xv compat in server would _not_ be a large chunk of code +< ajax> positing all the stuff mentioned above, it's like... thousand lines or so? most of which is protocol banging? +< daniels> sure. +< ajax> (also, anyone doing xv on the wire is already a bit barmy, seriously just do mpeg frames, it's less work for both sides) +< ajax> i buy the decrufting argument, and --disable-xv for server should still work, but unlike a lot of the other bullshit we've deleted we're starting to approach things that people actually use +< daniels> meh, anything other than YUV in requires dealing with the DSP in the X server, and no. +< daniels> ajax: yeah. +< daniels> ajax: consider me talked over. +< ajax> also when i say "on the wire" i mean "between different machines" +< ajax> if client and server are same machine, fix the damn player +< ajax> if they're not the same machine, you're using more bandwidth than you ought to be +< ajax> hopefully in N years everyone will be using gstreamer and we can fix the bottom layer of it at will +< ajax> right, so this sounds like a plan then. +< daniels> indeed. +"""]]
\ No newline at end of file diff --git a/Development/git.mdwn b/Development/git.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Development/git.mdwn diff --git a/DisplayPort.mdwn b/DisplayPort.mdwn new file mode 100644 index 00000000..45c2469b --- /dev/null +++ b/DisplayPort.mdwn @@ -0,0 +1,37 @@ + + +## DisplayPort + +DisplayPort is a new digital output format. It has support for higher resolutions than DVI, a connector that doesn't fall out all the time like HDMI, backwards compatibility with DVI and (in principle) VGA, better power management, daisy-chained displays, partial screen updates, cheaper transcievers, and probably more things the author is forgetting. + +Support for DP in open drivers is a work in progress. This page attempts to document the current status. + +For all drivers, the ability to drive a DisplayPort sink (monitor) using a DVI source is entirely a function of the feature set of the sink. No amount of change to the driver is going to make this work for you if it doesn't already. + + +### ATI + +Prior to DCE 3.0 (RV620, RV635, RS780), the GPU does not have DisplayPort connectivity natively, only over DVO. This does not work at all yet. + +For DCE 3.0 (RV620, RV635, RS780) and later chips (RV710, RV730, RV770, etc.) using the UNIPHY transmitters, DisplayPort sources can drive DVI sinks using the radeon driver. Native DisplayPort connections work with xf86-video-ati from git master and with KMS. + + +### Intel + +The G40-series chips and later have native DisplayPort support. There is a [[branch|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=display-port]] of the intel driver that attempts DP setup. It's not clear whether this branch supports DP->DVI connections, but it certainly doesn't support DP->DP connections yet. + +Prior to G40, DP support would be theoretically possible over SDVO. So far, no DP SDVO devices have been seen in the wild. + + +### NVIDIA + +On G98, DP->DVI connections work out of the box with the nouveau driver. The nv driver has not been tested yet. + +It's not clear that any earlier chips support DP. + + +### Other + +S3 makes a DisplayPort card, but there's no open driver for it at all. + +No other vendors (VIA, Matrox, etc) are known to make a DisplayPort product at this time. diff --git a/DistroFAQList.mdwn b/DistroFAQList.mdwn new file mode 100644 index 00000000..c5db573a --- /dev/null +++ b/DistroFAQList.mdwn @@ -0,0 +1,33 @@ + + +# Links to Support provided by Distribution Vendors + + +## Mailing Lists / Forums + + * [[Debian's X Mailing list|http://lists.debian.org/debian-x/]] + * [[The Ubuntu Forum Community|http://ubuntuforums.org/]] and [[Ubuntu Mailing Lists|http://www.ubuntu.com/support/community/mailinglists]] + * FreeBSD's X Mailing List: [[Subscription|http://lists.freebsd.org/mailman/listinfo/freebsd-x11]] [[Archive|http://lists.freebsd.org/pipermail/freebsd-x11/]] + * [[Gentoo's Mailing Lists|http://www.gentoo.org/main/en/lists.xml]] + * [[Mandrake's Mailing Lists|http://www.linux-mandrake.com/en/flists.php3]] + * [[OpenBSD's Mailing Lists|http://www.openbsd.org/mail.html]] + * [[OpenSolaris X Mailing List|http://mail.opensolaris.org/mailman/listinfo/xwin-discuss]] + * [[Red Hat's X Mailing list|http://www.redhat.com/mailing-lists/xfree86-list/index.html]] + * [[SuSE's X Mailing List|http://lists.suse.com/archive/opensuse-xorg/]] + +## Documentation + + * [[Debian Documentation|http://www.debian.org/doc/]] + * [[FreeBSD X Server Configuration|http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x11.html]] + * [[Gentoo X Server Configuration HOWTO|http://www.gentoo.org/doc/en/xorg-config.xml]] + * [[Mandrake Documentation|http://www.linux-mandrake.com/en/fdoc.php3]] + * [[Ubuntu X Configuration|https://wiki.ubuntu.com/X/Config]] and [[Ubuntu Video Documentation|https://help.ubuntu.com/community/Video]] + +## Other + + * [[Debian X Strike Force|http://wiki.debian.org/XStrikeForce]] + * [[Gentoo X11 Herd|http://www.gentoo.org/proj/en/desktop/x/x11/]] + * [[KNOPPIX English Language Mailing Lists/Documentation|http://www.knoppix.net/]] + * [[OpenSolaris X Window System community page|http://opensolaris.org/os/community/x_win/]] + * [[Red Hat's Support Page|http://www.redhat.com/apps/support/]] + * [[Ubuntu X team|https://wiki.ubuntu.com/X]]
\ No newline at end of file diff --git a/Documentation.mdwn b/Documentation.mdwn new file mode 100644 index 00000000..539dc176 --- /dev/null +++ b/Documentation.mdwn @@ -0,0 +1,17 @@ + + +# Running X + +[[User documentation|UserDocumentation]] contains documentation for running the X server and basic X clients, as well as protocol specifications and basic client programming documentation. + + +# Developing X applications + +Rather than develop directly for X, we recommend you use a toolkit such as [[GTK+|http://www.gtk.org/documentation.php]] or [[Qt|http://doc.qt.nokia.com/latest/]]. There are many other popular toolkits, some special-purpose, such as [[Clutter|http://www.clutter-project.org]] and [[Enlightenment/EFL|http://www.enlightenment.org]]. + +For low-level X development, [[XCB|http://xcb.freedesktop.org/tutorial/]], the X C Bindings provide a clean low-level protocol binding. Its older cousin Xlib (or libX11), is not recommended for new development, but is still very widely used. Xt is a similarly deprecated library for building toolkits. [[Documentation for Xlib and Xt|ProgrammingDocumentation]] is available. + + +# Downloading, running, and developing X.Org code + +The [[development documentation|Development]] describes how to download and build the X.Org code (including the X server and drivers), and rough notes on their internals. diff --git a/DodjiSeketeli.mdwn b/DodjiSeketeli.mdwn new file mode 100644 index 00000000..23b79300 --- /dev/null +++ b/DodjiSeketeli.mdwn @@ -0,0 +1,13 @@ + + +## Dodji Seketeli + +[[http://www.seketeli.org/dodji|http://www.seketeli.org/dodji]] + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/EgbertEich.mdwn b/EgbertEich.mdwn new file mode 100644 index 00000000..4417d6ca --- /dev/null +++ b/EgbertEich.mdwn @@ -0,0 +1,39 @@ + + +## Egbert Eich + +Email: eich AT SPAMFREE freedesktop DOT org + + +### X.Org Board Elections + +I've been involved in the development of the X Window System since 1995. + I helped bootstrapping the X.Org Foundation. In the past two years I served on the Board of Directors of the X.Org Foundation. There I helped to ensure that the Boards focuses as an overseer on organizational issues and abstained from undue involvement in technical matters. + I was involved in drafting in our new By-Laws and Membership Agreement and I drafted the 2006 budget. + +My strong focus rests in development. As a Board Member I see my most important duty to support our community of contributors and bring its issues to the attention of the Board. + +A number of issues need to be addressed urgently: + +1. Create a Membership Committee to promptly deal with reviewing and accepting Membership applications thru an open process. +1. Establish a sponsorship program + This involves identifying funding opportunities and budget for them: + * Event Funding + * Set up travel fund program for X related events and coordinate with event organizers. + * Individual funding + * Set up Budget and policies to sponsor travel for X-related presentations + * Budget for and develop polices for sponsorship of individual contributors to attend meetings relavant to their area of contribution. + * Marketing + * Determine if and in which marketing activeties X.Org should be involved in and what their goals and intended target audiences are. From this develop a policy to fund such events. +1. Put X.Org server infrastructure fully in place: + 1. Installation of the donated machines from SUN. + 1. Identify services that can be shared with freedesktop.org. + 1. Establish a backup and mirroring system for the freedesktop.org infrastructure. + 1. Make sure that the administrational workload can be dealt with effectivly. + + +--- + + + +* [[CategoryHomepage|CategoryHomepage]]
\ No newline at end of file diff --git a/EricJeong.mdwn b/EricJeong.mdwn new file mode 100644 index 00000000..5369dbf0 --- /dev/null +++ b/EricJeong.mdwn @@ -0,0 +1,14 @@ + +Eric Jeong + +Email: babyimp AT gmail DOT com + +X on mobile + + + +--- + + + +* [[CategoryHomepage|CategoryHomepage]]
\ No newline at end of file diff --git a/Events.mdwn b/Events.mdwn new file mode 100644 index 00000000..94811993 --- /dev/null +++ b/Events.mdwn @@ -0,0 +1,21 @@ + + +## Upcoming Events + +* [[linux.conf.au 2013|http://lca2013.linux.org.au/]], Canberra, Australia, January 28 through February 2, 2013 +* [[FOSDEM 2013|fosdem2013]], Brussels, Belgium, February 2 through 3, 2013 +* X.Org Developer's Conference: XDC2013 - TBD (Portland?) + +## Recent Events + +* [[X.Org Developer's Conference: XDC2012|Events/XDC2012]], Nuremberg, Germany, September 19 through 21, 2012 +* [[Book Sprint 2012|Events/BookSprint2012]], Nuremberg, Germany, September 17 and 18, 2012 +* [[GUADEC 2012|http://www.guadec.org/]], A Coruña, Spain, July 26 through August 1, 2012 +* [[FOSDEM 2012|fosdem2012]], Brussels, Belgium, February 4 through 5, 2012 + * [[X/Graphics Dev Room Call for Participation|http://lists.x.org/archives/xorg-devel/2011-September/025000.html]], [[Followup|http://lists.x.org/archives/xorg-devel/2011-October/025953.html]] + * [[X.Org/Wayland/OpenICC Dev Room schedule|http://fosdem.org/2012/schedule/track/xorgopenicc_devroom]] +* [[linux.conf.au 2012|http://lca2012.linux.org.au/]], Ballarat, Australia, January 16 through 20, 2012 + +## Older Events + +* Events more than a year old are [[archived|Events/History]].
\ No newline at end of file diff --git a/Events/BookSprint2012.mdwn b/Events/BookSprint2012.mdwn new file mode 100644 index 00000000..f89d7067 --- /dev/null +++ b/Events/BookSprint2012.mdwn @@ -0,0 +1,28 @@ + +**Summary**: In order to help with documentation and guides for developers, both existing and new, we will have a book sprint the two days prior to [[XDC2012|Events/XDC2012]]. + +**When**: Monday Sept 17 & Tuesday Sept 18. Opening hours will be early in the morning (TBD, 8am?) until we call it a day (but certainly no longer than 10pm). + +**Where**: [[Keßlerstraße 1|http://maps.google.de/maps?f=q&source=s_q&hl=de&authuser=0&q=Keßlerstraße+1,+90409+Nürnberg,+Bayern&aq=&vps=1&jsv=402e&sll=51.151786,10.415039&sspn=14.100269,34.936523&vpsrc=1&ie=UTF8&oi=georefine&ct=clnk&cd=2&geocode=FT2y8gIdqRupAA&split=0]]. Room 4020 (4th floor, which would be 5th floor in American way of counting), a small part of the Georg-Simon-Ohm-University, in the old "[[Postbank|http://www.postbank.com/]]". It's the building at the corner, the yellow "Postbank" sign is still widely visible. In approximately the middle of the same building there is another "Postbank", with the same sign, that is the new (wrong) one. + +**What**: Driver Developers Guide (tentative) + +**Who**: The X Book Posse + +**Details**: + +Marcheu has a very nice start on a Guide. This sprint will be to review and fill in anything missing. + +Current Guide: [[http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf|http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf]] + +git: [[http://cgit.freedesktop.org/~marcheu/lgd/|http://cgit.freedesktop.org/~marcheu/lgd/]] +[[!table header="no" class="mointable" data=""" +**Proposed Schedule (_**very_** rough storyboard. It's at least something):**|| +Mon 9am-noon | Review existing Guide and create TODO list (identify holes and what needs polish) +Mon noon~1pm | lunch +Mon 1pm-5pm | Fill in any holes +Tues 9am-noon | Begin polish +Tues noon-1pm | lunch +Tues 1pm-5pm | finish polish +Tues 5pm-? | beer +"""]] diff --git a/Events/History.mdwn b/Events/History.mdwn new file mode 100644 index 00000000..3a7b2196 --- /dev/null +++ b/Events/History.mdwn @@ -0,0 +1,64 @@ + +A collection of older events that X.Org has held, presented at, or had significant presence at. Move things here from the [[current events page|Events]] when they get too old, and if possible, link to what we did there. + + +### 2011 + +* [[X.Org Developers' Conference (XDC2011)|Events/XDC2011]]. Chicago, USA, September 12 through 14, 2011. +* [[Linux Plumbers Conf 2011|http://www.linuxplumbersconf.org/2011/]], Santa Rosa, California, USA, September 7 through 9, 2011 +* [[GNOME/KDE Desktop Summit|http://www.desktopsummit.org/]], Berlin, Germany, August 6 through 12, 2011 +* [[linux.conf.au 2011|http://lca2011.linux.org.au/]], Brisbane, Australia, January 24 through 29, 2011 + +### 2010 + +* [[Linux Plumber's Conference|http://events.linuxfoundation.org/events]], Cambridge, Massachusetts, USA, November 3 through 5, 2010 +* [[X.Org Developers' Summit (XDS2010)|Events/XDS2010]]. Toulouse, France, September 16 through 18, 2010. +* [[GUADEC 2010|http://www.guadec.org/index.php/guadec/2010]], The Hague, The Netherlands, July 24 through 30, 2010 +* [[Akademy 2010|http://akademy.kde.org/]], Tampere, Finland, July 3 through 10, 2010 +* [[FOSDEM 2010|fosdem2010]], Brussels, Belgium, February 6 and 7, 2010 +* [[linux.conf.au 2010|http://www.lca2010.org.nz/]], Wellington, New Zealand, January 18 through 23, 2010 + +### 2009 + +* [[VideoHackfest|http://gstreamer.freedesktop.org/wiki/VideoHackfest]], Barcelona, Spain, November 19th through 22nd, 2009 +* [[X.Org Developers' Conference 2009|Events/XDC2009]], Portland, Oregon, USA, September 28 through 30 +* [[Linux Plumber's Conference|http://linuxplumbersconf.org/2009/]]: [[X Window System track|http://linuxplumbersconf.org/ocw/events/2009/tracks/3]], Portland, Oregon, USA, September 23 through 25 +* [[Gran Canaria Desktop Summit: GUADEC & Akademy 2009|http://www.grancanariadesktopsummit.org/]], Las Palmas, Gran Canaria, July 3 through 11, 2009 +* [[FOSDEM 2009|fosdem2009]], Brussels, Belgium, February 5 through 8, 2009 +* [[linux.conf.au|http://linux.conf.au/]], Hobart, Tasmania, January 19 through 24, 2009 + +### 2008 + +* [[Gnome Boston Summit|http://live.gnome.org/Boston2008]], Cambridge, Massachusetts, October 10 through 13. +* [[X.Org Developers' Summit 2008|Events/XDS2008]], Edinburgh, Scotland, September 3 through 5. +* [[GUADEC 2008|http://2008.guadec.org/]], Istanbul, Turkey, July 7th through 12 +* [[X.Org Developers' Conference 2008|Events/XDC2008]], Mountain View, California, April 16 through 18. +* [[xorg@fosdem 2008|fosdem2008]], February 23 - 24. Brussels, Belgium. +* [[linux.conf.au|http://linux.conf.au/]], Melbourne, Australia, Jan 28 - Feb 2 + +### 2007 + +* [[Gnome Summit|http://live.gnome.org/BostonSummit]], Cambridge, Massachusetts, October 6 through 8. +* [[X.Org Developers' Summit 2007|Events/XDS2007]], Cambridge, England, September 10 through 12. +* [[GUADEC 2007|http://2007.guadec.org/]], Birmingham, England, July 15 through 21. +* [[xorg@fosdem 2007|fosdem2007]], February 24-25. Brussels, Belgium. +* [[Xorg Developer's Conference 2007|Events/XDC2007]] was held on February 7, 8, and 9 in the San Francisco Bay Area. See [[XDC2007Notes|XDC2007Notes]] for the talk transcript. + +## 2006 + +* An X.Org BOF was held at [[SIGGRAPH 2006|http://www.siggraph.org/s2006/index.php]] (August 1 through 3, 2006) in Boston. +* The [[Desktop Developers' Conference|http://lanyrd.com/2006/desktop-developers-conference/]] was held July 17 and 18, 2006, in Ottawa prior to OLS 2006. +* X.Org presented at [[LinuxTag|LinuxTag]] 2006 in Wiesbaden, Germany May 3 - 6 2006. +* X.Org had an [[X Developers HotHouse and X DevRoom|fosdem2006]] on February 24-26 at FOSDEM 2006 in Brussels, Belgium. +* [[X Developers' Conference 2006|Events/XDC2006]] was held on February 8-10 2006 at the Sun Microsystems campus in Santa Clara, CA. + +## 2005 + +* [[Desktop Developers' Conference|http://lanyrd.com/2005/desktop-developers-conference/]], July 18 and 19, 2005, Ottawa, prior to OLS 2005. +* X.Org had its first European Developers meeting in Karlsruhe, Germany from June, 19 to June, 20, right before [[LinuxTag 2005|http://www.linuxtag.org]]. (Read more at [[LinuxTagMeeting2005|LinuxTagMeeting2005]]) +* [[X Developers' Conference 2005|Events/XDC2005]], February 12 through 14, in Cambridge, Massachusetts. + +## 2004 + +* [[Desktop Developers' Conference|http://lanyrd.com/2004/desktop-developers-conference/]], July 19 and 20, 2004, Ottawa, prior to OLS 2004. +* The first X Developers' Conference (well, first for the X.Org Foundation) was April 28 through 30, 2004 in Cambridge, Massachusetts.
\ No newline at end of file diff --git a/Events/XDC2005.mdwn b/Events/XDC2005.mdwn new file mode 100644 index 00000000..9b06f0e0 --- /dev/null +++ b/Events/XDC2005.mdwn @@ -0,0 +1,143 @@ + + +## X Developer's Meeting 2005 +[[!table header="no" class="mointable" data=""" + **XDC 2005** | [[XDC 2006 >>|Events/XDC2006]] +"""]] + +We have scheduled a three day X Developer's meeting from Saturday, February 12, through Monday, February 14, at the Cambridge Research Laboratory (CRL) in Cambridge, Massachusetts. + +**** The meeting is now full!!! *** + +This meeting is intended to cover a wide variety of topics about X Window System technologies, and the as yet unmet needs of the technologies that depend on the X Window System. As a result, this meeting is intended for people working across the entire X Window System stack, including toolkits and window managers and desktop infrastructure. This meeting is not, however, intended to cover general X application development topics or concepts. + +There will be a number of people giving presentations or leading discussions. These presentations will likely consume no more than half of the overall meeting time so the remaining time can be spent with informal discussions, hacking, breakout sessions, etc. + +If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well. + + +### Attend via Phone + +The phone bridge is not working. See below for Audio streaming. + + +### Attend via IRC + +IRC: freenode, #xdevconf + + +### Attend via Audio/Video feeds + +X developer's meeting audio and video feeds: + +* Audio: Point gnomemeeting at gabe.freedesktop.org. First, go into Audio Codecs and disable everything but G.711-uLaw and G.711-ALaw; needs a bit more bandwidth but means you can actually hear what people are saying. +* Vide:o Depending on your browser click on [[http://freedesktop.org:9192/|http://freedesktop.org:9192/]] or [[http://freedesktop.org/~keithp/webcam.html|http://freedesktop.org/~keithp/webcam.html]]. +Will video presentations be available somewhere? Are them recorded? + + +### Presentation Agenda + +Current presentations for the X Developer's Meeting include: + + +#### 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 + * DND, Other Specification Issues - Owen Taylor and George Staikos + * xrestop, xephyr, and X on handhelds - Mathew Allum ([[slides|http://www.o-hand.com/xmeet/]], [[demo|http://projects.o-hand.com/matchbox/demos.html]]) + * Testing Strategies - Stuart Anderson, Free Standards Group and X.org + * Short Topics - All + +#### Sunday, February 13 + +* Starting at 9:00 + * X Proxy and Multicast Demo - David Flynn, Realm Systems +* A Unified View of Improving X Desktop Rendering - The Owen Taylor, Søren Sandmann, Kristian Høgsberg and Diana Fong show + * Cairo Status - Carl Worth, Red Hat (Slides: [[SVG|http://cairographics.org/talks/xdevconf_2005_02_13/svg]], [[HTML|http://cairographics.org/talks/xdevconf_2005_02_13/html]] [[PDF|http://cairographics.org/talks/xdevconf_2005_02_13/cairo.pdf]]) + * X Input Redirection - Deron Johnson, Keith Packard ([[Intro & Slides|http://lists.freedesktop.org/archives/xevie/2005-February/000039.html]]) + * A New Input System - Kristian Hogsberg, Jim Gettys + * Polling And Scheduling in the X Main Loop - Kristian Høgsberg, Red Hat + * Reworking the X server main loop, with proposed changes. + * X and Media Support - Leon Shiman + * 3D Graphics Pipelines - Nick Triantos, NVidia + +#### Monday, February 14 + +* Starting at 9:00 + * Open Source Legal discussion, Patents and Copyrights - Scott Peterson, Greg Jones, Linda Hamel, General Counsel, MA ITD (Information Technology Division) + * X on GL - David Reveman, Novell + * Mesa Solo - Jon Smirl + * Merging fbdev and DRM - Jon Smirl + * X.org Update - Audience +Please all the people leave your presentations here so other people can see them. + + +### Limited In-Person Attendance + +Due to space limitations, attendance will be limited to no more than 40 people, and we are almost full. If you would like to attend, please send mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. Having the names of attendees in advance eases building security, as we share the building with other companies. + +An audio feed will be made available for those attending remotely or unable to attend due to limitations on space. The meeting venue provides networking support with high speed Internet access. + +The hotels recommended near CRL are The Kendall Hotel, the Cambridge Marriott, and the Residence Inn. All three of these are a short walk from CRL and easily accessible via public transportation from the Kendall Square subway stop next to MIT. We have not negotiated any special rates with these hotels, so you'll need to shop around for the best rates, as they vary. A longer list of hotels is available at [[http://www.ai.mit.edu/visiting/hotels/hotels.shtml|http://www.ai.mit.edu/visiting/hotels/hotels.shtml]] . Directions to the lab can be found at: [[http://www.crl.hpl.hp.com/who/lab/directions.htm|http://www.crl.hpl.hp.com/who/lab/directions.htm]] + + +### Currently Registered Attendees + +Currently registered attendees include: + + 1. Bill Abt + 1. Matthew Allum + 1. Paul Anderson + 1. Stuart Anderson + 1. Scott Balneves + 1. David Boloker + 1. Phil Blundell + 1. Mirko Boehm + 1. Alan Coopersmith + 1. Egbert Eich + 1. Mike Emmel + 1. David Flynn + 1. Nat Friedman + 1. Diana Fong + 1. Bdale Garbee + 1. Jim Gettys + 1. Jim Glutting + 1. Linda Hamel + 1. Mike A. Harris + 1. Kristian Høgsberg + 1. Mattias Hopf + 1. Harold Hunt + 1. Miguel de Icaza + 1. Lars Knoll + 1. Tommi Komulainen + 1. Adam Jackson + 1. Deron Johnson + 1. Eric Kunze + 1. Stewart Kreitman + 1. Paul Litvak + 1. Chris Lee + 1. Lubos Lunak + 1. Duncan Mak + 1. Kevin Martin + 1. Jim [[McQuillan|McQuillan]] + 1. Nhan Nguyen + 1. Keith Packard + 1. Tapani Pälli + 1. Havoc Pennington + 1. Larry Rau + 1. David Reveman + 1. Andy Ritger + 1. Robin Rowe + 1. Zack Rusin + 1. George Staikos + 1. Søren Sandmann + 1. Leon Shiman + 1. Owen Taylor + 1. Nick Triantos + 1. Peter Winston + 1. Carl Worth + 1. Scott Peterson + 1. Greg Jones +-- [[JimGettys|JimGettys]] - Feb. 13, 2005 diff --git a/Events/XDC2006.mdwn b/Events/XDC2006.mdwn new file mode 100644 index 00000000..128568ff --- /dev/null +++ b/Events/XDC2006.mdwn @@ -0,0 +1,132 @@ + + +# X Developers Conference 2006 +[[!table header="no" class="mointable" data=""" + [[<< XDC 2005|Events/XDC2005]] | **XDC 2006** | [[XDC 2007 >>|Events/XDC2007]] +"""]] + + +### Overview + +As a followon to previous conferences, we invite presentations on all topics related to the development and furtherance of X Window System technologies. + +If you wish to volunteer to give a presentation or lead a discussion, please send e-mail to [[xdevconf@lists.freedesktop.org|mailto:xdevconf@lists.freedesktop.org]]. In addition, if you have specific topics you'd like to see discussed in a presentation or during informal sessions, please send e-mail with your suggestions to that address as well. + + +### Location and Dates + +The next X.Org Developer's Conference will be held from February 8, 2006 to February 10, 2006 at the [[Sun Microsystems Santa Clara (Agnews) Campus|http://www.cr.nps.gov/nr/travel/santaclara/agn.htm]] in Santa Clara, CA, USA. ([[Driving Directions|http://www.sun.com/aboutsun/media/presskits/directions.html#sc]]) + + +#### Building Change + +Same Sun Santa Clara Campus, but we have acquired a room inside the Fortress. The Building Name is SCA15, room "HARVARD" on the first floor. This building is accessed from the North``East side of the campus, a short, direct walk from the River``Mark Plaza shopping area/Sierra Suites area. + +([[Google Map of the Sun Campus, Centered on SCA15|http://maps.google.com/?t=k&ll=37.394948,-121.952373&spn=0.003077,0.005456&t=k]]) + +We have an attended lobby with badges for everyone listed on this Wiki page. If you do not see your name here, let me know ASAP or you will not gain admittance to the conference. + + +### Registration + +REGISTRATION IS CLOSED + +Simple: Send email to [[stuart.kreitman@sun.com|mailto:stuart.kreitman@sun.com]] + + +### Conference Notes + +Notes from the presentations are being maintained by Adam Jackson ([[Presentation Notes|http://people.freedesktop.org/~ajax/xdc2006-notes.txt]]). (thanks, Adam! skk) + + +### Conference Schedule + + +#### Wednesday, February 8, 2006 + + * 8:00 AM Room Open, Get Togethers, Continental Breakfast 9:00 AM Real Start: Welcome, logistics, agenda, schedule bashing 9:30 AM Board of Directors Introductions + * 10:00 AM "Xgl" - David Reveman, Novell ([[Slides|http://www.freedesktop.org/~davidr/xdevconf06/]]) 11:00 AM "Avalon" - Matthias Hopf 12:00 AM Lunch 1:00 PM "Status Update on Project Looking Glass" - Deron Johnson, Sun 1:30 PM "Coordinate Redirection" - Keith Packard 2:00 PM "NVIDIA Driver Internals" - Andy Ritger, Nvidia ([[Slides|http://developer.nvidia.com/object/xdevconf_2006_presentations.html]]) 3:00 PM "Development Challenges for X and GL" - Kevin Martin, Red Hat ([[Slides|http://people.freedesktop.org/~kem/kem-xdevconf2006.pdf]]) 4:00 PM "Device Driver Issues TBD" - David Airlie 5:00 PM "X on Small Devices, Nokia 770" - Tapani Pälli, Nokia ([[Slides|https://stage.maemo.org/svn/maemo/projects/haf/doc/presentations/xdevconf2006_770.pdf]]) 6:00 PM Shuttle to El Torito's Mexican Restaurant (2950 Lakeside Dr, Santa Clara), Dinner Hosted by [[StarNet|StarNet]] Communications 9:00 PM Shuttle back to Campus, Hotels + +#### Thursday, February 9, 2006 + + * 9:00 AM Soft Start (joint Board/Sponsor's headbashing from 7:30 to 10:00) + * 10:00 AM Real Start 10:00 AM "What Accessibility Needs from X" - Peter Korn, Sun 11:00 AM Open Time Slot - BREAKOUT SESSIONS + * XCB status update - Keith Packard + * GLX_EXT_texture_from_pixmap spec wrangling - numerous people 12:00 AM Lunch "Open Solaris, Open Source Development at Sun" + * - Stephen Harpster, Director of Open Solaris, Sun Microsystems +1:00 PM "Accelerated Indirect GLX" - Kristian Høgsberg, Red Hat ([[slides|http://people.freedesktop.org/~krh/aiglx.pdf]]) +2:00 PM "A preview of the GNOME compositing manager" - Søren Sandmann Pedersen, Red Hat +3:00 PM "Deconstructing X Server Configuration" - Adam Jackson, Red Hat ([[slides|http://people.freedesktop.org/~ajax/xdc2006.pdf]]) +4:00 PM Break, Depart for Intel computer museum 6:00 PM Shuttle to Mountain View Castro Street Restaurant District 8:30 PM Everyone meet at Tied House Brewery off of Castro 10:00 PM Shuttle back to conference center + +#### Friday, February 10, 2006 + + * 8:00 AM Continental Breakfast 9:00 AM Start 9:00 AM "Power Management for Graphics Subsystems" - Jay Cotton, Sun ([[slides|http://mediacast.sun.com/share/alanc/xdevconf06-fbpm.pdf]]) + * 10:00 AM "Beyond Modelines: Xorg Display Configuration" - Stuart Kreitman, Sun 11:00 AM "Challenges of [[OLPC|http://www.laptop.org/]] Graphics" - Jim Gettys, OLPC 12:00 AM Lunch 1:00 PM "New DRI memory manager and i915 driver update" - Keith Whitwell & Thomas Hellstrom, Tungsten Graphics ([[slides|http://www.tungstengraphics.com/xdevconf2006.pdf]]) 2:00 PM "Evolving" - Zack Rusin (cancelled) 3:00 PM TALKS ARE OVER! Beer by the case. We'll keep the room open till 6 6:00 PM BYE ALL!! + +##### Hackfesting, Brainstorming, and Beer + +In response to feedback from previous Developer Conferences, we will enable good amounts of time, infrastructure, and space for getting actual work done. + +Proposed Breakout Sessions/Hacking Focus on: + +* Display configuration +* Accessibility +* Composite-aware managers +* Composite-aware screen magnification +* Live Video +* Security +* Thin Client and workstation performance analysis +* Composite / OpenGL compatibility +* Composite / XVideo compatibility +* Making X pixmaps directly usable as textures by OpenGL clients +* A session on improvements that should be made to OpenGL texture resource management in order to gracefully operate in an environment where all running programs are using textures +Please submit your interest in these and other topics. + + +#### Confirmed Attendees + +Mahmood Ali, David Airlie, Paul Anderson, Stuart Anderson, Jesse Barnes, Billy Biggs, Eric Boucher, David J. Brown, Ignacio Castano, Jesse Clayton, Alan Coopersmith, Jay Cotton, Jim Gettys, Alexandre Gouaillard, Thomas Hellstrom, Jay Hobson, Kristian Høgsberg, Alan Hourihane, David Hoover, Matthias Hopf, Harold Hunt, Adam Jackson, Deron Johnson, James Jones, Joe Kain, Stuart Kreitman, Tommi Komulainen, Peter Korn, Carol Lavelle, Phillip Langdale, Sam Lau, John M. Martin Jim Mc``Quillan, Kevin E. Martin, Valery Moya, Shrijeet Mukherjee, Jens Owen, Keith Packard, Tapani Palli, Stuart Parmenter, Søren Sandmann Pedersen, Aaron Plattner, Martin Porcelli, Nivedita Rao, Andy Ritger, Zack Rusin, Bankim Shah, Jamie Sharp, David Schleef, Steve Schoch, Leon Shiman, Edward Shu, Paul Swart, Carl Switzky, Vladimir Vukicevic, Keith Whitwell, Henry Zhao, Daniel Zhu, + +Count: 59 + + +#### Logistics + +The nearest airport is San Jose Mineta ("SJC"). Distance to Sun Santa Clara Campus Bell Tower is 3 miles. San Francisco Airport ("SFO") is larger and be more accessible by air. It is about 45 miles north of the Bell Tower, but you can take the Caltrain shuttle down to Santa Clara or up to San Francisco. The Sunway shuttle stops at various caltrain stations near Santa Clara and Menlo Park. Bicycles are permitted on the caltrain and Sunway. + +[[http://www.caltrain.com/caltrain_map.html|http://www.caltrain.com/caltrain_map.html]] + +Stay tuned for a list of closeby hotels with favorable rates and shuttle bus availability + +This is California. Public transportation is mostly nonexistant.You don't get anywhere without wheels. Therefore, we are working on attaching the [[SunWay|SunWay]] shuttle fleet to help move willing groups of people to the selected evening events. We will make every attempt to minimize the need for having a car during this conference. Carpooling will figure large in this endeavor, so please indicate whether you will have seats available, or will need a seat during your stay here. + +Update, Dec 13, 2005: + +It looks like we will be able to provide Sunway Shuttle service for airport pickups, hotel sweeps, and evenings out. We do need headcount for these resources ASAP. Feb 6,2006: Having received zero requests for ground transportation, this option is no longer being offered. + + +#### Recommended Hotels + +***Sierra Suites, 3915 Rivermark Plaza, Santa Clara, CA (408) 486-0800 + + * +++ 3 miles from SJC, Walking Distance to Conference. +++ +*Biltmore Hotel, 2151 Laurelwood Road, Santa Clara (408) 988-8411, (800) 255-9925 + +*Double``Tree Hotel, 2050 Gateway Place, San Jose (408) 453-4000 + +*Embassy Suites, 2885 Lakeside Drive, Santa Clara (408) 496-6400 + +*Hyatt San Jose, 1740 North 1st Street, San Jose (408) 993-1234, (888) 975-1234 + +*Marriott Santa Clara, 2700 Mission College Boulevard, (408) 988-1500 + +*Santa Clara Hilton, 4949 Great America Parkway, Santa Clara (408) 330-0001 + +*Staybridge Suites, 900 Hamlin Court, Sunnyvale (408) 745-1515 + +*Staybridge Suites, 1602 Crane Court, San Jose (408) 436-1600 + +*Westin Santa Clara, 5101 Great America Parkway, Santa Clara (408) 986-0700 + +*Wyndham Hotels, 1350 North 1st Street, San Jose (408) 453-6200 diff --git a/Events/XDC2007.mdwn b/Events/XDC2007.mdwn new file mode 100644 index 00000000..491146b2 --- /dev/null +++ b/Events/XDC2007.mdwn @@ -0,0 +1,139 @@ + + +# XDC2007: Xorg Developer's Conference +[[!table header="no" class="mointable" data=""" + [[<< XDC 2006|Events/XDC2006]] | **XDC 2007** | [[XDS 2007 >>|Events/XDS2007]] +"""]] + + +## February 7,8,9 2007 San Francisco Bay Area + +Conference organizer: [[Stuart Kreitman|mailto:stuart.kreitman@sun.com]] + +Live notes are going up at [[XDC2007Notes|XDC2007Notes]]. Play along! + + +## Location + +We're a go for the [[TechShop|http://techshop.ws./]], a very cool Maker's workshop very near Sun's Menlo Park campus, and close to Palo Alto and Menlo Park Hotels and dining. + +Address/Map: [[120 Independence Drive, Menlo Park, CA 94025|http://maps.google.com/maps?q=120+Independence+Dr,+Menlo+Park,+CA+94025]] + + +## Getting There, Getting Around There + +[[San Jose (SJC) Airport|http://www.sjc.org/]] is 16 miles south of Menlo Park airporter shuttle (1-800-XXX XXXX) + +[[San Francisco (SFO) Airport|http://www.flysfo.com/]] is 20 miles north of Menlo Park + + +## Recommended Hotels + +* Hampton Inn, 390 moffett blvd, Mountain View CA +* Marriot Residence Inn, 4460 El Camino Real, Los Altos +* Marriot Residence Inn, # 1854 El Camino Real West Mountain View , CA +* Sheraton Palo Alto +* Westin Palo Alto +* Stanford Park Hotel +_range of price/convenience options, The above listed are good places in good locations_ + + +## Agenda (Presenters: Get your talk listed here. If you need a change, negotiate directly with other presenters and update the wiki) + +_each item corresponds roughly to one hour of programming_ _Each day, we're planning 3 1 hr slots before lunch, and 2 1 hr slots after lunch, then breakouts_ + +_In response to feedback from last year's conference, we are leaving more open space in the schedule for structured and unstructured un-conferencing each day_ + + +### Wednesday 9AM -> 5 PM + +* Introductions, Overview - Stuart Kreitman +* [[MultiPointer|MultiPointer]] X - Peter Hutterer +* Virtual Multihead - Philip Langdale, VMware +* Lunch +* Randr 1.2 - Keith Packard, Intel +* 7.2/7.3 Roadmap - Adam Jackson, Red Hat +* Breakout Sessions - All +* Breakout Reports - All + +### Thursday 9AM -> 5 PM + +* Board of Directors Report, Q&A +* Display Technology, EDID, VESA - Joe Miseli (Sun) +* Lunch +* Secure X - Eamon Walsh ([[SecurityTalkAgenda|SecurityTalkAgenda]]) +* Cut&Paste - Bart Massey +* Breakout Sessions - All +* Breakout Reports - All + +### Friday 9AM -> 5 PM + +* Compiz - David Reveman +* Beryl - Quinn Storm +* Mesa - Brian Paul +* Lunch +* NVIDIA, Xinerama - Andy Ritger, NVIDIA +* Xcb - Bart Massey, Portland State U. +* Breakouts +* Bash! Gunn High School's award winning Jazz Combo will play for us! + +### Items not covered + +* Virtualization (Xen) +* (auto)-configuration +* Open Source drivers vs Vista-certified +* Display Port / HDMI / replacing VGA/DVI +* Nouveau +* One Laptop Per Child - Jim Gettys, olpc (Cancelled) + +## Attendees + +_insert your name on a separate line_ + +* Eric Anholt, Intel +* Jesse Barnes, Intel +* Ben Byer, Apple +* Erwann Chénedé, Sun +* [[Alan Coopersmith|AlanCoopersmith]], Sun +* Jay Cotton, Sun +* Alex Deucher +* Egbert Eich, SuSE +* Behdad Esfahbod, [[RedHat|RedHat]] +* Matthias Hopf, SuSE +* Peter Hutterer, UniSA +* Adam Jackson, Red Hat +* James Jones, Nvidia +* Stuart Kreitman, Sun +* Philip Langdale, VMware +* Chris Lee, VMware +* Kevin Martin, Red Hat +* Bart Massey, Portland State University +* Jim [[McQuillan|McQuillan]], ltsp.org +* Joe Miseli, Sun +* Keith Packard, Intel +* Brian Paul, Tungsten Graphics +* Aaron Plattner, Nvidia +* Niveditha Rau, Sun +* David Reveman, Novell +* Andy Ritger, Nvidia +* Bankim Shah, Attachmate +* Carl Switzky, Sun +* Roberto Tam, Sun +* Bernard Traversat, Sun +* Kevin Van Vechten, Apple +* Eamon Walsh, NSA (SELinux developer) +* NOT ATTENDING: + * Carl Worth, Red Hat, (I had been planning to attend, but due to unforeseen circumstances will not be available. Have fun, everybody!); + * Daniel Stone, Nokia (cannot attend due to schedule clashes -- sorry!) + * Jim Gettys, OLPC (Thursday only) + +## Sharing Stuff + +Folks in need, and folks in a generous mood, please list your interests (or send me email if you want me to help you get matched up) + + +## Other Stuff + +If you're finishing up the Xorg Developer's Conference, and haven't had your fill of geek stuff, head down the coast to Los Angeles on Friday. The Fifth Annual [[SoCal|SoCal]] Linux Expo will be February 9th-11th at the Westin LAX Hotel (which is a short shuttle ride from LAX). There are four speaker tracks on both Saturday and Sunday, plus BOFs and a couple of mini-conferences on Friday. If you'd like a BOF for any reason, contact [[g@socallinuxexpo.com|mailto:g@socallinuxexpo.com]] . For more info on the Expo, see [[http://socallinuxexpo.org|http://socallinuxexpo.org]] + +Thanks to Stu for the commercial space! diff --git a/Events/XDC2008.mdwn b/Events/XDC2008.mdwn new file mode 100644 index 00000000..4a9c6048 --- /dev/null +++ b/Events/XDC2008.mdwn @@ -0,0 +1,39 @@ + + +# XDC 2008 +[[!table header="no" class="mointable" data=""" + [[<< XDS 2007|Events/XDS2007]] | **XDC 2008** | [[XDS 2008 >>|Events/XDS2008]] +"""]] + +The X Developers' Conference for 2008 was hosted by Google in Mountain View, California, from the 16th through the 18th of April, 2008. The event will be held at [[1501 Salado Drive|http://maps.google.com/maps?f=q&hl=en&geocode=&q=1501+salado,+mountain+view&jsv=107&sll=37.0625,-95.677068&sspn=50.291089,80.15625&ie=UTF8&z=16]]. This is on the opposite side of the Ampitheater Parkway/Rengstorff Ave offramp from US-101 than the rest of the Google complex. Please make a note of how to get there. + +* [[Attendees|Events/XDC2008/Attendees]] +* [[Program|Events/XDC2008/Program]] +* [[Notes from the talks|Events/XDC2008/Notes]] +We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. + +Attendance is free, but you must register beforehand, by putting your name on the Attendees page. + + +## Accommodation + +There are [[several hotels|http://maps.google.com/maps?near=1600+Amphitheatre+Parkway,+Mountain+View,+CA+94043+(Google)&geocode=6913274534084284730,37.423398,-122.086507&q=hotels&f=l&hl=en&dq=google+loc:+Mountain+View,+CA&ie=UTF8&t=h&z=13]] near the Google offices. Many of them are filling up and most have said that they are usually full a week before the day you arrive, so don't wait til the last minute. The [[Best Western Mountain View|http://book.bestwestern.com/bestwestern/productInfo.do?propertyCode=05355]] is where several of us are staying, and as of 2008 Apr 11, they still had several rooms available. + + +## Travel + +The nearest airport to Mountain View is San Jose, California (SJC), but the one most attendees will likely be flying into is San Francisco International (SFO). SFO is about 30 miles from Mountain View, and as such, a taxicab would be rather expensive. Other options are renting a car (advised, since any hotel would be a few miles from Google) or using the BART/CalTrain to get to Mountain View, and then taking a taxicab to your hotel from there. + +The event will be held at 1501 Salado Drive, Mountain View. [[Map|http://maps.google.com/maps?f=q&hl=en&geocode=&q=1501+salado,+mountain+view&jsv=107&sll=37.0625,-95.677068&sspn=50.291089,80.15625&ie=UTF8&z=16]] directions are available from this point. + + +## Meals + +Breakfast, (starting at 10:00 AM), lunch, and an afternoon snack will be kindly provided by Google, at the location. You may make your own dinner plans for Wednesday and Friday. + +Thursday evening, the X.org Foundation is sponsoring a dinner for all attendees. We'll meet at 7:00 PM [[Don Giovanni Ristorante|http://www.dongiovannis.com]] which is at [[235 Castro St, Mountain View, CA 94041|http://maps.google.com/maps?hl=en&ie=UTF-8&um=1&q=don+giovanni%27s&near=Mountain+View,+CA&fb=1&cid=0,0,14678227340696319431&sa=X&oi=local_result&resnum=1&ct=image]]. + + +## Registration, talks + +If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xdc2008]] for updates. Also, please add your name to the [[Attendees|Events/XDC2008/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDC2008/Program]] page. diff --git a/Events/XDC2008/Attendees.mdwn b/Events/XDC2008/Attendees.mdwn new file mode 100644 index 00000000..5b32da63 --- /dev/null +++ b/Events/XDC2008/Attendees.mdwn @@ -0,0 +1,63 @@ + + +# XDC2008 Attendees + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xdc2008]]) if you are planning to attend [[XDC2008|Events/XDC2008]]. Please note there is a limit at around 70 participants. + +1. [[JesseBarnes|JesseBarnes]] +1. [[AlanCoopersmith|AlanCoopersmith]] +1. [[DanielStone|DanielStone]] +1. [[MatthiasHopf|MatthiasHopf]] +1. [[StuartKreitman|StuartKreitman]] +1. [[ChrisBall|ChrisBall]] +1. [[CarlWorth|CarlWorth]] +1. [[PatKane|PatKane]] (tentative) +1. [[AlexDeucher|AlexDeucher]] +1. [[JayCotton|JayCotton]] +1. [[BryceHarrington|BryceHarrington]] +1. [[MichaelLarabel|MichaelLarabel]] (tentative) +1. [[AdamJackson|AdamJackson]] +1. [[JohnBridgman|JohnBridgman]] +1. [[JeremyHuddleston|JeremyHuddleston]] +1. [[BenByer|BenByer]] +1. [[EricAnholt|EricAnholt]] +1. [[KeithPackard|KeithPackard]] +1. [[HenryZhao|HenryZhao]] +1. [[MatthewGarrett|MatthewGarrett]] +1. [[RandolphChung|RandolphChung]] +1. [[EdwardShu|EdwardShu]] +1. [[BartMassey|BartMassey]] +1. [[AndyRitger|AndyRitger]] +1. [[KevinMartin|KevinMartin]] +1. [[TiagoVignatti|TiagoVignatti]] +1. [[KristianHoegsberg|KristianHoegsberg]] +1. [[RinyQian|RinyQian]] +1. [[JeromeGlisse|JeromeGlisse]] +1. [[PauloZanoni|PauloZanoni]] +1. [[NivedithaRau|NivedithaRau]] +1. [[EamonWalsh|EamonWalsh]] +1. [[EricJeong|EricJeong]] +1. [[SooChanLim|SooChanLim]] (tentative) +1. [[MinskeyGuo|MinskeyGuo]] +1. [[DavidMarx|DavidMarx]] +1. [[StefanTeleman|StefanTeleman]] +1. [[JakeEdge|JakeEdge]] (tenative) +1. [[ZackRusin|ZackRusin]] +1. [[VinayBondhugula|VinayBondhugula]] +1. Sam Lau +1. [[StefanDoesinger|StefanDoesinger]] +1. [[ChrisLee|ChrisLee]] +1. Aaron Plattner +1. Pierre-Loup Griffais +1. [[LarryMaloney|LarryMaloney]] +1. Jens Owen +1. Allen Lorenz +1. [[DavidSchleef|DavidSchleef]] +1. Zephaniah Hull (tentative) +1. [[LarryLehman|LarryLehman]] +1. [[MatthewTippett|MatthewTippett]] +1. [[YannickHeneault|YannickHeneault]] +1. [[JoachimDeguara|JoachimDeguara]] +1. [[JoshGargus|JoshGargus]] +1. Mahmood Ali +See also [[CarPoolInfo|CarPoolInfo]] if you need a lift. diff --git a/Events/XDC2008/Notes.mdwn b/Events/XDC2008/Notes.mdwn new file mode 100644 index 00000000..833deea9 --- /dev/null +++ b/Events/XDC2008/Notes.mdwn @@ -0,0 +1,666 @@ + + +# Adam Jackson on X release status and process + +We do have a list of (70) bugs blocking the release (10101): + +[[https://bugs.freedesktop.org/show_bug.cgi?id=10101|https://bugs.freedesktop.org/show_bug.cgi?id=10101]] + +But nobody other than Adam has ever looked at that. + +It seems we're all heads down now. There were lots of good talks at XDS in the fall about new stuff that was coming, (Gallium, etc.). But it's + +[[Bug 13795|https://bugs.freedesktop.org/show_bug.cgi?id=13795]]: With Mozilla and cairo now using Render, we're using lots of parts of the server/drivers that have never really been used before. As expected, they are broken. + +Some of the breakage is avoidable with XAANoOffscreenPixmaps. + +Can we drop XAA altogether? Not for this release. EXA isn't quite ready yet. And Glucose isn't happening at all. + +Ajax: I'm feeling kind of alone here. Nobody else is looking at this stuff? Daniels: I just closed a blocker. One fixed. + +Ajax: I don't feel like I'm scaling that well. There are huge swaths of the code that nobody cares about. Things change and break, but nobody takes responsibility for things. + +Even the drivers that are "well maintained" have problems. We see lots of churn in the drivers, but not releases. Releases are cheap guys! I don't have a solution for that except shaming people---maybe this is how I get a start. + +Every 6 months or so we have a session where we say "what do we want in our next release?" and we write them on the whiteboard. Then, several months later someone, (lately, Ajax), looks at the list and sees which ones are actually coming together, (about 50%), and decides those are the ones that actually go in. + +Example of the picaccess change that was on the "desired" list for several releases, but never went in. Finaly, we sat down and forced it in, but found that only the "top 3" drivers had been ported to it, and everything else broke. Fortunately, someone stepped in to save things after the fact. The problem is that we don't have anyone signing up for that janitorial work---or a commitment to "don't break the drivers". But we could have done the whole pciaccess change in-pace with a compatibility layer so that nothing would have ever broken. + +Jesse Barnes: We had a big flamewar about putting the drivers back "in tree" in one git module or whatever. That never came to consensus, but wouldn't it help? Right now, nobody cares about the "server" and the distribution maintainers end up taking on all the pain. Wouldn't it be better if driver hackers had a vested interest in getting the "big blob of server and drivers" into a releasable state together. + +John: Is the big problem lack of resources for driver development? + +Someone: Or just lack of policy? + +Ajax: I don't think it's lack of resources. If we had done pciaccess correctly, then it wouldn't have been any work---just a sed script. + +Daniel: Bisectability is really nice. People can bisect an independent driver and find Jesse's driver bug. But if we had the big blob, and someone tried to bisect, then it would all just be "Oh my God, my keyboard doesn't work". So if we did put everything together, we'd need lots of separate trees, (input, etc.). + +Ajax: Do git submodules help us address the issue? + +Eric: Zack's done more work with the submodule thing, but I don't think it gives us what we want. We don't get a master supermodule that points to all the "master" branches of the submodules. Instead, it has to have exact sha1 sums for each point. It would be great for tagging releases, but not so nice for "build master". + +[Discussion: What was the whole point of modularization?] + +Ajax: It's great to be able to build the server without having to build xedit. + +Daniel: It was great for distributions. + +Jesse: The only thing that makes sense to merge back together is the server and drivers. It's a social problem, but this technical change would help. + +Kevin: That puts structure onto the technical side of things, but not any structure onto the social problem. + +Ajax: The problem with merging things together is that it doesn't address the modularization problem. What happens when I want to package up the server, but the Intel driver happens to be broken at the time? If all I can grab is one point in the development of everything, then there's a problem there. How can I back out just the Intel driver changes? + +John: It sounds like we want monolithic build and test, but we want modular packaging and distribution. + +Ajax: One of the problems is that we're just not testing in the first place. And that's a big part of the problem. + +Ajax: We actually do have a test suite (XTS) that we got released under a free license a while ago, but nobody is actually running that. And nobody is adding new tests. + +Keith: But we can't add tests to that test suite. We are writing new ad-hoc tests. Do we create a new test suite infrastructure? Do we use something like piglet? + +Bart: We don't have to solve all our problems with automated tests. We do need to put together the social organization, (maybe even pay people), to make things happen. + +[Someone]: We have a lot of server bugs already without automated tests and they already aren't getting worked on. + +Jesse: We're getting a little off-topic here. The original problem was that Ajax isn't getting any help with release management. + +Daniel: Release manager is a misnomer anyway. There's no herding of others doing work or anything. It's just signing up to be the person that fixes all the bugs. + +Eric: The advantage of automated testing is that you find out the regressions quickly and you only have a couple of commits to look at to find and fix the bug. + +[A few minutes more discussion on technical vs. social problems, lots of missing testing from anybody. Lack of a decent infrastructure for writing new tests.] + + +# Kevin Martin on roadmap and introspection + +Our goals include: + +* Embrace the dynamic world; hotplug of input and outputs, and all the technical requirements for that +* Smooth, flicker-free user experience; graphical boot, vsync, minimal visible redraw +* Seamless integration of Composite with the rest of rendering; redirected GL/Xv, Composite by default, no software fallbacks +* Secure environment, run X as unprivileged user +These are, of course, the same goals they've been for the last three years or so. We're making progress, but we're not there yet. + +What have we been doing? + +* RANDR 1.2 integration with Gnome (ssp) +* DRI2 (krh) +* DRM and kernel modesetting (airlied) +* Render acceleration (cworth) +* Cairo 1.6 and pixman (cworth and ssp) +* Shatter and other multiscreen infrastructure (ajax) +* Driver work (all) +We need to finish. What do we need to finish? + +Memory management is critical. And it's still not done. How do we finish this? + +DRM, kernel modesetting, VGA arbitration. + +Monitor hotplug. Have the desktop-side configuration support, really just need the event from the hardware. + +* Ensuing discussion about how to wire it up, how to persist beyond the session. Working in Gnome, not propagated out to the global config yet. +* Does the top level win, or does the bottom level win? +* What do we do for input? (Implementation details) +Sync to vertical retrace. + +Driver work: + +* Intel mostly feature-complete, needs stabilization. +* AMD making excellent progress, but not feature complete. +* nv/matrox/etc are nowhere near done. +Suspend/resume. Oh dear. Matthew will talk about this later. + +Video. MC and iDCT and such need to get properly implemented everywhere. + + +# Zack Rusin on Gallium + +Gallium is a rework of the DRI driver model. The driver ends up being rather large and opaque, and writing new ones is rough because it's so large. + +In Gallium, the driver is split up to isolate the core logic from the hardware from the window system from the OS. The core logic assumes that the driver is shaderful. + +This allows better reuse (state tracker stays the same, only the hardware driver changes). + +This allows better portability to other OSes or windowing systems. + +Still under development, but mostly interface-stable. + +Have several drivers already (i915, i965, softpipe, cell). External projects for nouveau and R300. + +The big pieces are the state tracker, the winsys layer, and the core driver itself. + +* State tracker is the API: OpenGL, OpenVG, [[D3D9|D3D9]], etc. +* winsys layer talks to the X server and/or the kernel for environment support +* the core driver encapsulates all the hardware knowledge +Other pieces: + +* "draw", software vertex walk +* CSO, constant state objects, responsible for optimisation of state emission +* buffer management code +* TGSI code, internal representation of shaders +* LLVM integration +It works! Software rendering path works. i915 works on both X and Windows. Works on PS3. + +Fallbacks are hard. Fallbacks are really hard. Ideally you wouldn't have them, but that requires a complex state tracker, since OpenGL is really big and weird. Being worked on. + + +# Matthew Garrett on power management + +APM used to exist. It more or less worked! But when it didn't, there was no recovering. + +Open Firmware exists, but isn't typically relevant for desktops. + +Embedded things have their own stuff. + +ACPI basically makes no guarantees about what happens when you come back from resume. + +The steps are: call device suspend callbacks, platform Prepare-to-sleep method, platform Go-to-sleep method, (suspend), random BIOS stuff, platform Back-from-sleep method, platform wakeup method, device resume callbacks. + +ACPI doesn't require that the platform do anything, but it also doesn't require that the platform do **nothing**. + +Some machines will reenable text mode in BIOS. Sometimes that happens during ACPI methods. Sometimes that only happens if the platform thinks Linux is running. But you'd really rather not go back to text mode at all. Ideally, you'd restore state and go back to graphics directly. + +Swapping out all the state is kinda difficult, but doable. The really hard part is getting the device into a consistent state before doing the state restore. Then you need to block X until everything is back to a reasonable state. + +(Lots of implementation details) + +How do you survive video hotplug? Actually, you're not expected to be able to. + +Need to be cleaner about input hotplug, not doing it right right now. Just a bug. + + +# Ben Byer and Jeremy Huddleston on X11.app + +DDX module in hw/xquartz/, old hacked-up version of Mesa + +Everything else is plain-jane Xorg, packaged up as X11.app + +History + +* XonX: port of XFree86 to Darwin IOKit framebuffer +* merged into XFree86 as XDarwin +* enhanced to do rootless mode: X windows and OSX windows in the same display +* Apple branched XFree86 4.3 and included it in the OS +Goals + +* Pleasant experience for Unix apps on a Unix OS +* Support all traditional X11 technologies on a Mac (GLX, drag and drop, copy/paste, rootless) +* Cater to wide range of users: sysadmins, developers, research, design +* Take advantage of OSX features +Keeping up + +* X11.app and XDarwin evolved in parallel +* XDarwin pulled most improvements from X11.app, X11.app pulled XFree86 updates +Decay + +* X11.app brought to release quality and parked in maintenance mode +* Resync with XDarwin depended on volunteers +* XFree86 licensing change forced a move +Leopard X.org resync + +* BSD team in Apple Core OS group took on task of porting X11.app to "new code" +* XFree86 code base severely bit-rotted +* Xplugin shim didn't keep up with the rest of the OS +* Non-existent developer community +* Limited Apple resources +* Functional, but some regressions, limited testing +* Installed by default on Leopard +Further open source push + +* xquartz.macosforge.org - trac instance, etc +* Code maintained in freedesktop.org git branch, binaries on macosforge +* x11-users mailing list, xquartz-devel +* Picked up an intern! Hi Jeremy! +X11.app today + +* Discarded old Darwin code, renamed DDX to Xquartz +* apple branches in git +* Built like a normal X server, configure && make && make install +* Limping along on old Mesa code though +Current challenges + +* Quirky input code +* Crashy rootless code +* Stale DRI code +Coming projects + +* New DRI driver using OpenGL.framework +* Fix rootless and/or replace with Composite +* Better input and RANDR support +* Smarter clipboard proxying +* Move to open source window manager +* Sync with git master + +# Kristian Høgsberg on DRI2 + +Debriefing: A one-time, semi-structured conversation with an individual who has just experienced a stressful or traumatic event. + +No kernel side + +* uses only buffer objects and associated API +* drmAddMap, Create/Destroy Context/Drawable are no longer used. yay! +* intel driver has a driver-specific ioctl for communicating the hardware lock with the kernel +* possible new ioctl for mapping a set of buffer objects (rather than just one) +Simpler DDX driver requirements + +* fbconfig come from the DRI driver instead of from the DDX +* back buffers allocated on demand by the DRI driver +* sarea is a buffer object rather than a magic map +* new self-describing block format for sarea records +* sarea still necessary for describing cliprect changes +(log showing dynamic buffer allocation) + +Event ring buffer + +* Used for communication from X server for window position and cliprects, and drawable to buffer-object mappings +* X server is only writer. two head pointers: end of valid data, and end of event currently being written +* client maintains per-drawable tail-pointer, checks for updates by comparing to server head pointer +* currently checked every time you take the lock +* protocol for catching up if the client falls too far behind the server +Initialization and operation examples + +* Server setup: DDX driver opens DRM device, calls dri2 to initialize the sarea, with optional size for driver-specific blocks +* Client setup: If DRI2 extension is available, call DRI2Connect for busid, driver name, sarea buffer object handle; call DRI driver's createNewScreen, which doesn't set up any pre-sized render buffers. +* Tell DRI2 module that we're interested in a given X drawable. Server responds by logging it to the new sarea. +* When the drawable is bound to a context, the DRI driver parses the sarea event log and sets up the necesary render buffers. +* GLX_EXT_texture_from_pixmap in direct contexts for free +Lockless options + +* As the server moves windows around, the cliprects change **and** you have to blit. You have to make this appear atomic to clients, otherwise the pixels and cliprects will be inconsistent +* Introduce two new submit methods: + * submit and update + * compare and submit +Probably makes sense to move buffer swaps to the server + +Technical discussion on how to implement sync to vblank. + +(Super hot demo) + + +# Eric Anholt on Render + +What do app authors want? + +YUV picture formats as a new source picture type + +JPEG/PNG picture formats for compressed image transport + +YUV needs new filter types for hue/contrast/etc + +Gradients need to be properly specified, should just copy the cairo spec + +Gradients need dithering, and for filters to work in general + +Technical discussion of how to do automatic mipmapping + +Rendercheck needs a ton of work + +Transforms need to be floating point? Or at least need to be specifiable in floating point + +(Søren rants for a while about the imprecision of the spec) + + +# Jérôme Glisse on Radeon + +Kernel modesetting is in progress, for all the usual reasons: suspend, flicker-free boot, reducing root code in userspace, graphical boot, graphical panic + +Really hard to preserve compatibility, so a new driver sounded like a good idea. Problem is the existing code is well-tested and also tedious to rewrite. Rewriting it was a mistake; should have used the existing DDX code to begin with. + +Why ATOM? Should work since Windows uses it. Reuses AMD engineering work. Keeps the driver from needing to know hw details. But, sometimes buggy and not always exactly what we want. + +What do users want? Working 3D. Accelerated video. Modesetting is uninteresting as long as it comes up. + +So, use ATOM to leverage the existing AMD engineering work. Reduce time to support new hardware, get on to the fun features. + +AMD GPU design is "like Lego blocks". Different GPUs share same modules (DAC/TMDSC, 3D engine, CP), but can move around between GPUs. Can and does. But ATOM takes care of most of this for us. + +Kernel code should reflect this modular design; each piece should talk only to the piece of the chip that it's responsible for. + +Lockups are easy to trigger. And, surprisingly hard to recover from. (Technical details.) Need to sanitize the command stream to be sure you don't do weird things, and avoid the WAIT_UNTIL feature. But this makes vsyncing hard. + +Lots of cases where the GPU can stall. Fencing is really hard; need to be careful about batching them. Some buffer offset registers stall until they can be done safely, so you want to avoid doing them. Context switches need some optimization for this case. + +Fragment programs are essential now, and optimisation is critical so you correctly run everything you claim to be able to run. LLVM will save us all. + +Texture indirections are a finite resource. You can reduce them by rescheduling the shader. + +r300 and r400 don't support all swizzling combinations. Want to redo shaders to use native swizzling when possible. + +Future work: DRI2, radeon gallium driver, get gears to work, fragprog compiler. + + +# David Schleef on video + +Background: working on Dirac, which is a codec from BBC that's designed to be competitive with MPEG4. + +Currently: 8 bit per channel, normal color gamut, 480i/30 or 720p/30. + +Future: 10-12 bit per channel, wide gamut, 1080p/60, possibly stereoscopic. + +Pipeline: + +* decode video +* post-process +* repack +* yuv to rgb +* gamma to linear +* rgb to device color space +* linear to gamma +* calibration curve +* rescale/compose +Colorspaces we care about: + +* BT-709 (sRGB) - the web, HD everything +* BT-601 - DVDs, SD TV, other old stuff +* Whatever your monitor uses +* CIE XYZ (Digital cinema, wide-gamut video) +(Explanation of a chromaticity diagram) + +Scaling/Resampling + +* Could go anywhere, somewhat depends on the colorspace +* use a bicubic filter or better +* Scaling is hard to do well, near-axis-aligned lines will alias badly +What do apps want to know? + +* Exact frame rate of the output pipe +* Exact time of image presentation +* Sync to vblank +XVideo API + +* Good sides: Zero copy with the SHM extension, simple, maps well to the original problem domain +* Bad sides: attributes underspecified, lots of useless attributes, missing modern details, slightly desynced with X rendering, doesn't work in cairo +XVideo implementations + +* Good: works everywhere, tends not to use software fallbacks +* Bad: vertical softening, bad scaling, bad conversions, no rgb support, only one overlay +OpenGL + +* Good: lots of control +* Bad: needs GLSL for that control, very complicated, no native YUV, three ways to do vsync, not meant for video, can't connect XVideo port to OpenGL +OpenGL implementations + +* Good: intel works, mostly; nvidia works, windows works. +* Bad: works inconsistently +Future + +* Pluggable pipeline +* Extend XVideo +* GPGPU codecs + +# Alex Deucher on R600 Architecture + +R500 was 3d build on R300. Very similar designs. + +(Diagram of GPU hardware evolution) + +R600 Overview + +* New surface setup +* Expanded CP, Prefetch processor (PFP) +* New paging and DMA engine +* New interrupt handler +* Virtual memory support +* Unified shaders +* Compose rect engine +Host data path + +* 32 surfaces for tiling and swapping +* Can do virtual or physical addresses +* Privileged and non-privileged access per surface +Command processor + +* Same basic setup and semantics as previous generations +* New prefetch parser +* Dedicated DMA engine +* Lots of new Type 3 packets +* All drawing and state can go through the CP, no need to touch registers +* 2D packets emulated by the CP +* Insert interrupts for event completion +Paging and DMA engine + +* Has own ring buffer, async from the GPU +* Host BLT, copy BLT, fences, interrupts +* Different packet formats from CP +Interrupt handler + +* Dedicated ring buffer for incoming interrupts +* Source ID to map interrupt to originating block and subfunction +Virtual memory + +* Translation of logical addresses seen by clients into physical addresses seen by the memory controller +* Page fault detection (maybe not validated) +* Page access bits (also maybe not validated) +Unified shaders + +* One big program of control flow, ALU, or fetch clauses +* 128 bit pixels, 5 way superscalar, access to vector and scalar results from previous insn +* Five main types of shader: vertex, pixel, geometry, DMA copy, fetch +Compose rect (crazy 1-bit text accel thing) + +Driver plan + +* TCORE programming SDK soon +* Programming guide + +# Keith Packard on RANDR 1.3 + +Proposed features: + +* DPMS events +* Per-output DPMS +* Panning rectangle +* Projective transform +* GPU objects +* CRTC properties +* Standard output properties +DPMS + +* Goal is power management without polling +* Basic plan: Enable/Disable requests, OutputDPMS request, OutputDPMSChanged and [[EnableChanged|EnableChanged]] event, IDLETIME sync counter +* Allows DPMS transition to be decoupled from "idle" +* Provides DPMS notification to applications +* Leaves legacy auto-DPMS stuff around +* New enable and disable are refcounted. Event includes the refcount. +Panning rectangle + +* Bounding box for the CRTC, just moves the CRTC origin around +* CRTC follows mouse on edge transitions +* CRTC events will be generated, probably needs to be a [[PanningNotify|PanningNotify]] for lack of room +Projective transform + +* Handles input +* Uses existing rotation backend +* No driver impact +* Would be more efficient done in the compositing manager, but wouldn't handle input +* This actually works. Whoa. +GPU objects + +* Completes the object hierarchy +* Object, list of properties, mapping to CRTC +Standard output properties + +* Provide more information about outputs +* Connector type, signalling level, etc. +* Need a list and a definition of each + +# Chris Ball on tinderbox + +Started working on tinderbox as part of the OLPC bringup effort + +Got interested in adding that test harness to X + +It works! [[tinderbox.x.org|http://tinderbox.x.org/]] + +Gives you a long list of build results, properly hierarchical, triggered by commits. + +Also has some basic test infrastructure for sanity-checking the builds: + +* x11perf +* cairo tests +* rendercheck +* piglet +* etc. +Not really clear how to measure failures. Some things never worked. Doesn't have a success metric for the tests right now besides "ran to completion"; should change to catching changes in numbers of passes/fails. + +What else do we need? + +* mozilla trender +* cairo tools could be rewritten to get a more parseable output +* possibility of making throwaway "tinderbox me please" branches for pre-commit testing +* possibility of keeping build output for the last N things so you can apply new test against older builds +* more machines +* others? + +# Bart Massey on image support in XCB + +XCB is a replacement for Xlib: a thin C binding with latency hiding and transparent multithreading + +Just does a protocol binding and some language bindings + +... and then also has a util library + +In attempting to port x11perf to XCB, noticed that the image implementation is broken + +X image protocol is subtle and quick to anger. Not many apps use the Xlib facilities in interesting ways. + +The gory details + +* Decide XY or Z format, size, depth +* Walk the connection data looking for valid formats +* Compute unit, pad, byte and bit swap, size; deal with planes +* Maybe convert or expand +xcb/util/image provides: + +* Create new image with given or native format +* Convert images between formats +* fast get/put pixel inlines +* User-controllable memory management +* Protocol insulation +xcb_bitops.h provides some fast bit-banging inlines + +Forced some reevaluation of some XCB design + +* error handling is weird +* latency hiding in libraries +* build mechanisms +* util packaging +Requests for help and further work + +* Finish the x11perf port +* Image test suite +* Specify or build other userland libs +* Port apps to XCB + +# Stefan Dösinger on Wine and X + +Wine is a set of libraries to allow running unmodified Windows apps. + +Uses X for input and output, translates GDI and DirectX to X APIs + +Raw mouse input + +* Windows can report relative mouse movement +* Mouse and keyboard notifications are windows independent +* Client-side workaround, but fails when you hit the screen border, or when the app changes focus +* Should be doable with XInput +Tablet support doesn't really exist yet, but that's being worked on in X already + +3D rendering issues + +* Flat shading colors; different behaviour in GL versus D3D. extension proposal, should be easy. +* pbuffers need to be supported in the driver, pain to implement them with FBOs. DRI2 should solve this. +* multithreading. Our drivers break when multiple contexts run on one drawable. +* sRGB rendering targets. GLX extension is stronger than [[D3D9|D3D9]] extension, so only works on DX10 hardware. Could get away with ability for write correction without blending. +* GLSL. Conversion from D3D done with generated GLSL, depends on the driver to optimize. + +# X.org Foundation Board on the X.org Foundation Board + +Members! Be members. Go to [[members.x.org|http://members.x.org/]] + +We exist to provide education, support, and infrastructure to enable X development. If you think you could use some of that, let us know! We will do what we can. + +Meetings and conferences are not necessarily limited to XDC and XDS. If you want to do something smaller and local, let us know! We will do what we can. + +The software has been coming out. See elsewhere for details. + +Vendor relationships keep getting better. Docs and source keep coming out. Life is good. + +We are doing GSoC again. We may be doing additional direct student funding again. + +We are VESA members, we're about to be CEA members. We should do something about Khronos; if this is you, let us know! Getting this information out to the development community is important, so let us know if this will help you. + +The old LLC structure is being closed out, finally. We're within epsilon of being a 501(c)3. + +Apologies for the election being so chaotic last time around. There is a team working on improving this process. + +Current board meeting structure is bi-weekly for the whole board plus committee meetings as needed. + +Membership agreement is being finalised to make membership easier to agree to and sign up for. + +We're spending money well now. We will begin looking for sponsorships again. Healthy cash flow is healthy. + +Infrastructure between x.org and freedesktop.org is being merged behind the scenes, for the betterment of both. + +There is another major conference coming. September 10-12 (ish) is XDS 2008 at Edinburgh Zoo. Conference facilities, probably a sunset tour, general good times. Should have final details in a few weeks. + + +# Eamon Walsh with A Talk + +[[DevPrivates|DevPrivates]] + +* reworked now. +* They're lazy allocated, way simpler to program, but have some small issues. +* Merge worked, and the changes are documented. Yay! +* xf86AllocateEntityPrivateIndex(), probably won't be touched +* [[AllocateFontPrivate|AllocateFontPrivate]](), also. Not really worth fixing. +* Some minor optimizations to be had with CSE. +Things I hate + +* State polling requests suck. "Give me the state of the keyboard! Including button up/down!" Doom. + * How do we fix? Lie? Rate limit? Visual feedback? + * Add a policy framework, start fixing the toolkits +* bg=None. + * This is how to steal window contents + * But just censoring to black flickers + * Maybe only block [[GetImage|GetImage]] from bg=None windows? Or just fix gtk? Hmm. +Please can we kill more extensions + +* Every protocol request is an entrypoint. +* But each one has to be characterised, and it's the ioctl problem. +* (Hateful spreadsheet) +* EVI, XTrap/Record, [[DoubleBuffer|DoubleBuffer]], [[MultiBuffer|MultiBuffer]]. Die. (XT/R needs a closer look.) +* MIT-SUNDRY-NONSTANDARD. Die. +* APPGROUP. Unused. Die. +* XFree86-DGA. Dead once we get relative mouse motion. +* XFree86-Misc. Die. +* TOG-CUP. Die. +* Xinerama. Enh. Kinda hard. +* DPMS. Can pretty much just go. +* XFree86-[[VidModeExtension|VidModeExtension]]. Can die once we fix RANDR. +To-do + +* Finish some XCB stuff. +* GLX and DRI. +* MPX/Input security improvements. +* Move on to higher desktop layers. +(Technical discussion of how to fix bg=None) + + +# Lightning talks + +Owen Taylor is working on fixing Radeon Render performance. And making progress! Should be done as generic Render services, so everyone wins. + +John Bridgman raises some concern about lockstepping DRM and X as far as getting support pushed out. There's some slip, it works. But it is something the driver maintainers need to be conscious of. Also, what are the last steps to getting X to run as non-root? + +Paulo Zanonni and Tiago Vignatti on VGA arbitration. This needs to be done in the kernel to get it right, since each server may want to have VGA space routed to it at various times. Existing proof-of-concept as kernel+library+server code. Should just be a /dev node. + +Jesse Barnes on getting off of /dev/mem. Mostly there. How do we expose caching policies to maps? How do we deal with non-PCI video devices like USB? + +Adam Jackson on Xinerama and shatter and stuff. If you're interested, go talk to him. [[http://cgit.freedesktop.org/~ajax/xserver-shatter|http://cgit.freedesktop.org/~ajax/xserver-shatter]] + +Daniel Stone on input. Core, XI, and XKB. Massive amounts of duplication. This is really terrible. Lots of it is being fixed, yay! Being worked on in xkb-atkins branch. This is sort of a prerequisite for merging MPX. + +Bart says cut and paste is still broken. diff --git a/Events/XDC2008/Program.mdwn b/Events/XDC2008/Program.mdwn new file mode 100644 index 00000000..15ed0481 --- /dev/null +++ b/Events/XDC2008/Program.mdwn @@ -0,0 +1,40 @@ + + +# XDC2008 Program + +This is the rough program for [[XDC2008|Events/XDC2008]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk. + +The schedule itself will be available closer to the conference. + + +## Program +[[!table header="no" class="mointable" data=""" + | **Wednesday** | **Thursday** _(multimedia/GL)_ | **Friday** _(clients and bits)_ + **10am** | _coalesce, breakfast, live schedule bashing_ | _coalesce, breakfast_ | _coalesce, breakfast_ + **10:30am** | Welcome, general socialising ([[CarlWorth|CarlWorth]] et al) | DRI2 debriefing ([[KristianHøgsberg|KristianHøgsberg]]) | Tinderbox with tests ([[ChrisBall|ChrisBall]]) + **11:15am** | [[X11R7|X11R7]].4 status ([[AdamJackson|AdamJackson]] et al) | Future plans for XRender ([[EricAnholt|EricAnholt]]) | Image support in XCB ([[BartMassey|BartMassey]]) + **12pm** | Introspection ([[KevinMartin|KevinMartin]]) | Radeon state of the art ([[JeromeGlisse|JeromeGlisse]]) | Wine and X ([[StefanDösinger|StefanDösinger]]) + **1pm** | _lunch_ | _lunch_ | _lunch_ + **2pm** | Mesa/Gallium overview ([[ZackRusin|ZackRusin]]) | Fixing video ([[DavidSchleef|DavidSchleef]]) | X.Org Foundation (Foundation board members) and [[impromptu XDS presentation with cute fluffy animals|http://www.flickr.com/photos/tags/edinburghzoo/interesting/show/]] + **3pm** | Suspend and resume ([[MatthewGarrett|MatthewGarrett]]) | r6xx architecture ([[AlexDeucher|AlexDeucher]]) | A talk not about SELinux ([[EamonWalsh|EamonWalsh]]) + **4pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_ + **4:30pm** | Xquartz ([[BenByer|BenByer]]) | RandR ([[KeithPackard|KeithPackard]]) | Lightning Talks (5 minutes each) Owen Taylor (by proxy): Fixing glyph performance. John: What's the transition plan for kernel modesetting? Paulo Zanoni and Tiago Vignatti: Multiseat and blocker bug on X server master. Jesse Barnes: Getting off of /dev/mem (helping to run server as non-root). Daniel Stone on input. Adam Jackson on doing Xinerama right. +"""]] + + +## Ideas + +* [[EricAnholt|EricAnholt]]: 3D driver optimization for TTM +* [[ChrisBall|ChrisBall]]: An X tinderbox with functional and performance tests +* [[BartMassey|BartMassey]]: X image support in XCB +* [[KristianHøgsberg|KristianHøgsberg]]: DRI2 Debriefing +* [[ZackRusin|ZackRusin]]: Mesa/Gallium overview/update +* [[StefanDoesinger|StefanDoesinger]]: Wine and X +* [[MatthewGarrett|MatthewGarrett]]: Suspend and resume in modern graphics drivers +* [[BenByer|BenByer]]: State of Xquartz +* [[JeromeGlisse|JeromeGlisse]]: Radeon state of the art +* [[DavidSchleef|DavidSchleef]]: Getting Video Right from a media framework perspective +* [[AlexDeucher|AlexDeucher]]: Radeon R6xx Architectural Overview +* [[BartMassey|BartMassey]], [[KeithPackard|KeithPackard]], [[AdamJackson|AdamJackson]], [[EricAnholt|EricAnholt]], [[CarlWorth|CarlWorth]], [[DanielStone|DanielStone]]: X.Org Foundation status etc +* [[KevinMartin|KevinMartin]]: What have we been up to lately? and what's next? +* [[AdamJackson|AdamJackson]]: Shattered pixmaps and the future of Xinerama
\ No newline at end of file diff --git a/Events/XDC2009.mdwn b/Events/XDC2009.mdwn new file mode 100644 index 00000000..5a6a3f94 --- /dev/null +++ b/Events/XDC2009.mdwn @@ -0,0 +1,39 @@ + + +# XDC 2009: Portland, Oregon September 28-30 +[[!table header="no" class="mointable" data=""" + [[<< XDC 2008|Events/XDC2008]] | **XDC 2009** | [[XDS 2010 >>|Events/XDS2010]] +"""]] + +The X Developers' Conference for 2009 will be held at Portland State University (PSU) in Portland, Oregon, from Monday September 28 through Wednesday September 30. PSU is within walking distance of Portland's downtown area and a wide variety of dining, lodging, and public transportation options. + +The conference is scheduled to follow directly after [[Linux Plumbers Conference 2009|http://linuxplumbersconf.org/2009/]] so that people attending both LPC and XDC can do that with a single trip. + +The conference will be held at the [[University Place|http://cegs.pdx.edu/stay/upl/]] hotel and conference center on the edge of the PSU campus. + +* [[Attendees|Events/XDC2009/Attendees]] +* [[Program|Events/XDC2009/Program]] +* [[Notes from the talks|Events/XDC2009/Notes]] +We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. + +Attendance is free, but you must register beforehand, by putting your name on the Attendees page. + + +## Accommodation + +We encourage attendees to stay at the conference hotel ([[University Place|http://cegs.pdx.edu/stay/upl/]]) for convenience. We have initially reserved a block of 20 rooms for the conference, (so let them know you're with the conference when making a reservation). We will attempt to increase that block size as needed, (so please make your reservation as early as possible). + + +## Travel + +Portland is easily accessed by the [[Portland International Airport(PDX)|http://flypdx.com]]. Portland has a very nice public transportation system, ([[TriMet|TriMet]]), including the MAX light-rail system with the red line service between the airport and downtown, and the green line serving PSU. Use [[TriMet's trip planner|http://ride.trimet.org/]] to find good transportation options. And note that you can simply enter "PDX" for the airport and "PSU" for the University. + + +## Meals + +Portland is a city of many food carts, and there is a large selection (Thai, Mexican, vegan African-Caribbean, soup, sandwiches, etc) right outside PSU, in the parking lot at the corner of 4th & College Sts. + + +## Registration, talks + +If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xdc2009]] for updates. Also, please add your name to the [[Attendees|Events/XDC2009/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDC2009/Program]] page. diff --git a/Events/XDC2009/Attendees.mdwn b/Events/XDC2009/Attendees.mdwn new file mode 100644 index 00000000..b0c18512 --- /dev/null +++ b/Events/XDC2009/Attendees.mdwn @@ -0,0 +1,41 @@ + + +## XDC2009 Attendees + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xdc2009]]) if you are planning to attend [[XDC2009|Events/XDC2009]]. Please note that attendance will be limited, so list yourself early to ensure your ability to attend. + + 1. [[CarlWorth|CarlWorth]] + 1. [[BartMassey|BartMassey]] + 1. [[AlanCoopersmith|AlanCoopersmith]] + 1. [[KeithPackard|KeithPackard]] + 1. [[BryceHarrington|BryceHarrington]] + 1. [[EamonWalsh|EamonWalsh]] + 1. [[AlexDeucher|AlexDeucher]] + 1. [[MichaelLarabel|MichaelLarabel]] (maybe) + 1. [[JakobBornecrantz|JakobBornecrantz]] + 1. [[DanielStone|DanielStone]] + 1. [[JeremyHuddleston|JeremyHuddleston]] + 1. [[KennyGraunke|KennyGraunke]] + 1. [[CorbinSimpson|CorbinSimpson]] + 1. [[BenByer|BenByer]] + 1. [[StuartKreitman|StuartKreitman]] (day2,3) + 1. [[UrosNedic|UrosNedic]] (depends from sponsorship) + 1. [[JameySharp|JameySharp]] + 1. [[JimGettys|JimGettys]] + 1. [[AdamJackson|AdamJackson]] + 1. [[MatthewGarrett|MatthewGarrett]] + 1. [[ChrisWilson|ChrisWilson]] + 1. [[PingCheng|PingCheng]] + 1. [[TiagoVignatti|TiagoVignatti]] + 1. [[McFaddenOliver|McFaddenOliver]] + 1. [[JohnChee|JohnChee]] + 1. [[ArvindUmrao|ArvindUmrao]] + 1. [[NaveenReddy|NaveenReddy]] + 1. [[AaronPlattner|AaronPlattner]] + 1. [[BernieThompson|BernieThompson]] + 1. [[AdamRichter|AdamRichter]] + 1. [[JesseBarnes|JesseBarnes]] + 1. [[KristianHoegsberg|KristianHoegsberg]] + 1. [[HenryZhao|HenryZhao]] + 1. [[BrianRogers|BrianRogers]] + 1. GregKH
\ No newline at end of file diff --git a/Events/XDC2009/Notes.mdwn b/Events/XDC2009/Notes.mdwn new file mode 100644 index 00000000..4d917916 --- /dev/null +++ b/Events/XDC2009/Notes.mdwn @@ -0,0 +1,255 @@ + + +# XDC2009 Notes + +Live from sunny Portland, it's the X Developer's Conference 2009! + +[[!toc ]] + + +## 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|CompositeRedirectSubWindows]], hook [[CreateWindow|CreateWindow]], redirect root window in CW hook +* Hook [[RealizeWindow|RealizeWindow]] and make GEM handles for the window pixmap, tear it down in [[UnrealizeWindow|UnrealizeWindow]] +* Update it in [[SetWindowPixmap|SetWindowPixmap]] (resize, reparent, etc) +* Hook [[MoveWindow|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|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|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|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|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|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|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|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?
\ No newline at end of file diff --git a/Events/XDC2009/Program.mdwn b/Events/XDC2009/Program.mdwn new file mode 100644 index 00000000..dfeb057f --- /dev/null +++ b/Events/XDC2009/Program.mdwn @@ -0,0 +1,53 @@ + + +# XDC2009 Program + +This is the rough program for [[XDC2009|Events/XDC2009]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk. + + +## Program +[[!table header="no" class="mointable" data=""" + | **Monday** | **Tuesday** | **Wednesday** + **10am** | _coalesce, breakfast, live schedule bashing_ | _coalesce, breakfast_ | _coalesce, breakfast_ + **10:30am** | Welcome, general socialising ([[CarlWorth|CarlWorth]] et al) | Mesa, OpenGL 3.x and patents (Ian) | PCI rework debrief (Tiago) + **11:15am** | Summer of Code debrief (SoC students) | GL extension for MMs/KMS/fbos, (and Wayland) (krh) | XACE update (Eamon) + **12pm** | Lightning talks (krh, et al) | OpenGL shaders for SM3.0/SM4.0 hw (Ian) | Why Xorg sucks and what to do about it (Corbin) + **12:45pm** | _lunch_ | _lunch_ | _lunch_ + **2pm** | Debugging Gallium drivers (Jakob) | Synchronisation and presentation (Aaron) | X on embedded platforms (Oliver & Tiago) + **2:45pm** | 7.5 post-partum, 7.6 planning (Daniel) | Technical overview of multi-seat plug-and-play (Bernie) | Future of the XFree86 DDX (ajax) + **3:00pm** | | Intel driver update (jbarnes) Followed by _Working sessions_ | + **4pm** | Power management in X (Matthew) | _Working sessions_ | X with alternate toolkit architectures (Bart) +"""]] + + +## Lightning talks (add your own here!) + +* Composite-based rootless X server (krh) +* X.Org Foundation update ([[AdamJackson|AdamJackson]], [[AlanCoopersmith|AlanCoopersmith]], [[BartMassey|BartMassey]], [[CarlWorth|CarlWorth]], [[DanielStone|DanielStone]], [[DonnieBerkholz|DonnieBerkholz]], [[EricAnholt|EricAnholt]], [[KeithPackard|KeithPackard]]) +* HAL dependancy removal (GregKH) +* Plug-and-play multi-seat (Bernie) + +## Talk proposals + +[If we're doing our job right, each of these appear in the schedule above.] + +* [[Google Summer of Code|http://socghop.appspot.com/org/home/google/gsoc2009/xorg]] & X.Org Vacation of Code students: _How I spent my Summer Vacation_ +* [[MatthewGarrett|http://mjg59.livejournal.com/]]: _[[Power management at the X-related platform level|http://lists.freedesktop.org/archives/xorg-devel/2009-June/001265.html]]_ +* [[CorbinSimpson|CorbinSimpson]]: _Why end-users say Xorg sucks, and what to do about it_ +* [[McFaddenOliver|McFaddenOliver]], [[TiagoVignatti|TiagoVignatti]]: _Challenges of Xorg on Embedded Platforms_ (Late in the day preferred) +* [[TiagoVignatti|TiagoVignatti]] (and the virtual presence of [[DavidAirlie|DavidAirlie]]): _fclose([[PciReworkProposal|PciReworkProposal]]);_ (I'll need half hour only here) +* [[AaronPlattner|AaronPlattner]]: _Synchronization and presentation in a composited desktop environment_ ([[description and slides|http://lists.x.org/archives/xorg-devel/2009-September/002194.html]]) +* [[JakobBornecrantz|JakobBornecrantz]]: _Debugging Gallium drivers_ +* [[EamonWalsh|EamonWalsh]]: _XACE Update_ +* [[BartMassey|BartMassey]]: _X with alternate toolkit architectures_ +* [[CarlWorth|CarlWorth]]: _Why can't I bisect my X server?_ +* [[IanRomanick|IanRomanick]]: _Mesa, OpenGL 3.x, and Patents: Where do we go from here?_ +* [[IanRomanick|IanRomanick]]: _OpenGL assembly shader for SM3.0 / SM4.0 hardware_ +* [[AdamJackson|AdamJackson]]: _Future of the XFree86 DDX_ +* [[PeterHutterer|PeterHutterer]], [[DanielStone|DanielStone]]: _X.Org 7.5 post-partum, 7.6 planning_ +* [[KristianHøgsberg|KristianHøgsberg]]: _COMPOSITE based rootless X_ (lightening talk... wait, do we do lightening talks?) +* [[KristianHøgsberg|KristianHøgsberg]]: _Wayland_ (recycled LPC talk, now with technical details) +* [[KristianHøgsberg|KristianHøgsberg]]: _A GL extension to integrate MMs, KMS and FBOs_ (BOF style) +* Someone: What's the deal with XF86 keysyms? +* [[YourNameHere|YourNameHere]]: _Your interesting topic here_ +* ...
\ No newline at end of file diff --git a/Events/XDC2011.mdwn b/Events/XDC2011.mdwn new file mode 100644 index 00000000..07342372 --- /dev/null +++ b/Events/XDC2011.mdwn @@ -0,0 +1,120 @@ + + +# XDC2011: Chicago, United States +[[!table header="no" class="mointable" data=""" + [[<< XDS 2010|Events/XDS2010]] | **XDC 2011** | [[XDC 2012 >>|Events/XDC2012]] +"""]] + +* [[Attendees|Events/XDC2011/Attendees]] +* [[Program|Events/XDC2011/Program]] +* [[Notes|Events/XDC2011/Notes]] +XDC2011 is to take place in from the 12th through the 14th of September in Chicago, Illinois, United States. The event is being hosted at the Illinois Institute of Technology within the [[McCormick|McCormick]] Tribune Campus Center in the Ballroom. + +The [[Chicago XDS proposal|http://www.michaellarabel.com/misc/xds-chicago-proposal.pdf]] has additional information that was prepared for the foundation board. + + +## Venue + +The XDC2011 event is taking place at the Illinois Institute of Technology at the [[McCormick Tribune Campus Center|http://en.wikipedia.org/wiki/McCormick_Tribune_Campus_Center]]. It's immediately due-south of downtown Chicago by just a few minutes with easy public transportation. Thanks go out to the Association for Computing Machinery in helping X.Org secure this venue at an affordable rate in conjunction with IIT. + + +## Program + +If you would be interested in providing a talk during the event, please add it to the [[program page|Events/XDC2011/Program]]. + +_For anyone arriving the weekend prior to XDC2011, [[MichaelLarabel|MichaelLarabel]] will already be showing around a few attendees various places around Chicago and various pubs in the evening. Contact him and you're more than welcome to meet-up with other attendees. His locations will also be [[tweeted|http://twitter.com/MichaelLarabel]] for those that may be showing up at a moment's notice. Sunday evening there might also be a pre-XDC2011 gathering at a local establishment._ + + +## Travel + +Chicago has two main airports, Chicago O'Hare (ORD) and Chicago Midway (MDW). Most attendees, especially international visitors, will likely arrive at O'Hare. Midway is common for the budget domestic airlines and other general aviation traffic. ORD is one of the lowest-cost airports in the United States to fly in from Europe with direct flights. + +Both airports are connected to the city via local train. There are also shuttle buses to major hotels within the city. + + +## Local Transit + +Chicago is much better than most cities in the United States with regard to public transportation. There's buses and trains (also referred to as 'El') that go under and above ground depending upon location. Trains are generally on time and most preferred as buses are often late, missing, or crowded, but still better than most US locations. + +All events should be within close proximity to a train line for a quick and easy commute around the city. + +Public transportation is served by the [[Chicago Transit Authority|http://www.transitchicago.com/]]. Local routes can also be planned using [[Google Maps|http://maps.google.com/]], which tends to provide accurate information for the city. + +The event itself at the [[McCormick|McCormick]] Tribune Campus Center is located along [[the CTA green line|http://en.wikipedia.org/wiki/Green_Line_%28Chicago_Transit_Authority%29]] directly at the [[35th–Bronzeville–IIT|http://en.wikipedia.org/wiki/35th%E2%80%93Bronzeville%E2%80%93IIT_%28CTA%29]] stop. There is also a red line Sox-35th stop within walking distance too, which is the train stop used for accessing the White Sox baseball stadium (Cellular Field). + +"The bus lines that run to IIT are the 29 (directly to MTCC from Navy Pier/Loop), the 24 (from the Loop down Wenworth/LaSalle, one block west of MTCC) and the 4 (from downtown on Michigan to one block east of MTCC). They are often slow, but they may be more convenient than the train depending on where you are staying." + +"There is a free IIT shuttle bus that takes people directly from the IIT downtown campus to the MTCC. The information is at [[http://www.iit.edu/directory/2011-2012IITShuttleBusSchedule.pdf|http://www.iit.edu/directory/2011-2012IITShuttleBusSchedule.pdf]] Technically it's only for IIT students/faculty but you might be able to hop on by saying you're with the CS department." + + +## Accommodations + +With Chicago being a popular tourist destination, there's a variety of accommodations in and around the city of Chicago for all price ranges. [[Hotels.com|http://www.hotels.com/]] is able to provide a list of Chicago area hotels. For those on a budget, the accommodations near O'Hare International Airport may be most economical (with an easy 20~30 minute train ride to reach the center of the city) while the hotels in the proper city center are the most expensive options. + +* [[Central Loop Hotel|http://www.centralloophotel.com/]] - heart of downtown right in the "loop" whereby all the public train lines wrap around. Convenient location. Circa $170~180 USD per night. +* [[Club Quarters Chicago|http://www.clubquarters.com/loc_chicago.php]] - Same as Central Loop Hotel in terms of price / central location. +* [[Travelodge Downtown Chicago|http://www.travelodge.com/Travelodge/control/Booking/property_info?propertyId=10073]] - In the center of downtown Chicago as well. Likely the least expensive hotel that one can find while still being in a very central location; circa $100~140 a night (as of 14 May on Hotels.com is $100 USD per night at a supposed discount of $40) +* [[Chicago South Loop Hotel|http://www.chicagosouthloophotel.com/]] - Same central location, slightly south / closer to IIT. $169 USD per night. The area around the hotel, however, has been reported to not be a nice area. It's been advised now that it's advised not to walk around in this neighborhood... So ideally better to be elsewhere or to use only taxi/bus for commuting. An IIT professor writes, "the Chicago South Loop Hotel used to be shady, but that whole neighborhood is much better than it was 5 years ago. That would definitely be the closest (8 minute walk) safe place to stay. It's a little far from the train, but there are cabs coming directly to it because many people who have conferences at the [[McCormick|McCormick]] Place stay there." + +## Chicago Dining + +Chicago has many dining options for all price ranges. Chicago is particularly known for unique styles of pizza and hot dogs. According to [[WikiTravel|http://wikitravel.org/en/Chicago]], Chicago is evidently also known for greasy, large sandwiches that are simply called "Italian Beef." + +Beer in America is an unfortunate travesty. Particularly for European visitors, if beer quality is even the smallest concern, avoid most restaurants near Wrigley Field and other sporting venues. For any other recommendations, consult [[MichaelLarabel|MichaelLarabel]]. + +The XDC2011 dinner and social event is TBD. + +Below are some unofficial recommendations on particular establishments. + +* Resi's Bierstube [2034 W Irving Park Road] - Good place. Small biergarten. Decent selection of good beer and food. Favorite local German beer hall. +* Laschet's Inn [2119 W Irving Park Road] – This along with Resi's is the best German food you'll be able to find in Chicago. +* The Berghoff Restaurant [17 W. Adams Street] - Another German restaurant, but this one at least is downtown. +* Fogo de Chao [661 N [[LaSalle|LaSalle]] Blvd] – A good Brazilian Steakhouse. It's expensive by American standards, but well worth it. +* Moto [945 W Fulton Market] - Favorite restaurant in Chicago, one of my favorites in the world. Quite a unique experience, but expensive and can be difficult to obtain a reservation in short notice. +* Hot Doug's [3324 N California] - Likely the best hot dogs in Chicago. +* English [444 N La Salle] - Decent bar downtown. +* Moe's Cantina [155 W Kinzie] - Good Mexican restaurant. +* Gibsons [1028 N Rush] - Good steakhouse. +* Portillo's [100 W Ontario Street] - Inexpensive restaurant and beer. +* Hopleaf [5148 N Clark] - Good bar and restaurant, good food. Bit far north, however. +* Goose Island [1800 N Clybourne or 3535 N Clark] – Decent local brewery and restaurant. +* Gino's Pizza [Multiple Locations] - Chicago style deep dish pizza. +* Giodano's Chicago Pizza [Multiple Locations] - Chicago style deep dish pizza. +* Kingston Mines [2548 N Halstead] - One of the oldest and most well known Chicago Blue's music joints. +If you would like any other recommendations about particular places or bars, ask [[MichaelLarabel|MichaelLarabel]]. + + +## Dining Near The Venue + +Below are a few restaurants / bars located near the IIT [[McCormick|McCormick]] Tribune Campus Center itself, if looking for additional food or drink during the event itself. Additional places can easily be found with Google Maps using "restaurant loc: The [[McCormick|McCormick]] Tribune Campus Center, Chicago, IL 60616" + +* 7-Eleven - There's a convenience store at the venue itself. +* Starbucks [3506 South State Street] +* Einstein Bros Bagels [3241 S Federal Street] - A cafe / bagel shop right near the venue. +* Cork & Kerry at the Park [3258 South Princeton Avenue] - Bar restaurant. +* Rocky's Bar & Grill [234 West 31st Street] - Bar restaurant, plus an outdoor "biergarten". +* Fratellini Pizza & Pasta [3258 South Wells Street] - Pizza and pasta. +* Miller Pizza Company [17 West 35th Street] - Normal pizza. +* Jimmy John's [3506 South State Street] - Cheap sandwiches. +* "Chinatown" is a short distance away from IIT with a wide selection of Chinese food. + +## Registration + +If you will be attending XDC2011, add your name to the [[attendees page|Events/XDC2011/Attendees]]. Additionally, subscribe to the [[X.Org events mailing list|http://lists.x.org/mailman/listinfo/events]] for further details. This is a low-volume mailing list. + + +## Remote Participation + +If physical participation is not possible but would be interested in participating remotely via IRC and ideally live audio / video streams, make your interest known to [[MichaelLarabel|MichaelLarabel]] that you would like live streaming of the event. + + +## Miscellaneous + +The United States uses standard North American 120V / 60Hz power plugs. American Express, VISA, and [[MasterCard|MasterCard]] are all common in Chicago and accepted by most retailers and restaurants. + +[[Wikitravel|http://wikitravel.org/en/Chicago]] and [[TripAdvisor|http://www.tripadvisor.com/Tourism-g35805-Chicago_Illinois-Vacations.html]] are great sources for other travel advice and recommendations. + + +## Contact + +Feedback and any other inquiries regarding the organization of the event -- or questions if encountered when in Chicago at the event -- can be directed to Michael Larabel <[[michaellarabel.com|http://www.michaellarabel.com/]]> or via SMS / voice-mail at +1.601.871.0456 (US) or +49.089.8091.2991 (DE). Note: these telephone numbers are screened for public callers. Michael can also be contacted on [[FreeNode|FreeNode]] IRC via the michaellarabel handle. diff --git a/Events/XDC2011/Attendees.mdwn b/Events/XDC2011/Attendees.mdwn new file mode 100644 index 00000000..8f28f575 --- /dev/null +++ b/Events/XDC2011/Attendees.mdwn @@ -0,0 +1,40 @@ + + +## XDC2011 Attendees + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDC2011|Events/XDC2011]]. Attendance will be limited to approximately 60 people. For organizational purposes, if you would like to add when you will be arriving/departing and where you will be staying, that may be to the convenience of others. + + 1. [[MichaelLarabel|MichaelLarabel]] (out Thurs 15) + 1. [[KenGraunke|KenGraunke]] + 1. [[DanielStone|DanielStone]] + 1. [[ShuangHe|ShuangHe]] (in Sat 10, out Fri 16, Amber Inn) + 1. [[JeremyHuddleston|JeremyHuddleston]] (in Sun 11, out Fri 16, Chicago South Loop) **Extra bed available if you want to split a room** + 1. [[Matt Turner|Matt Turner]] (in Sat 10, out Wed 14, Travelodge Downtown) + 1. [[StuartKreitman|StuartKreitman]] + 1. [[ChrisHalseRogers|ChrisHalseRogers]] + 1. [[BryceHarrington|BryceHarrington]] + 1. [[AlexDeucher|AlexDeucher]] (in Sun 11, out Wed 14, Travelodge Downtown) + 1. [[JeromeGlisse|JeromeGlisse]] + 1. [[MartinPeres|MartinPeres]] (in Fri 09, out Fri 16, HI Chicago) + 1. [[AlanCoopersmith|AlanCoopersmith]] (in Sun 11, Out Thu 15, Club Quarters Central Loop) + 1. [[PeterHutterer|PeterHutterer]] (in Sun 11, out Wed 14, Travelodge Downtown) + 1. [[IanRomanick|IanRomanick]] + 1. [[JesseBarnes|JesseBarnes]] (Crown Plaza Magnificent Mile) + 1. [[KeithPackard|KeithPackard]] (Crown Plaza Magnificent Mile) + 1. [[MatthiasHopf|MatthiasHopf]] + 1. [[LucVerhaegen|LucVerhaegen]] + 1. [[JayCotton|JayCotton]] + 1. [[ChaseDouglas|ChaseDouglas]] + 1. [[JasonGerecke|JasonGerecke]] + 1. [[MattDew|MattDew]] + 1. [[SimonFarnsworth|SimonFarnsworth]] (in Sat 10, out Thur 15, Travelodge Downtown) + 1. [[BenSkeggs|BenSkeggs]] + 1. [[ArvindUmrao|ArvindUmrao]] + 1. [[EamonWalsh|EamonWalsh]] + 1. John Bridgman (in Mon 12, out Wed 14, Travelodge Downtown) + 1. [[TomStellard|TomStellard]] (in Sun 11, out Wed 14, Travelodge Downtown) + 1. [[ShinpeiKato|ShinpeiKato]] + 1. [[BrianCameron|BrianCameron]] + 1. [[CorbinSimpson|CorbinSimpson]] (in Sun 11, out Thurs 15, Travelodge Downtown) + 1. [[LindaGoldstein|LindaGoldstein]] + 1. [[EgbertEich|EgbertEich]]
\ No newline at end of file diff --git a/Events/XDC2011/Notes.mdwn b/Events/XDC2011/Notes.mdwn new file mode 100644 index 00000000..7d4bd54d --- /dev/null +++ b/Events/XDC2011/Notes.mdwn @@ -0,0 +1,71 @@ + +MONDAY SEP 12 + +10:00 am - Jamey Sharp re: Codebase of the future + + * There's lot of code duplication in the codebase. There is an ongoing effort to clean this up but it's not easy. Replacing Xnest, Xepyhr with drivers for the main Xorg server is desirable, but awkward due to the split between input and video drivers. Wanted tricks that we can't yet do: + * Video card hotplug; either real hardware coming and going (e.g. USB display devices), or virtual (moving a graphics card between servers for multiseat). + * Separation of scanout and render - target use is things like using your desktop GPU to render for a USB display device, and hacks like nVidia Optimus. Xcms needs an overhaul to bring it into line with current understanding of colour correction, and hardware capabilities. +11:00 am - Matthias Hopf re: Bringing In New Contributors + + * attracting new contributors - not easy. X is difficult, steep learning curve and not sexy, what can we do? + * Guidelines for contributions - documented on the wiki + * XTS (X Test Suite)- out of date, lots of tests but a good number of them report success but may not actually be correct. Updating these and maintaining them would be a huge chore + * Piglit - good, but not many tests yet and it requires developers to be diligent in writing test cases. + * accessibility in X - what can we do? - probably not much. This belongs at a higher level like the toolkits. It was said that this is throwing the problem over the wall, but Chase pointed out that these days the client composes everything on window and the server essentially just blits the window onto the screen, so the server is completely ignorant as to what's in the window so doing accessibility isn't really possible. (CORRECT THIS IF WRONG.) +3 pm - Daniel Stone, Peter Hutterer, Chase Douglas re: Multi-Touch BoF / Wacom BoF + + * Multitouch work continues. It's not as easy as you might think. Old apps will not have these new features. XKB still a pain point - no redesign has yet worked. Daniel's current plan is a XKB 1.1, losing rarely used features, and extending keycodes to 32-bit. +TUESDAY SEP 13 + +9:10 am - Tom re: compiler stacks + + * Lots of work with LLVM - plenty of issues coming out of this, including how best to integrate LLVM codegen into Mesa. OpenCL is big driver of this work. GLSL, not so much, as shaders tend to be hand-optimized for hardware already. +10:55 am - Shinpei re: [[TimeGraph|TimeGraph]] GPU scheduling + + * Fundamental trick is to implement scheduling in the DRM driver, thus avoiding the need for userspace drivers to co-operate with each other. Research prototype of code is at [[http://rtml.ece.cmu.edu/projects/timegraph/|http://rtml.ece.cmu.edu/projects/timegraph/]] +2:00 pm - Alex re: GPU Virtual Memory + +- planning to start with Cayman (currently shipping) - + +2:40 pm - Luc's talk re: Conference planning + +Fosdem Feb 2012 + + * still same location (ULB Brussels) + * 5000+ attendees + * programs printed in advance so need much earlier planning of program + * better planning may help get larger facility + * Luc needs minimum 6 people committing to talks by Oct 1 +XDC Sep 2012 in Nuremberg + + * central location + * train between Frankfurt / Nuremberg good, many flights from Frankfurt + * should be very easy to find hotels near event, if you can't find you're doing something wrong + * Egbert: enough hotels to support big trade fairs, so between fairs accomodation easy to find + * get onto Metro from airport + * beer gardens can easily hold groups of 50 + * 1 hr to Oktoberfest for Michael + * location TBD, SuSE and university are options +4pm - Q&A panel on attracting new developers + +WED SEP 14 + +9:10am - Jesse Barnes re: DRM Overlay Plane + +10:00am - Ian Romanick re: OpenGL 3.0 + + * Intel expects to have OpenGL 3.0 support in Mesa by the end of the year, but much remains to be done. If it is, mesa 7.12 may actually be released as 8.0. The team gathered for a 1 day activity to itemize all remaining tasks for achieving OpenGL 3.0. Went through the spec and for each requirement wrote down 1 or more tasks to achieve it onto sticky notes, with no task taking more than (1 week?) Then, given N engineers, they posted the sticky notes into N rows; the number of columns == number of weeks needed to implement. Then all tasks were written into a wiki table where people can grab tasks by adding their name. Process is being found to be simple and straightforward for distributed team work. See [[http://dri.freedesktop.org/wiki/WorkQueue|http://dri.freedesktop.org/wiki/WorkQueue]] +11:00am - Martin Peres re: GPGPU + + * General purpose computing on the GPU. Processing needs from academics was discussed as well, but these cases might not fit well within open source development models. +2:00pm - Shuang He re: Auto Regression Analysis + + * Intel's testing group in China does nightly automated regression testing of the X stack. Faults (lockups, crashes, test failures) are detected and recovered from (e.g. machine is power cycled), and then a regression analysis is done via automated tools, which perform automatic git bisection searches to isolate when the fault began. The system can perform up to 100 bisection iterations per night. The tools for this are not open source (yet?) +3:00pm - Jerome Glisse re: GPU kernel and userspace border + + * The API from the kernel GPU driver impacts performance and maintainability and can become a critical bottleneck. Security is a major consideration (over-writing system memory, crashing the computer, etc.) So we can't permit open source drivers to directly feed GPU commands. Jerome discussed an alternative way to build the graphics stack to work around this issue, permitting both high performance and strong security. +4:00pm - Jeremy Huddleston re: Release Schedules + + * Jeremy showed the past schedule of releases. X.org has gotten better at sticking to a regular schedule for rc's and releases. Any regression without a credible fix within one week is going to be reverted by Keith Packard. Should the DDX drivers be merged back into the xserver tree? Pros: Easier to propagate API changes across drivers (easier ABI); incentives driver developers to work on server; allows dropping server compat code from drivers; increased testing coverage since users would have to build server in order to test drivers. Cons: More work for distros to backport just driver changes; harder for users to upgrade drivers independently. There was much debate on this topic; there were insufficient stakeholders present to try to achieve a decision nor were any votes taken. The actual mechanics of how this would be managed were examined. A suggestion was made to perhaps post this as a referendum to the X membership. +4:45pm - X.Org Foundation session, Conclusion (XDS2012 Ideas?) diff --git a/Events/XDC2011/Program.mdwn b/Events/XDC2011/Program.mdwn new file mode 100644 index 00000000..e7ad1748 --- /dev/null +++ b/Events/XDC2011/Program.mdwn @@ -0,0 +1,89 @@ + + +# XDC 2011 program + + +## Schedule + +**If you would like to add a talk or change information regarding your talk, please edit the Ideas section below the schedule or contact [[MichaelLarabel|MichaelLarabel]], and it will be added to the schedule or if anything needs to be re-arranged.** + +**11 September (Sunday; ~14.00+):** For anyone arriving into Chicago early, on Sunday at around 2:00PM (and will likely be there for several hours thereafter) there will be several X.Org developers meeting up at [[Snickers|http://www.yelp.com/biz/snickers-chicago]] ([[Google Maps|http://maps.google.com/maps/place?cid=17973169954687798724&q=Snickers+Chicago&gl=us&ved=0CBEQ-gswAA&sa=X&ei=q-JnToWkMZugMuv_4LYE]], a fairly traditional and decent American "dive bar". The location is quite ideal (located at 448 N State St and one block away from a Red line CTA train), there's several other bars and restaurants within easy walking distance to go after meeting up, a good selection of alcohol with decent prices, friendly bartenders, and we should have nearly the entire bar to ourselves. Several developers may also end up on there on Saturday. If any questions or more info contact [[MichaelLarabel|MichaelLarabel]]. +[[!table header="no" class="mointable" data=""" + **12 September (Monday)** ||| + 9:00 | Welcome coffee - registration | [[MichaelLarabel|MichaelLarabel]] + 10:00 | Codebase of the future | [[JameySharp|JameySharp]] + 11:00 | Bringing In New Contributors | [[MatthiasHopf|MatthiasHopf]] + 12:00 | Lunch break || + 14:00 | XKB 1.1 | [[DanielStone|DanielStone]] + 15:00 | Multi-Touch BoF / Wacom BoF | [[DanielStone|DanielStone]], [[PeterHutterer|PeterHutterer]], [[ChaseDouglas|ChaseDouglas]] + 16:00 | Driver Support BoF | Daniel Stone +"""]] +[[!table header="no" class="mointable" data=""" + **13 September (Tuesday)** ||| + 9:00 | Welcome coffee | ```Coffee Table``` + 9:10 | Compiler Stacks | [[TomStellard|TomStellard]] + 10:10 | Nouveau | [[MartinPeres|MartinPeres]] + 10:55 | [[TimeGraph|TimeGraph]] / GPU Scheduling | [[ShinpeiKato|ShinpeiKato]] + 11:30 | LLVM In Mesa | Ian Romanick + 12:30 | Lunch break || + 14:00 | _Phoronix-Sponsored Beer Afternoon_ (~2:30PM to 5PM) | + 14:10 | Graphics Memory Management | [[AlexDeucher|AlexDeucher]] + 16:00 | [[Contributing To X.Org & Open-Source Panel Discussion|http://www.phoronix.com/scan.php?page=news_item&px=OTg3NQ]] | [[MichaelLarabel|MichaelLarabel]] Panel: [[PeterHutterer|PeterHutterer]], [[MartinPeres|MartinPeres]], [[CorbinSimpsom|CorbinSimpsom]], [[KeithPackard|KeithPackard]], [[MattDew|MattDew]], [[KenGraunke|KenGraunke]] +"""]] +[[!table header="no" class="mointable" data=""" + **14 September (Wednesday)** ||| + 9:00 | Welcome coffee | ```Coffee Table``` + 9:10 | DRM overlay plane | [[JesseBarnes|JesseBarnes]] + 10:00 | OpenGL 3.0 | [[IanRomanick|IanRomanick]] + 11:00 | GPGPU | [[MartinPeres|MartinPeres]] + 11:45 | Lunch break || + 14:00 | Auto Regression Analysis | [[ShuangHe|ShuangHe]] + 15:00 | GPU kernel and userspace border | Jerome Glisse + 16:00 | Release Schedules | [[JeremyHuddleston|JeremyHuddleston]] + 16:45 | X.Org Foundation session, Conclusion (XDS2012 Ideas?) | +"""]] + + +## Ideas + +* Multitouch BoF ([[DanielStone|DanielStone]], [[PeterHutterer|PeterHutterer]], [[ChaseDouglas|ChaseDouglas]]) + * Status, plans, etc +* XKB 1.1 ([[DanielStone|DanielStone]]) + * Not XKB 2. +* Auto regression Analysis ([[ShuangHe|ShuangHe]]) + * Introduction, plans +* Nouveau ([[MartinPeres|MartinPeres]],[[ShinpeiKato|ShinpeiKato]]) + * Community, past, present and future work (30 minutes) ([[MartinPeres|MartinPeres]]) +* [[Towards DRM-compliant GPU scheduling at the device driver level|http://rtml.ece.cmu.edu/projects/timegraph]] ([[ShinpeiKato|ShinpeiKato]]) + * To be scheduled after the Nouveau talk, if possible + * 30-45 minutes, to be scheduled on the 13th or the 14th +* DRM overlay plane API ([[JesseBarnes|JesseBarnes]]) + * review of new ioctls, platform considerations +* GPGPU (Informal talk? Proposed by [[MartinPeres|MartinPeres]]) + * What we can already do, what do we want and what needs to be done + * Meant as a follow-up of the OpenCL GSoC and the pscnv work + * A compute abstraction layer (driver-side): [[ShinpeiKato|ShinpeiKato]] + * 30 minutes, to be scheduled on the 13th or the 14th +* Automated Per-Commit Testing Of Mesa Drivers ([[MichaelLarabel|MichaelLarabel]]) + * Introduction, Demonstration of Nouveau/Radeon/Intel + * Seek feedback, ideas +* Driver support BoF +* BoD BoF (X.Org [[BoardOfDirectors|BoardOfDirectors]]) +* Release Schedules (Volunteer: [[JeremyHuddleston|JeremyHuddleston]], Voluntold: [[KeithPackard|KeithPackard]], [[AlanCoopersmith|AlanCoopersmith]]) + * Rolling drivers into main xserver? +* Wacom BoF ([[PeterHutterer|PeterHutterer]]) + * Status, where to go from here? (probably not of interest to those not working on wacom) +* LLVM as a requirement for Mesa ([[IanRomanick|IanRomanick]], discussion) + * It's useful for a lot more than generating code for shaders... +* Compiler Stacks ([[TomStellard|TomStellard]]) + * Supporting OpenCL + * Using LLVM as an IR + * Better code generation for backends + * Discussion about the current status of various MESA IRs? + * Remaining refactors leading to using GLSL IR to represent ARB_vertex_program / ARB_fragment_program assembly shaders ([[IanRomanick|IanRomanick]]) +* Codebase of the future! (discussion, [[JameySharp|JameySharp]]) + * X needs to do more in less code. What are our biggest cleanup targets? + * To kick things off: in xserver, I suggest unifying DDX and DIX as the big goal. +* Contributing To X.Org & Open-Source [Panel Discussion, [[MichaelLarabel|MichaelLarabel]]] +* The long, hard road to OpenGL 3.0 ([[IanRomanick|IanRomanick]]) +* Methods of Attraction - How to gain more contributors ([[MatthiasHopf|MatthiasHopf]])
\ No newline at end of file diff --git a/Events/XDC2012.mdwn b/Events/XDC2012.mdwn new file mode 100644 index 00000000..2c54436b --- /dev/null +++ b/Events/XDC2012.mdwn @@ -0,0 +1,135 @@ + + +# XDC2012: Nürnberg, Germany +[[!table header="no" class="mointable" data=""" + [[<< XDC 2011|Events/XDC2011]] | **XDC 2012** | XDC 2013 +"""]] + +* [[Attendees|Events/XDC2012/Attendees]] +* [[Program|Events/XDC2012/Program]] +* [[BookSprint|Events/BookSprint2012]] +* [[Weekend Event|Events/XDC2012/Weekend]] +* [[Proceedings and Recorded Videos|Events/XDC2012/Proceedings]] +* Experimental Live Video - Closed +The 2012 X.Org Developer Conference (XDC2012) is to be held from September 19th thru 21st 2012 in Nürnberg (Nuremberg), Germany. The event will be hosted by [[SUSE|http://www.suse.com]] at their company headquarters in Nuernberg. Please join us to celebrate the 25th anniversary of the first [[X11 release|http://groups.google.com/group/comp.windows.x/browse_thread/thread/3454f7031d88a3b8#]] (15 September 1987, but we'll round a bit) during this conference, we are looking forward to seeing you. An after-conference weekend event will be organized to honor this date [[(check below)|Events/XDC2012]]. + + +## Venue + +The conference will be held in the main conference room at the SUSE headquarters at [[Maxfeldstrasse 5|http://maps.google.de/maps?f=q&source=s_q&hl=de&authuser=0&q=Maxfeldstra%C3%9Fe+5,+Altstadt+und+Engere+Innenstadt+90409+N%C3%BCrnberg,+Bayern&aq=&vps=1&jsv=402e&sll=51.151786,10.415039&sspn=14.100269,34.936523&vpsrc=1&ie=UTF8&oi=georefine&ct=clnk&cd=2&geocode=FT2y8gIdqRupAA&split=0]]. + +The conference room is easy to find: it is directly accessible from the outside. If you are coming from Pirckheimerstrasse turn into Maxfeldstrasse and walk uphill along the blue building on the right until you get to a free area on your right. From there you can enter the conference room directly. You will find a sign at the door. + +Please note: for security reasons the door is locked. The door will be open in the morning before the conference and after lunch. If you need to get in at other times and you find the door locked you will find my mobile number on a sign at the door. Please call me so I can let you in. As attendee you will get a conference badge, please carry the badge with you at all times when you are inside the building. + + +## Program + +There are two ways to submit a presentation for this event: + +1. There is a [[Call for Papers|http://www.x.org/wiki/Other/Press/CFP2012_supplemental]]. The deadline for submission is August, 15, 2012. +1. For more informal presentations you may add your talk to the [[program page|Events/XDC2012/Program]]. The deadline for submission here is September 14, 2012. +For more information please also check [[here|http://www.x.org/wiki/Other/Press/CFP2012_supplemental]]. A schedule will be available shortly. + + +## Videos + +Recorded videos of the session are available from [[YouTube|http://www.youtube.com/phoronix]]. + + +## Registration + +If you want to attend XDC2012 please add your name to the [[attendees page|Events/XDC2012/Attendees]]. Additionally please subscribe to the [[X.org events mailing list|http://lists.x.org/mailman/listinfo/events]] where we will post regular updates. + + +## Accommodation + +There are a number of affordable hotels in Nuernberg (especially since we painstakingly avoided any week with a major trade show), many close to the conference venue. + +We have a recommended conference hotel as we are in the process of negotiating a special conference rate. This hotel should not only offer you good rates it is also at a convenient 5 minute walking distance from the conference venue. There is a separate [[hotel page|Events/XDC2012/Hotels]]. + + +## Travel + +Nuernberg can be reached: + +* By **plane**. The Nuernberg Airport is close to the city and can be reached by local transportation in just a few minutes. Nuernberg airport is serviced from some international locations, still expect to travel via Franfurt or Munich. If possible you should avoid Munich at that time as Octoberfest will start directly following the event. If you fly via Frankfurt, you have the choice between flying on to Nuernberg or taking the train and enjoying a bit of the countryside: An railroad station is located right at the airport (Frankfurt(M) Flughafen Fernbf.) where you can board a high speed train going to Nuernberg at least every hour. The train offers more comfort and leg room than coach class on airplanes and also provides electrical power outlets. +* By **train**. Nuernberg is located conveniently on a major high speed train line (ICE) running to Munich (1 hour), Frankfurt (2h), Cologne, Berlin and several other major cities. It can also be reached conveniently by train from anywhere else in Europe, too. You can search for [[connections|http://www.bahn.de]] and [[purchase tickets|http://www.bahn.de]] ([[English website|http://www.bahn.com/i/view/USA/en/index.shtml]]) on-line with any major credit card. The train station is just a few subway stops away from the conference venue and preferred hotel. The train station in Nuernberg is **Nürnberg Hbf**, and the train station at the Frankfurt airport is **Frankfurt(M)Flughafen** +* By car. The conference hotel offers guest parking (for an additional charge). Those of you who do plan to take the car will figure out the rest ;-) + +## Local transportation + +Nuernberg has an excellent public [[transportation system|http://www.vng.de]]: Most locations in Nuernberg can easily be reached by public transportation. + +Tickets are available from vending machines at any stop (see also our hints on using public transportation). The conference venue and hotel can be reached on subway line 3. Please also check out our [[tips on public transportation|Events/XDC2012/PublicTransportation]]. + +It is unlikely that you will need any public transportation during the time of the conference, though, as the venue is conveniently located just north of the inner city. The inner city can conveniently be accessed by foot: it is only roughly 1km from east to west and 1.5km from north to south. For lines please check [[here|http://www.vgn.de/liniennetze/schienennetz_nuernberg_furth/]]. + + +## Local Dining + +The conference venue is right outside the old city wall, thus in close walking distance from the city center. There are many restaurants close-by as well as towards the city center. Just walk down the street or ask for recommendations on site. + +Also check out the [[Nuernberg Tourist Information|http://tourismus.nuernberg.de/]]. + + +## Remote Participation + +For those who cannot make it to the conference we are planning to record the sessions. We may even have a live stream, also participation via IRC should be available. + + +## Travel Sponsoring + +If you are not on a corporate budget but have something to present, please contact the X.Org Foundation Board of Directors [[board@foundation.x.org]] for travel sponsorship. + + +## Miscellaneous + +Germany uses Type E/F [[hybrid plugs (CEE7/7)|http://en.wikipedia.org/wiki/AC_power_plugs_and_sockets]] and [[Euro plugs|http://en.wikipedia.org/wiki/Euro_plug]] at 230V/50Hz. People should remember to bring their own adapters. + +The currency is Euro (EUR), language is German. Hotel and restaurant staff should speak some English, since Nuernberg is a tourist town many restaurants have English menus available. + +Major credit cards (AMEX, Visa and M****asterCard) are accepted at most hotels and restaurants. Some pubs and beer gardens may require cash. + + +## After Conference Events + +<a name="beer_hiking_trip"></a> If you can spare the weekend after the conference - hang around with us to celebrate the 25th anniversary of the first release of X11 and join us for [[a beer hiking trip thru the 'Fraenkische Schweiz'|Events/XDC2012/Weekend]] on Saturday. On Sunday, [[a visit to the Nazi Party Rally Grounds|Events/XDC2012/Weekend]] will take place. + +In nearby Munich, from 22 September to 7 October is Oktoberfest. [[Michael Larabel|http://www.michaellarabel.com/]] is able to provide tours of München / the wiesn (with either a historical and/or beer focus) at any point after the first Saturday (22nd). + + +## Further Inquiries + +If you have any questions regarding the event please feel free to contact me at [[egbert.eich@gmail.com]]. + + +## Thanks + +The organizers want to thank: + +* the 'SUSE Linux Products GmbH' which provided the venue as well as funds for coffee breaks. +* 'Phoronix' for the beer. +Our Helpers + +* [[Omar Gomez Rey|http://omar-gomez-rey.de]] for setting up the conference room +* Oliver Fecher for organizing the conference room +* Salvatorica Serra for organizing the catering +* Iwona Maher for infrastructure support +* Christian Deckelmann for setting up the network +* Jürgen Weigert for video recording +* Gerhard Schlotter for helping out keeping the room open and getting some last minute printing done. + +## Links + +[[Email Announcement|http://lists.x.org/archives/xorg-devel/2012-March/030164.html]] + +[[Email Update #1|http://lists.x.org/archives/xorg-devel/2012-August/033131.html]] + +[[Email Update #2|http://lists.x.org/archives/xorg-devel/2012-August/033360.html]] + +[[Email Update #3|http://lists.x.org/archives/xorg-devel/2012-September/033634.html]] + +[[Email Update #4|http://lists.x.org/archives/xorg-devel/2012-September/033641.html]] + +[[Email Update #5|http://lists.x.org/archives/xorg-devel/2012-September/033642.html]] diff --git a/Events/XDC2012/Attendees.mdwn b/Events/XDC2012/Attendees.mdwn new file mode 100644 index 00000000..0eff41c4 --- /dev/null +++ b/Events/XDC2012/Attendees.mdwn @@ -0,0 +1,64 @@ + + +# XDC2012 Attendees + +Please list your name here (and subscribe to the mailing list) if you are planning to attend XDC2012. Attendance will be limited to approximately 60 people. For organizational purposes, if you would like to add when you will be arriving/departing and where you will be staying, that may be to the convenience of others. + +1. [[MatthiasHopf|MatthiasHopf]] (IRC: emmes) +1. [[LucVerhaegen|LucVerhaegen]] (IRC: libv) +1. [[EgbertEich|EgbertEich]] (IRC: egbert) Hotel: Azimut +1. [[MichaelLarabel|MichaelLarabel]] (IRC: michaellarabel) +1. [[MichelDaenzer|MichelDaenzer]] (IRC: [[MrCooper|MrCooper]]) +1. [[AlanCoopersmith|AlanCoopersmith]] (IRC: alanc) (Hotel: [[Woehrdersee Hotel Mercure|https://plus.google.com/103669440673257991258/about]]) +1. [[KeithPackard|KeithPackard]] (IRC: keithp) +1. [[MatthieuHerrb|MatthieuHerrb]] (IRC: mherrb) (Hotel: Azimut. Arr Hbf tuesday 19h59 from FRA) +1. [[StefanDirsch|StefanDirsch]] (IRC: sndirsch) +1. [[MartinPeres|MartinPeres]] (IRC: mupuf) +1. [[MarioKleiner|MarioKleiner]] +1. [[LucasStach|LucasStach]] (IRC: lynxeye) +1. [[SaschaHlusiak|SaschaHlusiak]] +1. [[MattDew|MattDew]] (IRC: marcoz) (hotel: Azimut) +1. [[MartinGraesslin|MartinGraesslin]] +1. [[MichaelHasselmann|MichaelHasselmann]] (IRC: mikhas) +1. [[JeromeGlisse|JeromeGlisse]] (IRC: glisse) +1. [[DanielMartin|DanielMartin]] +1. [[MaartenLankhorst|MaartenLankhorst]] (IRC: mlankhorst) +1. [[U0001f42b LarsDɪᴇᴄᴋᴏᴡ U0001f42b|LarsDɪᴇᴄᴋᴏᴡ]] +1. [[PeterHutterer|PeterHutterer]] (IRC: whot) +1. [[BenSkeggs|BenSkeggs]] (IRC: darktama) +1. [[DanielVetter|DanielVetter]] (IRC: danvet) +1. [[ArvindUmrao|ArvindUmrao]] +1. [[MichalSrb|MichalSrb]] (IRC: msrb) +1. [[ChristianKoenig|ChristianKoenig]] +1. [[AndyRitger|AndyRitger]] +1. [[KristianHoegsberg|KristianHoegsberg]] (IRC: krh) +1. [[JanArnePetersen|JanArnePetersen]] (IRC: jpetersen) +1. [[BarryScott|BarryScott]] +1. [[SimonFarnsworth|SimonFarnsworth]] (IRC: farnz) +1. [[IanRomanick|IanRomanick]] (IRC: idr) +1. [[ChadVersace|ChadVersace]] +1. [[FranciscoJerez|FranciscoJerez]] (IRC: curro) +1. [[EricAnholt|EricAnholt]] (IRC: anholt) +1. [[MarcBalmer|MarcBalmer]] (IRC: mbalmer) +1. [[SimonNiklaus|SimonNiklaus]] +1. Supreet Pal Singh +1. Timothée Ravier +1. [[OliverMcFadden|OliverMcFadden]] (IRC: omcfadde) - AZIMUT Hotel Nuremberg. Arrival: Tuesday 18 Sep @ 17:45. Nuremberg Airport. Departure: Sunday 23 Sep @ 18:25. +1. [[MichaelSchuldt|MichaelSchuldt]] +1. [[BenBrewer|BenBrewer]] (IRC: flatmush) +1. [[RobClark|RobClark]] (IRC: robclark) - hotel:Azimut, arrive:Tues midday(ish).. (1130@FRA, then train) +1. [[JessVanDerwalker|JessVanDerwalker]] +1. [[HaraldKoenig|HaraldKoenig]] +1. [[BartMassey|BartMassey]] +1. [[KonstaKarsisto|KonstaKarsisto]] +1. Blaž Tomažič +1. [[StuartKreitman|StuartKreitman]] (IRC: stukreit) +1. [[MarcinSlusarz|MarcinSlusarz]] (IRC: joi) (hotel: Azimut) +1. [[ChristophBumiller|ChristophBumiller]] (IRC: calim) +1. Mathias Fröhlich +1. [[JoeBurmeister|JoeBurmeister]] +1. Lubosz Sarnecki (IRC: lubosz) +1. Markus Schlüter +1. Gerhard Schlotter +1. Juergen Weigert +1. [[MichaelKerrisk|MichaelKerrisk]]
\ No newline at end of file diff --git a/Events/XDC2012/Hiking.mdwn b/Events/XDC2012/Hiking.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Events/XDC2012/Hiking.mdwn diff --git a/Events/XDC2012/Hotels.mdwn b/Events/XDC2012/Hotels.mdwn new file mode 100644 index 00000000..360969ac --- /dev/null +++ b/Events/XDC2012/Hotels.mdwn @@ -0,0 +1,38 @@ + + +## XDC2012 Hotels + +The preferred conference hotel is the Azimut Hotel: + +**[[AZIMUT Hotel Nuremberg ***|http://www.azimuthotels.de/hotelstandorte/index.php?SECTION_ID=270&IBLOCK=7&SUBSECTION_ID=TOP]] +** Kaulbachstrasse 1 + D - 90408 Nuernberg + phone: +49 911 3657 - 0 + fax: +49 911 3657 - 488 + email: [[info.nuernberg@azimuthotels.com]] + for reservation: [[reservierung.nuernberg@azimuthotels.com]] + We've got a number of rooms held for XDC participants for **EUR 68/night** for a single room including breakfast and wireless access. + Please make your reservation until August 18th, 2012, state **Res.No.142733** with your reservation. + +Parking garage available at extra cost. + +**Update: the period has ended and the hotel has informed me that it is now completely booked out.** You may still be able to find a room at the other hotels listed. + +This hotel is [[500 meters away|http://maps.google.de/maps?saddr=Pirckheimerstra%C3%9Fe&daddr=49.4608619,11.0772507+to:Maxfeldstra%C3%9Fe+5,+904\09+N%C3%BCrnberg&hl=de&ie=UTF8&ll=49.461507,11.08115&spn=0.003563,0.008529&sll=49.461556,11.078886&sspn=0.003563,0.008529&geocode=FX228gIdZgapAA%3BFX228gIdggapACnHInTZsFefRzFBH6SaMtoeEw%3BFae18gIdRx6pACl_i-ksulefRzFD1xgwc0v1Kg&dirflg=w&mra=dpe&mrsp=1&sz=17&via=1&t=m&z=17]] from the venue. + + +There are a few other hotels in the area, notably: + **[[Hotel Burgschmiet GmbH ***|http://www.hotelburgschmiet.de/index.php/en/]]** + Burgschmietstr. 8 + 90419 Nürnberg + phone: +49 911 93 33 60 + fax: +49 911 93 33 620 + email: [[info@hotel-burgschmiet.de]] + +**[[Noris Hotel Nürnberg ***|http://www.noris-hotel.de/]]**(formerly Nestor Hotel Nürnberg) + Bucher Straße 125 + D-90419 Nürnberg + phone: +49 911 3476-0 + fax: +49 911 3476-113 + email: [[service@noris-hotel.de]] + Parking garage and Wifi available at extra cost. diff --git a/Events/XDC2012/Proceedings.mdwn b/Events/XDC2012/Proceedings.mdwn new file mode 100644 index 00000000..62e0252a --- /dev/null +++ b/Events/XDC2012/Proceedings.mdwn @@ -0,0 +1,633 @@ + +These are rough notes (provided by [[SimonFarnsworth|SimonFarnsworth]], whose travel to XDC was paid for by [[ONELAN Digital Signage|http://www.onelandigitalsignage.com/]]), plus links to the video recordings. Please feel free to improve the notes; they're there to help you decide whether to watch the recording or not. + +[[!toc ]] + + +# Day 1 + + +## Board presentation + +[[http://www.youtube.com/watch?v=tiNU_zyDUJo|http://www.youtube.com/watch?v=tiNU_zyDUJo]] + +The X.org foundation supports development, rather than controlling it. + +Foundation is now a US 501(c)(3) charity (thanks to SFLC). Board meetings open and public. + +Book sprint to write developer docs has happened (one in March, one in September). Results will be published on wiki. + +Xorg has just joined [[OIN patent pool|http://www.openinventionnetwork.com/]]. + +The war chest is shrinking back to a sensible size; the foundation will soon need to fundraise. Current balance is around $85,000, run rate is around $30k/year. Can burn for 3 years before going bankrupt, but would prefer to find new funding sources. Old funding sources were big UNIX workstation vendors; foundation expects new funding sources to be smaller sums per contributor. + +Infrastructure (shared with freedesktop.org) is a challenge, but being worked on; new sysadmin hired and will be working on web stability. + +EVoC had 5 students this year; 4 succeeded. Question - does EVoC replace Google Summer of Code, or does X.org need to work out why we weren't accepted and get back into GSoC in future years? + +Various IP issues (new logo etc). Also need to revise foundation bylaws. Note; foundation is not tied to X.org (25 years old!), and will continue with Wayland or any other graphical stack that subsumes X11. + +Usual need to get more developers on board. + + +## EVoC + +[[http://www.youtube.com/watch?v=kOgh2EpKfSo|http://www.youtube.com/watch?v=kOgh2EpKfSo]] + +Endless Vacation of Code is inspired by Google Summer of Code, but funded by X.Org foundation. No time restrictions, but 3 month long projects (doesn't have to be summer). + +Goal is to get students to become X.Org developers (productive output from EVoC is a bonus); covers the entire graphics stack, basically from drivers (OpenCL, DDX, OpenGL etc) up to the layer beneath the toolkits. It's not meant to provide a wage, just to let you work on X.Org instead of flipping burgers over a long vacation. + +Puts extra load on mentors; honestly interested students are welcomed whole heartedly and are worth the extra load, but if you're not actually interested, please don't waste their time (EVoC is not free money for students). Mentor has to establish that student is competent to tackle project, and provide regular assistance to keep you on track. Board relies on mentor's judgement to evaluate students. + + +## Graphics stack security + +[[http://www.youtube.com/watch?v=hJpiJii44oo|http://www.youtube.com/watch?v=hJpiJii44oo]] + +Inspired by driver development book sprint. These guys aren't driver developers, and had to learn for this presentation. + +Security is a trifecta - confidentiality, integrity, availability. + +Users have expectations - e.g. cross-app communication is drag-and-drop or cut-and-paste, and therefore under my control. X breaks this - get the auth cookie, you have full access (can keylog, can screenshot as credit card number is typed). Isolation is therefore between users, not between one user's apps. + +Problem - all apps grow, and have bugs. Any exploitable bug in any app lets you have full access to the user's desktop session. + +So, confidentiality breach; keyloggers, screenshots at interesting moments. Integrity breach; draw over Firefox, so that the user can't tell that you've redirected them from their bank to a phishing site. Any application can act as a "virtual keyboard", and type - another integrity breach. Availability breach - any application can act as a screen locker. ClearGrab bug - a virtual keyboard app can kill a screen locker. + +Current mitigations: XSELinux has fine grained access control, but normally deactivated as default distro policy doesn't confine users. Xephyr can provide virtual X screens - but coarse grained, so tricky to use right. + +QubesOS uses VMs to solve security problem. PIGA-OS uses SELinux + XSELinux + PIGA-SYSTRANS daemon to solve it. + +QubesOS groups apps into security domains. Each security domain is a Xen domU; X server provided for each domain has colourful marking to indicate security domain, inter-domain comms via a daemon in dom0, which implements MAC. + +PIGA maps security domains to SELinux types, labels everything. SYSTRANS grants rights as needed, prompting users if this is a cross-domain move. + +Wayland moves the security problem into the compositor - events unicast, so compositor has control needed to secure everything. However, compositor is then attack target - how to solve this? Privilege separation? We have an opportunity to fix things here, let's not waste it. + +Driver/hardware story not too bad - CPU can't access arbitrary VRAM unless root. Opensource drivers not too bad at GPU isolation between users - mix of VM contexts and switching contexts on GPU, and command validation - scan commands and stop user doing things it shouldn't. Trades context switch cost for CPU time. + +Goal is per-GPU-process isolation, just like we have per-CPU-process isolation on the main CPU. Think about information leakage (uncleared buffers), privileged plugins (e.g. to compositor) scanning address space (ASLR helps?) etc. + + +## Solaris privilege separated X11 + +[[http://www.youtube.com/watch?v=hphjH2KYGAw|http://www.youtube.com/watch?v=hphjH2KYGAw]] + +Solaris can run X without root privileges. Aim is to upstream as much of this as possible. + +Solaris Xorg creates a named pipe for GDM to X11 comms, and runs Xorg as root. At login, GDM tells X (via pipe) about new user. X switches UID, but keeps root as its saved UID (POSIX-compliant) so it can become root again when it needs to (VT switch, regen). + +Solaris has facilities to set device ownership/permissions on a VT and all associated on login; Xorg uses those facilities to ensure that it can open devices as the user, rather than becoming root. + +Patches linked from slides. Side note - UEFI secure boot locks out most non-KMS drivers, so we have to work out what we do about hardware like MGA. + + +## Dante: chasing performance + +[[http://www.youtube.com/watch?v=PYGeXko_xf0|http://www.youtube.com/watch?v=PYGeXko_xf0]] + +Oliver took Doom3 (8 years old) GPL3+ release, ported from OpenGL 1.x with extensions (depending on backend used) to EGL and OpenGL ES 2.0 (including clean-room creation of GLSL shaders to replace the ARBfp/ARBvp shaders), then tried to make the OpenGL ES 2.0 version perform well. + +No good performance analysis tools for Mesa. "Best" available is `intel_gpu_top` for i965 driver hardware, but it's a top-like coarse-grained performance tools. Also not user-friendly, as represents load as hardware units (so you need to read HW docs to have a clue what's going on if it's showing an issue). + +Every closed driver vendor has decent tools - AMD bought gDEBugger, and made it fglrx-only, other vendors have equivalent tools. Older version of gDEBugger sort-of works with Mesa, sometimes. Mesa has nothing. + +Linux has perf infrastructure - lots of performance counters and sampling with source code annotation of results. Nice profiler; can we reuse for GPU performance? Hook DRM and intel_gpu_top data in, rely on existing tools for UI. Need userspace co-operation to get all the way (per-frame indication without GPU stall, so that profile can be interpreted per-frame). + +Mesa's best infra so far is perf_debug - but not tied to ARB_debug_output, just to stdout. Also not frame boundary aware - so no way to tie perf_debug output to render operations. + +Given all these hints, how do we cope with separate debugger processes? + +Oliver found a GLX versus EGL bug. Others may exist. + +Intel avoided the need for tools to fix Valve's L4D2 - they sent skilled engineers in instead - this does not scale, so tools are needed. + +Comment at end from audience - apitrace is being developed into one profiling tool (although only runs on captured traces, not on live apps); work is underway on a shimGL that hooks live. + + +## Phoronix benchmarking + +No video. Contact [[MichaelLarabel|MichaelLarabel]] for more information. + +Michael would like developers to expose performance information (clocks, utilization %age, thermals) in a consistent fashion (e.g. standard sysfs files, with speeds in kHz). Please all behave the same, though. + +Remaining discussion was Michael asking how Phoronix can be useful to driver devs, even though benchmarks are end-user targeted. + +Some discussion of goals of benchmarks, agreement from floor that devs can write their own benchmarks to target individual bits of the driver. Big thing Michael can do is benchmark git snapshots regularly, and bisect performance regressions. + + +## DRI3 + +[[http://www.youtube.com/watch?v=ZLnl6s60YL8|http://www.youtube.com/watch?v=ZLnl6s60YL8]] + +DRI2 fixed the SAREA disaster of DRI1. Experience (including implementing Wayland) has shown that DRI2 has pain points, so let's discuss DRI3 to fix these pain points. + +Underlying issue is X server allocating buffers, and thus having to synchronise tightly with clients. DRI3 aims to make GLX buffer management similar to Wayland (clients allocate, "present frame" from glSwapBuffers becomes send buffer to X). Can we avoid having the server tell the client how big the buffer is (e.g. by relying on glViewport and providing an extension for apps where the bounding box of all viewports is not the buffer size)? + +DMABUF may let us remove GEM handles from the pile - pass a private DMABUF fd via the UNIX socket, instead of a guessable GEM handle. Lots to consider here - YUV buffers, buffer sharing etc. + +DRI3 can now flip when window size matches buffer size - blits only needed if size mismatch (so client/server disagree on window size, so something will go wrong anyway). + +Identifying reusable buffers is also a challenge. + +Discussion will be on mailing list - this talk is to get people thinking about it. + + +## Board meeting + +[[http://www.youtube.com/watch?v=J9QpJEwfLM0|http://www.youtube.com/watch?v=J9QpJEwfLM0]] + +New logo is needed. The board will fund a contest if someone steps up to run it, provided the board gets trademark, copyright on resulting logo. + +Election cycle upcoming - 4 to replace as per bylaws. + +Finances are now about what the board wants to run with - time to raise money to stay put. + +Foundation no longer paying for hosting at MIT - now hosted at PSU, sharing infrastructure with freedesktop.org. Machines donated by Sun Microsystems. + +New sysadmin starting this week, will start by working on web service reliability. + + +# Day 2 + + +## X Server Integration Testing + +[[http://www.youtube.com/watch?v=dZTz151SJLw|http://www.youtube.com/watch?v=dZTz151SJLw]] + +This is around 1 month's experience so far - most things up for change as a result. + +Rationale - testing is hard. Manual testing hurts. Regressions happen if there's no easy tests to find them. + +XTS is not the right test suite for lots of good reasons, but has 1,000 test cases to learn from. We need combined server + driver tests. It must be really easy to write test cases (otherwise no-one bothers). They must be easy to run, and the output must be easy to parse, so that people get in the habit of trying tests. + +New thing is XIT - based on xorg-gtest which is based on googletest C++ framework. Peter showed some example tests. + +Some problems; no shared library => Is gtest the right framework? Server can be slow to start - Keith thinks this should be treated as a bug (server start should always be fast). Issues with version combinations and distro-specific results. Documentation of test cases also an issue - remembering why you wrote it, and what it's supposed to tell you. + +Googletest good at controlled execution of subset of tests - can select by regex, for example. Would be nice to combine XIT with tinderbox, for continuous testing - we're good at fixing compile fails flagged by tinderbox. + +On to Q&A. Currently Linux-tied by uinput - can do equivalents for non-Linux systems. However, this also means no special hardware needed - events are faked by uinput, so you can test things you don't have. + +XTS is broken - written as a contracted piece of work by non-X people, so many tests are broken. How do we recover the valuable bits of XTS? Peter currently not interested in this, as wants driver tests first, protocol tests like XTS can come later. + +Googletest not a Google service, just a chunk of code from Google. No tie-in to G+ etc. + +Tests aim to observe user-visible behaviour - no driver internal state examination needed. + +Contrast to Wayland's test infra (simpler); will Wayland test infra become as complex as googletest, or is googletest too complex for the use case. + +Can be extended for output tests - rendercheck is apparently broken, but we have the concept to hand. + +Can also produce nice XML for processing into tinderbox-style HTML. + +If we redo XTS, we need to avoid the code dump problem we have - but formal specification and RFP process valuable. + + +## Hardware independent accelerated graphics + +[[http://www.youtube.com/watch?v=Qc5dFnBCHas|http://www.youtube.com/watch?v=Qc5dFnBCHas]] + +Today, we have multiple DDXes; a select few do modern acceleration, and only the big three (Intel, Radeon, Nouveau) have high quality modern acceleration. We removed XAA from all DDXes, as not useful in the modern world. + +Hard to implement acceleration - XRender does a lot, and drivers only accelerate "popular" XRender paths - but popular changes with time. We're developer time limited - unless we acquire many developers suddenly, we won't be able to accelerate everything easily. + +Three attempts so far at generic acceleration - glamor, st/xorg, st/xa (OpenGL, Gallium, Gallium). Benchmarks used to determine if any of them help. + +All tests run on AMD E-450 with 8GB RAM, as Radeon supports EXA, glamor and Gallium. 25 cairo traces used to provide representative sample of operations. All tests baselined against image backend (CPU rendering). + +No graphs - Phoronix will produce if considered helpful - just some interesting points. First, only CPU and EXA accel could survive all traces - glamor triggered one panic, st/xorg triggered 3 and fails to cope with tiled scanout (interesting pictures). st/xa is not complete enough to test easily. + +CPU rendering usually faster (except when test is fillrate limited). Only Intel's SNA acceleration is as fast as CPU rendering in almost all cases - but don't get fooled by speed, as acceleration is also about responsiveness under load (reduced CPU use by graphics => more CPU for user applications). + +Glamor is only maintained option - st/xorg, st/xa not actively developed, and both have issues. But glamor is slow, and "fights" OpenGL to do 2D ops (claim from floor that this is mostly because Gallium is a heavyweight layer, and not fast). + +Q and A - Radeon developers at AMD open to using st/xorg, st/xa, but prefer glamor as it's maintained already (so no need for more manpower). + +Any measurements of what's improved? Text rendering is everything in 2D - only common operations are blit scrolling and text rendering (word processing etc); glamor will get better at text rendering when GL_ARB_blend_func_extended is supported and used by it. + +In the long run, apps that care about render performance will use OpenGL (matches hardware capabilities with buffer objects etc, when X is immediate mode and therefore not modern-hardware-friendly). + +Can Gallium overhead be reduced enough to make glamor competitive? Time will tell. + + +## Joystick input driver module + +[[http://www.youtube.com/watch?v=Ul2em93dpX4|http://www.youtube.com/watch?v=Ul2em93dpX4]] + +This module is for special cases - most users don't need it. It's meant to let you operate X with a joystick or gamepad instead of a mouse (not needed for games). Uses are cheap remote, kiosk system (joystick instead of mouse), consoles, media centres etc. + +Needed over evdev because you want to do special axis/button mapping - e.g. absolute axes into acceleration of a moving pointer instead of position. Lots of mapping options provided, to cover most common use cases. + +Does not grab device, so concurrent use by (e.g.) games is possible. + +Distro users mostly install it in error. Needs sensible on-the-fly configuration (graphical frontends on hotplug etc), so that it doesn't cause problems. + +Server has a design problem; we want to be both a pointing device (mouse-like) and a slightly funky keyboard - needs to be two server-side devices, not one (leading to mess). Server doesn't cope well with funky keyboard (special driver-controlled keymap etc). + +Focus is on Linux systems, but works on FreeBSD as well. However, Linux consoles tend to use kernel drivers or userspace daemons to fake a "real" mouse instead of this driver. Console distro awareness therefore needed. + +Wiimote/Kinect not the focus of this driver - they're not joysticks, they're a different sort of input device. + +Some fun with force feedback (and nostalgia for ASR-33s) - XI1 allows some events, but toolkits don't use them so never ported to XI2. Doesn't mean it can't be done, though. + +Request from audience - please update documentation to cover everything in this talk, to help reduce confusion. + + +## XCWM and XtoQ + +[[http://www.youtube.com/watch?v=XC3Y63PhcR4|http://www.youtube.com/watch?v=XC3Y63PhcR4]] + +Started as Portland State University capstone project (5/6 students doing an externally sponsored project). Goal is library to run X clients in a non-X window system (Wayland, Mac OS X, Microsoft Windows...) without needing special hacks in the server like XQuartz and XWin. + +Uses Damage and Composite to do the heavy lifting, with dummy drivers as needed. XtoQ was proof of concept for XCWM - can XCWM replace XQuartz?. + +Currently has basic WM functionality - limited ICCCM, EWMH, functional mouse + keyboard, and support for override-redirect windows. + +Basic idea is that XCWM runs its own XCB event loop, tracking important data in its own data structures (accessible from native window system event loop) and callbacks on interesting X-side changes. Certain amount of cross-thread excitement as native system and XCWM interact. + +Example code flowcharts for XCB_MAP_NOTIFY and Damage event. Damage handling is interesting - XCWM basically gives the native system damage notification, which results in the native system coming back to ask for pixmap for damaged area. When native grabs pixmap, XCWM subtracts the damage, and relies on native rendering the pixmap to get good looking output. + +Input event passed by native to XCWM, then XCWM uses XTest to inject into server. Nice and simple. + +Future work: more ICCCM, EWMH. Rethink event loop. XtoSomethingElse (Wayland or Windows) to prove that there's no Mac OS X dependency in XCWM. Real drivers for input, instead of XTest. + +Contributors welcome - libxcwm git repo, or e-mail Jess <[[jvanderw@freedesktop.org|mailto:jvanderw@freedesktop.org]]>. + + +## Languages for X client development + +This talk was interrupted by a power cut, so two recordings: + +[[http://www.youtube.com/watch?v=3BgQU82yG5s|http://www.youtube.com/watch?v=3BgQU82yG5s]] then [[http://www.youtube.com/watch?v=WaAkkmi1ybA|http://www.youtube.com/watch?v=WaAkkmi1ybA]] when power returned. + +Question; why are desktop apps apparently harder to write than mobile or web apps? Is choice of language (usually C or C++) the problem? Note that webapps are rarely C or C++, mobile is usually Java or Objective C. + +One problem is that desktop apps are bigger with more requirements; however, mobile and web gain from GC, OOP, dynamic binding. Mobile/web is often not modular, nor do they provide big mega-apps. + +Any interesting domain-specifics? + +Issues to consider: + +* Correctness + * Threading versus event streams + * Callbacks and control flow + * Memory management +* Modularity +* Widget manipulation from code +* Configuration + * I18N +Lots of language choices out there. + +C and C++ popular with XDC attendees - we write the server and drivers in C. Is that why we use it for desktop apps? Does mainstreamness help? + +C libraries work well due to FFIs. Toolkits seem to continue C or C++ theme (Qt, GTK are entrenched). Structure makes using other languages hard. + +Basically, it's all too hard. Big Q is requirements from a programming language - is it even the right question? How do we fix things so that people go back to building X11 apps for "geek cred" instead of mobile or web apps? Code generators not the answer - too hard to work with generated code. + +Question - is X's age part of why other things seem simpler? We have 25 years of finding and resolving problems; web apps and mobile don't yet, and have fewer problems as a direct result (see also Android fragmentation). + +Question - is JavaScript the answer? Note history of JS - it's an accident that it dominates web. However, people learn it. + +Qt's QML suggested. Point from floor - packaging is the unsolved problem. I have a browser already, I might not have Qt, QML or other important libraries installed. + + +## Wayland + +[[http://www.youtube.com/watch?v=L8zwnqKysfI|http://www.youtube.com/watch?v=L8zwnqKysfI]] + +Basic principle of Wayland is to remove the bits of X11 that toolkits don't use any more, and then clean up the cruft. + +In the X11 world, compositor runs as a client of the server. X server sits in the middle of everything, getting in the way. Wayland makes the compositor and the display server one process. + +Current plan is to have a stable release later this year; not a final finished release, but stable protocol and API so you can build against it. + +Buffer management is client side (see DRI3 ideas). Client allocates and manages buffers including releasing them when unused. Protocol exists to hand buffers to compositor, and to discover when the buffer is no longer used by the compositor (and when the buffer was presented). + +XVideo is replaced by YUV buffer support (described by fourcc). There will be a libva backend that can feed YUV buffers direct to compositor. Compositor can use YUV samplers for texture sampling; there is a Mesa extension for this already. Presentation timestamp for buffers lets you tie application clocks to presentation clocks (e.g. for movie playback with lipsync). + +Even better, because all you're passing is GPU buffer objects, the compositor can use hardware overlays (aka sprite planes on some hardware) instead of sampling, as and when the compsitor thinks it's a good idea. The client doesn't need to know what's going on - atomic pageflip (Rob Clark) will make it faster than today (where using sprite planes isn't full frame rate). + +Couple of demos - first a simple spinning triangle, then a libva movie trailer. + +Testing tools are Weston compositor and a toy Wayland toolkit (used for things like a terminal). Weston is a simple, usable compositor (maybe good for embedded), but desktops will end up taking your X11 compositor and making it the Wayland compositor (using same libraries as Weston to talk Wayland). + +List of Wayland features next; Wayland doesn't give apps global co-ordinates, so no risk of confusion by apps. Makes input redirection totally reliable, even when window has arbitrary rotation. XWayland clients find themselves at global 0,0, which leads to weirdness for things like xeyes. Events tell applications about subpixel layout, which can change live. + +Weston uses a framebuffer per output, so some of the reasons for clone mode go away - but clone mode still possible. + +X integration works a lot like XCWM; there's an XWayland module that translates X to and from Wayland as needed. DDXes need some changes to provide acceleration, but not hard to do. Basically the same idea as composited X11, but with the X server being a client of the compositor. Note that even GLX works under XWayland, although Shape extension is not yet present. + +Some work needs to be done on X window management - WM is in Weston, leading to a loop (Weston is a client of X is a client of Weston). Needs splitting up before deadlock bites. + +Wayland has a handshake protocol for popup menus, to avoid offscreen problem without global geometry. + +Weston reuses libxkbcommon for keymaps, to share the work done on X11 keymaps. Zoom in Weston has a "follows mouse or typing, whichever was last" policy. Also screen recording present, with useful tools. There is a Wayland "ping" protocol to check for dead clients - Weston only uses it when it needs to. Because it's UNIX socket connectivity, Wayland compositors can terminate misbehaving apps by PID; this is more reliable than X, which uses a window property. + +On-screen keyboard is an external process, launched by Weston as a specially privileged client. Remoting is currently a VNC-like differencing protocol, either whole-desktop or single window. As it happens, because Wayland is optimized for minimal context switches (no round trips), remoting is responsive, even with VNC-like behaviour. + +XWayland will be sent to xorg-devel@ list for review soon. + +GBM is part of Mesa, but created for Wayland use of OpenGL. It's an EGL display, providing the functions EGL needs (display, surface creation etc), plus extras for buffer swap via compositor, KMS, headless operation, cursors etc. It's been used in [[KMSCon|https://github.com/dvdhrm/kmscon]] as well as Weston. + + +# Day 3 + + +## New i915 modesetting + +[[http://www.youtube.com/watch?v=ayP6bw6EBPo|http://www.youtube.com/watch?v=ayP6bw6EBPo]] + +The new code is entirely kernel changes backing the same userspace ABI. It's really all about why the helpers were unhelpful. + +Naming is a bit problematic - prepare/commit map to enable/disable. Kernel "encoder" is Intel "port", kernel "crtc" is Intel "pipe", terms get used interchangeably. + +The crtc helper assumes encoder/crtcs are completely split and can be enabled, disabled and routed independently without influencing each other. + +This is both too flexible (can call disable at unexpected times, reorders encoder and crtc enable and disable sequences depending on what changes it's making, which breaks hardware and requires driver to do state tracking to elide dangerous hardware prodding), and is also not flexible enough to cope with hardware quirks (Intel CPU eDP PLL, LVDS pin pair, Haswell DDI port). + +New code simplifies DPMS - with the exception of old VGA, Intel hardware only does DPMS on and DPMS off. This is connector-driven; Intel had to map to encoder state as well. + +Modeset sequencing is now fixed, which helps with hardware quirks. Callbacks in place to get things done in the same order at the same times, no need to elide any hardware poking. + +Output state got staged, so that when things go wrong, you can get back to a sane state. Hardest part of conversion job, but has had two benefits - can read out firmware state during takeover (flicker-free boot) and can compare hardware state to software intended state at suitable points, making it possible to sprinkle WARNs in to make debugging simpler. + +The incomplete split between crtc helper and fb helper is obvious WIP; modeset semantics that fb helper depends on were "fun" to duplicate. Cleanup in progress, including training helper to not call the driver to do things if it shouldn't have any effect. + +A few WTFs found - DPMS On after modeset, disabling of disconnected outputs, helper vtables not typed. Again, being fixed. + +Remaining todos include HPD IRQ handling - may have to move to driver to deal with things like HDMI versus DP signalling on Intel DP++ ports. Not sure why all connectors get polled on HPD IRQ - bug workaround? Tread carefully. + +Atomic modeset and pageflip (aka nuclear pageflip) need to understand shared resources like PLLs. Doesn't work with the current disable everything then enable pattern, but fixable. + +Always need to clean up dirver code, but it's happening. + +Seamless takeover of firmware state is happening. Output routing, firmware FB storage done, just have to deal with resources like PLLs, reference clocks, panel fitter, and state like interlacing. + +DP MST is going to make things interesting (but no sinks yet); currently, one crtc feeds multiple encoders. MST means multiple crtcs feed one encoder. Two ideas to consider, either DP encoder as a shared resource like a PLL, or pipes grouped and controlled as a block. Can wait until sinks exist. + +Question on whether this fixes flicker during modeset; answer is no, but gets code into shape to fix it. If it does fix it, it'll be because they've made a hardware quirk workaround fix actually take place now. + + +## Release planning + +[[http://www.youtube.com/watch?v=xOr8SsKzimQ|http://www.youtube.com/watch?v=xOr8SsKzimQ]] + +1.13 was 2012-09-05. Target for 1.14 is thus 2013-03-05. Any reasons to delay? No. + +Keith would like bugs filed once in stabilization period, rather than private complaints to developers. We want to hold up the release to get the bugs out - this won't happen if Keith is unaware of the problems. + +There are features planned - "DRI3" (which may turn out to be just DRI2 fixes), XWayland if we can, some GLX stuff. + +Atomic modesetting in X as well as KMS is a target, too. + +Rough plan is 3 months to build new features, 2 months for general bugfixing, last month for critical bugs only. + + +## Atomic modeset and pageflip + +[[http://www.youtube.com/watch?v=Hg-NLICrDB8|http://www.youtube.com/watch?v=Hg-NLICrDB8]] + +AKA nuclear pageflip if you've been confused on IRC. + +Atomic pageflip is update all plane and crtc fbs and properties within a single vblank. Atomic modeset relaxes the time constraint, but sets all connectors to required state in a single kernel call. + +Both IOCTLs have a test flag, to confirm that the hardware will do it sucessfully, as well as a live flag to do the operation requested. If test says it'll fail, you can fall back to a different option (e.g. draw a textured quad instead of using a plane, or reduce resolution on an output). + +Most state is now stored in property lists, to reduce the number of codepaths in pageflip/modeset/property set (avoids unexpected bugs). + +There's been work done to split out kernel state from user-visible state. Test flag means you need to build up proposed state and then rollback, so helpers have been written to assist. + +Atomic sequences become begin, check, commit, cleanup. Only commit should touch hardware, and check should be the same between the actual sequence and the test version. + +Patchset also cleans up the code a bit - some object properties added, the idea of "dynamic" properties (which can be changed freely, so test will always return true), signed ranges for properties. + +TODOs: remove plane->update_plane, crtc->page_flip. They're now obsolete. Fix the IOCTLs - still not quite stable. + +Question - how does core code handle things like memory bandwidth requirements? Answer - it doesn't, it punts to driver. Core checks things that are common (e.g. sane size, fbs being passed actually exist), then lets the driver cope. + +All checking must be done in check, commit shouldn't fail if check passed, otherwise users can't do the right thing. + +Can we provide better diagnostic information (e.g. an error string)? Preference is to use error numbers, so that we can evade I18N issues. + + +## DRI2 video + +[[http://www.youtube.com/watch?v=nwpy2PNb_MQs|http://www.youtube.com/watch?v=nwpy2PNb_MQs]] + +Replace XV with DRI2 by pushing more buffer types. + +XV downsides - at a minimum, two memcpys (Xshm, XvShmPutImage). More if you don't do Xshm. Not ideal for any hardware acceleration, as can't allow for HW decoders with special memory requirements (alignment etc). Not ideal for GPUs - at best, map/unmap, at worst copy. + +Today's DRI2 is unscaled RGB buffers only. VA-API and VDPAU do a GPU YUV->scaled RGB blit, then compositor does at least one blit. Memory bandwidth becomes an issue. + +Wayland does this - get X to match capabilities on local machine. + +So, teach DRI2 to allocate unscaled YUV buffers (video-size, with codec borders available), including multiplanar formats. If driver/display can support it, we can scan out directly (overlays) from the unscaled buffer (zero-copy scanout). + +Removes at least one blit, so always helpful. + +New protocol to support this. + +Some missing bits - interlace, stereo. Client control of buffer/plane mapping (e.g. NV12 in one buffer or two) - can we fix that with DRI3 proposal. Destination co-ordinates (for fixing aspect ratio). + + +## Optimus and cross-device sync + +[[http://www.youtube.com/watch?v=CQ1-Myt3coY|http://www.youtube.com/watch?v=CQ1-Myt3coY]] + +This uses DMA-BUF, X.org server, patched DDXes and xrandr 1.4 to make it work. + +DMA-BUF wraps buffer objects in special (shareable) fds, that can let you remap across hardware. + +Server needs GPU hotplug support (platform bus), xrandr 1.4 for configuration. DDXes have to learn about Optimus roles (render slave, output slave). + +Would be nice to use robustness extensions to enable compositors to do seamless muxed GPU switching - ideally completely user-invisible. + +Sync is hard - you have multiple hardware devices, and arbitrary buffer ordering and sharing, with arbitrary locking. Avoiding deadlock is done using TTM reservation code, and TTM fence primitive for cross-device sync. Make lockdep annotations possible (helps with bug fixing). + +All APIs are unstable - not even the name is tied down. + +Fence is a dumb primitive - literally "block until signalled". Can implement purely in software, but hardware implementations also work to kick things. Have one exclusive fence, and a few shared fences per device. + +Reservation is based on tickets to let clients make progress without deadlocking. Rules exist for using both APIs. + +Demo on Ubuntu system, showing that it's still not working well (although it does work), and can crash the system. + +The example for shared fences is a camera feeding both the GPU (for a preview display) and a hardware H.264 encoder (for recording). + + +## DRM2 + +[[http://www.youtube.com/watch?v=4fRXNHAjMIY|http://www.youtube.com/watch?v=4fRXNHAjMIY]] + +Problems are authentication and buffer sharing. + +Security model is that master has control, but can literally only stop clients authorizing. Once authorized, clients are unrestricted. + +Only one master at a time (needs root), but you drop master when you don't need it. + +Display servers need master; X uses it for limiting modesetting to active server. Isolation between clients (or at least between masters) would be nice, but not currently provided. + +There's a VT switch race; VT switches need us to release master in one process, gain in another. Malicious process can race for the gap. + +GEM buffer sharing is flink-based, and dangerous - any client can access any buffer if it guesses the handle. No confidentiality or integrity. + +Non-GUI apps need the GUI to authenticate them - makes GPGPU feel weird (why do I need X to co-operate)? + +Idea - split master into two, one for modeset, one for GEM. flink restricted to only working between a master and clients it has authed (won't break current user space). Driver + HW can then isolate clients completely. + +KMSCon could, in the long run, replace VT switches. It takes master, it forwards things between running display server (e.g. Weston compositor, X.org) and the hardware, and pays attention to what should and should not have access. + +DMA-BUF is nearly as secure as reasonable, but could be slightly enhanced by LSM (SELinux) hooks. Not used by most mortals, but some people have plans. + +Details as patches over the next month. + + +## EVoC Nouveau project experience + +[[http://www.youtube.com/watch?v=n41aYIPTiiU|http://www.youtube.com/watch?v=n41aYIPTiiU]] + +Student started as a web developer. Moved onto KDE, but developing X seemed scary and hard. + +EVoC was an accident; tried to get an onsite intership at Mozilla, Google, Apple, but failed. GSoC deadline had gone past, so either Android app development, or EVoC. + +Student wanted a fast GPU anyway, for gaming. Bought an NVIDIA card, and found out that Nouveau couldn't do reclocking on modern cards. + +Presented a brief history of reclocking, from nv50 (where defaults were OK) to Fermi (default 10% of max performance). + +Goal was to make it work as well as it did on nv50; nv50 had HWSQ, but Fermi replaced it with PDAEMON, which changed ISA to FµC (flexible microcode). + +Martin Peres had already done fan management and host -> PDAEMON comms. Project had three parts; PDAEMON to Host comms, replace HWSQ, and write more documentation (audience enthused by documentation comment). + +PDAEMON->host comms was a simple ringbuffer with sanity checks. Tested, proven working, merged, then onto the hard bit (Fermi Scripting Engine). + +FSE acts as a HWSQ replacement. Implemented in FµC, provides 6 basic operations - two types of delay, MMIO read/mask/write, message to host. + +Send message to host is still not working, but rest works and is being tested. + +Did lots of good documentation on his blog [[http://supreetpal.blogspot.in/|http://supreetpal.blogspot.in/]] Also got mwk to write intro.txt in envytools. + +Still thinks we need more newbie docs; Supreet wrote a "Beginner's guide to KDE devel", X needs the same to get people in. + +On to EVoC; EVoC is a 13 week project proposed by student. Money is $1k up front, $2k mid-term, $2k completion. Can start at any time, as long as you have 13 weeks. + +Money was delayed, but did arrive. + +Moved onto discussion of EVoC with audience - how do we make it better? Important bits are that X can't afford to pay wages, and is really aiming to get people over the "X is too scary - I can't possibly contribute to it" barrier - if it wanted work done, it'd have the mentors do it. + +Student suggests publicity needed, and more documentation to ensure that mentor time doesn't get wasted (prerequisites for suggested projects). + + +## Tegra and embedded graphics + +[[http://www.youtube.com/watch?v=KbMOQ5rit54|http://www.youtube.com/watch?v=KbMOQ5rit54]] Hardware is ARM CPUs + GeForce ULP (no unified shaders, no virtual memory). Sophisticated memory controller, to share bandwidth and control memory access latency for GPU/CPU accesses. + +Two similar display controllers - different encoders (HDMI, DSI, TV). Scanout engines have 3 plane plus cursor support, 2 YUV-capable planes, separate colorkey and palette per plane. No rotation possible at scanout. + +Tegra is OSS friendly - can get the TRM from developer website. No documentation for acceleration engines now, though, although there are plans to open up fully. Still a lot of work to upstream everything done so far (partly due to Android focus). + +There's a start on a DRM driver; KMS works, but memory management not done. Efforts underway to RE the 3D engine. + +Problem; no memory virtualisation at all. Security issues; all buffers must be continuous DMA memory; misbehaves under memory pressue. Fixed for Tegra 3. + +Challenges: low memory bandwidth - scanout can eat *all* the bandwidth. Copying data hurts more than ever before (so RandR with shadow buffers really hurts). Surface tiling required to have enough bandwidth to cope - fallbacks are proportionately more expensive. + +Memory again - you don't have much of it - fixed "stolen" VRAM is a waste of memory, but lack of IOMMU makes smart sharing hard. + +Compositing with OpenGL not preferable. Subpar use of 2D engines, no plane usage. Wayland provides some help here (makes it possible to write a 2D compositor). + +Q&A - is CMA a fix for the memory problem? No, as you can't easily release memory from the GPU when the CPU needs it. + +Nokia mentioned that hardware scanout rotation is overrated - you want things like animations, so you don't use the hardware rotate anyway. + + +## Waffle + +[[http://www.youtube.com/watch?v=BdLEn6lji-U|http://www.youtube.com/watch?v=BdLEn6lji-U]] + +Motivation was improving Piglit's GL tests. Piglit is a GLUT user - GLUT is simply outdated; on Linux, is GLX only and can only do legacy GL contexts, so can't do OpenGL 3.1 core profiles, or even request a specific GL version. Lots of ugly hacks to get GLES tests, so not many ES tests. + +Piglit should really run on Wayland, Android, X/EGL. GLEW also an issue (for GLES and for GL > 3.0). + +Qualities of an ideal solution: + +1. Build each test once, run on each of the available systems - GLX, X/EGL, Wayland, decision at runtime. +1. Where sane, mux a test over multiple GL APIs (e.g. ES 2, ES 3, GL 3.2, legacy GL etc). This may be a first anywhere. +1. Benefit projects other than Piglit - so should be a separate library (e.g. for apitrace to reuse with glretrace). +Solution so far; can do the first with libwaffle. Getting going on the second, but more work to go. + +Piglit needs GL core profile support - not Waffle's fault. + +Waffle API resembles EGL with extras for window creation, dlsyming your GL library (with OS abstraction), getting at the underlying native objects (e.g. for input behaviour that's outside Waffle's scope). + +Supported platforms are all Linux display engines, Android (experimental - bugs may be Android's fault), Mac OS X (experimental, not fully tested). Patches welcome for Windows. + +Demo of Dante ported on top of Waffle instead of EGL. Run same binary on Wayland and EGL/X11. + +Waffle is not GLUT or SDL. Will never do input or audio. It's meant for demo applications and tests. See examples in repo (aims to use a GL-like attribute list API). + +Question: considered a wrapper header to avoid the dlsym stuff? Yes - piglit has macros to do dispatch. + +There is a KMS/GBM backend being written - will let you run piglit on a headless server. Side benefit - lets you work on new hardware as soon as 3D hardware works, while rest of team tackles the modesetting problem. + +Question: Dynamic detection of GL API? Example does a dispatch based on environment variables. As yet, Waffle can't pick for you. What are sensible defaults? Consider X on Wayland and Wayland on X (both supported options) - which is the "best" window system? + +Waffle dlsym just calls dlsym for you on the right library. But have to be aware of ABI - waffleGetProcAddress backs it the right way, though. EGL, GLX, CGL all have different rules on dlsym and GetProcAddress. Windows backend will trigger an API revision due to GetProcAddress weirdness. Chad is scared of Windows now, so will not be implementing that backend. + + +## New GL ABI + +[[http://www.youtube.com/watch?v=LesAb4sTXgA|http://www.youtube.com/watch?v=LesAb4sTXgA]] + +Starts with a look at the current position (set down in 2000, so outdated). + +Lots of hoops for more OpenGL. GLES with GLX is worse. OpenGL with EGL is awkward. Indirect rendering - just don't start on it, we want to kill it with fire (can't exceed OpenGL 1.5, usually claimed in error, leading to bug reports). + +Things to do; split libGL into libOpenGL for OpenGL (like libGLESv2 or libGLESv1_CM) and libGLX for GLX. libGL just links to the two of them. + +Version libOpenGL. App developers hate GetProcAddress; how do we escape that? Versioned libOpenGL sonames? Can we bump the minimum GL version (noting old hardware is still out there)? + +Want to deprecate GLX, as new GLX extensions are hassle, and we've already decided to kill indirect rendering. + +Try and convince everyone to use EGL instead. Hassle is proprietary drivers - NVIDIA apologised, they're working on it (and already ship it for Tegra). + +Make OpenGL ES part of the ABI; makes it easier to port between mobile and X. + +Where do we go? Update loader/driver interface - closed source driver vendors showing interest, but this will be slow. Killing indirect makes it easier, because the X server stops having trouble with it. + +TODO now: split libGL. Convince distros to drink EGL coolaid - GLX to EGL porting guide? + +NVIDIA's Andy Ritger has a good proposal up at [[https://github.com/aritger/linux-opengl-abi-proposal|https://github.com/aritger/linux-opengl-abi-proposal]] and will help drive this. Discussion on mesa-dev to get it moving. + +Discussion on how you version libOpenGL - soname? ELF versioning? We'll work it out. + +Question - what is replacement for indirect? Answer is VNC-like remoting - note that we're now talking about limiting ourselves to 1999 OpenGL versions, as indirect GLX is not keeping up. + +NVIDIA has extended indirect GLX to newer OpenGL. Maybe though, X should learn to ship images across the wire instead of GL commands - can be done without applications to be aware of it. + + +## OpenCL testing framework in piglit + +[[http://www.youtube.com/watch?v=J7xQn_KuPrQ|http://www.youtube.com/watch?v=J7xQn_KuPrQ]] + +This was an EVoC project: Use piglit to test OpenCL as well as OpenGL. Benefits TDD and regression finding. + +Goals; test OpenCL compliance and versions. Make test writing easy. + +Piglit provides concurrent execution of tests. Grouped tests. Results display. + +Test as much as possible, aim for all-platform, all-device tests, but tests can be tied to a device or platform. + +Try to make test code common. Helpers to deal with common blocks of code. + +A test is configuration section to set up environment, then a test section. So far, three test types (API, OpenCL program execution, and custom). Tries to reduce code you need to write if you're focusing your test. Shown example of custom test. + +Program tester aims to let you write an OpenCL program, specify inputs and expected outputs, and execute multiple tests on your OpenCL code, without writing a line of C. + +Showed that it does run its 70 tests on 3 different OpenCL implementations - 32 passes on Clover, 53 on Intel (CPU-side implementation), 55 on AMD APP. + +Short term - more tests, clinfo (like glxinfo, but for OpenCL). Add support for half type. + +Longer term, want OpenGL+OpenCL combination testing (buffer sharing). Support for SPIR (Standard Portable Intermediate Representation) binary OpenCL program format. diff --git a/Events/XDC2012/Program.mdwn b/Events/XDC2012/Program.mdwn new file mode 100644 index 00000000..a21ec271 --- /dev/null +++ b/Events/XDC2012/Program.mdwn @@ -0,0 +1,66 @@ + + +# XDC2012 Program + +**If you would like to add a talk re-arrange your schedule, please contact [[EgbertEich|EgbertEich]] <[[e4t@freenet.de]]> or [[MatthiasHopf|MatthiasHopf]] <[[mat@mshopf.de]]>. Please add an abstract to your talk if there is none available yet.** + + +## Tracks +[[!table header="no" class="mointable" data=""" +General business | Security | Performance | X.org: Server | X.org: Environment | Wayland | Gfx Hardware | DRI/DRM/Kernel | 3D Graphics +"""]] + + +## Schedule +[[!table header="no" class="mointable" data=""" + | **Wednesday** | **Thursday** | **Friday** + 09:00 | **Members of the Board**: [[XorgFoundation Status Update, Book Sprint Results, EVoC Results|Events/XDC2012/XDC2012AbstractKickOff]] | **Peter Hutterer**: [[X server integration testing. Yes, it's possible|Events/XDC2012/XDC2012AbstractPeterHutterer]] | **Daniel Vetter**: [[New i915 modeset infrastructure Code|Events/XDC2012/XDC2012AbstractDanielVetter]] + 09:30 | **Lucas Stach**: [[Discussing approaches for hardware independent accelerated graphics drivers|Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent]] + 10:00 | **Martin Peres**: [[Return of experience on the EVoC : How to better prepare the Students|Events/XDC2012/XDC2012AbstractMartinPeres]] | **Sascha Hlusiak**: [[Development State and Features of the Joystick Input Module|Events/XDC2012/XDC2012AbstractSaschaHlusiak]] | **Rob Clark**: [[DRM/KMS Atomic-Modeset / Nuclear-Pageflip|Events/XDC2012/XDC2012AbstractRobClark-KMS]] + 10:30 | _Break_ | _Break_ | _Break_ + 11:00 | **Martin Peres, Timothée Ravier**: [[Recap, Vulnerabilities, Attacks and Discussions on the graphic Stack's Security|Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier]] | **Jess van Derwalker**: [[XCWM, the X Composite Window Manager library and XtoQ, an OS X Window Manager|Events/XDC2012/XDC2012AbstractJessVanDerwalker]] | **Rob Clark**: [[DRI2Video|Events/XDC2012/XDC2012AbstractRobClark-Video]] + 11:30 | **Maarten Lankhorst**: [[Optimus support|Events/XDC2012/XDC2012AbstractMaartenLankhorst]] + 12:00 | **Alan Coopersmith**: [[X server privilege model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable|Events/XDC2012/XDC2012AbstractAlanCoopersmith]] | **Bart Massey**: [[Programming languages for X Application Development|Events/XDC2012/XDC2012AbstractBartMassey]] | ** Kristian Hoegsberg,Martin Peres,Timothée Ravier, Daniel Vetter**: [[DRM2|Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter]] + 12:30 | _Lunch_ | _Lunch_ | _Lunch_ + 14:00 | **Michael Larabel**: [[Benchmarking, Request for Phoronix Benchmarks / graphics Tests, Feedback or Flames|Events/XDC2012/XDC2012AbstractMichaelLarabel]] | **Kristian Hoegsberg**: [[Wayland/Weston Status/Overview|Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland]] | **Supreet Pal Singh**: [[EVOC Experience and Project "Nouveau - Software scripting Engine for Fermi Architecture based GPUs"|Events/XDC2012/XDC2012AbstractSupreetPalSingh]] + 14:30 | **Oliver Mc****Fadden**: [[Dante: Doom3 GPLv3+; Teaching an old Engine new Tricks, Community building, Performance on embedded Hardware|Events/XDC2012/XDC2012AbstractOliverMcFadden]] | **Lucas Stach**: [[A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general)|Events/XDC2012/XDC2012AbstractLucasStach-Tegra]] + 15:00 | **Keith Packard, Eric Anholt**: [[DRI3|Events/XDC2012/XDC2012AbstractPackard+Anholt]] | - | **Chad Versace**: [[A quick Look at Waffle, deferring Choice of GLX, X11/EGL, Wayland/EGL, its use for testing Mesa|Events/XDC2012/XDC2012AbstractChadVersace]] + 15:30 | _Break_ | _Break_ | _Break_ + 16:00 | **Members of the Board**: [[X.org Board Meeting|BoardOfDirectors/IrcLogs]] | **Kristian Hoegsberg**: [[Composite based rootless X server. How does it work? How do we get it upstream?|Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX]] | **Ian Romanick**: [[Discuss the future of EGL, GLX, and OpenGL ES on Linux|Events/XDC2012/XDC2012AbstractIanRomanick]] + 16:30 | **Blaž Tomažič**: [[OpenCL Testing Framework for Piglit. Project Overview and future Plans|Events/XDC2012/XDC2012AbstractBlažTomažič]] + 17:00 | - | <del>**Mario Kleiner**: [[How Neuro-Scientists Use the Open Source Graphics Stack: some Examples|Events/XDC2012/XDC2012AbstractMarioKleiner]]</del> | - + 17:30 | - | - | - + 19:00 | - | Evening event, meet at 19:00 at Schoener Brunnen: [[picture of meeting point|http://commons.wikimedia.org/wiki/File:Nuernberg-schoener-Brunnen-gp.jpg]], [[Google map of route from conference venue to meeting point|https://maps.google.com/maps?saddr=maxfeldst,+nuernberg&daddr=Unknown+road&hl=en&ll=49.45892,11.086922&spn=0.015342,0.052314&sll=49.453888,11.078591&sspn=0.001918,0.006539&geocode=FbTG8gIdRzepACldcIiowFefRzHhDivEyJXe3Q%3BFVmc8gIdZAWpAA&dirflg=w&mra=dme&mrsp=1&sz=18&t=m&z=15]]; | - +"""]] + + +## Topics + +As usual, we are open to talks across the layers of the graphics stack, from the kernel to applications, and about how we make things better for the developers who build them. If you're not sure if something might fit, mail or add it anyway, and find out if there's room in the schedule. + + +## Ideas + +* [[XorgFoundation|XorgFoundation]] status update, [[BookSprint|Events/BookSprint2012]] results : [[BoardOfDirectors|BoardOfDirectors]] +* Return of experience on the EVoC : How to better prepare the students : [[MartinPeres|MartinPeres]] +* Recap, vulnerabilities, attacks and discussions on the graphic stack's security : [[MartinPeres|MartinPeres]], Timothée Ravier +* X server privilege model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable: [[AlanCoopersmith|AlanCoopersmith]] +* 15 minute talk about development state and features of the joystick input module : Sascha Hlusiak +* X server integration testing. Yes, it's possible: [[PeterHutterer|PeterHutterer]] +* Discuss the future of EGL, GLX, and OpenGL ES on Linux. +* Wayland/Weston status/overview. +* xwayland: Composite based rootless X server. How does it work? How do we get it upstream? +* Optimus support : [[MaartenLankhorst|MaartenLankhorst]] / danvet (maybe?) +* A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general): Lucas Stach +* Discussing approaches for hardware independent accelerated graphics drivers : Lucas Stach +* New i915 modeset infrastructure code. My blog post about it caught the wrath of some *bsd guys so some explaining might be in order: Daniel Vetter +* Dante: Doom3 GPLv3+ (OpenGL 1.x, GLX) through to Dante (OpenGL ES2.0, EGL, GLSL); Teaching an old engine new tricks, building a ad-hoc community, and the struggle for performance on embedded hardware. : [[OliverMcFadden|OliverMcFadden]] + * Overlap with "Discuss the future of EGL, GLX, and OpenGL ES on Linux."? +* A quick look [15min] at [[Waffle|http://people.freedesktop.org/~chadversary/waffle]], a library that allows one to defer choice of GLX, X11/EGL, Wayland/EGL until runtime, and how it is used for testing Mesa. : Chad Versace +* Benchmarking, request for Phoronix benchmarks / graphics tests, feedback or flames, etc : Michael Larabel +* drm/kms atomic-modeset / nuclear-pageflip : [[RobClark|RobClark]] +* Programming languages for X application development : Bart Massey +* EVOC experience and project[Nouveau - Software scripting engine for Fermi architecture based GPUs] : [[SupreetPalSingh|SupreetPalSingh]] +* xcwm and XtoQ, a library for X compositing window managers and a proof of concept OS X window manager that uses it. Project overview and status : [[JessVanDerwalker|JessVanDerwalker]] +* OpenCL testing framework for Piglit. Project overview and future plans (15 min): Blaž Tomažič +* "Special needs": Some example uses of computer graphics in neuro-science and our wishlist for the ideal graphics stack: Mario Kleiner
\ No newline at end of file diff --git a/Events/XDC2012/PublicTransportation.mdwn b/Events/XDC2012/PublicTransportation.mdwn new file mode 100644 index 00000000..e2f02bb6 --- /dev/null +++ b/Events/XDC2012/PublicTransportation.mdwn @@ -0,0 +1,21 @@ + + +# Some Hints on Public Transportation for XDC2012 + + +## Local Destinatons + +The conference venue and hotel can be reached easily + +* from the **airport**: Take subway line 2 (destination Roethenbach), change at Rathenauplatz to line 3 (destination Friedrich-Ebert Platz). +* from the **main railroad station**: Take suway line 3 (destination Friedrich-Ebert Platz). +Get off: + +* for the **conference venue** at Maxfeld and walk 350 meters to the [[building|http://maps.google.de/maps?saddr=Goethestra%C3%9Fe&daddr=Maxfeldstra%C3%9Fe+5,+90409+N%C3%BCrnberg&hl=de&ie=UTF8&ll=49.462616,11.085505&spn=0.001782,0.004265&sll=49.462856,11.085752&sspn=0.001782,0.004265&geocode=FTvA8gIdfCWpAA%3BFae18gIdRx6pACl_i-ksulefRzFD1xgwc0v1Kg&dirflg=w&mra=mift&mrsp=0&sz=18&t=m&z=18]] +* for the **conference hotel** at Kaulbachplatz and walk 270 meters to the [[hotel|http://maps.google.de/maps?saddr=Schweppermannstra%C3%9Fe&daddr=Kaulbachstra%C3%9Fe&hl=de&ie=UTF8&sll=49.461266,11.078108&sspn=0.001782,0.004265&geocode=FQTA8gIdcgepAA%3BFeS28gIdLwepAA&dirflg=w&mra=mift&mrsp=1&sz=18&t=m&z=18]]. +The announcements on the subways are made both in German and English. + + +## Tickets + +You can buy single ride tickets, "Streifenkarten" for 5 rides and day passes at vending machines at every stop. The single ride tickets are presently EUR 2.40 and are valid for 90 minutes. You can change between subway (U-Bahn), Trams and buses as often as you want during this time. "Streifenkarten" cost EUR 9.70 for 5 rides. You need to fold back and stamp 2 strips per ride. These tickets are useful if several people are traveling together as you can put each one on a single ticket. diff --git a/Events/XDC2012/Weekend.mdwn b/Events/XDC2012/Weekend.mdwn new file mode 100644 index 00000000..1cbb6afc --- /dev/null +++ b/Events/XDC2012/Weekend.mdwn @@ -0,0 +1,69 @@ + + +# XDC2012 Weekend Events + +<a name="saturday"></a> +## Saturday: BierWanderung + +We are going to have a hiking trip to the Frankonian countryside on Saturday, Sept 22. On this trip you will have the opportunity to visit some local brewery beergardens and have a taste of a small selection from the numerous local beers. + +The trip itself will be an extended inverse 5 Seidla Steig: a well known tour around the city of Graefenberg. + +* We meet up at the Nord-Ost Bahnhof at 9:10. This station can be easily reached with subway line 2 'U2' or 'U21' going to the airport (Flughafen) or Ziegelstein. Please check [[the line map|http://www.vgn.de/liniennetze/schienennetz_nuernberg_furth/]]. We will meet on the platform of the train. To get there leave the subway station building towards the north, keep right, proceed further north until you cross the tracks, then turn right. There's a ticket vending machine on the platform. +* At 9:30 the train will leave for Graefenberg where we will arrive at 10:11. +* A bus will take us to Egloffstein at 10:20, and we will arrive there at 10:38. +* We will then hike to Thuisbrunn. This is a steep treck with a few very interesting views in which we will cover about 3.5km and 250heightmeter. At the Elch-Brau brewery in Thuisbrunn we will have lunch, and can enjoy our first beer. +* A short 1.5kms later, we are in Hohenschwaerz, where we will have a quick refreshment at the Hofmann brewerey. +* Afterwards, we have a 5km mostly flat walk to Graefenberg where we will enjoy a Lindenbrau in the afternoon, +* For the final part of our journey, we gratuitously walk up a hill again, so we can have another nice view of the valley and the Weissenhohe abbey on the way down (3km, 100heightmeter). Down at the brewery we will enjoy a hearty supper and some beer (they even sell Mass for the october fest frequenters), and then we can roll the last few meters back to the train. +* At XX:40, a train will take us back to the Nuremberg Nord-Ost-Bahnhof. Last train out is at 23:40. +The cost of this trip should be estimated by EUR 10 per meal (2x), EUR 3 per beer (4x + ...) and about EUR 8 for transportation (either 'Bayernticket' or 'Tagesticket plus'). Bring at least around EUR 50 in cash as the breweries probably are not equipped with card terminals, and beware, the ticket-vending machines tend to only take up to 20 euro bills. The preferred ticket is probably a tagesticket-plus, which costs 16.20EUR. This gives two people (when traveling together) the ability to travel through the whole VGN network on both Saturday and Sunday. + +While 4 breweries are visited, this tour is not just about beer. A total of close to 13km and 450heightmeters will be covered, so it is also going to be some taxing physical activity for the less well-trained among us. There are a few steep bits, but nothing dangerous or scary, and the way the route and schedule are planned means that the whole can be done leisurely. But if the sole goal is to simply consume alcohol, then please, stay in Nuremberg. + +An approximate map of the route is available at [[google maps|http://maps.google.de/maps?saddr=Talstra%C3%9Fe%2FST2260&daddr=49.6937682,11.2574561+to:49.6920439,11.2509813+to:49.68974,11.24964+to:49.684786,11.249122+to:49.6778521,11.2474872+to:49.677654,11.2523543+to:49.6654383,11.2600493+to:49.6554344,11.253826+to:49.650872,11.250426+to:49.6455589,11.2487438+to:49.639797,11.257334+to:49.6345251,11.255666+to:49.62971,11.25226+to:Bahnhofstra%C3%9Fe&hl=en&ie=UTF8&sll=49.694382,11.259356&sspn=0.007842,0.016887&geocode=Fa1k9gIdGdCrAA%3BFUhE9gIdcMarACk_SxboXO6hRzG1sSY3I6G2Xw%3BFYs99gIdJa2rACnlu3t9RO6hRzFtarXh5MERtw%3BFYw09gId6KerACn5CTxNRO6hRzGOE8r71g9Pvw%3BFTIh9gId4qWrACnXN3-tT-6hRzHhI2GbMtoeEw%3BFRwG9gIdf5-rACl9IDNUre-hRzExHWCbMtoeEw%3BFVYF9gIdgrKrAClZP_0gU-6hRzFxLWCbMtoeEw%3BFZ7V9QIdkdCrACkJhyB2CO-hRzGQjmGbMtoeEw%3BFYqu9QIdQrirACnpiaVUde-hRzFG1jvG-s5GzQ%3BFbic9QId-qqrACkfTITsne-hRzFWnjQ5WcnoFg%3BFfaH9QIdZ6SrAClZf6yugu-hRzGhVWybMtoeEw%3BFXVx9QId9sWrACmr3AiAfO-hRzGQY2ebMtoeEw%3BFd1c9QIdcr-rACk7Ms-ch-WhRzEJ_mUPoACwiA%3BFQ5K9QIdJLKrACk3BFYkhOWhRzGopwLoeXYkAw%3BFfhJ9QIdfKirAA&t=h&dirflg=w&mra=dpe&mrsp=1&sz=16&via=1,2,3,4,5,6,7,8,9,10,11,12,13&z=17]]. + +When you are taking part in this activity, it is necessary that you add yourself to the below list before Thursday 20th 17:00 as we need to make reservations. Please also indicate if you will bring someone with you: + +1. [[MatthiasHopf|MatthiasHopf]] (+ company) +1. [[StefanDirsch|StefanDirsch]] +1. [[LucVerhaegen|LucVerhaegen]] +1. [[EgbertEich|EgbertEich]] +1. [[LucasStach|LucasStach]] +1. [[MichaelLarabel|MichaelLarabel]] +1. [[ArvindUmrao|ArvindUmrao]] +1. [[MichelDaenzer|MichelDaenzer]] +1. [[AlanCoopersmith|AlanCoopersmith]] +1. [[SaschaHlusiak|SaschaHlusiak]] (+ company) +1. [[BenBrewer|BenBrewer]] +1. Supreet Pal Singh +1. [[HaraldKoenig|HaraldKoenig]] (+ company??) +1. [[JessVanDerwalker|JessVanDerwalker]] +1. [[JoeBurmeister|JoeBurmeister]] +1. [[SimonFarnsworth|SimonFarnsworth]] +1. [[MarcBalmer|MarcBalmer]] +1. [[VeraHardmeier|VeraHardmeier]] +1. [[MaartenLankhorst|MaartenLankhorst]] +1. Martin Peres +1. [[RobClark|RobClark]] +1. Timothée Ravier +1. [[IanRomanick|IanRomanick]] +1. [[KonstaKarsisto|KonstaKarsisto]] +<a name="sunday"></a> +## Sunday: Nazi Party Rally grounds + +On Sunday a trip to the [[Reichsparteitagsgelände|http://en.wikipedia.org/wiki/Nazi_party_rally_grounds]] is planned. This site is one of the most important historic sites of Europe, with a few Speer buildings in their typical megalomaniac style still standing. It includes [[a museum|http://www.museums.nuremberg.de/documentation-centre/index.html]] (Dokumentationszentrum) which provides an excellent overview of events leading up to the Holocaust, WWII and all the horrors involved. It is a must for anyone with any interest in the history of the last century, and an important lesson on a history worth preventing in future. + +On Sunday, Sept. 23: + +* At 10:00 we will meet at the tram-station in front of the main railway station. Bring your tagesticket-plus from the beerhike :) +* We will then ride the 10:27 No. 9 tram all the way to the 'Dokuzentrum', where we will arrive about 10 minutes later. +* A walk around the grounds and a visit to its most marked landmarks will lead us to the "Gutmann am Dutzenteich" beergarten for lunch. +* After lunch the documentation center will be visited to take the 2-3h tour around the permanent exhibit called "Fascination and Terror". +Entrance to the Museum is EUR 5, which includes an audio-guide in various languages. + +1. [[LucVerhaegen|LucVerhaegen]] +1. [[EgbertEich|EgbertEich]] +1. [[MatthiasHopf|MatthiasHopf]] +1. [[HaraldKoenig|HaraldKoenig]] +1. Martin Peres
\ No newline at end of file diff --git a/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn b/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn new file mode 100644 index 00000000..64c2a5e0 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractAlanCoopersmith.mdwn @@ -0,0 +1,10 @@ + + +### X server Privilege Model on Solaris - explaining how we drop privs and reviewing to see what's upstreamable. + + +### Alan Coopersmith + +Solaris includes Xorg built with patches that drop root privileges after startup, relying on the kernel to handle input device access for hotplugging & vt switching, and utilizing patches to gdm to pass information to Xorg on authenticated users. This talk will go over some of the details and open a discussion on what should be upstreamed. + +[[video|http://www.youtube.com/watch?v=hphjH2KYGAw&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractBartMassey.mdwn b/Events/XDC2012/XDC2012AbstractBartMassey.mdwn new file mode 100644 index 00000000..97217a93 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractBartMassey.mdwn @@ -0,0 +1,10 @@ + + +### Programming languages for X Application Development + + +### Bart Massey + +A lot of the problems with writing desktop applications are made much worse by using inappropriate programming languages (such as C/C++). I will review some of these problems, discuss alternative languages, and make suggestions about what to do about it all. + +[[video part 1|http://www.youtube.com/watch?v=3BgQU82yG5s&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] [[video part 2|http://www.youtube.com/watch?v=WaAkkmi1ybA&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn b/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn new file mode 100644 index 00000000..ce8a7b81 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractBlažTomažič.mdwn @@ -0,0 +1,10 @@ + + +### OpenCL Testing Framework for Piglit. Project Overview and future Plans + + +### Blaž Tomažič + +OpenCL testing framework written over the course of EVoC. This talk will give an overview of the design and functionality, usage, current status and future plan. + +[[slides|XDC2012-OpenCL-2.pdf]] [[video|http://www.youtube.com/watch?v=J7xQn_KuPrQ&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf Binary files differnew file mode 100644 index 00000000..522b9d65 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL-2.pdf diff --git a/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf Binary files differnew file mode 100644 index 00000000..1f8a017d --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractBlažTomažič/XDC2012-OpenCL.pdf diff --git a/Events/XDC2012/XDC2012AbstractChadVersace.mdwn b/Events/XDC2012/XDC2012AbstractChadVersace.mdwn new file mode 100644 index 00000000..28b15bec --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractChadVersace.mdwn @@ -0,0 +1,16 @@ + + +### A quick Look at Waffle, a Llbrary that allows one to defer choice of GLX, X11/EGL, Wayland/EGL until Runtime, and how it is used for testing Mesa + + +### Chad Versace + +Waffle is a cross-platform C library that allows GL applications to defer choice of window system until runtime. For example, on Linux, Waffle enables an application to select X11 with GLX, X11 with EGL, Wayland, or (coming soon) GBM. Its API closely resembles EGL. + +Waffle will soon replace GLUT in Piglit, Mesa's OpenGL test suite. This will allow one to build Piglit once, then run its tests under different window systems. This will extend Piglit's portability to Wayland, Android, and X11/EGL. Using GBM, one will even be able to run GL tests on headless machines. + +Future plans for Waffle is to add the ability to defer the choice of OpenGL API until runtime using a dynamic dispatch mechanism similar to the one currently used in Piglit. + +[[http://people.freedesktop.org/~chadversary/waffle|http://people.freedesktop.org/~chadversary/waffle]] + +[[slides|http://people.freedesktop.org/~chadversary/waffle/files/talks/2012.09.21-xdc/notes.txt]] [[video|http://www.youtube.com/watch?v=BdLEn6lji-U&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn b/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn new file mode 100644 index 00000000..6bb1ed11 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractDanielVetter.mdwn @@ -0,0 +1,12 @@ + + +### New i915 modeset infrastructure Code + + +### Daniel Vetter + +Up to now all kms drivers used the same shared crtc helper framework to implement the modeset ioctls. Intel hardware has never been a perfect fit for the crtc helper framework and we've accumulated our fair share of hacks. But with recent efforts (Haswell enabling and planned better handling of shared resources like plls) piling hacks over hacks became no longer manageable, and for kernel 3.7 i915.ko will have a new, driver-private modeset framework. + +This presentation details the assumptions and limitations of the crtc helper framework that are at odds with how intel hardware works and explains the design principles of the new code and some of the implementation details. + +[[video|http://www.youtube.com/watch?v=ayP6bw6EBPo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn new file mode 100644 index 00000000..cdde429e --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter.mdwn @@ -0,0 +1,10 @@ + + +### DRM2 : Let's fix the DRM authentication policy and buffer sharing + + +### Kristian Høgsberg, MartinPeres, Timothée Ravier & Daniel Vetter + +Following the security talks and following discussions, some propositions emerged to refine the DRM interface. This talk will present our conclusions and will request comments from the community. + +[[slides|drm2_xdc2012.pdf]] [[video|http://www.youtube.com/watch?v=4fRXNHAjMIY&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf Binary files differnew file mode 100644 index 00000000..987f2462 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractHoegsberg+Peres+Ravier+Vetter/drm2_xdc2012.pdf diff --git a/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn b/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn new file mode 100644 index 00000000..2fd6a518 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractIanRomanick.mdwn @@ -0,0 +1,10 @@ + + +### Discuss the future of EGL, GLX, and OpenGL ES on Linux + + +### Ian Romanick + +The last Linux OpenGL ABI dates from 2000. The world has dramatically changed since then. Thanks to the proliferation of smartphones and tables, OpenGL ES and EGL have risen in popularity. Most Linux distros don't ship either OpenGL ES or EGL, and the existing libGL requires applications to use archaic means to access any function added to OpenGL since 1998. I would like to open a discussion for a revision of the Linux OpenGL ABI and a set of recommendations for distros and application developers. + +[[video|http://www.youtube.com/watch?v=LesAb4sTXgA&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn b/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn new file mode 100644 index 00000000..1e704a74 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractJessVanDerwalker.mdwn @@ -0,0 +1,16 @@ + + +### XCWM, the X Composite Window Manager library and XtoQ, an OS X Window Manager that uses it: Overview and Project Status + + +### Jess VanDerwalker + +The XCWM X Composite Window Manager library and XtoQ are two parts of a project that began as a Portland State University CS Capstone course project. Development on the project has continued as part of X.org's EVoC program. + +The goal of XCWM is to create a C library that acts as a layer between XCB and OS specific window manager code that facilitates running X client windows as OS native windows on platforms such as OS X, Microsoft Windows, or Wayland. Through XCWM would allow developers to share more code, improve maintainability, and eventually remove some of the specific DDX's within the server code base. + +XtoQ, which has been developed concurrently, is a proof of concept window manager application developed for OS X which uses XCWM. + +The presentation will cover the basic library structure, some of its features, why certain desisions in implementation were made, and future work. + +[[slides|xdc2012_xcwm_presentation.pdf]] [[video|http://www.youtube.com/watch?v=XC3Y63PhcR4&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf b/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf Binary files differnew file mode 100644 index 00000000..37a289fb --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractJessVanDerwalker/xdc2012_xcwm_presentation.pdf diff --git a/Events/XDC2012/XDC2012AbstractKickOff.mdwn b/Events/XDC2012/XDC2012AbstractKickOff.mdwn new file mode 100644 index 00000000..feb9ebc4 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractKickOff.mdwn @@ -0,0 +1,5 @@ + + +### XorgFoundation Status Update, Book Sprint Results, EVoC Results + +[[video|http://www.youtube.com/watch?v=tiNU_zyDUJo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn new file mode 100644 index 00000000..23a2b5e4 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-RootlessX.mdwn @@ -0,0 +1,8 @@ + + +### Composite based rootless X server. How does it work? How do we get it upstream? + + +### Kristian Høgsberg + +[[video|http://www.youtube.com/watch?v=Y9VYvAevjiU&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn new file mode 100644 index 00000000..51d68e0c --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractKristianHoegsberg-Wayland.mdwn @@ -0,0 +1,8 @@ + + +### Wayland/Weston Status/Overview + + +### Kristian Høgsberg + +[[video|http://www.youtube.com/watch?v=L8zwnqKysfI&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn b/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn new file mode 100644 index 00000000..9c223659 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractLucasStach-HWIndependent.mdwn @@ -0,0 +1,8 @@ + + +### Discussing approaches for hardware independent accelerated graphics drivers + + +### Lucas Stach + +[[video|http://www.youtube.com/watch?v=Qc5dFnBCHas&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn b/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn new file mode 100644 index 00000000..5c20890c --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractLucasStach-Tegra.mdwn @@ -0,0 +1,8 @@ + + +### A look at the NVidia Tegra platform (and graphics drivers in the embedded space in general) + + +### LucasStach + +[[video|http://www.youtube.com/watch?v=KbMOQ5rit54&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn b/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn new file mode 100644 index 00000000..2cf283cb --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMaartenLankhorst.mdwn @@ -0,0 +1,8 @@ + + +### Optimus support + + +### MaartenLankhorst + +[[video|http://www.youtube.com/watch?v=CQ1-Myt3coY&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn b/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn new file mode 100644 index 00000000..dea5136a --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMarioKleiner.mdwn @@ -0,0 +1,8 @@ + + +### How Neuro-Scientists Use the Open Source Graphics Stack: some Examples + + +### Mario Kleiner + +This talk gives some examples on how neuro-scientists / brain-researchers use computer-graphics for conducting experiments on human perception and cognition, and what kind of sometimes slightly special requirements this imposes on the graphics stack in terms of features, robustness, accuracy and control and what the pain points and wishes of the developers and users of such research software are. Basically we will talk about how one can make live better (or worse) for developers/users of such research software. diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn new file mode 100644 index 00000000..5484ca90 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier.mdwn @@ -0,0 +1,10 @@ + + +### Recap, Vulnerabilities, Attacks and Discussions on the graphic Stack's Security + + +### MartinPeres, Timothée Ravier + +With the release of new uses of the Linux Graphic Stack (wayland, WebGL), new opportunities and challenges are facing the xorg developers. In this presentation, we talk about what the user can be expecting from the graphic stack and what is currently proposed by X11 and Weston compared to other approaches like QubesOS/PIGA-OS. We then try to analyze ways to introduce stronger security and provide some advices on how to implement some operations in the stack from the hw to the compositors. + +[[slides|secu_xdc2012.pdf]], [[video|http://www.youtube.com/watch?v=hJpiJii44oo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]], [[LWN coverage|https://lwn.net/Articles/517375/]] diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf Binary files differnew file mode 100644 index 00000000..be0bf376 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMartinPeres-TimothéeRavier/secu_xdc2012.pdf diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn b/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn new file mode 100644 index 00000000..e5fa2660 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMartinPeres.mdwn @@ -0,0 +1,10 @@ + + +### Return of experience on the EVoC : How to better prepare the Students + + +### Martin Peres + +With the X.org foundation not participating to the GSoC program, we have seen many students apply to the X.org equivalent of the GSoC, the Endless Vacation of Code (EVoC). + +[[slides|evoc.pdf]] [[video|http://www.youtube.com/watch?v=kOgh2EpKfSo&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf b/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf Binary files differnew file mode 100644 index 00000000..d9b3a178 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMartinPeres/evoc.pdf diff --git a/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn b/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn new file mode 100644 index 00000000..25f2f0b3 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMichaelLarabel.mdwn @@ -0,0 +1,8 @@ + + +### Benchmarking, Request for Phoronix Benchmarks / graphics Tests, Feedback or Flames + + +### MichaelLarabel + +[[slides|michaellarabel-xdc2012.pdf]] diff --git a/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf b/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf Binary files differnew file mode 100644 index 00000000..280b0ee0 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractMichaelLarabel/michaellarabel-xdc2012.pdf diff --git a/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn b/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn new file mode 100644 index 00000000..a22cfb81 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractOliverMcFadden.mdwn @@ -0,0 +1,10 @@ + + +### Dante: Doom3 GPLv3+ (OpenGL 1.x, GLX) through to Dante (OpenGL ES2.0, EGL, GLSL); Teaching an old Engine new Tricks, building a ad-hoc Community, and the struggle for Performance on embedded Hardware + + +### Oliver McFadden + +Using Dante (my Doom 3 ES2.0 engine) as a development example it is shown where we're lacking in Mesa compared to others with proper performance analysis tools and how we could possibly fix that situation. + +[[slides|Dante.pdf]] [[video|http://www.youtube.com/watch?v=PYGeXko_xf0&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf b/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf Binary files differnew file mode 100644 index 00000000..d89cd30b --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractOliverMcFadden/Dante.pdf diff --git a/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn b/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn new file mode 100644 index 00000000..56e2a73e --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractPackard+Anholt.mdwn @@ -0,0 +1,8 @@ + + +### DRI3 + + +### Keith Packard, Eric Anholt + +[[video|http://www.youtube.com/watch?v=ZLnl6s60YL8&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn b/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn new file mode 100644 index 00000000..a1c94771 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractPeterHutterer.mdwn @@ -0,0 +1,14 @@ + + +### X Server Integration Testing. Yes, it's possible + + +### Peter Hutterer + +Aside from the dusty X Test Suite, X server testing tends to be sporadic, manual and ad-hoc. This leads to recurring bugs and breakage that may last several months. + +Over the last couple of weeks, I've been working on a test suite based on googletest and xorg-gtest to automate input driver testing, bug replication and general server behaviour. In this talk, I'll give an outline of the current state of this test suite, followed by a discussion on the future direction of this test suite. Amongst the topics to be discussed are scalability, test case design, the requirement for test cases to be added to bug fixes, etc. Audience participation required and appreciated. + +[[Slides|xorg-integration-testing.pdf]] [[Video|http://www.youtube.com/watch?v=dZTz151SJLw&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] + +See [[http://who-t.blogspot.de/2012/08/xorg-integration-test-suite.html|http://who-t.blogspot.de/2012/08/xorg-integration-test-suite.html]] for more info and (links to) examples diff --git a/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf b/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf Binary files differnew file mode 100644 index 00000000..283fdd05 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractPeterHutterer/xorg-integration-testing.pdf diff --git a/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn b/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn new file mode 100644 index 00000000..53fcc453 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractRobClark-KMS.mdwn @@ -0,0 +1,8 @@ + + +### DRM/KMS Atomic-Modeset / Nuclear-Pageflip + + +### Rob Clark + +[[slides|xdc2012-atomic-pagefilp.pdf]] [[video|http://www.youtube.com/watch?v=Hg-NLICrDB8&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf b/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf Binary files differnew file mode 100644 index 00000000..e2bf0a8f --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractRobClark-KMS/xdc2012-atomic-pagefilp.pdf diff --git a/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn b/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn new file mode 100644 index 00000000..92d14805 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractRobClark-Video.mdwn @@ -0,0 +1,8 @@ + + +### DRI2 Video + + +### Rob Clark + +[[slides|xdc2012-dri2video.pdf]] [[video|http://www.youtube.com/watch?v=nwpy2PNb_MQ&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf b/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf Binary files differnew file mode 100644 index 00000000..5483d340 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractRobClark-Video/xdc2012-dri2video.pdf diff --git a/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn b/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn new file mode 100644 index 00000000..c733b629 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractSaschaHlusiak.mdwn @@ -0,0 +1,12 @@ + + +### Development State and Features of the Joystick Input Module + + +### Sascha Hlusiak + +The joystick input module was part of the old XFree86 distribution, but the driver was in a bad state until 2007, when development was pushed forward. It first supported the Linux joystick kernel device only, later on support for evdev devices was added, which added support for the driver to be hotplugged by hal enabled server. A FreeBSD kernel backend is available as well, but like Solaris, this is not a prominent system on workstations. Today the joystick driver is well hotpluggable using udev and supports many features and configuration possibilities, like generating mouse button events, pointer movement or key strokes. Enabling the driver to act as both, a pointer and a keyboard device, was particularly challenging. Having a second keyboard device with a different keyboard layout was a problem too, but situation improved with recent servers and XI2/MPX. Support for properties enable 3rd party programs to be written that change the configuration of the device on demand. Prominent target platforms are Linux on the PS3 or the XBox. + +Slides: [[xf86-input-joystick.pdf|xf86-input-joystick.pdf]] + +Presentation: [[http://www.youtu.be/Ul2em93dpX4|http://www.youtu.be/Ul2em93dpX4]] diff --git a/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf b/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf Binary files differnew file mode 100644 index 00000000..c25fb82c --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractSaschaHlusiak/xf86-input-joystick.pdf diff --git a/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn b/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn new file mode 100644 index 00000000..ae61de59 --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractSupreetPalSingh.mdwn @@ -0,0 +1,10 @@ + + +### EVOC Experience and Project 'Nouveau - Software scripting Engine for Fermi Architecture based GPUs' + + +### Supreet Pal Singh + +The talk will majorly consist of two parts. In the first section, I will talk about my experience as an EVOC student, how I got involved and selected my area of work. Some of the early problems that I faced and I will put forward some suggestions on how to make the program better. I personally believe this is a great opportunity for students and hence recommend some ways of streamlining and publicizing it. The second section will however be a bit technical as I will describe my work. Starting with the basic setup, I will describe the need of what I did and how much I have been able achieve. This section will include Pdaemon -> Host communication and the Fermi Scripting Engine. Some details of the process will be discussed and what the future course of action is. + +[[slides|XDC 2012 Talk.pdf]] [[video|http://www.youtube.com/watch?v=n41aYIPTiiU&feature=share&list=UUYhzLcUuRRyyhPqGxqr9E3A]] diff --git a/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf b/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf Binary files differnew file mode 100644 index 00000000..bdd6e1ac --- /dev/null +++ b/Events/XDC2012/XDC2012AbstractSupreetPalSingh/XDC_2012_Talk.pdf diff --git a/Events/XDS2007.mdwn b/Events/XDS2007.mdwn new file mode 100644 index 00000000..207c3c6c --- /dev/null +++ b/Events/XDS2007.mdwn @@ -0,0 +1,54 @@ + + +# XDS 2007 +[[!table header="no" class="mointable" data=""" + [[<< XDC 2007|Events/XDC2007]] | **XDS 2007** | [[XDC 2008 >>|Events/XDC2008]] +"""]] + +The X Developers' Summit for 2007 was held at [[Clare College|http://www.clare.cam.ac.uk]], [[Cambridge|http://wikitravel.org/en/Cambridge_(England)]], UK (not the one near Boston), from the 10th-12th September. + +* [[Attendees|Events/XDS2007/Attendees]] +* [[Program|Events/XDS2007/Program]] +* [[Notes from the talks|Events/XDS2007/Notes]] +We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. + +Attendance is free, but you must register beforehand, by putting your name on the Attendees page. + + +## Accommodation + +Accommodation has been arranged through Clare College for around £70 per night, please take advantage of this if possible to help defray the costs of the meeting. The rooms are single rooms with a private ensuite (i.e. own bathroom and toilet). Currently, everyone who has listed themselves on the attendees page without 'non-college accommodation' next to their name is assumed to be staying in the college. We'll have a system set up for you to provide your details and payment shortly. The rooms will have wireless internet access. + +The rooms are available for checkin on Sunday afternoon (the 9th, at 2pm), and checkout on Thursday morning (the 13th, at 9:30pm). Luggage storage will be available. + + +## Travel + +Cambridge is located closest to London Stansted airport (STN), a major hub for low-cost carriers, but is also reachable from London Heathrow (LHR) via train (approximate travel time: two, to two and a half, hours). More travel information is available from Wikitravel. Clare College itself is accessible from Cambridge railway station. + +* From Stansted, there's an hourly train service from underneath the airport, to Cambridge, and a bus during the night/early morning. +* From Heathrow, you have a few choices: + * Take the tube (Underground, any Picadilly line train) direct to Kings Cross (~75m, ~£6), or the Heathrow Express to Paddington (~15m, £13) and then the tube (Underground, Hammersmith & City or Circle line) to Kings Cross (~20m, ~£2). Once at Kings Cross: + * Saturday & Sunday: Take a mainline train service from Kings Cross to Peterborough, changing at Stevenage for a bus service to Cambridge (~2h, ~£15); the train is unavailable due to engineering works. + * Monday-Friday: Take a mainline train service from Kings Cross to Cambridge (~45m, ~£15). + * Take a National Express bus directly from Heathrow to Cambridge (~2-3h, ~£25.50). +* From Gatwick, take the Gatwick Express (~30m, £15) to Victoria, then the tube (Victoria line, going north, ~20m, ~£4) to Kings Cross. See above for how to get from Kings Cross to Cambridge. +* From Luton, a bus runs straight from Luton airport (~90m, £14) to Cambridge bus station. +* From Paris/Belgium/Netherlands/Köln: Eurostar (~2h15/2h30) to Waterloo, then the tube (Northern line going north, changing to either Picadilly or Victoria lines, ~30m, ~£4) to Kings Cross, and see above for how to get from Kings Cross to Cambridge. You get power sockets, GSM reception, and less hassle than the plane. +For train times, please see nationalrail.co.uk, and nationalexpress.com for bus times. Nationalrail has a [[Printable Pocket Timetable|http://ojp1.nationalrail.co.uk/en/pj/jp]] that seems quite useful. + +You should probably plan to arrive on Sunday night, and leave late Wednesday night or early Thursday morning, as there is a (free for attendees) four-course dinner at the college on Wednesday night. The conference itself will run from roughly 9am to 6pm during the three days. We're also planning some optional social activities for the nights: Cambridge, however, has a stupendous number of pubs, and a great many restaurants, cafés, and other places to hang out (all non-smoking now). + + +## Registration, talks + +If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/xds2007]] for updates. Also, please add your name to the [[Attendees|Events/XDS2007/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2007/Program]] pagee. + + +## Links + +* [[Clare College|http://maps.google.com/maps?f=q&hl=en&geocode=&q=trinity+lane,+cambridge,+uk&sll=52.202544,0.131236&sspn=0.085007,0.233459&ie=UTF8&ll=52.207686,0.116258&spn=0.010625,0.029182&t=h&z=15&iwloc=addr&om=1]] map +* [[Clare College information|http://www.clare.cam.ac.uk]] +* [[Cambridge travel information|http://wikitravel.org/en/Cambridge_(England)]] from Wikitravel +* [[Cambridge information|http://en.wikipedia.org/wiki/Cambridge]] from Wikipedia +* [[UK Train Times|http://www.traintimes.org.uk]]
\ No newline at end of file diff --git a/Events/XDS2007/Attendees.mdwn b/Events/XDS2007/Attendees.mdwn new file mode 100644 index 00000000..874a5363 --- /dev/null +++ b/Events/XDS2007/Attendees.mdwn @@ -0,0 +1,59 @@ + + +# XDS2007 Attendees + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/xds2007]] if you are planning to attend [[XDS2007|Events/XDS2007]]. THERE ARE NO MORE PLACES LEFT FOR XDS. Sorry! + +If you do _not_ plan to use the college accommodation, please note this next to your name. + +1. [[DavidAirlie|DavidAirlie]] +1. [[MatthewAllum|MatthewAllum]] +1. [[DanAmelang|DanAmelang]] +1. [[EricAnholt|EricAnholt]] +1. [[MarcBalmer|MarcBalmer]] +1. [[JesseBarnes|JesseBarnes]] +1. [[JakobBornecrantz|JakobBornecrantz]] +1. [[RobBradford|RobBradford]] +1. [[JohnBridgman|JohnBridgman]] +1. [[MichelDaenzer|MichelDaenzer]] +1. [[AlexDeucher|AlexDeucher]] +1. [[JimGettys|JimGettys]] +1. [[BriceGoglin|BriceGoglin]] +1. [[JeromeGlisse|JeromeGlisse]] +1. [[BryceHarrington|BryceHarrington]] +1. [[ThomasHellstrom|ThomasHellstrom]] +1. [[MatthieuHerrb|MatthieuHerrb]] +1. [[AlanHourihane|AlanHourihane]] +1. [[KristianHøgsberg|KristianHøgsberg]] +1. [[ZephaniahHull|ZephaniahHull]] +1. [[PeterHutterer|PeterHutterer]] +1. [[AdamJackson|AdamJackson]] +1. [[StuartKreitman|StuartKreitman]] +1. [[StephaneMarchesin|StephaneMarchesin]] +1. [[BartMassey|BartMassey]] +1. [[KeithPackard|KeithPackard]] +1. [[VedranRodic|VedranRodic]] +1. [[ZackRusin|ZackRusin]] +1. [[RolandScheidegger|RolandScheidegger]] +1. [[DodjiSeketeli|DodjiSeketeli]] +1. [[DanielStone|DanielStone]] +1. [[MatthewTippett|MatthewTippett]] +1. [[TiagoVignatti|TiagoVignatti]] +1. [[ZhenyuWang|ZhenyuWang]] +1. [[KeithWhitwell|KeithWhitwell]] +1. [[CarlWorth|CarlWorth]] +1. [[PauloZanoni|PauloZanoni]] +1. [[ZouNanhai|ZouNanhai]] +1. [[EamonWalsh|EamonWalsh]] +1. [[BenSkeggs|BenSkeggs]] (tentative) +1. [[MichaelDales|MichaelDales]] (non-college accomodation) +1. [[EgbertEich|EgbertEich]] (non-college accommodation) +1. [[MatthewGarrett|MatthewGarrett]] (no college accommodation) +1. [[MarcusGranado|MarcusGranado]] (non-college accommodation) +1. [[ThomasHunger|ThomasHunger]] (non-college accomodation) +1. [[DaveJones|DaveJones]] (non-college accommodation) +1. [[KyleMcMartin|KyleMcMartin]] (non-college accommodation) +1. [[DavidReveman|DavidReveman]] (non-college accommodation) +1. [[PaulSladen|PaulSladen]] (non-college accomodation) +1. [[LucVerhaegen|LucVerhaegen]] (non-college accommodation) +There are only 50 spots: this is a hard limit! diff --git a/Events/XDS2007/ModeSettingBoF.mdwn b/Events/XDS2007/ModeSettingBoF.mdwn new file mode 100644 index 00000000..ea6f6a8c --- /dev/null +++ b/Events/XDS2007/ModeSettingBoF.mdwn @@ -0,0 +1,46 @@ + +This page is to get a preliminary idea of what people want to discuss at the modesetting BOF at XDS. + +The BOF will mostly be concerned with the push to add modesetting to kernel space on Linux platforms, which is useful for suspend/resume and also for smooth GUI bootup. + +[[DavidAirlie|DavidAirlie]]: 1. Bash out the correct API level, at the moment modesetting-101 possibly does too much in-kernel. 2. Add a control drm device node that is persistent. 3. Userspace daemon vs none. + + + +--- + + + +* [[JakobBornecrantz|JakobBornecrantz]]: 1. Persistent- vs dynamic memory allocation for scanout buffers. + + +--- + + + +* [[SylvainBertrand|SylvainBertrand]]: 1. suspend/resume/power management kernel interfaces to implement are specific to each driver model. Creating a DRM interface which would suit all driver models may not be reasonable. Another approach would be to have driver model specific code (with all the suspend/resume/power management kernel interfaces implementations) and a perfectly orthogonal DRM interface (As far as I understood current DRM, it provides almost a full blown driver model abstraction layer, I may be wrong though). The mode setting interface would be part of the "perfectly orthogonal DRM interface". 2. What's up with ACPI model (see ACPIspec30a.pdf pages 591&592)? + + +--- + + + +* [[JesseBarnes|JesseBarnes]]: my main concern is the current fb layer. The current code & design duplicates a lot of fb functionality (getting mode lists, setting modes, exporting interfaces to userland). How much duplication is acceptable? Should we extend the fb APIs or accept the duplication? Should fb be obsoleted entirely by this new code? Should we share code? If the answer to the last question is no, I think we can expect a lot of pushback from the fb and broader kernel community... + + +--- + + + +* [[JeromeGlisse|JeromeGlisse]]: +1. Do we want to emulate framebuffer in kernel ? The scanout buffer format might be a little bit complicated to handle in kernel (stride, tiles, ...) and we may want to avoid to put such knowledge in the kernel. Then how kernel can tell you when anythings when it panics (asking for the modesetting to provide a failsafe and easy to use mode might help but also might not work in all case). This was already discussed a bit on IRC and mail. + +2. IOCTL versioning versus tag based arguments. Maybe it's good to think now to possible interface change rather than find out in couple of month, years that changing the interface is painfull (as it is now). + +3. For power management i would like to see the kernel exporting each hw capacity through somethings like HAL so we can then use some project like ohm which i believe is aimed to centralize all this power things. But i don't think this really fit modesetting topic and likely we could already work on this without drastic change in drm. + + + +--- + + diff --git a/Events/XDS2007/Notes.mdwn b/Events/XDS2007/Notes.mdwn new file mode 100644 index 00000000..44ee6f7d --- /dev/null +++ b/Events/XDS2007/Notes.mdwn @@ -0,0 +1,421 @@ + +Various notes from XDS2007 presentations. Please fill this out with links to slides, project pages, etc. + +[[!toc ]] + + +# Day One + + +## John Bridgman, Matthew Tippet - AMD/ATI + +* NDA-less 2D specs coming soon, 3D specs coming later, r300 3D specs coming even later +* Dedicated developer support team too +* Modesetting to use ATOM BIOS for some things: set of data tables, and interpreted code, which means you can do native POST on any architecture. Windows driver and BIOS already using this, so it's very capable (not another VESA). +* Legal issues regarding HDCP and DRM video decoding, which means those parts become harder. +* AMD using the doc release process to improve internal documentation quality too + +## Dave Airlie - Red Hat X.Org work + +* Fedora 9 in May/June of 2008 +* Composite needs to be on by default. What needs to be fixed for that? +* GLX needs to obey window redirection +* Likewise for Xv +* 2D acceleration should work, hardware accel all the way through rendering +* Need a proper memory manager to tie all these things together +* krh has been working on redirected GL +* airlied working on getting TTM mergeable into the kernel +* cworth been optimising intel EXA and benchmarking +* Smooth GUI booting: no mode switches and annoying flashes. +* Requires kernel modesetting, which requires TTM. +* X thus requires DRM, which hurts the BSDs and Solaris, which don't really have it everywhere. +* Life's tough, can't hold back development for OSes which lack development resources. +* Some Linux developers want the DRM to become a Linux-only project and not cross-platform anymore, but airlied and others have been admirably resisting this. + +## Stuart Kreitman - Sun Desktop Update + +* EOL of Xsun! Solaris-wide commitment to Xorg +* Transition complete for x86, in process for SPARC and [[SunRay|SunRay]] +* S10_U4/SXDE3 are on Xorg 7.2. S10_U5/SXDE4 are Xorg 7.3. +* Features TSOL, Composite, RANDR 1.2, wide hardware support +* Primary support for ATI, Intel, and NVIDIA +* SPARC hardware projects: ffb, elite3d, PGX64, XVR100, PGX32 +* Xorg has a DTrace provider now +* Belenix: Merged osol and Xorg packaging +* Martux: SPARC distro, includes the various SPARC drivers +* FOX project: OSOL project to integrate X efforts among OSOL distros +* [[http://www.opensolaris.org/os/community/desktop/|http://www.opensolaris.org/os/community/desktop/]] + +## Alex Deucher - driver/xf86-video-ati, yesterday, today, and tomorrow + +* Yesterday: Hardcoded crtc to output mappings +* 2 output limit, randr-like functionality through mergedfb +* Today: full randr 1.2 support, all outputs supported, initial mac support +* Tomorrow stuff! + * RMX, the panel scaler. Off, full, center, aspect. + * In principle can be used on any output, currently only used on LCDs. + * DVO, external connections for outputs. DAC, TMDS, etc. + * Needed for external TMDS. x86 legacy bios has external TMDS table. + * Non-VBE posting. Code for legacy BIOS that doesn't quite work. + * ATOM BIOS should get this for free with the new parser. + * ATOM parser should get folded into radeon too. + * Planning to merge r128 into radeon. + * Probably want to split mach64 out and drop the old ATI wrapper + * Composite transforms need fixing on R100 and R200 so rotation works + * More TV-out modes, fix PAL, random bugfixes +* Day after tomorrow + * TTM. Needs DRM support. airlied did some experimental work. + * R300/R400 Composite. Render accel and rotation support. + * PCI rework, kernel modesetting. + +## Zack Rusin - Accelerating Desktops + +* Render has good text handling, but is quirky and complicated +* So what gets used? Composition, rasterisation, transforms and gradients +* What is easy to accelerate? Composition, transform, gradients. Rasterisation is a problem. +* EXA doesn't require DRI, is self-contained, basic composition is easy +* EXA syncs. And syncs. And shares state with 3D engine. +* Using the 3D engine from the 2D driver requires writing the code twice. +* (long technical discussion about where to put code) +* Things that still aren't accelerated: Tesselation, Image effects, Curve decomposition +* (lots of head nodding and general planning) + +## X.Org Board Update + +* Trying to convert from LLC to 501(c)3 +* Also trying to divest a cash backlog, since we should be not-for-profit +* Most of the current cash reserve is from heldover consortium fees +* Still need other ideas for things to do! Ask! +* We are now VESA members. +* May join Khronos soon for GL stuff. +* Developers, please sign up for Foundation membership! + +## Zhenyu Wang - XvMC and stuff + +* XvMC status, VLD extension issues +* H.264/AVC intro +* new XvMC API proposal for H.264/AVC +* slides at [[http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf|http://people.freedesktop.org/~zhen/xds2007_xvmc.pdf]] + +## Keith Packard - Intel Status Update + +* 2D driver for i810 through present +* 3D driver splits at major architectural changes: 830, 915, 965 +* Include old hardware support for new features +* Test environment includes at least one of each chipset +* Ship new features when ready +* BIOS-free modesetting, hotplug monitors, rotation, other randr1.2 hotness +* TV-out supported on all mobile chips +* Current driver: OpenGL 1.5, overlays on hardware that has it, textured video on everything else +* Next driver: OpenGL 2.1, HW MPEG decode, output scaling, HDMI, power savings +* DFGT, DRRS, DPST, D2PO. Magic acronyms with no definition. +* OpenGL performance measurement and tuning planned +* Future media: MPEG iDCT, VLD, H.264, VC-1, de-interlace, etc. +* Output support: kernel modesetting, eliminate POST on S3 resume +* Moving to TTM and new memory manager, lots of optimisation there +* GLSL with minor issues. TTM mostly working. Shipping GL 2.1 by January. + +## Carl Worth - EXA/i965 Performance + +* [[http://cworth.org/tag/exa/|http://cworth.org/tag/exa/]] +* Cairo adoption: gnome (librsvg, poppler, evince), mozilla, webkit-gtk +* Stack: app, cairo, Render, EXA +* Benchmarks! Wouldn't those be nice + * cairo-perf: git://git.cairographics.org/git/cairo, make perf. synthetic, micro + * x11perf. synthetic, micro, very poor Render coverage + * mozilla trender. [[http://cworth.org/trender_bookmark/|http://cworth.org/trender_bookmark/]]. real, macro. +* Results. EXA does blit and solid fill really really well. +* EXA is a slowdown for trender, which is primarily a glyphs benchmark. +* i965 problems. hidden RMW cycles, synchronous compositing, pinned glyphs. +* Improvements. Fixed RMW cycles. +* Posted patches to store glyphs as pixmaps and eliminate some fallbacks +* Idea for "[[PolyComposite|PolyComposite]]" hook. +* Future work: memory management, fallback elimination, transforms +* Want to do trapezoid/polygon rasterisation and gradients in hardware too + +## Vedran Rodic - OpenGL performance + +* Performance is really bad. How can I help? +* Gamers want high performance, aren't finding it in OSS drivers +* R100 was released in 2000, didn't get HyperZ until 2004 +* gears is ~twice as slow on linux than windows for 945GM +* (sysprof profile, technical discussion about implementation details) +* Need better documentation for GPU instruction sets +* Ideas + * Cross-platform performance and conformance test suite + * Test farm with all supported hardware for regression testing + * Driver developers should work from beginning of product development + +# Day Two + + +## Zou Nan Hai - GLSL + +* GLSL is the OpenGL shading language, a feature of GL 2.0 +* There are other high level shading language: Cg, HLSL +* Supports vertex and fragment programs with the same syntax +* Provides C like language: function calls, onditionals, branches +* Some builtins and keywords are different between vertex and fragment shaders +* Use "varying" variables to pass values between vertex and fragment stages +* (example programs) +* Mesa includes a GLSL frontend, IR, and software backend +* Intel working on 965 backend based on existing program emit code +* 965-glsl branch in Mesa, many demos are working +* Not fully tested yet, some IR ops not implemented yet, error report needs work +* Ideas about optimization (register allocation, various builtins) +* Future ideas: debugger, profiler, wider adoption + +## Keith Whitwell - Gallium, softpipe, Cell, and beyond + +* Historically we had a complete core and very compact drivers +* This has been changing: more complex drivers, harder bringup +* Want to fix this. Driver model is no longer correct +* Impose new interfaces and objects +* Stack: Mesa, state tracker, Gallium hardware driver, os/window layer, dri/drm +* New model inspired by GL3, NV_GPU4, 965, etc. +* constant state objects, simple drawing interface +* unified shading language as bytecode, private buffers as reder targets +* ability to re-target hw drivers to new APIs, window systems, and OSes +* interface: create/bind/delete state, draw, buffer management, fencing, flush +* state tracker reduces GL to this small interface, deals with GL quirks +* winsys layer does two interfaces: glx/dri and hw/drm +* glx/dri is the window system, cliprects, swapbuffers, etc. +* hw/drm is the kernel, command buffer dispatch, etc +* reference driver is "softpipe", the reference/sample software renderer +* looks very much like a GPU pipeline written for a CPU +* also a proof of concept driver for i915 +* two winsys backends: xlib and dri +* Mesa-GL3 basically talks to gallium drivers directly +* eliminates most of the state tracker complexity of GL1/GL2 +* Also means you can port the gallium drivers to DX/Vista +* future: softpipe + llvm, pervasive codegen for the whole driver +* should have initial targets of x86 and cell +* failover driver, moves fallback handling out od driver and state tracker + +## Kristian Høgsberg - Redirected Direct Rendering + +* ... and GLX 1.4, and zero-copy tfp, and lazy buffer alloc, and cleanup +* DDX and EXA changes. DDX allocates all buffers as DRM buffer objects +* Shared ancillary buffers allocated dynamically +* EXA calls DDX driver hook to allocate pixmaps as buffer objects +* DRI module changes. Add DDX driver hook to allocate ancillary buffers. +* Adds pixmap private to store ancillary buffers so client sharing works +* This works for all pixmaps, including the screen pixmap +* (technical discussion of senamtics of back buffers) +* Hooks [[SetWindowPixmap|SetWindowPixmap]] to allocate ancillary buffers when redirection happens +* On buffer reallocation, signal the DRI driver through the SAREA +* From DRI driver perspective, redirecting and resizing are the same operation +* Again, works for the screen pixmap too +* Breaks the DRI API slightly, removing X assumptions +* New extension mechanism for the DRI driver to advertise new functionality +* (example of DRI_COPY_SUB_BUFFER extension) +* Redirected direct rendering falls out for free, because the front buffer moves +* GLXPixmaps are mostly the same as a redirected window now +* GLXPbuffers are also easy to create +* Add support for glXChangeDrawableAttributes for API reasons +* ... but we never clobber them, so you never need to send out the event +* glXGetProcAddress is already done, so with all that, we get GLX 1.4! +* Need to fix visual setup so you can advertise fbconfigs with pbuffer support +* GLX_texture_from_pixmap gets cooler too +* Pixmaps are now buffer objects, so you can bind them to textures directly +* SAREA is now the only user of drmAddMap/drmMap +* Suggestion for SAREA journal and/or deletion, and upgrade path +* (really hot demo) + +## Lots of people - TTM BoF + +* Things to fix for upstreaming: accounting pinned memory, initial memory size +* Is the API finished? Is superioctl correct? +* There's a NO_MOVE flag and a NO_EVICT flag, discussion about why both +* Want to remove hardware lock requirement for creating buffers +* Split buffer creation and buffer validation +* Locking issues surrounding the 'kernel context' + +## Dan Amelang - jitblt + +* Addresses the problem of the complexity of Render compositing operations +* Currently implemented as a big case explosion of unpack/composite/pack +* Plus some special casin for fastpaths +* jitblt replaces that with a dynamic code generator +* implemented in a lispish microlanguage called jolt +* declarative syntax for pixel formts and compositing operators +* optimization passes for constant folding, algebraic identities, and CSE +* pixman goes from 9500 lines to ~750 +* faster than pixman for anything in fbCompositeGeneral +* comparable for many common fastpaths. slower for arm and for memcpy. +* still lots of room for optimization + +## Michael Dales - drivers for non-local graphics and input + +* Currently, the usage model is one computer per person +* This doesn't scale well: cost, energy, resources, maintenance +* How do you share the system without degrading the user experience? +* "nivo": network in, video out. vga+input over ethernet, ultra-thin client. +* Also available as vga+input over usb, available in many products +* Currently driven as a pipe to Xvnc +* Developing an Xorg driver as well for better performance +* not a typical driver: both input and output, no modesetting, not pci +* Working on Xorg 7.x, DVD playback over USB with no optimisation effort +* Need to finish keyboard, rotation, Xv, hotplugging + +## Daniel Stone - Input overview and plans + +* Xi, hotplug, MPX, XKB, DDX/DIX status, event refurbishment +* Xi was developed for "one mouse for normal UI, plus a spaceball" +* Basically only used in the gimp. +* Exposes a device with an arbitrary number of buttons, axes, keys. +* You walk the device list, open your device, and get exclusive event delivery +* Horrible event model though. The better model would be core + device id. +* Once you do that, hotplug is pretty easy. +* MPX is multiple pointers with multiple cursors. Which means multiple foci. +* "Multiple grabs mean head-exploding issues." +* XKB is wretched. Exposes bad binary format over the wire. +* API was defined in terms of (bad) implementation. +* New API that matches use was patched on as badly as possible. +* But, it's very necessary. So how do you fix it? +* Delete the old API, everything is rules-model-layout-variant-options +* Fold xkbcomp into the server to speed up startup and make it work +* Far too much stuff was handled in the DDX, identically among all of them +* input hotplug moves as much as possible to the DIX layer +* Get*Events return a pile of wire protocol xEvents +* Requires much back-inference to actually send the events +* Needs a rework, there is a plan +* Remaining issues +* High keycodes - can't solve without a protocol bump +* More than four layouts - either a ridiculous server hack, or a protocol bump +* Multiple pointers - almost done! +* Code quality is wretched, needs to be redone for bugs' sake +* Input hotplug basically not adopted yet + +## Peter Hutterer - MPX + +* MPX basics +* Currently, there's only one pointer and keyboard; how lame +* MPX splits that into a cursor per device +* core pointer and keyboard are now virtual, only for compatibility +* multiple devices in any client, multiple clients at a time +* nothing changed if you only have one set of devices +* (demo) +* MPX quirks +* Enter/Leave and [[FocusIn/FocusOut|FocusIn/FocusOut]] changed. +* First pointer in sends an Enter event, last one out sends a Leave +* Same for Focus; first keyboard in sends a [[FocusIn|FocusIn]], last one out sends [[FocusOut|FocusOut]] +* Keyboard has to be paired with a pointer +* Pairing rules +* Pair keyboard with first unpaired pointer +* Else, pait keyboard with first pointer +* Else if no real pointer, pair with the virtual core pointer +* API for changing the default rules +* For ambiguous requests, the client is assigned a "client pointer" +* Grabs: formerly, core devices with core grabs, single device with Xi grab +* Now, grabs act on a single device, so multiple clients can grab +* For core events, grabs mean the whole UI is bound to just that device +* Core grab means 1:1 mapping between device and client +* Xi device grab means device bound to client but client can talk to many devices +* Passive grabs are owned by the device that activates the grab +* Remaining issue: N devices per cursor and grab semantics +* XGE +* The core event spec is painfully constrained. 32 bytes per event, 64 events. +* Generic events fix this, more space per event, more event types +* Server can't send a long event until the client says it knows about them +* MPX uses this for several things, required for multitouch +* MPX multitouch +* Mouse is fine for point events, but some touchscreens send mutiple blobs +* New XBlobEvent that just shoves data to the clients +* 282 lines for all this plus pointer emulation on the hotspot + +# Day Three + + +## Matthew Garrett - ACPI + +* ACPI started as a replacement for APM, MP-BIOS, interrupt routing, e820 +* Interface between the firmware and the OS, bonghits, misc, other +* Often extended in undocumented, inconsistent ways by vendors +* ACPI 2.0 added an optional video extension; now required by Vista +* Gives you display switching, brightness control, EDID, POST device +* _DOS method (display output switch) switches displays and gives you an event +* Sometimes you can suppress the system from doing this and handle it yourself +* Brightness control gives you events on change, and a get/set interface +* But the platform may change brightness anyway without telling you +* Display enumeration gives you CRTCs and physical connectors +* Might tell you connection status, if you're lucky +* Will tell you whether the port is currently present (or on a dock) +* ROM method if you don't have a PCI BAR, except it's not the ROM +* Can query the boot adaptor, and can set the boot adaptor +* EDID method mandatory if it's not available some other way +* Impossible to map the ACPI video ID to a PCI slot +* [[OpRegions|OpRegions]] (unpublished spec) provides a backchannel for communication +* ACPI doesn't require anything of the gfx hardware over suspend +* So we try to POST and hope, and sometimes that works +* Or you can do VBE save and restore state, and sometimes that works +* Or you can do pre-VBE set text mode, and sometimes that works +* Mostly it just doesn't + +## Dave Airlie, Jesse Barnes, Jakob Bornecrantz - Kernel Modesetting BoF + +* API looks pretty much like the RANDR protocol now +* Add a DRM control file for persistent state (since we can't with current DRM) +* Use privileged switcher for fast user switching +* Requires some enhancements to the resume path to really work nicely +* Memory eviction on suspend is hard + +## Adam Jackson - Monitors and why they hate you + +I didn't take notes on my own talk. Anybody? + + +## Egbert Eich, Luc Verhaegen - ATI Driver Status + +* When ATI dropped support for the open driver, distros lives got hard +* SuSE has a end-user installer, but that's still not perfect +* Started discussions about how to enable an open source driver again +* ATI approached SuSE to develop a driver, working on it for the last ~6 weeks +* Mostly working, still some output setup buglets +* (Details about some bringup issues) +* First code drop planed on Monday +* Docs approved for release without NDA about 45 seconds ago + +## Zack Rusin - LLVM for Mesa + +* LLVM has two primary components: optimizer and codegen, and gcc front-end +* Standard suite of SSA-based optimizations, support for many targets +* Strongly typed, extensible, vector-aware IR +* Good pipeline, link time opt, jit, easy to work ith and learn +* Well maintained, BSD licensed, great for us to use but not care about +* So: Cg/HLSL/GLSL -> LLVM IR -> Optimizer -> codegen or jit +* Minor problem since it assumes the target CPU has branches +* But really easy to wire up already + +## Daniel Stone - KDrive futures + +* Xorg within spitting distance of being as small as KDrive +* Move generally useful Xorg stuff to DIX, at which point there's not much difference between the two +* Smaller systems mostly running KDrive on framebuffer because everyone else is +* Pure size isn't too much of an issue, compared to FPU/cache locality/etc + +## Eric Anholt, Adam Jackson, Daniel Stone - Future releases + +* 1.4.1: 1st November, 2007. Daniel as RM, nominate on [[Server14Branch|Server14Branch]] as usual. +* 1.5.0: 1st March, 2008 +* Scribbled on the board for 7.4/1.5: XGE, XACE, RandR 1.3 (GPU object), input transformation, pci-rework, XKB 2, _X_EXPORT, DRI memory manager, GLX 1.4, Glucose +* 7.5 features: MPX, lifting DMX up to DIX + +## Stephane Marchesin, Jerome Glisse - Reverse Engineering + +* We have kernel source, but no driver source. +* So we can watch everything the closed driver does and try to figure it out +* Or, that's the theory +* Simple tools: register dumper, BIOS emulator +* Complex tools: libsegfault (unmap the card, trap the fault, record, put back) +* Later done better as valgrind-mmt. But all this is userspace only. +* mmiotrace works on kernel-level accesses too +* renouveau: find the command fifo, feed it GL, watch for changes +* Inspect one thing at a time: single video mode at different refresh rates, eg +* Do lots of dumps so you can identify the commonalities and differences +* (example of delta finding) +* Future work on higher level tools, other architectures, etc. + +## Eamon Walsh - XACE Demo + +* (Demo of protected windows)
\ No newline at end of file diff --git a/Events/XDS2007/Program.mdwn b/Events/XDS2007/Program.mdwn new file mode 100644 index 00000000..03f53192 --- /dev/null +++ b/Events/XDS2007/Program.mdwn @@ -0,0 +1,57 @@ + + +# XDS2007 Program + +This is the rough program for [[XDS2007|Events/XDS2007]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk. Please contact Dave Airlie < [[airlied@gmail.com|mailto:airlied@gmail.com]] > for any scheduling suggestions or changes. + +Refreshments (coffee, tea, biscuits, etc) will be served throughout the day. Breakfast will be served at 8am for those in the college. Lunch and dinner will be off-campus. + + +## Program +[[!table header="no" class="mointable" data=""" + | **Monday** (Drivers) | **Tuesday** (OpenGL and related, Input) | **Wednesday** (Future plans, misc, other) + **9am** | Welcome and Foundation overview ([[DanielStone|DanielStone]] and crew) | GLSL ([[ZouNanhai|ZouNanhai]]) | Local compositing with DMX ([[DavidReveman|DavidReveman]]) + **10am** | Red Hat X.org Overview ([[DavidAirlie|DavidAirlie]]) / Sun X.org overview ([[StuartKreitman|StuartKreitman]]) | [[Softpipe|http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007.odp]] ([[KeithWhitwell|KeithWhitwell]]) | Embedded systems ([[DanielStone|DanielStone]]) + **11am** | _morning tea_ | _morning tea_ | _morning tea_ + **11:30am** | [[Radeon driver status|http://www.botchco.com/alex/xorg/radeon-xds.pdf]] ([[AlexDeucher|AlexDeucher]]) | TTM and redirected DRI ([[KristianHøgsberg|KristianHøgsberg]]) | ACPI and video driver interactions ([[MatthewGarrett|MatthewGarrett]]) + **12:15pm** | Render acceleration improvements ([[ZackRusin|ZackRusin]]) | TTM BoF ([[KeithWhitwell|KeithWhitwell]]) | Kernel Modesetting BoF ([[DavidAirlie|DavidAirlie]]) + **1pm** | _lunch_ | _lunch_ | _lunch_ + **2pm** | XvMC ([[ZhenyuWang|ZhenyuWang]]) | Jitblt ([[DanAmelang|DanAmelang]]) | Long lunch + **3pm** | Intel driver architecture ([[KeithPackard|KeithPackard]]) | Ndiyo ([[MichaelDales|MichaelDales]]) | Monitor specs ([[AdamJackson|AdamJackson]]) + **3:30pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_ + **4pm** | EXA/i965 performance ([[CarlWorth|CarlWorth]]) | [[Input overview and plans|http://www.fooishbar.org/talks/xds2007-input.pdf]] ([[DanielStone|DanielStone]]) | LLVM for acceleration ([[ZackRusin|ZackRusin]]) + **5pm** | OpenGL performance ([[VedranRodic|VedranRodic]]) | MPX ([[PeterHutterer|PeterHutterer]]) | Reverse engineering ([[JeromeGlisse|JeromeGlisse]], [[StephaneMarchesin|StephaneMarchesin]]) + **7pm** | _be social_ | _be social_ | four-course dinner at the college +"""]] + + +## Ideas + +* Input ([[DanielStone|DanielStone]]): explanation of how our input code works today, and what we're planning (e.g., the input thread and its mini-status given by [[TiagoVignatti|TiagoVignatti]]). +* Small devices ([[DanielStone|DanielStone]]): The challenges _actually_ facing X on small devices, such as the Nokia N800; what are we going to do with KDrive? +* EXA/i965 performance issues ([[CarlWorth|CarlWorth]]): How can we make our newest free-software supported hardware really fast? +* Reverse-engineering tools ([[JeromeGlisse|JeromeGlisse]], [[StephaneMarchesin|StephaneMarchesin]]): The tools and techniques you need for reverse engineering. (Not that you'd ever want to ...) +* Intel driver architecture ([[KeithPackard|KeithPackard]]): How the intel driver works today and where the cool new features are landing. +* MPX and XGE ([[PeterHutterer|PeterHutterer]]): Update on the status, what works, what doesn't yet. +* Fixing Xrender's rasterization ([[ZackRusin|ZackRusin]]): General talk on ways in which we could improve Xrender's rasterization semantics and algorithm to make it more acceleration friendly. +* LLVM and graphics ([[ZackRusin|ZackRusin]]): What's LLVM, how it works and what are the most interesting things about it when viewed from a perspective of graphics. +* Accelerating desktops ([[ZackRusin|ZackRusin]]): Problems and challenges in building a robust acceleration framework for modern desktops. Focused on acceleration of font and complex polygon rendering. +* OLPC display and power management ([[JimGettys|JimGettys]]): The OLPC XO-1 has a unique, novel LCD panel, and can suspend the processor leaving the LCD alive. If I can persuade [[AdamJackson|AdamJackson]], we'll probably do a tag team about how this came to be and how it's been implemented. +* GLSL support in Intel driver ([[ZouNanhai|ZouNanhai]]): How GLSL is implemented on Intel graphic card and mesa driver. +* X.Org Foundation (Foundation board): What the Foundation has done, what we're planning to do, and general status. +* X Protocol in Java ([[RomanKennke|RomanKennke]]): Introducing and discussing [[Escher|http://escher.sourceforge.net]], an X protocol implementation written completely in Java. +* Jitblt ([[DanAmelang|DanAmelang]]) Just-In-Time compilation of image compositing kernels in pixman. +* XvMC improvement ([[ZhenyuWang|ZhenyuWang]], [[HaihaoXiang|HaihaoXiang]]): How's current XvMC support on Intel graphics, what's needed to be improved for hw accelerated H.264/AVC decoder. +* coming Red Hat X.org attractions ([[DavidAirlie|DavidAirlie]]) - Overview of upcoming roadmap for X.org in Fedora and RHEL - compositing + modesetting +* Modesetting BOF (David Airlie) - [[ModeSettingBoF|Events/XDS2007/ModeSettingBoF]]- A BOF session on moving modesetting interfaces into the kernel +* If it wasn't for those pesky kids ([[DavidAirlie|DavidAirlie]]) - current status of open source drivers for X.org +* Softpipe, whats all that about then? ([[KeithWhitwell|KeithWhitwell]]) - Tungsten Graphics and others plans for renewing the Mesa software rasterizer, creating a Cell driver, and a new driver model for Mesa. +* TTM BOF ([[KeithWhitwell|KeithWhitwell]]) - Wiki page at [[TTMBoF|Events/XDS2007/TTMBoF]] I see lots of disjoint conversations about the memory manager, I think we need to take this opportunity to get some alignment amongst all the groups using & developing TTM. +* 3D driver performance ([[VedranRodic|VedranRodic]]): I'll focus on the intel915 driver since I own the hardware. 915tex driver helps Quake3 (about 50% faster), but [[SecondLife|SecondLife]] is still much slower than Windows +* Redirected direct rendering, TTM based texture-from-pixmap and GLXPixmaps (Kristian Høgsberg) - presenting a working prototype and discussing required interface changes. +* New monitor standards (and/or ones we just don't implement yet) and their impact on RANDR and the driver model. ([[AdamJackson|AdamJackson]]) +* radeon driver: where we were, where we are now, where we are going ([[AlexDeucher|AlexDeucher]]) +* Ethernet & USB Thin Client drivers: Some bits of the ethernet Nivo think client work and drivers for USB monitors from based on the Display Link chipset ([[MichaelDales|MichaelDales]]) +* Using Xdmx as a remote proxy X server that allows compositing to be done locally ([[DavidReveman|DavidReveman]]) +* The interaction between ACPI and video drivers ([[MatthewGarrett|MatthewGarrett]]) +* What happens in the year of the desktop ([[MatthewTippett|MatthewTippett]])
\ No newline at end of file diff --git a/Events/XDS2007/TTMBoF.mdwn b/Events/XDS2007/TTMBoF.mdwn new file mode 100644 index 00000000..6e057c67 --- /dev/null +++ b/Events/XDS2007/TTMBoF.mdwn @@ -0,0 +1,61 @@ + +Discussion list for TTM BoF at XDS 2007. + +Please just add your name and a list of things you would like to raise... + + + +--- + + + +* [[DavidAirlie|DavidAirlie]] +1. Unfenced list removal + +2. removal of any unused interfaces to avoid long term support in upstream kernels + +3. Mandatory super ioctl in the driver. + +4. Relocation types. + +5. fake buffer type (do we need to pass in the type at all, really userspace dc or user can be worked out from the pointer - krh) - agreed to remove this from interface. + + + +--- + + + +* [[JeromeGlisse|JeromeGlisse]]: There was a discussion on irc about handling of cliprect i am not sure this truely fit this topic and likely could be worked before TTM. The things is that if we want multiple consumer of DRM (could be two X server running at the same time using the same hw but each one having its head or one visible while the other in background, whatever) for that i think it would be better to move all sarea and other DRI initialization bit out from DDX to libdrm for instance, also providing API to handle cliprect in libdrm (this was proposed by [[KristianHøgsberg|KristianHøgsberg]]). So libdrm handle remaining initialization of DRI that were done in DDX. In such scheme we might need to have some notion of master/slave or parent/child in libdrm so parent|master own the framebuffer and authorize who can have a dri context for this framebuffer|scanoutbuffer and also is the only one who can update cliprect of its child|slave. This is just my feeling and wish (i tend to always ask too much to Santa :-)) and i could also be totaly wrong about all this as i never truely looked deep into this part of the code ) + * [[KristianHøgsberg|KristianHøgsberg]]: I'm no longer convinced that we need to push this into libdrm and the kernel modules. Optimizing the way the server communicates cliprects will probably go a long way. I've been working on a system BO based 'journal' idea, where the xserver writes changes to cliprects, window positions and drm_drawable_t -> ancillary buffer objects mappings. DRI clients read from this journal and keep their own tail pointer. This way,clients can quickly see if they're behind, and can catch up without doing protocol do the server (ie while holding the lock). + * [[KeithWhitwell|KeithWhitwell]]: Cliprects are just evil anyway. Switching to a private-backbuffer arrangement leads to drivers which are vastly easier to understand and deal with, and then you only have to examine cliprects once per frame which is not a significant cost with the existing DRI facilities. In any case they certainly have nothing to do with the buffer manager - if you care about cliprects it is because of choices you have made in the window-system integration layer, in my opinion the buffer manager shouldn't care about this at all. + + +--- + + + +* [[JesseBarnes|JesseBarnes]]: + * per-process GTT entries + * page fault support I can look into what Intel hardware supports in this regard; hopefully we can fit this stuff into the current design without too much trouble. + + +--- + + + +* [[KeithWhitwell|KeithWhitwell]]: + * Relocations are great, but sometimes you really need to know where a buffer is going to be. + * Software zone/tiled rendering - can generate 10,000's of relocations. The CPU overhead of this would otherwise defeat the technique. + * Reusing buffers containing relocations over multiple scenes -- eg. caching generated programs/state which themselves contain relocations. + * Approaches for dealing with this -- 'prevalidation', investigating NO_MOVE buffers. + * Differences between NO_MOVE and NO_EVICT. Both are important but for different reasons. + * Private backbuffers --> We need to be able to allocate tiled buffers on Intel IGPs. + * Private backbuffers and pageflipping. How will this work? +--- + + + + * [[KristianHøgsberg|KristianHøgsberg]]: + * Can we drop drmBODestroy and only use drmBOUnreference? Sometimes the X server creates a BO and the DRI driver running in a DRI client may end up being the last user. The X server can't just call drmBODestroy, since others may be using it, at the same time, the DRI client can't destroy it because it didn't create it. + * We need to talk about how the private back buffer work overlaps with redirected direct rendering.
\ No newline at end of file diff --git a/Events/XDS2008.mdwn b/Events/XDS2008.mdwn new file mode 100644 index 00000000..38b6934c --- /dev/null +++ b/Events/XDS2008.mdwn @@ -0,0 +1,52 @@ + + +# XDS 2008 +[[!table header="no" class="mointable" data=""" + [[<< XDC 2008|Events/XDC2008]] | **XDS 2008** | [[XDC 2009 >>|Events/XDC2009]] +"""]] + +The X Developers' Summit for 2008 was held at [[Edinburgh Zoo|http://www.edinburghzoo.org.uk]], [[Edinburgh|http://wikitravel.org/en/Edinburgh]], UK, from the 3rd-5th September. + +* [[Attendees|Events/XDS2008/Attendees]] +* [[Program|Events/XDS2008/Program]] +* [[Notes from the talks|Events/XDS2008/Notes]] +* [[Audio Recordings of the talks|Events/XDS2008/Recordings]] (courtesy of [[Phoronix|http://phoronix.com/]]) +We will run the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. + +Attendance is free, but you must register beforehand, by putting your name on the Attendees page; attendance is currently limited to 60 people. + + +## Accommodation + +Unlike XDS 2007, on-venue accommodation has not been arranged. We will, however, arrange a group booking rate with an affordable and accessible hotel: hold tight. + + +## Travel + +Edinburgh has its [[own airport|http://en.wikipedia.org/wiki/Edinburgh_Airport]] (EDI), 10 miles west of the city. Edinburgh is not an enormous international hub, but there are very frequent services from all London airports (Heathrow, Gatwick, Stansted, City, Luton) with all alliances, decent European connectivity, plus Continental and Delta flights to JFK/Newark. A full list of destinations is available from the airport site. From the airport, the 100 and 35 buses connect you to the city. + +Edinburgh Waverley train station is very close to the city centre, and has good connections to the rest of the UK, including a 4h30m fast east coast service to London, and a ~7h overnight sleeper service. For more details, as well as booking, please check the [[Scotrail site|http://www.firstgroup.com/scotrail/]]. For those under the age of 25, buying a 16-25 Railcard (£20, valid for a year, can halve ticket prices) will likely save you a great deal on a long train journey: more information is available from nationalrail.co.uk. + +Edinburgh Zoo is easily accessible from the centre of the city, with the 12, 26, 31 and 100 (Airlink) [[Lothian buses|http://lothianbuses.com/]] all departing from Princes St; the trip is roughly 15 minutes. + + +## Sponsorship + +As usual, we will be running a travel sponsorship program. If you are unable to afford travel/accommodation on your own, please investigate the cheapest reasonable way for you to get to Edinburgh, and let us know a ballpark price. Full details are in the [[list post|http://lists.x.org/archives/events/2008-July/000000.html]] (note that the deadline is Wed 6th Aug). + + +## Registration, talks + +If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/events]] for updates; note that as a general-purpose mailing list, this will be reused for future events, so please remember to unsubscribe afterwards if you don't plan on attending future events. Also, please add your name to the [[Attendees|Events/XDS2008/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2008/Program]] page. + + +## Misc, other + +Scotland uses UK plugs. There will no doubt be all kinds of foreign power boards and adaptors floating around, but please do remember to bring your own. The currency is the British Pound (GBP), and the language mostly resembles English. + +[[Google Maps: Edinburgh Zoo|http://maps.google.co.uk/maps?f=q&hl=en&geocode=&q=edinburgh+zoo&sll=53.800651,-4.064941&sspn=12.061542,28.212891&ie=UTF8&ll=55.946701,-3.225861&spn=0.044602,0.110207&z=13]]. + + +## Contact + +If you have any problems or questions, please contact Daniel Stone -- [[daniel@fooishbar.org|mailto:daniel@fooishbar.org]]. diff --git a/Events/XDS2008/Attendees.mdwn b/Events/XDS2008/Attendees.mdwn new file mode 100644 index 00000000..47a1d924 --- /dev/null +++ b/Events/XDS2008/Attendees.mdwn @@ -0,0 +1,34 @@ + + +# XDS2008 Attendees + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDS2008|Events/XDS2008]]. List here any special dietary requirements you have or anything we'd otherwise need to know. Even if you haven't got it confirmed yet, please put your name down with 'pending' next to it, so we can plan better. + +1. [[JakobBornecrantz|JakobBornecrantz]] +1. [[EgbertEich|EgbertEich]] +1. [[LucVerhaegen|LucVerhaegen]] +1. [[JohnTapsell|JohnTapsell]] +1. [[JakubLamik|JakubLamik]] +1. [[MichaelLarabel|MichaelLarabel]] +1. [[MatthieuHerrb|MatthieuHerrb]] +1. [[AlexDeucher|AlexDeucher]] (not likely) +1. [[RobertBragg|RobertBragg]] +1. [[JeromeGlisse|JeromeGlisse]] +1. [[KeithWhitwell|KeithWhitwell]] +1. [[AlanHourihane|AlanHourihane]] +1. [[AndyShaw|AndyShaw]] +1. [[JeremyHuddleston|JeremyHuddleston]] (herbivore, pending funding) +1. [[AlanCoopersmith|AlanCoopersmith]] +1. [[PeterHutterer|PeterHutterer]] (lactose-free if possible, otherwise normal grub) +1. [[TiagoVignatti|TiagoVignatti]] (carnivore) +1. [[SimosXenitellis|SimosXenitellis]] (pending) +1. [[GordonJin|GordonJin]] +1. [[EricAnholt|EricAnholt]] +1. [[KeithPackard|KeithPackard]] +1. [[IanRomanick|IanRomanick]] +1. [[JesseBarnes|JesseBarnes]] +1. [[JayCotton|JayCotton]] +1. [[StuartKreitman|StuartKreitman]] (no haggis or porky things) +1. [[SimonThum|SimonThum]] (leaving sep 5th, omnivore) +1. [[TomasFrydrych|TomasFrydrych]] +1. [[KristianHøgsberg|KristianHøgsberg]]
\ No newline at end of file diff --git a/Events/XDS2008/Notes.mdwn b/Events/XDS2008/Notes.mdwn new file mode 100644 index 00000000..e9bf6e3d --- /dev/null +++ b/Events/XDS2008/Notes.mdwn @@ -0,0 +1,169 @@ + + +## 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|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|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|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|PowerPlay]]). + * NVIDIA: Can clock-down core and memory frequencies (Note: [[CoolBits|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|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: <ins>constructor, _operator, </ins>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.
\ No newline at end of file diff --git a/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf b/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf Binary files differnew file mode 100644 index 00000000..42917dc8 --- /dev/null +++ b/Events/XDS2008/Notes/PredictablePointerAcceleration.pdf diff --git a/Events/XDS2008/Program.mdwn b/Events/XDS2008/Program.mdwn new file mode 100644 index 00000000..eae6ee87 --- /dev/null +++ b/Events/XDS2008/Program.mdwn @@ -0,0 +1,51 @@ + + +# XDS2008 Program + +This is the rough program for [[XDS2008|Events/XDS2008]]. If you would like to give a talk, please add a proposal to the Ideas section below. Please do not edit the program itself: instead, if you have any time constraints (e.g. are arriving late or leaving early), please note them with your talk. + +Refreshments (coffee, tea, biscuits, etc) will be served throughout the day; a light breakfast will be served in the morning (coffee, tea and pastries), and lunch will be served on-campus. Dinner is at your own discretion, as long as you're out of the zoo by 6pm. There's a pub across the road from the zoo, which is apparently quite good. + +On Thursday, there'll be a guided tour of the zoo at sunset, going from 6pm-7:30pm, after which there'll be a drink and some finger food back at Mansion House. + +Feel free to fill the bof/demo/misc slots if you want to talk about something. + + +## Program +[[!table header="no" class="mointable" data=""" + | **Wednesday** (input and misc) | **Thursday** (GL-related happiness) | **Friday** (other) + **9am** | _tea/coffee/pastries, coalesce_ | _tea/coffee/pastries, coalesce_ | _tea/coffee/pastries, coalesce_ + **9:30am** | Welcome and Foundation overview ([[MatthewGarrett|MatthewGarrett]], Foundation board) | Gallium3D status ([[TungstenGraphics|TungstenGraphics]]) | Plymouth graphical boot synergies ([[KristianHøgsberg|KristianHøgsberg]]) + **10:30am** | _morning tea_ | _morning tea_ | _morning tea_ + **10:45am** | Input summary ([[PeterHutterer|PeterHutterer]]) | Gallium3D, i915, and you ([[JakobBornecrantz|JakobBornecrantz]]) | DRI2 v2 ([[KristianHøgsberg|KristianHøgsberg]]) + **11:45am** | Pointer acceleration ([[SimonThum|SimonThum]]) | [[Intel Graphics Testing|http://www.intellinuxgraphics.org/testing/gfx_test_xds2008.pdf]] ([[GordonJin|GordonJin]]) + Radeon KMS, memory management, etc ([[JeromeGlisse|JeromeGlisse]]) | More DRI2 hilarity + **12:30pm** | _lunch_ | _lunch_ | _lunch_ + **1:30pm** | [[Improving input latency|http://www.inf.ufpr.br/vignatti/talks/XDS08-ImprovingInputLatency.pdf]] ([[TiagoVignatti|TiagoVignatti]]) | [[GLSL|http://web.cecs.pdx.edu/~idr/publications/xds2008-GLSL_work.pdf]] ([[IanRomanick|IanRomanick]]) | Everybody loves Intel ([[KeithPackard|KeithPackard]]) + **2:30pm** | Runtime GPU power management ([[MatthewGarrett|MatthewGarrett]]) | (2:15pm) [[Penguin Parade|http://www.edinburghzoo.org.uk/visiting/daily-events/]] | XKB stuff ([[SimosXenitellis|SimosXenitellis]]) + **3:15pm** | _afternoon tea_ | _afternoon tea_ | _afternoon tea_ + **3:30pm** | Live XI2 spec drafting ([[PeterHutterer|PeterHutterer]]) | GEM: The easy and simple memory manager everyone's gonna love ([[EricAnholt|EricAnholt]]) | Lock doors, no-one leaves until [[7.4|Releases/7.4]] released ([[EricAnholt|EricAnholt]], possible virtual presence from [[AdamJackson|AdamJackson]] and [[DanielStone|DanielStone]]) + **4:30pm** | (bof?) | (bof?) | (continuation of previous?) + **6pm** | _be social_ | _sunset zoo tour then drinks/nibbles in Mansion House_ | _be social_ +"""]] + + +## Ideas + +* Input and related: + * Input summary ([[PeterHutterer|PeterHutterer]]): Current state of input, XI2, MPX. + * Improving input latency ([[TiagoVignatti|TiagoVignatti]]): Current state of input-thread and other ideas. + * Introduction to pointer acceleration: a few slides on ptr accel ([[SimonThum|SimonThum]]; not on sep 5th) + * Interactive session: XI 2 Protocol specification Draft 0 ([[PeterHutterer|PeterHutterer]]) +* X.Org Foundation ([[EricAnholt|EricAnholt]], [[EgbertEich|EgbertEich]], [[MatthieuHerrb|MatthieuHerrb]], [[KeithPackard|KeithPackard]], feat. all of [[AdamJackson|AdamJackson]], [[BartMassey|BartMassey]], [[DanielStone|DanielStone]] and [[CarlWorth|CarlWorth]] in spirit): Rough overview of how and what the Foundation's up to, begging for members, etc. +* Peace full talk on radeon kms, memory management, cache coherency, command submission and various others topics ([[JeromeGlisse|JeromeGlisse]]) +* DRI2 version 2! Now without sarea or locks ([[KristianHøgsberg|KristianHøgsberg]]) +* The Plymouth Graphical Boot Experience ([[KristianHøgsberg|KristianHøgsberg]]) +* State of Gallium3D (TG) +* Gallium3D, i915 and you ([[JakobBornecrantz|JakobBornecrantz]]) +* Runtime power management of graphics hardware - interfaces and capabilities ([[MatthewGarrett|MatthewGarrett]]) +* Graphics testing ([[GordonJin|GordonJin]]): what community can help on testing, how to file a good bug report. +* Rah rah Intel rah rah ([[KeithPackard|KeithPackard]]) +* Probably something to do with Mesa ([[EricAnholt|EricAnholt]]) +* Everyone loves OpenGL 3 ([[IanRomanick|IanRomanick]]) +* X.Org 7.5, server 1.6, and similarly cheerful topics ([[EricAnholt|EricAnholt]] with [[AdamJackson|AdamJackson]] and [[DanielStone|DanielStone]] in spirit and possibly heckling via IRC)
\ No newline at end of file diff --git a/Events/XDS2008/Program/gfx_test_xds2008.pdf b/Events/XDS2008/Program/gfx_test_xds2008.pdf Binary files differnew file mode 100644 index 00000000..0ae039d5 --- /dev/null +++ b/Events/XDS2008/Program/gfx_test_xds2008.pdf diff --git a/Events/XDS2008/Recordings.mdwn b/Events/XDS2008/Recordings.mdwn new file mode 100644 index 00000000..5ca28ff3 --- /dev/null +++ b/Events/XDS2008/Recordings.mdwn @@ -0,0 +1,6 @@ + +Audio recordings of the 2008 XDS talks were made and posted by Michael Larabel of [[Phoronix|http://phoronix.com/]]: + +* [[Day 1|http://www.phoronix.com/vr.php?view=12810]] +* [[Day 2|http://www.phoronix.com/scan.php?page=news_item&px=NjcwMg]] +* [[Day 3|http://www.phoronix.com/scan.php?page=news_item&px=NjcwNw]]
\ No newline at end of file diff --git a/Events/XDS2010.mdwn b/Events/XDS2010.mdwn new file mode 100644 index 00000000..1bbbedac --- /dev/null +++ b/Events/XDS2010.mdwn @@ -0,0 +1,74 @@ + + +# XDS2010: Toulouse, France, September 16-18 +[[!table header="no" class="mointable" data=""" + [[<< XDC 2009|Events/XDC2009]] | **XDS 2010** | [[>> XDC 2011|Events/XDC2011]] +"""]] + +[[!img xds2010-color-small.png] + +The last X Developers' Summit was held at the University of Toulouse 1 Capitole, in France, during September 16th-18th. + +* [[Attendees|Events/XDS2010/Attendees]] +* [[Program|Events/XDS2010/Program]] +* [[Notes|Events/XDS2010/Notes]] +We ran the 3-day summit as a normal conference, with presentations and also birds-of-a-feather group sessions, as well as informal 'corridor sessions', and plenty of time for after-hours social activities. + + +## Venue + +The conference has been held in the "_Colloque - Guy Isaac_" Amphiteather at the old Tobacco Factory (_manufacture des tabacs_ in french) a few hundred meters from the initially planned location. + +See the map below for details. + +The _Guy Isaac_ amphitheater is in the building **I** on [[this map of the Manufacture des Tabacs|http://www.univ-tlse1.fr/94522330/0/fiche___pagelibre/&RH=FR_01-06]]. + + +## Accommodation + +On-venue accommodation will not be arranged. However we provide a [[list of hotels|Events/XDS2010/Hotels]] where you should be able to find rooms at reasonable rates. Use the wiki or the mailing list if you'd like to share rooms and need to find roomates. + + +## Travel + +Toulouse can be reached: + +* By **plane** to the [[Toulouse-Blagnac|http://www.toulouse.aeroport.fr/en]] (TLS) airport. From there you can take the [[flybus|http://www.toulouse.aeroport.fr/airport/access-transport-car-park/access/public-transportation/navette-city-centre]] bus shuttle or a taxi to downtown. + The airport of [[Carcassonne|http://www.carcassonne.aeroport.fr/uk/]] (CCF) hosts a low cost company. It's 90km away from Toulouse, but has good train connections. +* By **train** to the [[Toulouse-Matabiau|http://www.gares-en-mouvement.com/gare.php?gare=frxyt]] station, TGVs run from Paris in 5-6 hours, depending on the schedule. Tickets can be [[purchased on-line|http://www.voyages-sncf.com/]]; as of 2010-08-12, it was possible to get a Paris<->Toulouse round trip in first class for €104, from tgv-europe.com or the much more reliable voyages-sncf.com. Note that the iDTGV is a special 'youth' train, so expect lots of hair gel and bad house music if you book that. +* Avoid the car if possible. It's difficult and expensive to park in the city center and driving in Toulouse may be a nightmare for those who are only used to large and straight avenues. + +## Sponsorship + +As usual, we will be running a [[travel sponsorship program|http://lists.freedesktop.org/archives/xorg-devel/2010-August/011776.html]]. If you are unable to afford travel/accommodation on your own, please investigate the cheapest reasonable way for you to get to Toulouse, and let us know a ballpark price. + + +## Registration, talks + +If you are coming, or just interested, please subscribe to a [[low-volume mailing list|http://lists.x.org/mailman/listinfo/events]] for updates; note that as a general-purpose mailing list, this will be reused for future events, so please remember to unsubscribe afterwards if you don't plan on attending future events. Also, please add your name to the [[Attendees|Events/XDS2010/Attendees]] and if you are thinking about giving a talk, add your ideas to the bottom of the [[Program|Events/XDS2010/Program]] page. + + +## Misc, other + +Toulouse uses [[Type E/F hybrid|http://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Type_E_.2F_F_hybrid]] plugs (CEE7/7) and [[Euro plugs|http://en.wikipedia.org/wiki/Euro_plug]] at 230V/50Hz. There will no doubt be all kinds of foreign power boards and adaptors floating around, but please do remember to bring your own. The currency is the Euro (EUR), and the language is french. Many shops, bars and restaurant speak some level of English. + +[[A Map of Toulouse with the University and a few hotels nearby|http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=109509719165610042544.00046bd61e2c98b82d61e&z=15]] + +[[Touristic informations|http://www.toulouse-tourisme.com/accueil/index_en.php]] to visit Toulouse and the area after/before the summit. + + +## Thanks + +The X.Org foundation thanks the following sponsors who made the event possible: + +* [[Intel|http://www.intel.com]] +* [[Arcapos.ch|http://www.arcapos.ch]] + +## Contact + +If you have any problems or questions, please contact Matthieu Herrb -- matthieu DOT herrb AT laas DOT fr + + +## Downloads + +* [[XDS2010 SVG logo|xds2010-color.svg]]
\ No newline at end of file diff --git a/Events/XDS2010/Attendees.mdwn b/Events/XDS2010/Attendees.mdwn new file mode 100644 index 00000000..b03a7e12 --- /dev/null +++ b/Events/XDS2010/Attendees.mdwn @@ -0,0 +1,65 @@ + + +## XDS2010 Attendees + +**Update 2010/09/01**: Registration is now closed the maximum number of participants has been reached. Contact matthieu . herrb AT laas DOT fr if you are not registered yet and really want to attend, to check for opportunities. + +Please list your name here (and subscribe to the [[mailing list|http://lists.x.org/mailman/listinfo/events]]) if you are planning to attend [[XDS2010|Events/XDS2010]]. Please note that attendance will be limited (50 persons approximatly), so list yourself early to ensure your ability to attend. + +Please keep this list in alphabetical order by last name. + + 1. [[OwainAinsworth|OwainAinsworth]] + 1. [[ZenoAlbisser|ZenoAlbisser]] + 1. [[MarcBalmer|MarcBalmer]] + 1. [[JesseBarnes|JesseBarnes]] (Arrive 15 Sept, depart 19 Sept, staying at Le Gran Balcon) + 1. [[JakobBornecrantz|JakobBornecrantz]] (Arrive 15 Sept, depart 19 Sept) + 1. [[MohamedBoulabiar|MohamedBoulabiar]] + 1. [[CyrilBrulebois|CyrilBrulebois]] (tentative) + 1. [[AndreaCanciani|AndreaCanciani]] + 1. [[RemiCardona|RemiCardona]] (tentative) + 1. [[ErwannChenede|ErwannChenede]] + 1. [[PingCheng|PingCheng]] + 1. [[AlanCoopersmith|AlanCoopersmith]] (Arrive 15 Sept, depart 20 Sept) + 1. [[JayCotton|JayCotton]] + 1. [[JulienCristau|JulienCristau]] + 1. [[MichelDaenzer|MichelDaenzer]] (tentative) + 1. [[AlexDeucher|AlexDeucher]] (arrive 15 Sept, depart 19 Sept) + 1. [[MattDew|MattDew]] (Arrive 15 Sept, depart 19 Sept) + 1. [[ChaseDouglas|ChaseDouglas]] + 1. [[DenisDzyubenko|DenisDzyubenko]] + 1. [[AlexandrosFrantzis|AlexandrosFrantzis]] + 1. [[JeromeGlisse|JeromeGlisse]] + 1. [[ChrisHalseRogers|ChrisHalseRogers]] + 1. [[MatthieuHerrb|MatthieuHerrb]] + 1. [[MatthiasHopf|MatthiasHopf]] + 1. [[PeterHutterer|PeterHutterer]] + 1. [[KristianHøgsberg|KristianHøgsberg]] + 1. [[AdamJackson|AdamJackson]] + 1. [[JamesKetrenos|JamesKetrenos]] (arrive 15 Sept, depart 19 Sept) + 1. [[MarioKleiner|MarioKleiner]] + 1. [[MichaelLarabel|MichaelLarabel]] + 1. [[JoséLuisLopezCastillo|JoséLuisLopezCastillo]] + 1. [[BartMassey|BartMassey]] + 1. Duncan [[McGreggor|McGreggor]] + 1. Uros Nedic + 1. [[KeithPackard|KeithPackard]] (Arrive 15 Sept, depart 19 Sept) + 1. [[MartinPeres|MartinPeres]] + 1. Ian Romanick + 1. [[JameySharp|JameySharp]] + 1. [[EdwardShu|EdwardShu]] (tentative) + 1. [[CorbinSimpson|CorbinSimpson]] + 1. Maria Starodubtseva (tentative) + 1. [[BenjaminTissoires|BenjaminTissoires]] + 1. Josh Triplett + 1. [[MiodVallat|MiodVallat]] (logistics) + 1. [[DanielVetter|DanielVetter]] + 1. [[ChrisWilson|ChrisWilson]] + 1. Henry Zhao (tentative) + 1. Richard Li + 1. [[LucVerhaegen|LucVerhaegen]] + 1. [[KenGraunke|KenGraunke]] + 1. [[TiagoVignatti|TiagoVignatti]] (Arrive 15 Sept, depart 20 Sept, staying at Holiday Inn City Centre) + 1. [[TapaniPaelli|TapaniPaelli]] + 1. [[GowriRies|GowriRies]] + 1. [[PascalAuriel|PascalAuriel]] + 1. [[EgbertEich|EgbertEich]]
\ No newline at end of file diff --git a/Events/XDS2010/Hotels.mdwn b/Events/XDS2010/Hotels.mdwn new file mode 100644 index 00000000..b57be4eb --- /dev/null +++ b/Events/XDS2010/Hotels.mdwn @@ -0,0 +1,137 @@ + + +# Hotels in Toulouse + +Prices given here are subject to change. Contact the hotel directly to confirm availability and price. +[[!table header="no" class="mointable" data=""" +**HOTEL DU TAUR** ** +2, Rue du Taur +31000 Toulouse +phone: +33 561 21 17 54 +fax: +33 561 13 78 41 +E-Mail: contact AT hotel-du-taur DOT com +web: [[http://www.hotel-du-taur.com|http://www.hotel-du-taur.com]] +rate: 50/72 € +breakfast included +**HOTEL PATIO WILSON** ** +7, rue Lafaille +phone: +33 561 62 74 74 +fax: +33 561 99 15 44 +web: [[http://www.hotelpatiowilson.com/|http://www.hotelpatiowilson.com/]] +E-mail: hotelpatiowilson AT orange DOT fr +rate: single standard: 61 € single standard large bed: 70 € single superior: 86 € +Breakfast: 5 € +**HOTEL DE FRANCE** ** +5, Rue d'Austerlitz +31000 Toulouse +phone: +33 561 21 88 24 +fax: +33 561 21 99 77 +E-Mail: contact AT hotel-france-toulouse DOT com +web: [[http://www.hotel-france-toulouse.com|http://www.hotel-france-toulouse.com]] +rate: single 63/76 €, double 86 € +breakfast: 7 € +**HOTEL VICTOR HUGO** ** +26, Bd de Strasbourg +31000 Toulouse +phone: +33 561 63 40 41 +fax: +33 561 62 66 31 +E-Mail: contact AT victorhugo-hotel DOT com +web: [[http://www.victorhugo-hotel.com/|http://www.victorhugo-hotel.com/]] +rate: single 73/78 €, double 88/93 €, twin 93 € +breakfast included +**HOTEL WILSON SQUARE** ** +12 Rue d'Austerlitz +31000 Toulouse +phone: +33 561 21 67 57 +fax: +33 561 21 16 23 +E-mail: contact AT hotel-wilson DOT com +web: [[http://www.hotel-wilson.com|http://www.hotel-wilson.com]] +rate: single 64 €, double 74 €, twin 84 €, triple 94 € +breakfast included +Free WIFI +**HOTEL CASTELLANE** ** +17, Rue Castellane +31000 Toulouse +phone: +33 561 62 18 82 +fax: +33 561 62 58 04 +E-Mail: castellanehotel AT wanadoo DOT fr +web: [[http://www.castellanehotel.com|http://www.castellanehotel.com]] +rate: single/double 74 €, twin 78 € +breakfast: 8,50 € +Parking: 10 €/24h +**HOTEL ALBERT 1er** ** +8, Rue Rivals +31000 Toulouse +phone: +33 561 21 17 91 +fax: +33 561 21 09 64 +E-Mail: toulouse AT hotel-albert1 DOT com +web: [[http://www.hotel-albert1.com|http://www.hotel-albert1.com]] +rate: 79/98 € +breakfast: 10 € +**HOTEL IBIS CENTRE** ** +2, Rue Claire Pauilhac +31000 Toulouse +phone: +33 561 63 61 63 +fax: +33 561 63 07 46 +E-Mail: H1429 AT accor-hotels DOT com +web: [[http://www.ibishotel.com|http://www.ibishotel.com]] +rate: week: 94 €, week-end: 69 € +breakfast: 7,50 € +Free WIFI +**Citadines Toulouse Wilson** +8, boulevard de Strasbourg +31000 Toulouse +phone: +33 534 41 75 00 +Fax: +33 561 99 07 55 +E-mail: wilson AT citadines DOT com +web: [[http://www.citadines.com/fr/france/toulouse/wilson.html|http://www.citadines.com/fr/france/toulouse/wilson.html]] +rates: Studio (2 pers.): 90 € / 2 rooms (4pers.): 132 € +**HOTEL de BRIENNE** *** +20 Boulevard Maréchal-Leclerc +31000 Toulouse +phone:+33 561 23 60 60 +fax: +33 561 23 18 94 +E-mail: direction DOT hoteldebrienne AT wanadoo DOT fr +web: [[http://www.hoteldebrienne.com|http://www.hoteldebrienne.com]] +rate: 81/93 € (week), 70/80 € (week-end) +breakfast: buffet 10 € or continental 5 € +**HOTEL MERMOZ** *** +50, Rue Matabiau +31000 Toulouse +phone: +33 561 63 04 04 +fax: +33 561 63 15 64 +E-mail: reservation AT hotel-mermoz DOT com +web: [[http://www.hotel-mermoz.com|http://www.hotel-mermoz.com]] +rate: single or twin 99 € +breakfast: 14 € +Free WIFI +Private parking: 12 € +**HOTEL MERCURE MATABIAU** *** +Boulevard Pierre-Semard +31000 Toulouse +phone: +33 534 41 36 70 +fax: +33 534 41 36 71 +E-mail: H1259 AT accor DOT com +web: [[http://www.mercure.com|http://www.mercure.com]] +rate: single 95 €, double 105 € +breakfast: 13 € +**HOTEL MERCURE ATRIA** *** + Boulevard Lascrosses + 31000 Toulouse +Phone: +33 561 11 09 09 +fax: +33 561 23 14 12 +E-mail: H1585 AT accor DOT com +web: [[http://www.mercure.com|http://www.mercure.com]] +rate: 121/153 € +breakfast: 15 € +Free WIFI +**HOTEL HOLIDAY INN (CAPOUL)** *** +13, Place Wilson +31000 Toulouse +phone: +33 561 10 70 70 +fax : +33 561 21 96 70 +E-mail: hi AT capoul DOT com +web: [[http://www.hotel-capoul.com|http://www.hotel-capoul.com]] +rate: 141/194 € +breakfast: 16 € +"""]] diff --git a/Events/XDS2010/Notes.mdwn b/Events/XDS2010/Notes.mdwn new file mode 100644 index 00000000..1dbd51b0 --- /dev/null +++ b/Events/XDS2010/Notes.mdwn @@ -0,0 +1,615 @@ + +IRC transcript of the notes from XDS2010. + + +## Thursday, September 16 + + +### Board (Alan Coopersmith, Matthieu Herrb) + + +[[!format txt """ +<@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) + + +[[!format txt """ +<@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) + + +[[!format txt """ +<@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) + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +< 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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +< 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 + + +[[!format txt """ +< 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 + + +[[!format txt """ +< 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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 + + +[[!format txt """ +<@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 +"""]]
\ No newline at end of file diff --git a/Events/XDS2010/Program.mdwn b/Events/XDS2010/Program.mdwn new file mode 100644 index 00000000..037e4b4e --- /dev/null +++ b/Events/XDS2010/Program.mdwn @@ -0,0 +1,106 @@ + + +# XDS2010 Program + +This is the rough program for [[XDS2010|Events/XDS2010]]. + +Recordings of the presentations can be found at [[Videos|http://www.x.org/videos/XDS2010]] or at [[youtube|http://www.youtube.com/results?search_query=XDS2010&aq=f]]. Search for XDS2010 +[[!table header="no" class="mointable" data=""" + **Thursday September 16** ||| + 9:00 | Welcome coffee - registration || + 10:00 | [[Introduction|intro.pdf]] | [[MatthieuHerrb|MatthieuHerrb]] + University staff + 10:30 | [[X.Org Foundation|XorgFoundation]] session | [[AlanCoopersmith|AlanCoopersmith]] & other [[Board members|BoardOfDirectors]] + 11:30 | Review of latest DRI2 protocol additions | [[JesseBarnes|JesseBarnes]] + 12:30 | Lunch break || + 14:00 | Documentation or: how a newbie got involved | [[MattDew|MattDew]] + 15:00 | Development process recap [[Video|http://www.phoronix.com/scan.php?page=news_item&px=ODYzMQ]] | [[PeterHutterer|PeterHutterer]] & [[KeithPackard|KeithPackard]] ? + 16:00 | Coffee break || + 16:30 | Transportation to ENAC/CENA || + 17:00 | Visit and demos at CENA - X11 based UIs for air trafic control | CENA Team + **Friday September 17** ||| + 9:00 | Multitouch session | + 10:30 | Coffee break || + 11:00 | Gestures session | [[ChaseDouglas|ChaseDouglas]] + 12:30 | Lunch break || + 14:00 | XCB session | [[JoshTriplett|JoshTriplett]], [[JameySharp|JameySharp]] + 15:00 | Xephyr future | [[DanielStone|DanielStone]] ? + 16:00 | Coffee break || + 16:30 | EGL in Mesa [[Video|http://www.phoronix.com/scan.php?page=news_item&px=ODYyMA]] | [[KristianHøgsberg|KristianHøgsberg]] + 17:30 | Board meeting | + 20:30 | Social event: dinner at _le Patio de la Table Ronde_ || + **Saturday September 18** ||| + 9:00 | Wacom input driver* | [[PeterHutterer|PeterHutterer]] + 9:45 | OpenGL - which functions can developers rely on ? | [[JohnBridgman|JohnBridgman]] + 10:30 | Coffee break || + 11:00 | libxkbcommon | [[KristianHøgsberg|KristianHøgsberg]] + 11:45 | Handling input events: threads or not ? | [[TiagoVignatti|TiagoVignatti]] + 12:30 | Lunch break || + 14:00 | Non Linux DRI/KMS support | [[OwainAinsworth|OwainAinsworth]] + 15:00 | Kill it with fire | [[IanRomanick|IanRomanick]] + 15:30 | Mesa GLSL compiler internals | [[IanRomanick|IanRomanick]] + 16:00 | Coffee break || + 16:30 | Xserver 1.10 planning | [[KeithPackard|KeithPackard]] + 17:30 | Closing session || +"""]] + +* This session will be just be a discussion for those involved with the driver. There won't be a presentation and it will likely be of limited use for others. + + +## Ideas + +* X server 1.10 planning session + * merge drivers back? + * old PCI support (non-libpciaccess) on **driver** side (or why keep a 1:n for driver:server) + * and the close-source ones? + * and what about the big proto module? +* Non-Linux support BoF + * DRM/KMS on *BSD +* Review of latest DRI2 protocol additions ([[JesseBarnes|JesseBarnes]]) + * DRI2SwapBuffers + * DRI2 events (swap, invalidate) + * DRI2Wait* + * discussion of triple/n-buffering +* Development process recap + * what is working, what isn't? + * master vs. stable vs. -next +* Multi-touch session +* Gestures session +* Xephyr BoF + * last one out the room is the maintainer +* XCB BoF + * What still needs doing to support widespread porting efforts? +* Handling Input events: [[assume threads or not?|http://cgit.freedesktop.org/~vignatti/xserver/commit/?h=inputthread-diff&id=126b89196122162515d8d5e9c4603d6cd7829f94]] ([[TiagoVignatti|TiagoVignatti]]) +* [[BoardOfDirectors|BoardOfDirectors]] chat + * XDC 2011 (in Brazil?) +* Documentation or: how a newbie got involved +* EGL in mesa + * what is EGL + * what's in mesa + * how does it work + * what do dri/gallium drivers need to provide. +* libxkbcommon - who's the maintainer, where's it going? +* Wacom roadmap BoF +* Which functions can app developers rely on ? + * used to be that apps using ~GL 1.2 or 1.3 worked, anything higher was iffy + * most drivers now either support GLSL / GL 2.x or are getting close + * implementation is sufficient to make many apps work but not "perfect" yet + * app devs are starting to rely on GL 2.x but need per-platform testing to succeed + * can we identify a "new recommended level" that should work across all major HW platforms ? + * something like "GL 2.x minus <list> plus <low hanging fruit from GL 3/4 eg sRGB> ? + * What extensions should we force to be enabled in all drivers? + * GL_ARB_copy_buffer - GL_ARB_vertex_buffer_object is always enabled, and this is a trivial addition. **Done in Mesa master.** + * GL_ARB_map_buffer_range - This extension requires additional driver hooks that not all drivers implement. This may still be doable in the future. + * GL_APPLE_object_purgeable - Same as GL_ARB_copy_buffer, right? Some concern was expressed at XDS that apps might make (false) assumptions based on the availability of this extension. + * GL_ARB_vertex_array_object + * GL_ARB_draw_elements_base_vertex - We can (mostly?) fake this on hardware that doesn't have real support. Do we care that much? + * GL_SGIS_generate_mipmaps **Done in Mesa master.** + * Are there sufficient tests for these in piglit or glean? +* Kill it with fire + * What can we remove from X, Mesa, etc? + * GL_ARB_imaging - [[EricAnholt|EricAnholt]] has a branch. Nobody uses convolution or histograms. **Removed in Mesa master.** + * GL_EXT_cull_vertex - This is only enabled in swrast and the Intel drivers. Do any applications use this? **Removed in Mesa master.** + * GL_EXT_paletted_texture and GL_EXT_shared_texture_palette - This is only enabled by swrast and tdfx drivers + * GL_EXT_clip_volume_hint - No hardware driver supports this. The support in swrast appears to be fake. [[JakobBornecrantz|JakobBornecrantz]] expressed some concern that this can enable some extra fast paths in llvmpipe and softpipe. The question remains whether or not applications actually use this extension. + * GL_APPLE_client_storage - This is only enabled in swrast and the Intel drivers. Do any applications use this? The support appears to be fake. + * GL_MESA_packed_depth_stencil - No hardware driver supports this. It's not enabled in swrast either. This is a **superset** of GL_EXT_packed_depth_stencil that also has a 15.1 depth/stencil format. **Removed in Mesa master.** + * [[Corbin's list|CorbinSimpson/KillItWithFire]]
\ No newline at end of file diff --git a/Events/XDS2010/Program/intro.pdf b/Events/XDS2010/Program/intro.pdf Binary files differnew file mode 100644 index 00000000..5c9baa96 --- /dev/null +++ b/Events/XDS2010/Program/intro.pdf diff --git a/Events/XDS2010/xds2010-color-small.png b/Events/XDS2010/xds2010-color-small.png Binary files differnew file mode 100644 index 00000000..4a28b924 --- /dev/null +++ b/Events/XDS2010/xds2010-color-small.png diff --git a/Events/XDS2010/xds2010-color.svg b/Events/XDS2010/xds2010-color.svg new file mode 100644 index 00000000..b7dcc628 --- /dev/null +++ b/Events/XDS2010/xds2010-color.svg @@ -0,0 +1,350 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:xlink="http://www.w3.org/1999/xlink" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="588.58331" + height="557.48865" + id="svg2547" + sodipodi:version="0.32" + inkscape:version="0.47pre4 r22446" + sodipodi:docname="xds2010-color.svg" + inkscape:output_extension="org.inkscape.output.svg.inkscape" + version="1.1"> + <defs + id="defs2549"> + <linearGradient + id="linearGradient3676"> + <stop + style="stop-color:#e0e0e2;stop-opacity:1;" + offset="0" + id="stop3678" /> + <stop + style="stop-color:#e00000;stop-opacity:0;" + offset="1" + id="stop3680" /> + </linearGradient> + <linearGradient + inkscape:collect="always" + id="linearGradient3662"> + <stop + style="stop-color:#e00000;stop-opacity:1;" + offset="0" + id="stop3664" /> + <stop + style="stop-color:#e00000;stop-opacity:0;" + offset="1" + id="stop3666" /> + </linearGradient> + <linearGradient + id="linearGradient3654"> + <stop + style="stop-color:#000000;stop-opacity:1;" + offset="0" + id="stop3656" /> + <stop + style="stop-color:#000000;stop-opacity:0;" + offset="1" + id="stop3658" /> + </linearGradient> + <linearGradient + id="linearGradient4130"> + <stop + id="stop4132" + offset="0" + style="stop-color:#ffff4f;stop-opacity:0.86274511;" /> + <stop + id="stop4134" + offset="1" + style="stop-color:#fff600;stop-opacity:0;" /> + </linearGradient> + <linearGradient + id="linearGradient4122"> + <stop + style="stop-color:#ff0000;stop-opacity:1;" + offset="0" + id="stop4124" /> + <stop + style="stop-color:#e6af00;stop-opacity:0;" + offset="1" + id="stop4126" /> + </linearGradient> + <inkscape:perspective + sodipodi:type="inkscape:persp3d" + inkscape:vp_x="0 : 372.04724 : 1" + inkscape:vp_y="0 : 1000 : 0" + inkscape:vp_z="1052.3622 : 372.04724 : 1" + inkscape:persp3d-origin="526.18109 : 248.03149 : 1" + id="perspective2556" /> + <radialGradient + inkscape:collect="always" + xlink:href="#linearGradient4130" + id="radialGradient3634" + cx="453.75146" + cy="355.98727" + fx="453.75146" + fy="355.98727" + r="266.65195" + gradientTransform="matrix(1,0,0,1.0086379,0,-3.074984)" + gradientUnits="userSpaceOnUse" /> + <radialGradient + inkscape:collect="always" + xlink:href="#linearGradient4130" + id="radialGradient3642" + cx="452.02399" + cy="354.8356" + fx="452.02399" + fy="354.8356" + r="274.1377" + gradientTransform="matrix(1,0,0,1.0021004,0,-0.74530549)" + gradientUnits="userSpaceOnUse" /> + <radialGradient + inkscape:collect="always" + xlink:href="#linearGradient3654" + id="radialGradient3660" + cx="419.20187" + cy="347.34985" + fx="419.20187" + fy="347.34985" + r="279.32016" + gradientTransform="matrix(1,0,0,0.91135425,0,30.791089)" + gradientUnits="userSpaceOnUse" /> + <radialGradient + inkscape:collect="always" + xlink:href="#linearGradient3662" + id="radialGradient3668" + cx="419.20187" + cy="347.34985" + fx="419.20187" + fy="347.34985" + r="279.32016" + gradientTransform="matrix(1,0,0,0.91135425,0,30.791089)" + gradientUnits="userSpaceOnUse" /> + <radialGradient + inkscape:collect="always" + xlink:href="#linearGradient3676" + id="radialGradient3682" + cx="382.9248" + cy="344.4707" + fx="382.9248" + fy="344.4707" + r="286.80588" + gradientTransform="matrix(1,0,0,0.94579145,-4.6066138,-31.999495)" + gradientUnits="userSpaceOnUse" /> + </defs> + <sodipodi:namedview + inkscape:document-units="mm" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="0.86831673" + inkscape:cx="623.62297" + inkscape:cy="299.26351" + inkscape:current-layer="layer2" + id="namedview2551" + showgrid="false" + inkscape:window-width="1280" + inkscape:window-height="778" + inkscape:window-x="-1" + inkscape:window-y="0" + inkscape:window-maximized="0" /> + <metadata + id="metadata2553"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title /> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:groupmode="layer" + id="layer2" + inkscape:label="Fond" + transform="translate(-152.54991,-76.667113)"> + <rect + style="opacity:0.77777782;fill:#e00000;fill-opacity:1;stroke:#000000;stroke-width:3.54330707;stroke-miterlimit:4;stroke-opacity:0.21076235;stroke-dasharray:none" + id="rect3672" + width="585.03998" + height="553.94531" + x="154.32156" + y="78.438766" /> + <rect + style="opacity:0.77777782;fill:url(#radialGradient3682);fill-opacity:1;stroke:none" + id="rect3674" + width="570.06848" + height="538.97382" + x="93.283936" + y="24.311049" /> + </g> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + style="display:inline" + transform="translate(-152.54991,-76.667113)"> + <path + d="m 451.96875,343.90625 0,-71.21875 L 340.375,106.75 230.59375,106.65625 392.0625,349.9375 l 55.65625,0 4.25,-6.03125 z" + id="path2737" /> + <path + d="m 450.34375,359.875 0,73.625 109.84375,164.71875 109.78125,0 -159.90625,-241.75 -57.3125,0 -2.40625,3.40625 z" + id="path4040" /> + <g + style="fill:#fcef3c;fill-opacity:1;stroke:#000000;stroke-width:1.88821995;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;display:inline" + transform="matrix(1.588788,0,0,1.588808,-3046.2811,-670.20233)" + id="g16252"> + <path + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.88821995;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + d="m 2201.4845,500.70333 c -4.7445,0 -9.4057,0.2639 -14.0313,0.71875 -0.2868,12.97986 -10.9206,23.43752 -23.9687,23.4375 -5.1093,-8e-5 -9.8347,-1.63974 -13.7188,-4.375 -2.2056,-2.45229 -4.4786,-4.85284 -6.8125,-7.1875 -5.4822,2.48316 -10.7899,5.30529 -15.875,8.4375 1.8116,1.69271 3.5803,3.41917 5.3125,5.1875 0.9351,1.11745 1.9518,2.14558 3,3.15625 0.068,0.0658 0.1188,0.15342 0.1875,0.21875 22.38,24.1556 37.657,54.94886 42.5,89.125 -38.3346,-5.42977 -72.4383,-23.98976 -97.6562,-50.96875 -3.1307,5.08128 -5.9862,10.36584 -8.4688,15.84375 2.0007,1.9988 4.0376,3.96832 6.125,5.875 3.3757,4.13081 5.4062,9.41583 5.4063,15.15625 -1e-4,13.06932 -10.491,23.68449 -23.5,23.9375 -0.425,4.47328 -0.6251,9.00982 -0.625,13.59375 0,4.89355 0.2352,9.73331 0.7187,14.5 12.9652,0.30349 23.4062,10.93119 23.4063,23.96875 -1e-4,4.66188 -1.3433,9.01161 -3.6563,12.6875 -2.694,2.39906 -5.3195,4.86243 -7.875,7.4063 2.5682,5.6668 5.5205,11.1335 8.7813,16.375 25.1633,-26.77177 59.0893,-45.19557 97.2187,-50.62505 -5.5898,37.99185 -24.0768,71.78525 -50.875,96.81255 5.093,3.1371 10.4149,5.9515 15.9063,8.4375 2.038,-2.0283 4.0306,-4.0928 5.9687,-6.2188 4.1126,-3.3169 9.3155,-5.3124 15,-5.3125 13.0587,10e-5 23.6679,10.4742 23.9375,23.4688 4.4835,0.4269 8.999,0.6562 13.5938,0.6562 4.8935,0 9.7333,-0.2665 14.5,-0.75 0,-3e-4 0.031,3e-4 0.031,0 0.3203,-12.9502 10.9108,-23.375 23.9375,-23.375 4.6794,10e-5 9.0341,1.3899 12.7188,3.7188 2.3852,2.6766 4.844,5.2811 7.375,7.8125 5.6759,-2.571 11.1569,-5.5156 16.4062,-8.7813 -26.5665,-24.9688 -44.9135,-58.5778 -50.5,-96.34375 37.7562,5.58971 71.3818,23.91034 96.3438,50.46875 3.2615,-5.2462 6.1822,-10.7342 8.75,-16.4062 -2.3226,-2.32558 -4.7095,-4.58075 -7.1563,-6.7813 -2.7264,-3.88977 -4.3437,-8.61826 -4.3437,-13.71875 10e-5,-13.03745 10.441,-23.63489 23.4062,-23.9375 0.4548,-4.62558 0.6875,-9.31801 0.6875,-14.0625 0,-4.73391 -0.2347,-9.4157 -0.6875,-14.03125 -12.9653,-0.30344 -23.4062,-10.93116 -23.4062,-23.96875 10e-5,-5.12497 1.6243,-9.8592 4.375,-13.75 2.4304,-2.18711 4.8158,-4.43881 7.125,-6.75 -2.486,-5.49134 -5.3004,-10.81321 -8.4375,-15.90625 -1.7668,1.89537 -3.5818,3.7532 -5.4375,5.5625 -1.0978,0.93785 -2.1643,1.92066 -3.1563,2.96875 -23.9289,22.14845 -54.3982,37.33603 -88.1875,42.3125 5.4331,-38.12885 23.8756,-72.06549 50.6563,-97.21875 -5.2482,-3.26636 -10.7314,-6.20943 -16.4063,-8.78125 -2.3091,2.31661 -4.5599,4.69301 -6.75,7.125 -3.9111,2.77508 -8.6935,4.43741 -13.8437,4.4375 -13.0481,-1.7e-4 -23.6514,-10.45766 -23.9375,-23.4375 -4.6256,-0.45485 -9.3181,-0.71875 -14.0625,-0.71875 z m 0,14.40625 c 5.4852,14.65345 19.2193,25.25893 35.5312,26.25 -18.591,27.8166 -29.7948,60.96631 -30.7187,96.6875 35.7195,-0.91794 68.9048,-12.07803 96.7187,-30.65625 1.0096,16.28659 11.6475,29.97823 26.2813,35.46875 -14.6483,5.48332 -25.2839,19.1956 -26.2813,35.5 -27.8138,-18.5782 -60.9991,-29.76931 -96.7187,-30.6875 0.9235,35.7122 12.1362,68.87535 30.7187,96.68755 -16.1071,1.1604 -29.6178,11.7696 -35.0625,26.2812 -5.5304,-14.7738 -19.4178,-25.4737 -35.9062,-26.3125 18.5586,-27.8036 29.7016,-60.9561 30.625,-96.65625 -35.7135,0.92401 -68.8445,12.13636 -96.6563,30.71875 -1.1604,-16.10716 -11.7698,-29.6178 -26.2812,-35.0625 14.7805,-5.53279 25.4823,-19.43906 26.3125,-35.9375 27.8043,18.56783 60.9271,29.73277 96.625,30.65625 -0.9242,-35.72327 -12.0746,-68.8717 -30.6563,-96.6875 16.2943,-1.00304 29.9763,-11.61102 35.4688,-26.25 z" + id="path14367" /> + <g + style="fill:#fcef3c;fill-opacity:1;stroke:#000000;stroke-width:1.88821995;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="g16238"> + <path + transform="matrix(0.775253,0,0,0.81501,1089.4,186.8612)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14388" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546897;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + transform="matrix(0.671389,-0.387627,0.407505,0.705818,1010.393,804.0035)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14390" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + transform="matrix(-0.671389,-0.387627,0.407505,-0.705818,2936.607,1593.817)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14392" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + transform="matrix(-0.775254,-4.402797e-7,4.628583e-7,-0.815011,3313.6,1098.86)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14394" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546611;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + transform="matrix(-0.671389,0.387627,-0.407505,-0.705819,3392.606,481.716)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14396" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546873;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546802;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14398" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(-0.387628,0.671389,-0.705819,-0.407505,3152.458,-92.24858)" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546611;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14400" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(-4.402797e-7,0.775254,-0.815011,-4.628583e-7,2657.502,-469.2423)" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546873;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14402" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(0.387627,0.671389,-0.705819,0.407505,2040.357,-548.2492)" /> + <path + transform="matrix(0.671389,0.387628,-0.407505,0.705819,1466.393,-308.0995)" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + sodipodi:ry="19.5" + sodipodi:rx="20.5" + sodipodi:cy="387.86218" + sodipodi:cx="1434.5" + id="path14404" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546802;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + sodipodi:type="arc" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14406" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(0.387627,-0.671389,0.705818,0.407505,1250.543,1377.968)" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37546897;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14408" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(1.565175e-7,-0.775253,0.81501,1.645442e-7,1745.499,1754.96)" /> + <path + sodipodi:type="arc" + style="fill:#fcef3c;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:2.37547016;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none" + id="path14410" + sodipodi:cx="1434.5" + sodipodi:cy="387.86218" + sodipodi:rx="20.5" + sodipodi:ry="19.5" + d="m 1455,387.86218 c 0,10.76956 -9.1782,19.5 -20.5,19.5 -11.3218,0 -20.5,-8.73044 -20.5,-19.5 0,-10.76955 9.1782,-19.5 20.5,-19.5 11.3218,0 20.5,8.73045 20.5,19.5 z" + transform="matrix(-0.387627,-0.671389,0.705818,-0.407505,2362.644,1833.966)" /> + </g> + </g> + <path + d="m 450.34375,359.875 -25.3125,35.65625 25.3125,37.96875 0,-73.625 z" + id="path4071" /> + <path + d="m 451.96875,343.90625 24.5,-34.78125 -24.5,-36.4375 0,71.21875 z" + id="path4065" /> + <path + d="M 630.21875,106.4375 452.75,356.46875 l 57.3125,0 -9.84375,-14.875 166.5625,-235.15625 -36.5625,0 z" + id="path2644" /> + <path + d="m 447.71875,349.9375 -55.65625,0 L 401.40625,364 235.5,598.0625 l 37.5,0 174.71875,-248.125 z" + id="path4034" /> + </g> +</svg> diff --git a/Events/XDS2012.mdwn b/Events/XDS2012.mdwn new file mode 100644 index 00000000..11926796 --- /dev/null +++ b/Events/XDS2012.mdwn @@ -0,0 +1,8 @@ + + +# XDC2012: Nürnberg, Germany +[[!table header="no" class="mointable" data=""" + [[<< XDC 2011|Events/XDC2011]] | [[XDC 2012|Events/XDC2012]]** | XDS 2013 +"""]] + +**Please refer to [[XDC2012|Events/XDC2012]]** diff --git a/ExaStatus.mdwn b/ExaStatus.mdwn new file mode 100644 index 00000000..cfdce729 --- /dev/null +++ b/ExaStatus.mdwn @@ -0,0 +1,66 @@ + +[[EXA|http://lists.freedesktop.org/archives/xorg/2005-June/008356.html]] support status for various drivers. To help out, take a driver that isn't started, or improve one of the patches below, or port the code from KAA or XAA. Documentation is in xorg git under xserver/xorg/hw/xfree86/doc/devel/exa-driver.txt and found in doxygen from in the exa.h header. + +If you want to test, you will need at least +[[!format txt """ + Option "AccelMethod" "exa" +"""]] +in your card's `Device` section in `xorg.conf`. Do *not* try `Load "exa"` because it will fail. You may also want to enable Composite, by saying +[[!format txt """ +Section "Extensions" + Option "Composite" "enable" +EndSection +"""]] +Supported: + +* i128 (Solid and Copy only so far, incompatible with DGA, only tested on T2``R4 cards) +* radeon (r1xx-r7xx with Render accel) +* sis (sis/xgi; Solid and Copy only) +* trident cyberblade and xp4 (Solid and Copy only) +* via (Solid, Copy, Render) +* savage (Solid, Copy, UTS) +* mach64 (Solid, Copy, Render. [[DFS|https://bugs.freedesktop.org/show_bug.cgi?id=8414]] pending) +* mga (Solid, Copy, UTS. [[Render|https://bugs.freedesktop.org/show_bug.cgi?id=1293]] pending) +* siliconmotion (Solid, Copy. UTS pending) +* i810/intel (Solid, Copy, Render) +* nouveau (Solid, Copy, UTS/DFS on nv0x, Render on newer cards) +* geode (GX and LX variants, Copy/Solid/Composite) - [[README|http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/README]], [[code|http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src]] +Work in progress: + +* [[tdfx|http://c133.org/tmp/tdfx_exa.patch]] +* [[s3virge|http://git.sh0n.net/]] (Copy only currently) <-- link died ? +* [[r128|http://www.botchco.com/alex/2006soc/]] Joseph Garvin SoC +No work started, but capable of Render acceleration: + +* glide +* glint (supported in KAA), Coming soon ([[ShawnStarr|ShawnStarr]]) +* i740 +* imstt +* newport +* impact +* rendition +* trident (supported in KAA) +* voodoo +No work started, some chips might be capable of Render acceleration: + +* apm (via the voodoo rush) +* cirrus (laguna?) +* neomagic (256XL+ was the only one with a 3D engine) (supported in KAA) +* cyrix/nsc (new GX2s have an alpha combiner) +* sun{ffb,leo} +No work started, no Render acceleration possible: + +* ark +* chips (supported in KAA) +* s3 (supported in KAA) +* sun{bw2,cg14,cg3,cg6,tcx} (tcx has some EXA support in NetBSD tree: [[WebCVS Link|http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xf86-video-suntcx/dist/src/?only_with_tag=MAIN]]) +* tga +* tseng +Probably unsuitable for EXA support: + +* dummy +* fbdev +* vesa +* vga +* vmware +* wsfb
\ No newline at end of file diff --git a/FAQ.mdwn b/FAQ.mdwn new file mode 100644 index 00000000..ee5c1a2f --- /dev/null +++ b/FAQ.mdwn @@ -0,0 +1,87 @@ + + +# X.Org User FAQ + + * If you have problems getting X to start please make sure you have configured your X using one of the available configuration tools. If you are uncertain you did please check the [[ConfigurationHelp|ConfigurationHelp]] before you read any further. + * You can find driver related information in the [[KnowledgeBase|KnowledgeBase]]. + * If you are using a version of X.Org shipped by a distribution you should check there [[DistroFAQList|DistroFAQList]], too, before you report an error. + * If you cannot find an answer to your problem here feel free to subscribe to our [[SupportMailingList|SupportMailingList]]. Please follow the instructions given there on how to post a support question. + * X server information is usually logged in **/var/log/Xorg.0.log**, which can be consulted for errors or warnings if the server does not function as expected. + * If you want to add information don't add it to this page. Try to find a category it belongs to. If you cannot find any that fits feel free to create a new one on this page. + +# FAQ + +<a name="networktransparencyisslow"></a> +## hay guys why do u still hav network transparency dont you know its making everyfing slow + +Network transparency is actually not the problem: pretty much all inter-process communication uses local UNIX sockets and shared memory, which is ... exactly what X uses! Shocked. + +A lot of the problems with X are related to round trips: many events that X sends to clients are actually just prompts for clients to send another request, block, and wait for a reply actually containing the information you need. In turn, those requests will probably get stuck behind rendering requests from other clients, adding huge amounts of latency. Also, many operations look something like this: request from client A -> event sent to client B -> request sent from client B -> reply sent to client B -> request sent from client B -> client A's original request fulfilled. So, by the time you've scheduled ten times, a perceptible amount of time has actually passed. + +tl;dr: It doesn't. + + +## How to clone and build Xorg + + * See Peter's instructions at: [[Quickstart for those that do not use jhbuild|http://lists.x.org/archives/xorg-devel/2009-August/001826.html]] + +[[!format txt """ + # Quickstart for those that do not use jhbuild: + export PREFIX=/opt/xorg + export LD_LIBRARY_PATH=$PREFIX/lib + export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig + export PATH=$PREFIX/bin:$PATH + export ACLOCAL="aclocal -I $PREFIX/share/aclocal" + + git clone git://anongit.freedesktop.org/git/xorg/util/modular/ util/modular + echo "util/macros" > built.modules + ./util/modular/build.sh --clone -p -f built.modules -r `tail -n 1 built.modules` $PREFIX + + # Re-run the last command until a build succeeds. +"""]] + +## How to use XRandR 1.2 (for Dual-Head etc) + + * See the links on the [[XRandR Documentation|http://wiki.x.org/wiki/Projects/XRandR]] page + +## How to set-up a multiseat configuration (aka zaphod mode) + + * See the [[Multiseat|Development/Documentation/Multiseat]] page + +## Server doesn't start and generates an error message + + * [[FAQErrorMessages|FAQErrorMessages]] + +## Server generates warning messages + + * [[FAQWarningMessages|FAQWarningMessages]] + +## Server doesn't set the video mode I would like to use + + * [[FAQVideoModes|FAQVideoModes]] + +## Video Driver FAQ + + * [[VideoDriverFAQ|VideoDriverFAQ]] + +## Migration FAQ + + * [[FAQMigration|FAQMigration]] + +## Proprietary Drivers + + * [[ATI|ATIProprietaryDriver]] + * [[NVIDIA|NVIDIAProprietaryDriver]] + +## Miscellaneous + + * [[FAQMiscellaneous|FAQMiscellaneous]] + * [[UpdateProblems|UpdateProblems]] - Issues that may occur after updating. + +## Advanced Topics + + * [[AdvancedTopicsFAQ|AdvancedTopicsFAQ]] - This is a collection of solutions to advanced setup and configration problems and customizations for special purposes. + +# More FAQs + +For your convenience we collected some links to X related informations on [[OtherFAQs|OtherFAQs]]. diff --git a/FAQErrorMessages.mdwn b/FAQErrorMessages.mdwn new file mode 100644 index 00000000..a9db67a0 --- /dev/null +++ b/FAQErrorMessages.mdwn @@ -0,0 +1,336 @@ + +**If you have a question not listed here, don't post your question here, please use the bugzilla or the mailing list.** + + +# Server doesn't start and generates an error message + +Error messages that don't immediately lead to a fatal server error (and the termination of the server) are marked in the log file by a `(EE)` at the beginning of the line. An error that leads to immediate server termination usually prints the line `Fatal server error:` followed by some explanation. + + +[[!toc ]] + + +## I keep getting the error message: could not open default font 'fixed' + +This is by far the most popular Frequently Asked Question :( + To run X you need at least the font 'fixed' and 'cursor' to display a cursor image and be able to print meaningful error messages. If these fonts are not present the server doesn't start. My Xserver refuses to start and gives me the error message: + + +[[!format txt """ +Fatal server error: +could not open default font 'fixed' +When reporting a problem related to a server crash, please send +the full server output, not just the last messages. +This can be found in the log file "/var/log/Xorg.0.log". +Please report problems to xorg@lists.freedesktop.org. +"""]] +There may be different reasons for this: + + +Somewhere (pretty much at the beginning of the log) there is a message: + + +[[!format txt """ + Could not init font path element unix/:7100, removing from list! +"""]] +This message tells that the Xserver is trying to contact a font server which appearantly isn't running. So you need to get your font server up and running before you start X. How this is done depends heavily on the OS and/or the distribution you use. Please contact your vendor support on how to do this! + Please note: The use of the font server `xfs` is deprecated due to several bugs in it. It is recommended that the Xserver loads the fonts directly. To do so add at least the lines: + + +[[!format txt """ + FontPath "/usr/X11R6/lib/X11/fonts/misc/" + FontPath "/usr/X11R6/lib/X11/fonts/Speedo/" + FontPath "/usr/X11R6/lib/X11/fonts/Type1/" + FontPath "/usr/X11R6/lib/X11/fonts/CID/" + FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" + FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" +"""]] +to the `"Files"` section of your `xorg.conf` file. + + +The Debian package xfonts-base puts these fonts in /usr/share/fonts/X11. If this is the package you are using, the [[FontPaths|FontPaths]] should instead be + + +[[!format txt """ + Fontpath "/usr/share/fonts/X11/misc" + FontPath "/usr/share/fonts/X11/Type1/" + FontPath "/usr/share/fonts/X11/75dpi/" + FontPath "/usr/share/fonts/X11/100dpi/" +"""]] +There is also a possibility that the [fontpath]/misc/fonts.alias file is missing. This can cause the X server to not find the alias of 'fixed' to whatever is the actual fixed font. + + +[[!format txt """ + fixed -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-1 +"""]] + + +--- + + + +* If you see a messages like: + +[[!format txt """ +(WW) The directory "/usr/X11R6/lib/X11/fonts/100dpi" does not exist. + Entry deleted from font path. +"""]] +it means that this font path element either does not exist or isn't readable. Normally it is no problem if some font path elements listed in your `xorg.conf` are missing. However if `/usr/X11R6/lib/X11/fonts/misc/` is missing the `cursor` and the `fixed` fonts are missing, too, therefore the server cannot start. Therefore please make sure that this directory exists and is readable. To have a good selection of standard fonts you should have at least the directories listed above. If you need non-latin character sets more fonts may be required. + + + +--- + + + +* Please also check for messages like: + +[[!format txt """ + (WW) `fonts.dir' not found (or not valid) in "/usr/X11R6/lib/X11/fonts/local/"\ +. + Entry deleted from font path. + (Run 'mkfontdir' on "/usr/X11R6/lib/X11/fonts/local/"). +... + Could not init font path element /usr/X11R6/lib/X11/fonts/misc/, removing from\ + list! +"""]] +These tell you that the fonts were probably not installed correctly. Please do as suggested and run + + +[[!format txt """ + mkfontdir /usr/X11R6/lib/X11/fonts/local/ +"""]] +Please replace `/usr/X11R6/lib/X11/fonts/local/` with the directories listed in your log file. You should do this for every directory listed. + + + +--- + + If adjusting the paths in the xorg.conf file didn't fix it, try the following. It essentially rebuilds the fonts.dir and fonts.scale files and force refreshes the cache. + + +[[!format txt """ + cd /usr/share/fonts/misc + mkfontscale . + mkfontdir -e /usr/share/fonts/encodings -e /usr/share/fonts/encodings/large . + /usr/bin/fc-cache -f +"""]] + + +--- + + + +* Some additional resources: +* [[XFree86 Font De-uglification HOWTO|http://feenix.burgiss.net/ldp/fdu/]] +* [[XFS man page for X 4.3.0|http://www.freedesktop.org/~xorg/current/doc/xfs.1.html]] +* [[Red Hat v9.0 documentation regarding fonts|http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-x-fonts.html]] +* [[Xorg man page for X 4.3.0|http://www.freedesktop.org/~xorg/current/doc/Xorg.1.html]] + +## I keep getting the message: "kernel module version is 1.1.1 but 1.3.1 or later is preferred." + +Your DRM kernel driver version is older than the one desired by your Xorg driver. You should get a later DRM module version. + If you are using a distribution and X and your kernel were shipped by your distribution vendor you should contact your vendor support to find out how to fix this problem. + If you've built X and/or the kernel yourself you should make sure the kernel is recent enough. + + +## I keep getting the message: "AddScreen/ScreenInit failed for driver 0" + +You get an error message like: + + +[[!format txt """ +(EE) R128(0): (Ron = 12288) + (Rloop = 17) >= (Roff = 12012) +Fatal server error: +AddScreen/ScreenInit failed for driver 0 +"""]] +This kind of problem typically occurs when you're using a big monitor with an old graphics card. You can solve it by deleting some of the highest resolutions of the deepest colour mode in the `Screen` section of your `xorg.conf`, or even the whole last `Display` subsection. + + +## I keep getting the message: "failed to initialize core devices" + +You get an error message like: + + +[[!format txt """ +(EE) xf86OpenSerial: Cannot open device Logitech + No such file or directory. +(EE) Mouse1: cannot open input device +(EE) PreInit failed for input device "Mouse1" +(II) UnloadModule: "mouse" +(II) Keyboard "Keyboard1" handled by legacy driver +(WW) No core pointer registered +No core pointer +Fatal server error: +failed to initialize core devices +"""]] +The message `xf86OpenSerial: Cannot open device Logitech` tells you that the input device 'Logitech' cannot be opened. The next line tells you why: `No such file or directory.` There is no such device. Device names usually start with `/dev/`. The device name itself depends on the device you use, your OS and the distribution you use. Usually there os a symlink from `/dev/mouse` to the correct device. If you are using a distribution it usually comes with a configuration tool for X, so you may just want to rerun the configuration tool to correct the setup. + Please note: Usually the server refuses to start if there is no core pointer device. You can change this by adding the line: + `Option "AllowMouseOpenFail" "1"` + to the `ServerFlags` section of your `xorg.conf`. + +Note: Be sure you have either hotplug or udev installed. If you don't, you will have problems detecting mice and video hardware. + + +## I keep getting the message: "Server is already active for display 0" + +<a name="AlreadyActive"></a> You get an error message like: + + +[[!format txt """ +Fatal server error: +Server is already active for display 0 + If this server is no longer running, remove /tmp/.X0-lock + and start again. +"""]] +The number denotes the display number (in this case 0). This number needs to be unique on the system, so you cannot run two servers on one system with identical display numbers. This message indicates that there is already a server with this number running on the system. You can verify this by running + + +[[!format txt """ + ps aux | grep `cat /tmp/.X0-lock` +"""]] +If you see an output like: + + +[[!format txt """ +root 2283 0.5 5.1 27796 6536 ? S Apr21 59:03 [X] +"""]] +it indicates that there is indeed an Xserver running under this PID. To start a second server on the same system you have to give it a different dislay number. If you start your servers using startx you can do + + +[[!format txt """ +startx -- :1 +"""]] +to start a server with display number 1. If you are sure there is no other server running on your system and above ps command indicates that no server with this PID is running, you should remove the file `/tmp/.X0-lock` by doing (as 'root'): + + +[[!format txt """ +rm -rf /tmp/.X0-lock +"""]] + +## I keep getting the message: "Cannot establish any listening sockets..." + +You get an error message like: + + +[[!format txt """ +_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed +_XSERVTransMakeAllCOTSServerListeners: server already running +Fatal server error: +Cannot establish any listening sockets - Make sure an X server isn't already running +"""]] +This problem is very similar to the [[previous one|FAQErrorMessages]]. You will get this message possibly because the lock file was removed somehow or some other program which doesn't create a lock file is already listening on this port. You can check this by doing a `netstat -ln`. Xservers usually listen at tcp port 6000+<Display Number>, therefore if you have started your Xserver with the command line option `:1` it will be listening on port 6001. + Please check the [[article above|FAQErrorMessages]] for further information. + + +## I keep getting the message "Unable to load required base modules, Exiting..." + +You get an error message like: + + +[[!format txt """ +(II) Loading /usr/X11R6/lib/modules/libpcidata.a +(II) Module pcidata: vendor="The X.Org Foundation" + compiled for 6.7.0, module version = 1.0.0 + ABI class: X.Org Video Driver, version 0.6 +Fatal server error: +Unable to load required base modules, Exiting... +"""]] +This means that the server has problems loading a module. The message immediately above tells you which module it was. The most likely cause is that the module doesn't exist. You may therefore try to reinstall your Xserver modules. + + +## I keep getting the message: "no screens found" + +This is a very general message telling you that something went wrong and there is no screen left which the server can successfully drive. Usually you'll see another error message describing what went wrong in more detail: + + +### Message: "No devices detected" + +You get an error message like: + + +[[!format txt """ +(EE) No devices detected. +Fatal server error: +no screens found +"""]] +It is very likely that your `xorg.conf` file doesn't contain the correct driver(s) for the chipset(s) in your system or that your chipset isn't supported by any of the drivers. + You can check for the detected devices in the log file (in most cases `/var/log/Xorg.0.log`) by looking for lines like: + `(--) PCI:*(1:0:0) Neomagic Corporation NM2200 [MagicGraph 256AV] rev 32, Mem @ 0xfd000000/24, 0xfe800000/22, 0xfec00000/20` + In this example the active video device (the one with the `*`) is a Neomagic NM2200 video chip. In order to get this chipset to work you'd have to use the _neomagic_ driver. + <a name="ConfigurationHelp"></a> If you are using a distribution you should rerun its configuration tool. If there is no such tool, or if it keeps configuring your Xserver wrong you may want to try `xorgcfg`, the graphical tool shipped with Xorg. You can also let the server generate a config file: as root just run `X -configure`. + Please note: If you appear to use the correct driver and you still keep getting this message it is very likely that your chipset isn't supported (yet). In this case you may try the `vesa` driver or - if this doesn't work - the `vga` driver. However both are entirely unaccellerated. + + +### Message: "Screen(s) found, but none have a usable configuration. + +You get an error message: + + +[[!format txt """ +(EE) Screen(s) found, but none have a usable configuration. +Fatal server error: +no screens found +"""]] +In most cases this means there are no video modes available for your configuration. Each entry in the list of specified or default video modes gets checked if it lies withing the limit or the hardware: if it lies within the sync range specified or probed for the monitor, if it will work with the memory available on the video card or if the pixel clock lies within the range supported by the chipsets. There are many more limits. For each rejected mode you can see in the log file the reason for rejection: + + +[[!format txt """ +... +(II) VGA(0): Not using default mode "320x200" (vrefresh out of range) +(II) VGA(0): Not using default mode "720x400" (insufficient memory for mode) +(II) VGA(0): Not using default mode "360x200" (hsync out of range) +... +"""]] +In most cases the monitor ranges are the reason why your modes where rejected. Please try to extend these ranges carefully until you get a working mode. Please note: on older monitors you need to be careful extending the ranges as it can be easily destroyed. There may be other reasons why you get this message. + +* If the specified depth is not supported with your hardware. In this case try depth 8, or if you +* are using the `vga` driver even depth 4. + * If you specified a combination of options the driver cannot handle. + * If loading of a required sub module wasn't successful. In this case you'll get a message that the loading failed. Please try to investigate, why. The message may give you a clue: you may be using the wrong version of the module, or the file may not exist. + +### Message: "Unable to locate/open config file" + +You are getting the message: + + +[[!format txt """ +(EE) Unable to locate/open config file +(EE) Error from xf86HandleConfigFile() +"""]] +This means that the Xserver cannot find a configuration file because it has not been properly configured. Please check [[FAQMiscellaneous|FAQMiscellaneous]] for information how to configure your Xserver. + Another reason for this error may be that you have created a configuration file but it is not in the correct location. The Xserver checks for configuration files at different locations. The usual locations are: `/etc/X11/xorg.conf` or `/etc/X11/XF86Config-4`. + Another reason for this message may be that your Xserver cannot read the file because the server binary has the wrong permission. On UN*X like systems the server is usually owned by `root` and runs with the SUID bit set so that it runs with root privileges even if started by an ordinary user. Therefore it should be able to open the configuration file regardless of who owns it or of its permissions. Please check "How do I check if my server bianry has the correct permissions?" on the [[FAQMiscellaneous|FAQMiscellaneous]] page for futher information + + +### Message: "Error from xf86HandleConfigFile()" + +You are getting the message: + + +[[!format txt """ +(EE) Unable to locate /open config file +(EE) Error from xf86HandleConfigFile() +Fatal server error +no screens found +"""]] +This indicates that you have a problem with your config file. It either doesn't exist, in which case you'll additionally see the message: + + +[[!format txt """ +(EE) Unable to locate /etc/X11/xorg.conf config file +"""]] +or your config file contains a typo. In this case you see the message: + + +[[!format txt """ +(EE) Problem parsing the config file +"""]] +You are even told where the error was: + + +[[!format txt """ +Parse error on line 3 of section ServerLayout in file /etc/X11/xorg.conf + "Idntifier" is not a valid keyword in this section. +"""]] +You can then either correct the config file or regenerate the config file. How to do this is described [[here|FAQErrorMessages]]. diff --git a/FAQMigration.mdwn b/FAQMigration.mdwn new file mode 100644 index 00000000..84646aeb --- /dev/null +++ b/FAQMigration.mdwn @@ -0,0 +1,28 @@ +## I want to migrate to X.Org, what do I have to do? + +### I've used XFree86 [TM] before now I want to use X.Org. + +If you have a working setupt for XFree86[TM] you can reuse it without many changes. Just build and install the X.Org source tree. + +Files and option names that contain `xf86` or `xfree86` have been replaced but the old names are still accepted. Therefore your old configuration files and startup scripts don't have to be modified.<br> There is one exception, though: The server binary is not called `XFree86` any more but `Xorg` therefore you may have to change the soft link that points to your real Xserver binary. This soft link usually lives under `/var/X11R6/bin`. If your Xserver binary is located in /usr/X11R6/bin/ simply do: + + ln -sf /usr/X11R6/bin/Xorg /var/X11R6/bin/X + +#### Which options and file names have changed now? + +* The server name has been changed to `Xorg`. +* The keyboard rules file (usually under `/usr/X11R6/lib/X11/xkb/rules`) is now called xorg (a softlink is created to the file name that has been used by XFree86[TM] for backward compatibility. +* The command line option to specify the server config file name has been changed to `-config`. +* The default configuration file is now called `xorg.conf`. The search path and appendices have not changed. + +#### Are there known problems so far? + +Some programs seem to make use of the description files for the xkb rules and have the file names hardcoded to the names used bu XFree86[TM](`xfree86.lst` and `xfree86.xml`). The names of those files have also been changed but the installation procedure for X.Org Release 6.7 doesn't create a compatibility link. Therefore you should create these links by hand: + + ln -sf /usr/X11R6/lib/X11/xkb/rules/xorg.lst /usr/X11R6/lib/X11/xkb/rules/xfree86.lst + ln -sf /usr/X11R6/lib/X11/xkb/rules/xorg-it.lst /usr/X11R6/lib/X11/xkb/rules/xfree86-it.lst + ln -sf /usr/X11R6/lib/X11/xkb/rules/xorg.xml /usr/X11R6/lib/X11/xkb/rules/xfree86.xml + +### I'm using a vendor supplied system, what else do I have to change? + +If you have a working configuration of XFree86[TM] running on your system just follow the steps described. Some vendors use configuration utilities which make assumptions about the name of the server binary and the name of the server log file. Those utilities may not work any longer after you have installed X.Org. Please contact your system vendor for a updated versions of these tools. -- Main.[[EgbertEich]] - 11 Jun 2004 diff --git a/FAQMiscellaneous.mdwn b/FAQMiscellaneous.mdwn new file mode 100644 index 00000000..2057227e --- /dev/null +++ b/FAQMiscellaneous.mdwn @@ -0,0 +1,109 @@ + + +# Miscellaneous + +[[!toc ]] + + +## I don't know my hardware, how can I configure X? + +Don't worry, todays configuration tools do a pretty good job detecting hardware automatically. If you are using a distribution you will want to try the configuration tools provided by your distribution vendor first. If these don't work or if your vendor doesn't provide any you can use the tools shipped with X.Org. You may want to use the graphical tool `xorgcfg` to do your Xserver configuration or you may let the server generate it's own configuration file by running: `X -configure` as root. It will create the configuration file `xorg.conf.new` in the home directory of the user who ran it (usually root). You should then copy this file to the default location `/etc/X11/xorg.conf`. + +Please note: Xorg can only autodetect PCI and AGP video chipsets. If you still use an ISA/EISA/VL chipset you need to at least know the chipset vendor to specify the correct driver. Most drivers can then autodetect the chipset model. + + +## How do I set the correct permissions of my Xserver binary? + +On UN*X like systems the server is usually owned by `root` and runs with the SUID bit set so that it runs with root privileges even if started by an ordinary user. To check if your Xserver has the right permissions you have to locate the server binary. Usually the soft link `/var/X11R6/bin/X` points to the binary. Please do +[[!format txt """ + ls -l /usr/X11R6/bin/X +"""]] +obtain the binary the link points to (usually `/usr/X11R6/bin/Xorg` and do a: +[[!format txt """ + ls -l /usr/X11R6/bin/Xorg +"""]] +(Replace `/usr/X11R6/bin/Xorg` with the name of the binary pointed to by the link.) The result should look something like this: +[[!format txt """ + -rws--x--x 1 root root 2019033 2003-03-17 14:26 /usr/X11R6/bin/Xorg +"""]] +This file is owned by the user 'root' and has the SUID bit set (the 's' in `-rws--x--x`. If either one isn't true you need to fix this. Do +[[!format txt """ + chown root:root /usr/X11R6/bin/Xorg +"""]] +To make root owner of the file. (You have to be 'root' to do so). And +[[!format txt """ + chmod u+s /usr/X11R6/bin/Xorg +"""]] +to set the SUID bit. (Here again you may have to replace `/usr/X11R6/bin/Xorg` by the name of the binary you are using.) + + +## When I start X can I get the root window display a solid color instead of the 'root cross stitch'? + +Starting with version XFree86 4.3 there is the command line switch `-br` for the Xserver that changes the root window to a solid black. If you use `startx` please do: +[[!format txt """ +startx -- -br +"""]] +Please note: It is not easy to use any other color than black or white. At this point there is no other colormap entry than black or white in the colormap. + + +## My keyboard is dead, what can I do? + + +### I've upgraded to Xorg R6.7, now my keyboard is dead. + +You need a new set of keyboard description files in `/usr/X11R6/lib/X11/xkb/` that come with Xorg R6.7. Chances are that when you upgraded these files didn't get installed correctly. Try to reinstall these files and restart your Xserver. + + +### My keyboard is still dead. + +There may be several reasons for this: You have an entry for a PS/2 mouse (on Linux on /dev/psaux) in your `xorg.conf` however you don't have a PS/2 mouse connected. This is actually a kernel problem. You should remove this device from your `xorg.conf`. + + +## I seem to be unable to allocate a sufficient number of colors in 8 bit. + +The RENDER extension preallocates some entries in the default colormap of the PseudoColor modes. This limits the number of entries available to clients. Some older 8bit clients are optimized for 254 entries in the 8bit palette (two are aloways set to white and black). If they cannot allocate all their colors they don't display correctly. In some cases changing a colormap entry is used to make certain objects blink. If there are not sufficient entries this blinking may not work. <br> You should make your software use a private colormap. If this isn't possible you can reduce the number or preallocated entries with a command line option to the Xserver: if you use `startx` to start your Xserver you can do: <br> +[[!format txt """ +startx -- -render mono +"""]] +Please note that transparency or antialiasing may not work in this case. + + +## How do I set up a multihead configuration? + +I think there was a multihead FAQ someplace. I wonder where that's at? <br> Basically, you can have in the `xorg.conf` file: + + 1. monitor section for that monitor. + 1. device sections. One for each card. Use the !BusID token to specify which card is which. + 1. screen sections. Each referencing the separate card, but both can reference the single monitor section. + 1. server layout section that references both screens, eg: + +[[!format txt """ +Section "ServerLayout" + Identifier "DualHead" + Screen 0 "Screen0" 0 0 + Screen 1 "Screen1" RightOf "Screen0" + InputDevice "Mouse0" "CorePointer" + InputDevice "Keyboard0" "CoreKeyboard" +EndSection +"""]] +Start with a working single head configuration and create the second device and screen sections by cutting and pasting but assigning different Identifiers and, in the case of the device sections, different !BusIDs. Change the layout section to something like above. <br> If you have a single card with one chipset but two (or more) display connectors you have to create device sections for each connector with identical busID. To distinguish between the connectors you need to add the line +[[!format txt """ +Screen n +"""]] +* where `n` is replaced by the number of the connector. (ie. `n`0,1,2...=). + +## How can I configure the Xserver bell (xkbbell) to use the sound subsystem of my computer? (ALSA, OSS, etc.) + +Answer (hopefully) goes here.. :) + + +## How do I find out which process owns a given window? + +The answer to this is not straightforward and depends on which assumptions you are willing/able to make and what your usage model is. The first thing that should be noted is that X is a network service, so it is not enough to simply know the PID alone, you will need to know both the PID and hostname of the client, in case the client is running on a remote machine. + +That said, there is a standard method for X clients to report their hostname and PID. This is via two properties, _NET_WM_PID and WM_CLIENT_MACHINE. The idea behind these properties is that window managers can query them and use them to label windows graphically or otherwise make use of them. Your application code can also query them. However, there are several caveats: + + 1. Their use is recommended but not required. Not all X clients set them. + 1. Applications and toolkits that do set them often do so only on a single window which may not be anywhere close to either the root window or the "leaf" windows reported by mouse events. In this case, use of XQueryTree is required to traverse the window hierarchy to find it. + 1. **Most Importantly, the contents of the properties is entirely within the control of the application itself!** This means that a malicious application could easily report false values! +For anything more secure/robust you will need a server-side solution. Many local socket implementations provide a way to find out the PID of the remote end of a connection, such as getpeerucred(), which are kernel-based and cannot be spoofed. The server has a [[LocalClientCred|LocalClientCred]]() function that will return the values if supported. However, this will not work on remote connections. diff --git a/FAQVideoModes.mdwn b/FAQVideoModes.mdwn new file mode 100644 index 00000000..6e12d3cb --- /dev/null +++ b/FAQVideoModes.mdwn @@ -0,0 +1,164 @@ + + +# Video Modes FAQ + +[[!toc ]] + + +## When I change modes with ctrl-alt-(keypad''+) or ctrl-alt-(keypad''-) I get a virtual screen. I don't want that + +In X the size of the root window (ie. your desktop) is fixed. When you change the video mode using the hotkey sequence of `xvidtune` you therefore get a 'virtual' screen, ie. a screen that is bigger than your desktop and you can use your mouse to 'pan' thru it. + +There now is an extension which allows to change the video mode along with the size of the root window. It is called the _RandR_ extension. You can use `xrandr` to set the desired mode. Use `xrandr --query` to get a list of available modes. With `xrandr --size <width>x<height>` you can pick one of the available resolutions. Try `man 1x xrandr` or `xrandr -help` to get more information on `xrandr`. + +**Please note!** If your application/window manager doesn't support the _RandR_ extension you are likely to lose those windows which are entirely located outside of your new desktop. You can get them back when you restore your desktop to the original size. + + +## Why can't I get a 1400x1050 video mode (or some other size) + +Some drivers are limited to the set of modes in the video BIOS. The most common examples is vesa. Usually there's nothing you can do in this situation, because it's not possible to modify the BIOS. Sorry. The exception is some Intel chips, where you can use the 855resolution or 915resolution hacks, and it might work and it might not. + + +## Obtaining modelines from Xorg log + +The Xorg log may contain the information needed to manually create an optimized modeline. Usually the more user friendly automatic setup tools will do this job for you. But sometimes those tools fail. In those cases you are left with the task of reading the Xorg log file to figure out what to do. + +Using this information does require manually editing the configuration file, but this is not a terribly difficult process. The key is to have a mostly correct configuration file as a starting point. In my situation I had a valid configuration file, but it was for the old monitor. The new LCD panel has a much more limited frequency range than the old monitor, and it could not accept the previous setup. I could have done a full re-install of X (I think), but it was easier to just edit the configuration file. + +I switched into a text mode VT (CTL-ATL-F2), edited the config file, and restarted X. Voila. + +The Xorg log contained + + +[[!format txt """ +(II) R128(0): Supported additional Video Mode: +(II) R128(0): clock: 162.0 MHz Image Size: 432 x 324 mm +(II) R128(0): h''active: 1600 h''sync: 1664 h''sync''end 1856 h''blank''end 2160 h_border: 0 +(II) R128(0): v''active: 1200 v''sync: 1201 v''sync''end 1204 v''blanking: 1250 v''border: 0 +(II) R128(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 170 MHz +(II) R128(0): Monitor name: SyncMaster +(II) R128(0): Serial No: H4JW502073 +(``) R128(0): Using gamma correction (1.0, 1.0, 1.0) +(II) R128(0): Monitor[0]: Using hsync range of 30.00-81.00 kHz +(II) R128(0): Monitor[0]: Using vrefresh range of 56.00-75.00 Hz +(II) R128(0): Clock range: 12.50 to 250.00 MHz +"""]] +I used this information to update the Monitor section and add the appropriate modeline to the Modes section: + + +[[!format txt """ +Section "Monitor" + Option "CalcAlgorithm" "UseFrameBufferTiming" + DisplaySize 432 324 + HorizSync 30-81 + Identifier "Monitor[0]" + ModelName "SyncMaster" + Option "DPMS" + VendorName "Samsung" + VertRefresh 56-75 + UseModes "Modes[0]" +EndSection +"""]] +The `VertRefresh` range, `HorizSync` range, and `DisplaySize` were obtained from the log. I copied the `ModelName` and `VendorName` but these do not really matter. + + +[[!format txt """ + Modeline "1600x1200" 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +"""]] +The name 1600x1200 is just a normal convention. The recommended clock speed of 162.00 and the pixel timings are taken from the log. + + +## Obtaining modelines from Windows program PowerStrip + +If you have a dual boot system and a monitor / graphics card that works fine under MS Windows but you can't figure out the equivalent modeline parameters for Linux, you can use the Windows program Power``Strip. + +I used this to configure X.org to work correctly with my Sun X7200A 20.1" LCD monitor and my Dell C400 Latitude notebook. + +Download and install Power``Strip from + + * [[http://entechtaiwan.net/util/ps.shtm|http://entechtaiwan.net/util/ps.shtm]] +Once installed and running you will see a Power``Strip icon in the system tray. + +With the display using the required settings (for me this was 1600x1200). + +Right Click on the Power``Strip icon in the system tray to display the pop up menu. + +Select sub menu "Display Profiles" then select menu item "Configure" + +The "Display profiles" window will be displayed, click button "Advanced timing options". + +The "Advanced Timing Options" window will be displayed, click button copy timings to clip board (this button is the icon to the right of the "Cancel" button. + +Paste your clipboard somewhere (notepad will do) and have a look. You will see at the end of the pasted data will be the information you need for an Xorg modeline. + +For my setup Power``Strip put the following information in the clipboard +[[!format txt """ +PowerStrip timing parameters: +1600x1200=1600,8,64,104,1200,5,10,24,132000,512 + +Generic timing details for 1600x1200: +HFP=8 HSW=64 HBP=104 kHz=74 VFP=5 VSW=10 VBP=24 Hz=60 + +VESA detailed timing: +PClk=132.00 H.Active=1600 H.Blank=176 H.Offset=-8 HSW=64 V.Active=1200 V.Blank=39 V.Offset=5 VSW=10 + +Linux modeline parameters: +"1600x1200" 132.000 1600 1608 1672 1776 1200 1205 1215 1239 +hsync +vsync +"""]] +As you can see the last line is all you need to know to create a modeline. + +With that information you can boot back into Linux and add the modeline to the monitor section. Within my xorg.conf file I now have: +[[!format txt """ +Section "Monitor" + Identifier "Generic Monitor" + VendorName "Sun" + ModelName "X7200A" + Option "DPMS" + ModeLine "1600x1200" 132.000 1600 1608 1672 1776 1200 1205 1215 1239 +hsync +vsync +EndSection +"""]] + +# Setting up a Dell 2001FP LCD + +Above was followed pretty much as a guide. + +This information is provided to show the variation of Log messages which may appear. + +**Monitor** Dell 2001FP (for 1600x1200) on X.org (Ubuntu Linux) + +**Graphics Card** Intel i810 Card + +The [[ModeLine|ModeLine]] entry needs to go in the +[[!format txt """ + Section "Monitor" +"""]] +The X.org Log entry showed # from the /var/log/Xorg.0.log +[[!format txt """ + (II) I810(0): clock: 162.0 MHz Image Size: 367 x 275 mm + (II) I810(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 + (II) I810(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 + (II) I810(0): Serial No: XXXXXXXXXXXX (removed serial number) + (II) I810(0): Monitor name: DELL 2001FP + (II) I810(0): Ranges: V min: 56 V max: 76 Hz, H min: 31 H max: 80 kHz, PixClock max 160 MHz + (II) I810(0): Using detected DDC timings + (II) I810(0): HorizSync 31-80 + (II) I810(0): VertRefresh 56-76 + (WW) I810(0): config file vrefresh range 56-86Hz not within DDC vrefresh range 56-76Hz + (II) I810(0): Will use BIOS call 0x5f05 to set refresh rates for CRTs. + (--) I810(0): Maximum space available for video modes: 12288 kByte +"""]] +I modified my Monitor section to the following +[[!format txt """ +Section "Monitor" + Identifier "DELL 2001FP" + DisplaySize 367 275 + HorizSync 31-80 + VertRefresh 56-76 + Option "DPMS" + ModeLine "1600x1200" 160.00 1600 1664 1856 2160 1200 1201 1204 1250 +EndSection +"""]] +[[DisplaySize|DisplaySize]], if included really should be the actual size of your display in mm. This is best assessed by determining the LCD's native resolution and dotpitch and multiplying the two. For a Dell 2001FP, the native resolution is 1600x1200 and the dotpitch is .255 mm, thus the display size should be 408 306. The display size listed above will not correctly display paper sizes in word processing or other programs (e.g., openoffice, gv). +[[!format txt """ + DisplaySize 408 306 +"""]]
\ No newline at end of file diff --git a/FAQWarningMessages.mdwn b/FAQWarningMessages.mdwn new file mode 100644 index 00000000..966a12ba --- /dev/null +++ b/FAQWarningMessages.mdwn @@ -0,0 +1,23 @@ + + +# Server issues warning messages + +[[!toc ]] + +The Xserver can report warning messages to the log file. They can be identified by the `(WW)` string at the beginning of the line. There are hundreds of possible warning messages and most of them may be ignored, however some may help to explain why things don't work as expected. We try to explain these here. + + +## No matching Device section for instance ??? found + +Your Xserver reports the warning like: +[[!format txt """ +(WW) RADEON: No matching Device section for instance (BusID PCI:1:0:0) found +"""]] +This means that the driver is able to drive the PCI device (chip) mentioned (here the one with the ID: 1:0:0) but the Xserver cannot find a valid device section for it in the Xserver config file. Without a device section this chip cannot be used. If the config file doesn't contain any other valid device section the server will terminate with the error message: `(EE) No devices detected.` + +Many devices include multiple device IDs on the same slot. Multi-head Radeons, for example, will often show up as both 1:0.0 and 1:0.1. The second device is totally fake, it only exists so the multihead support on certain other OSes will work. You can safely ignore these kinds of warnings. + + +## Open APM failed (/dev/apm_bios) (No such file or directory) + +The X server will check for the presence of APM power management support on startup. If your system does not have APM support, either in the BIOS or in the kernel, or if the device node simply doesn't exist, then you'll get this error message. This is not fatal to server startup, but if you're using APM for power management **and** you get this message, the server may get confused on power events. diff --git a/FTPXOrgMirrors.mdwn b/FTPXOrgMirrors.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/FTPXOrgMirrors.mdwn diff --git a/FindPage/Capacitor.pdf b/FindPage/Capacitor.pdf Binary files differnew file mode 100644 index 00000000..77612adb --- /dev/null +++ b/FindPage/Capacitor.pdf diff --git a/Fosdem2006DevRoomAttendants.mdwn b/Fosdem2006DevRoomAttendants.mdwn new file mode 100644 index 00000000..8bc96129 --- /dev/null +++ b/Fosdem2006DevRoomAttendants.mdwn @@ -0,0 +1,8 @@ + + +# X@FOSDEM2006 DevRoom Visitors: + +The [[DevRoom|DevRoom]] doesn't require registration of any kind. This list is nothing more than a poll which allows the organisers to know the number of possible attendants. It might also allow people to find out who they might encounter. + +* Luc Verhaegen +* Mirco Müller
\ No newline at end of file diff --git a/Fosdem2006HotHouseParticipants.mdwn b/Fosdem2006HotHouseParticipants.mdwn new file mode 100644 index 00000000..f1787ed9 --- /dev/null +++ b/Fosdem2006HotHouseParticipants.mdwn @@ -0,0 +1,17 @@ + + +### Confirmed Participants to the X@FOSDEM2006 Developers HotHouse on Friday, 24th of February: + +* Egbert Eich +* Keith Packard +* Luc Verhaegen +* Jerome Glisse +* Matthieu Herrb +* Stephane Marchesin +* Stuart Kreitman +* Matthias Hopf +* Jay Hobson +* Zack Rusin +* Lars Knoll +* Michel Daenzer +* Daniel Stone
\ No newline at end of file diff --git a/GSoCApplication.mdwn b/GSoCApplication.mdwn new file mode 100644 index 00000000..5fd16ead --- /dev/null +++ b/GSoCApplication.mdwn @@ -0,0 +1,41 @@ + + +## Project Proposal Guidelines + +We expect more project proposals than Google will be able to fund. Here is our list of suggestions about how to write a Summer of Code proposal that will stand a chance of rising to the top of the heap. + + +## Requirements + + * Applicants meet Google's requirements for participation in Summer of Code. + * Applicants are in regular and close contact with their X.Org mentors. + * Applicants know their target programming language. + +## Proposal Outline + + * Name and Contact Information + * Title + * Synopsis. A short summary. + * Benefits to the Community. What novel technologies or approaches will be demonstrated? + * Deliverables. Give a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. You may want plan to start by producing some kind of whitepaper, or planning the project in traditional software engineering style. Work should include + * investigation + * programming + * documentation + * dissemination + * Description. A list of project details (rough architecture, etc). + * Related Work. A list of other people's work. Could be as simple as a URL with one sentence description. Be sure to explain how the proposed work is different from similar related work. + * Biographical Information. + * Summarize your education, work, and open source experience. + * List your skills and give evidence of your qualifications. + * List published papers, successful open source projects, etc. + * Please list any non-Summer-of-Code plans you have for the Summer, especially employment and class-taking. Be specific about schedules and time commitments. + +## General Notes + +Your proposal should be around 1500-4000 words in plain text and should clearly state what you intend to do and the necessary steps to get there. There is no limit on the number of submitted proposals, if you have several ideas, please submit several proposals. Do include URLs pointing to information that would help convince us of your chances of success: preliminary project plans or progress, other projects you've been involved with that were successful, code samples, etc. + +It is better if your project is under-scoped and sure to complete; as opposed to a largeish project which may not get done. + +One of the features of Google/X.Org Summer of Code is that it is a organization to help with projects involving integrating free software and hardware from different sources. + +See [[SummerOfCodeIdeas|SummerOfCodeIdeas]] for project ideas. diff --git a/GalliumStatus.mdwn b/GalliumStatus.mdwn new file mode 100644 index 00000000..55437f8e --- /dev/null +++ b/GalliumStatus.mdwn @@ -0,0 +1,67 @@ + + +## Current Status of Gallium3D Pipes and State Trackers + +This table lists the current combinations of state trackers and pipe drivers. + +Explanation: + +* d3d1x: Direct 3D 10/11 +* g3dvl: Generic GPU-Accelerated Video Decoding +* vega: OpenVG - The Standard for Vector Graphics Acceleration +* egl: Windowing system trackers similar to dri of EGL standard. +* wgl: Windowing system trackers similar to dri for MS Windows. +Unlisted drivers: + +* identity: This is a skeleton driver, used for passthrough and wrapping of pipes. +* nouveau: This is not actually a driver, but a set of routines common to all nv pipes. +* trace: This is a passthrough driver that traces Gallium library calls. +State tracker conformance tests: + +* mesa: tri, gears, piglit. tri and gears must render correctly and not crash; piglit must pass. +* vega: None. +* exa: rendercheck. This should be a goal for improving exa, drivers bound to exa, and rendercheck. +* g3dvl: None. +* dri: glxinfo. Must say that direct rendering is enabled. +* xorg: Xorg. X server must come up. Input drivers do not matter. +* egl: eglinfo, eglscreen, egltri. egltri must render correctly. +* wgl: None. +What do these mean? + +* "**DONE**" means that it is implemented and passes the state-tracker-specific conformance test. +* "**MOSTLY**" means that it is implemented but does not pass the conformance test. +* "**WIP**" means that the implementation is being worked on, but should not be considered ready for general testing. +* "**SLOW**" means that the feature is DONE, but not performant due to known deficiencies in the code. +* "**TODO**" means that the implementation is incomplete and nobody is working on it. +* "**UNKNOWN**" means that the current status of this item isn't known. +If you're the maintainer of any of this code, please update these when you can, especially UNKNOWN slots. +[[!table header="no" class="mointable" data=""" + | **mesa** | **vega** | **exa** | **g3dvl** | **d3d1x** | **opencl** | | **dri** | **xorg** | **egl** | **wgl** +i915 (Intel i915/i945) | DONE | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | TODO | | DONE | DEPRECATED | DONE | UNKNOWN +nv30 (nVidia NV30 and NV40) | WIP | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | N/A | | MOSTLY | DEPRECATED | DONE | UNKNOWN +nv50 (nVidia NV50/G80) | DONE | UNKNOWN | UNKNOWN | WIP<sup>1</sup> | WIP | WIP | | MOSTLY | DEPRECATED | DONE | UNKNOWN +nvc0 (nVidia NVC0/Fermi) | DONE | UNKNOWN | UNKNOWN | WIP | DONE | TODO | | MOSTLY | DEPRECATED | DONE | UNKNOWN +r300 (ATI R300/R400/R500) | DONE | WIP | WIP | WIP | UNKNOWN | TODO | | DONE | DEPRECATED | DONE | TODO +r600 (ATI R600/R700/R800/R900) | DONE | WIP | WIP | WIP | UNKNOWN | WIP | | DONE | DEPRECATED | DONE | TODO +radeonsi (AMD Southern Islands) | WIP | UNKNOWN | UNKNOWN | WIP | UNKNOWN | TODO | | WIP | DEPRECATED | WIP | UNKNOWN +softpipe | MOSTLY | MOSTLY | UNKNOWN | UNKNOWN | UNKNOWN | TODO | | DONE | DEPRECATED | DONE | DONE +svga (VMware Virtual GPU) | DONE | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | TODO | | MOSTLY | DEPRECATED | DONE | UNKNOWN +"""]] + + +### Notes + +1 - mpeg2 hardware (not shaders) decoding DONE + + +### Feature stacks that give equivalent functionality to the classic MESA implementation + + +[[!format txt """ +Gallium3D Classic MESA +--------------------------------- +xorg + exa DDX + Xv +dri + mesa GL + GLSL +dri DRI2 +KMS + Gallium3D DRM + DRI + DDX +"""]]
\ No newline at end of file diff --git a/GoingModular.mdwn b/GoingModular.mdwn new file mode 100644 index 00000000..4f45505f --- /dev/null +++ b/GoingModular.mdwn @@ -0,0 +1,58 @@ + + +## Going Modular + +This is an outline of a scheme for incrementally migrating the X.org tree from a monolithic build based on imake to a modular build based on automake, autoconf and libtool. The goal is to accurately reproduce the existing binaries as closely as possible. + + + +--- + + + + +### Goals + +The goal of this process is to produce separately distributable �packages� for various parts of the system, including (but not limited to) + + * Individual libraries + * Individual video drivers + * Collections of Applications + * The core X server binary +In my opinion, we should strive to break things up enough so that no distribution feels the need to break things up further. This limits the downstream impact for any given patch. I also believe we should permit either the X server or libraries to be built without requiring the other; this means that all shared include files must be packaged separately. + +With this in mind, I believe the correct order of execution is something like: + +1. Move include files. + 1. global includes move to new packages for each sub-system + 1. library-specific headers move into the library in such a way as to not require any additional work before the library itself can be built -- e.g. in Xlib, a subdirectory 'X11' must hold the various Xlib headers so that -I. will permit #include <X11/Xlib.h> to work. +1. Fix the 'make includes' pass to actually install the header files in $(DESTDIR)/... +1. Fix Imakefiles so that these new locations work everywhere. Yes, this is busy work given the goal of eliminating the Imakefiles shortly, but it means that we can still build the tree in the interim. +1. Autotool the global include packages. We can steal liberally from the debrix and xlibs projects here. +1. Autotool the libraries, starting at the bottom of the stack and moving upwards. As each is autotooled, the imake bits need to be changed to locate the library in the installed location ($(DESTDIR)/...) and that library should be removed from the imake system. +1. Select appropriate modularization boundaries for the various X applications, modularizing them on an as-needed basis. +1. Borrowing liberally from debrix, construct autotool packages for the X server headers. +1. Convert the server over to use the installed server headers +1. autotool the X server drivers. Can we do this first? +1. autotool the X server core. Do we do this first? +Lots of this is just speculation at this point. I think the key points are: + + * Use imake to transition to a modular system; make sure the unfinished parts remain buildable from the monolithic imake system. + * Leave Imakefiles around in each finished module. This should make 'xmkmf -a' work in a lot of cases. + * Ensure binary compatibility at each stage by checking the results against the monolithic build. I think the actual binaries will be slightly different as libtool will end up passing different options to ld than imake does. If we could avoid this difference, we could actually compare the modular vs monolithic builds of each piece rather easily. +I'd like to see comments and suggestions for change, and I expect as we follow through this process that we'll have to come back here and make changes, so treat this as a working document, not a finished plan. + +-- Main.[[KeithPackard|KeithPackard]] - 19 Oct 2004 + + +### Questions and Comments + +Here are a few questions/comments I have after reading this page: + + * What is the target version of autotools? 2.59 with shiny new features or 2.13 for backwards compatibility with older systems? + * Autoconf has the ability to configure sub-projects using AC_CONFIG_SUBDIRS. I've found it useful in the past to create a toplevel project that does nothing but configure all the subprojects with identical configure lines, using a shared config.cache file. + * Reading the above text, it sounds like the idea is to create autotools packages for header files, separate from the code that actually implements each library. Is that the plan, or am I mis-reading the text? + * For comparing the resulting binaries, I think the easiest way would be to clean up the output of 'objdump -t' for each object and make a note of added/missing symbols or of symbols which have changed size unexpectedly. + * It isn't stated explicitly above, but I assume the goal is to support separated build directories? It's probably worth stating upfront, since it's quite easy to miss a $(srcdir) somewhere in the Makefile.am which would break this functionality. + * Most projects seem to have local .m4 files for project-specific things. Would it make sense to have an X.org-wide M4 module so that all projects have the same supporting macros? +-- Main.[[RayLehtiniemi|RayLehtiniemi]] - 20 Dec 2004 diff --git a/GrabsProcessing.mdwn b/GrabsProcessing.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/GrabsProcessing.mdwn diff --git a/HaraldKoenig.mdwn b/HaraldKoenig.mdwn new file mode 100644 index 00000000..8cd587fd --- /dev/null +++ b/HaraldKoenig.mdwn @@ -0,0 +1,13 @@ + + +## Harald König + +Email: koenig AT linux DOT de + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/InputEventProcessing.mdwn b/InputEventProcessing.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/InputEventProcessing.mdwn diff --git a/Intel28Branch.mdwn b/Intel28Branch.mdwn new file mode 100644 index 00000000..e37a0994 --- /dev/null +++ b/Intel28Branch.mdwn @@ -0,0 +1,42 @@ + + +## Proposed patches + +Since xf86-video-intel 2.8.1 has been released, nominations here will be considered for future 2.8.x bugfix releases, if we do any. + +Below here, please list patches to nominate them for merging into the [[2.8 branch|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=2.8]]. The commits must already exist in the [[master branch|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/]], and have received review and testing there. + +Proposed for 2.8.x (once these are merged, move them down to the next list) + + * +--- + + + +* [[7c48c21b22bf5862c5a35bda1635753cc5a7197c|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7c48c21b22bf5862c5a35bda1635753cc5a7197c]] set correct value for indirect access check bound +* [[376397c21eb9a7e4ea79d349af41da81c1af861f|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=376397c21eb9a7e4ea79d349af41da81c1af861f]] Fix VGA plane disabling +* [[62494407e529cfa68529b7267155a12d75418f21|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=62494407e529cfa68529b7267155a12d75418f21]] Fix typo in bios_reader for invalid pointer cast +* [[6955fc7a74edf6034a292c31a304577c35e925e6|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6955fc7a74edf6034a292c31a304577c35e925e6]] Don't use fb offset when using shadow buffer +* [[2786a66719a6dbb735eb7c551c412475c30ffa51|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=2786a66719a6dbb735eb7c551c412475c30ffa51]] KMS: allocate one bo per crtc for cursor +* [[5fa8d04d9c86f343802c05bd3e11c6e733f01b63|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5fa8d04d9c86f343802c05bd3e11c6e733f01b63]] Reload cursors as needed when setting new modes. +Released in 2.8.1 + + * +--- + + + +* [[6f3fc6b20f3daedab02e31f49678d4d2ff0fa7a3|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6f3fc6b20f3daedab02e31f49678d4d2ff0fa7a3]] drmmode_output_get_modes: Replace existing EDID property blob with new one +* [[6b7728491c3b771bcba2c7ffd75330c0a0b37f44|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=6b7728491c3b771bcba2c7ffd75330c0a0b37f44]] Only align DRI2 tiled pixmaps to the DRI2 tiled pixmap alignment requirement +* [[af45482a52999b52bf41468c458808e30c100e35|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=af45482a52999b52bf41468c458808e30c100e35]] Calculate the DVO relative offset in LVDS data entry to get the DVO timing (fixes #22787 and Debian #538148) +* [[79b6851148574419389ac8055b0c31b8bdac3ab3|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=79b6851148574419389ac8055b0c31b8bdac3ab3]] Fix sampler indexes on i965 planar video. +* [[465a4ab416b2e5ad53b96702720331a44fffa2fe|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=465a4ab416b2e5ad53b96702720331a44fffa2fe]] Align the height of untiled pixmaps to 2 lines as well. +Released in 2.8.0.901 + + * +--- + + + + * [[8084f76d86f048ca5b82da089fffa9665dbbcdd5|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8084f76d86f048ca5b82da089fffa9665dbbcdd5]] Allow DRM mode setting to include transformations + * [[222b52ef16895823fbf3a0fc0be4eb23b930ed1b|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=222b52ef16895823fbf3a0fc0be4eb23b930ed1b]] Align tiled pixmap height so we don't address beyond the end of our buffers (also include [[e8f0763d405a8152c74c28792c52fe12c1d41dd5|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=e8f0763d405a8152c74c28792c52fe12c1d41dd5]] Fix math in the tiling alignment fix)
\ No newline at end of file diff --git a/Intel29Branch.mdwn b/Intel29Branch.mdwn new file mode 100644 index 00000000..dc90de8e --- /dev/null +++ b/Intel29Branch.mdwn @@ -0,0 +1,36 @@ + + +## Proposed patches + +Since xf86-video-intel 2.9.1 has been released, nominations here will be considered for future 2.9.x bugfix releases, if we do any. + +Below here, please list patches to nominate them for merging into the [[2.9 branch|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?h=2.9]]. The commits must already exist in the [[master branch|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/]], and have received review and testing there. + +For each fix, please provide a short description of the bug being fixed in terms that make sense to the user, (which I will put in the release notes). The commit message is rarely the right thing here, (since it will often refer to internals). Often the title of a bug report is exactly what's wanted, so if your commit message already includes a bugzilla URL then that's likely sufficient. + +As an example of what I'd like for the descriptions: + +What I don't want: Fix uninitialized pScrnPtr value. What I do want: Fix crash on X server start with multiple outputs. + +Proposed for 2.9.x (once these are merged, move them down to the next list) + +--- + + + +Merged for 2.9.x + +--- + + + +Released in 2.9.1 + +--- + + + +* [[8a77877f9c2c6a8a1308bc1a3be9e7ad88bc7f49|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8a77877f9c2c6a8a1308bc1a3be9e7ad88bc7f49]] drmmode: with 1.7 server, set mode major doesn't get gamma setup. (Fixes orruption and artifacts due to wrong colors in the colormap with X server 1.7.) +* [[7e8f32d0a7279dce1976f87612833d9092554cfe|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=7e8f32d0a7279dce1976f87612833d9092554cfe]] uxa: Free the [[ScratchPixmapHeader|ScratchPixmapHeader]] after its associated Picture (Fixes incorrect rendering, such as missing scrollbar arrows in some themes: [[http://bugs.freedesktop.org/show_bug.cgi?id=24459|http://bugs.freedesktop.org/show_bug.cgi?id=24459]]) +* [[fcc2ee48b866b81c79315ff10189b56fc201539d|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=fcc2ee48b866b81c79315ff10189b56fc201539d]] Drop frontbuffer from crtc in [[I830CloseScreen|I830CloseScreen]] (Fixes black screen when X server is reset: [[https://bugs.freedesktop.org/show_bug.cgi?id=24383|https://bugs.freedesktop.org/show_bug.cgi?id=24383]]) +* Revert [[02fe9be695f7e209944bd0f7b67950f93619feee|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=02fe9be695f7e209944bd0f7b67950f93619feee]] Check whether the DVI-I/D is connected or disconnected based on EDID (Fixes regressions detecting DVI monitors: [[http://bugs.freedesktop.org/show_bug.cgi?id=24458|http://bugs.freedesktop.org/show_bug.cgi?id=24458]] [[http://bugs.freedesktop.org/show_bug.cgi?id=24458|http://bugs.freedesktop.org/show_bug.cgi?id=24458]] [[http://bugs.freedesktop.org/show_bug.cgi?id=24458|http://bugs.freedesktop.org/show_bug.cgi?id=24458]])
\ No newline at end of file diff --git a/IntelGraphicsDriver.mdwn b/IntelGraphicsDriver.mdwn new file mode 100644 index 00000000..2448f871 --- /dev/null +++ b/IntelGraphicsDriver.mdwn @@ -0,0 +1,66 @@ + +The Intel graphics driver in X.Org intends to support all intel chipsets from the i810 and upwards. Please **note** that this driver does **not** support the [[GMA 500|http://en.wikipedia.org/wiki/Poulsbo_(chipset)]], found in various Atom-based designs. + +A listing of known laptop graphics chips can be found at [[IntelLaptopChips|IntelLaptopChips]]. + +Table may be out of date. For a better view of daily progress, please see the logs of the [[source code repositories|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/]]. You may possibly want to refer to [[wikipedia|http://en.wikipedia.org/wiki/Intel_GMA]] for the graphics core/chipset mapping. + +* "**DONE**" means that it is implemented and relatively bug-free. +* "**MOSTLY**" means that it is implemented but has some known bugs. +* "**WIP**" means that someone has started on the initial implementation. +* "**BIOS**" means only if supported by your BIOS. No software support. Yet. +* "**N/A**" means that the feature is not supported by the hardware. +* "**N/N**" means that the feature will not be implemented, because a better alternative is or will be available. +* "**TODO**" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #intel-gfx if you want to get your feet wet on this. +* "**UNKNOWN**" means that the current status of this item isn't known. You are free to update it if you know. [[!table header="no" class="mointable" data=""" +**2D features** || | **i810-i815** | **i830-i865G** | **915G-945G/G33** | **965G/G35** | **G4x** | **HD Graphics (Gen5)** | **HD Graphics - Sandy Bridge (Gen6)** +Mode Setting || | UMS | KMS | KMS | KMS | KMS | KMS | KMS +2D Acceleration || | XAA | UXA/SNA | UXA/SNA | UXA/SNA | UXA/SNA | UXA/SNA | UXA/SNA +DRI || | DRI1 | DRI2 | DRI2 | DRI2 | DRI2 | DRI2 | DRI2 +Xv || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +XvMC || | DONE | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN +VA-API (MPEG-2) || | N/A | N/A | UNKNOWN | UNKNOWN | DONE | DONE | DONE +VA-API (H.264) || | N/A | N/A | UNKNOWN | UNKNOWN | MOSTLY | MOSTLY | DONE +sync to vblank || | TODO | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN +**Mesa 3D features** || | **i810-i815** | **i830-i865G** | **915G-945G/G33** | **965G/G35** | **G4x** | **HD Graphics (Gen5)** | **HD Graphics - Sandy Bridge (Gen6)** +Primitives || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Textures || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Hardware TCL || | N/A | UNKNOWN | UNKNOWN | UNKNOWN | N/A | DONE | DONE +Shaders || | N/A | N/A | UNKNOWN | DONE | DONE | DONE | DONE +**Output** || | **i810-i815** | **i830-i865G** | **915G-945G/G33** | **965G/G35** | **G4x** | **HD Graphics (Gen5)** | **HD Graphics - Sandy Bridge (Gen6)** +Console restore || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Dual-link DVI || | BIOS | BIOS | BIOS | BIOS | UNKNOWN | UNKNOWN | UNKNOWN +Dual head ([[Randr 1.2|Randr12]]) || | UNKNOWN | UNKNOWN | DONE | DONE | DONE | DONE | DONE +FB Console || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +TVout || | BIOS | DONE | DONE | DONE | DONE | DONE | DONE +**Other** || | **i810-i815** | **i830-i865G** | **915G-945G/G33** | **965G/G35** | **G4x** | **HD Graphics (Gen5)** | **HD Graphics - Sandy Bridge (Gen6)** +DPMS || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +LVDS Downclocking || | DONE | DONE | DONE | DONE | DONE | DONE | DONE +[[Suspend/Restore|Suspend_support]] || | TODO | TODO | TODO | TODO | TODO | DONE | DONE +"""]] + +The latest release is [[Intel 2011Q3 graphics package|http://intellinuxgraphics.org/2011Q3.html]]. + +The Intel Linux Graphics Driver web portal: [[http://www.intellinuxgraphics.org|http://www.intellinuxgraphics.org/]]. + +The Intel graphics driver is currently maintained in the [[xf86-video-intel|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/]] git repository in X.Org. To check out the current code, use: + + +[[!format txt """ +git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel +"""]] +or + + +[[!format txt """ +cg clone git://git.freedesktop.org/git/xorg/driver/xf86-video-intel +"""]] +More instructions on using git to interact with the repository can be found at [[UsingGit|http://wiki.freedesktop.org/wiki/UsingGit]]. + +The Intel graphics driver and hardware has support for sDVO ADD2 DVI Cards, which you can learn about at [[SDVOADD2Cards|SDVOADD2Cards]]. + +* User guide for [[How to build driver from scratch|http://www.intellinuxgraphics.org/install.html]] +* User guide for [[How to setup dual head|http://www.intellinuxgraphics.org/dualhead.html]] +* User guide for [[How to report bugs|http://intellinuxgraphics.org/how_to_report_bug.html]] +* User guide for [[Reporting suspend-resume issues|http://intellinuxgraphics.org/suspend-resume.html]] +Please note that TV out support is usually provided by third-party encoder chips, which typically require separate drivers. Some of these drivers have not yet been written or included in the intel driver, thus while everything else may work fine, TV out may not be supported depending on the encoder chip paired with your graphics chip. diff --git a/IntelLaptopChips.mdwn b/IntelLaptopChips.mdwn new file mode 100644 index 00000000..6b319bf7 --- /dev/null +++ b/IntelLaptopChips.mdwn @@ -0,0 +1,30 @@ +[[!table header="no" class="mointable" data=""" + **Vendor** | **Model** | **Chipset** | **Notes** + Acer | Travelmate 660 | 855 + Acer | Travelmate 2300 | 855 + Acer | Travelmate 290d/e | 855 + Acer | Travelmate c300 | 855 + Asus | Z91N | 855 + Compaq | NX5000 | 855 + Dell | x200 | 830 + Dell | c400 | 830 + Dell | d400 | 855 + Dell | x300 | 852/855 + Dell | x1 | 915GM + Dell | Inspiron 1100 | 845G + Dell | Inspiron 2200 | 915GM + Fujitsu | [[LifeBook|LifeBook]] P7010 | 855 + HP | [[OmniBook|OmniBook]] XE3 | 830 + IBM | Thinkpad X30 | 830 + IBM | Thinkpad X40 | 852/855(GM) + IBM | Thinkpad R50 | 852/855 + IBM | Thinkpad R51 | 852/855 + Lenovo | x61s | GM965/GL960 + Lenovo | z61t | 945GM + Panasonic | Toughbook CF-W2 | 855 + Panasonic | Toughbook CF-Y4 | 915GMS + Samsung | x20 | 915GM + Sylvania | GNET2800SO | 845 + Toshiba | Satellite A55 | 855 + HP Compaq | 6720s | 965 +"""]] diff --git a/IntelVideoDriver.mdwn b/IntelVideoDriver.mdwn new file mode 100644 index 00000000..938e01d4 --- /dev/null +++ b/IntelVideoDriver.mdwn @@ -0,0 +1,7 @@ + +For more information on the X drivers for Intel graphics, (including full documentation for several devices), please see [[http://intellinuxgraphics.org/|http://intellinuxgraphics.org/]] + +Proposals for addition to stable releases: + + * [[Proposals for the 2.9 branch|Intel29Branch]] + * [[Proposals for the 2.8 branch|Intel28Branch]]
\ No newline at end of file diff --git a/JakobBornecrantz.mdwn b/JakobBornecrantz.mdwn new file mode 100644 index 00000000..88cc7934 --- /dev/null +++ b/JakobBornecrantz.mdwn @@ -0,0 +1,13 @@ + + +## Jakob Bornecrantz + +Email: wallbraker AT SPAMFREE gmail DOT com or jakob AT SPAMFREE vmware DOT com + +I work for VMware and mostly hack on Gallium3D plumbing, build system or the Xorg state tracker. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/JeremyHuddleston.mdwn b/JeremyHuddleston.mdwn new file mode 100644 index 00000000..597d84bd --- /dev/null +++ b/JeremyHuddleston.mdwn @@ -0,0 +1,13 @@ + + +## Jeremy Huddleston + +Email: jeremyhu AT SPAMFREE freedesktop DOT org + +[[http://xquartz.macosforge.org|http://xquartz.macosforge.org]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/JeromeGlisse.mdwn b/JeromeGlisse.mdwn new file mode 100644 index 00000000..42448c8e --- /dev/null +++ b/JeromeGlisse.mdwn @@ -0,0 +1,13 @@ + + +## Your Name + +Email: glisse AT SPAMFREE freedesktop DOT org + +Brain damaged hacker enjoying reverse engineering graphics card just for the joy of drawing a couple of pixels. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/JessVanDerwalker.mdwn b/JessVanDerwalker.mdwn new file mode 100644 index 00000000..9ea3fd6a --- /dev/null +++ b/JessVanDerwalker.mdwn @@ -0,0 +1,15 @@ + + +## Jess VanDerwalker + +EVoC participant currently working on xcwm - The X Composite Window Manager Library + +Email: washu AT SPAMFREE sonic DOT net or jvanderw AT SPAMFREE freedesktop DOT org + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/JhBuildInstructions.mdwn b/JhBuildInstructions.mdwn new file mode 100644 index 00000000..a43fb227 --- /dev/null +++ b/JhBuildInstructions.mdwn @@ -0,0 +1,118 @@ + + +# Building modular X.org with ''jhbuild'' + + +## Introduction + +This page provides brief instructions on using _[[jhbuild|http://live.gnome.org/Jhbuild]]_, a Python-based build tool, to build modular X.Org. jhbuild was written to build GNOME from source, but has been adapted to many other projects. + + +## Prerequisites + +* Ubuntu 9.10: + * jhbuild: `sudo apt-get install git-core gnome-common libglib2.0-dev docbook-xsl subversion automake1.4 automake1.7 automake1.9 automake1.10 guile-1.8 waf` + * Xorg: `sudo apt-get install groff zlib1g-dev libfreetype6-dev libxml2-dev docbook gperf flex bison libssl-dev` +* Debian 5.0 (lenny): + * jhbuild: `sudo apt-get install git-core gnome-common gnome-doc-utils make automake1.4 automake1.7 automake1.9 docbook-xsl cvs subversion guile-1.8` + * Xorg: `sudo apt-get install groff zlib1g-devlib freetype6-dev g++ bison flex` ... +* Fedora 12: + * jhbuild: `sudo yum install @gnome-devel @development-tools gnome-common glib2-devel gnome-doc-utils docbook-style-xsl waf` + * Xorg: `sudo yum install zlib-devel freetype-devel libxml2-devel expat-devel gperf libgcrypt-devel` +* Cygwin: + * jhbuild: Devel/git, GNOME/gnome-common, Devel/subversion + * Xorg: X11/libfreetype-devel, Devel/gperf ... +* FreeBSD 8.0: + * jhbuild: ports `devel/git`, `devel/gnome-common`, `devel/autoconf262`, `devel/automake14`, `devel/automake17`, `devel/automake18`, `devel/automake19`, `devel/automake110`, `devel/glib20`, `devel/subversion` (don't use Apache 2.0 APR!), `textproc/gnome-doc-utils` (select all options for docbook-1.4!), `textproc/intltool`, `lang/guile` + * Xorg: ports `print/freetype2` ... + +## Building jhbuild + + +[[!format txt """ +git clone git://git.gnome.org/jhbuild +cd jhbuild +./autogen.sh +make +make install +cp sample.jhbuildrc ~/.jhbuildrc +"""]] +(On FreeBSD, do `gmake && gmake install` .) + +* Note: You may get an error message `msgfmt isn't installed` - it's in the GNU gettext package +* Note: You may get a message saying you need to run `make -f Makefile.plain install` - All this omits is building the documentation, which is also at [[http://library.gnome.org/devel/jhbuild/|http://library.gnome.org/devel/jhbuild/]] +The `jhbuild` executable is installed to ~/.local/bin/jhbuild. You will need to either symlink to it, use the full path or add it to your `$PATH`. + + +## Module Set and jhbuild Config File + +The [[moduleset|http://cgit.freedesktop.org/xorg/util/modular/tree/xorg.modules]] for jhbuilding xorg and [[an example jhbuildrc|http://cgit.freedesktop.org/xorg/util/modular/tree/jhbuildrc]] are stored in git in the xorg/util/modular repository. + + +## Building the Server, and Everything It Depends On + +To build everything, you can do: + + +[[!format txt """ +mkdir -p $HOME/xorg/util +git clone git://anongit.freedesktop.org/git/xorg/util/modular/ $HOME/xorg/util/modular +jhbuild -f $HOME/xorg/util/modular/jhbuildrc +"""]] +But often you would just want to build the X server and key drivers to enable support of your latest shiny hardware, without replacing all of your X libraries and utilities. In this case, you can build specific targets rather than everything. + +You will need a minimal number of drivers as well as the server; rather than executing separate jhbuild commands, you can issue a single one listing all the targets you want to build. The input drivers for PS/2 keyboards and mice are: _xf86-input-keyboard _and_ xf86-input-mouse_. + +To build the server and dependencies, along with these drivers, you would type: + + +[[!format txt """ +jhbuild -f $HOME/xorg/util/modular/jhbuildrc build xserver xf86-video-intel xf86-input-keyboard xf86-input-mouse +"""]] +Other interesting targets include _xorg-drivers_ which builds all maintained X.org drivers. + +Note: rather than building the target xorg-fonts, which will build you an entire additional set of fonts, you may want to make a link in your _$prefix_ area to link to your existing fonts. Unless you have built your X server with `--enable-builtin-fonts `it will need to access some fonts to start, even though few applications need legacy bitmap fonts anymore. + + +[[!format txt """ +cd $prefix/lib/X11; ln -s /usr/share/fonts/X11 fonts +"""]] +Other drivers you may need include the synaptics driver and/or wacom drivers, currently maintained elsewhere (fixme...). + + +## DRM and Kernel Modules + +The X server is finally using a device driver on many systems (e.g. Linux, BSD); this is called DRM. It consists of two parts, the generic DRM module and a driver specific to your hardware. Currently, the kernel modules are not built automatically by jhbuild; you can find them in _drm/linux-core_ or _drm/bsd-core_. To build the drm driver, +[[!format txt """ +make -C linux-core +"""]] +You may want to install these where you will be able to use them from your _/etc/modules_ file. + + +## Building Other Modules + +Other buildable modules include the applications (e.g. `xbiff`) and the libraries (e.g. `libXfixes`), plus there a couple of meta modules; `xorg-libs` will build all libs and `xorg-apps` will build all apps. + + +## Running The Results + +Now that your development environment is set up, you can try running it (as root). +[[!format txt """ +rmmod i915 # assuming you're using Intel +rmmod drm +insmod <path_to_drm_tree_above>/linux-core/drm.ko +insmod <path_to_drm_tree_above>/linux-core/i915.ko +export LD_LIBRARY_PATH=$prefix/lib +startx -- $prefix/bin/Xorg -verbose # make sure you have a ~/.xinitrc with what you want to run +"""]] +And there you have it, a fresh stack ready for tracking & doing upstream development. Enjoy! + +This page and the modules file for the build were originally written by Kristian Høgsberg, and modified by [[EricAnholt|EricAnholt]]. Wikified by [[JimGettys|JimGettys]]. + + +## Hiccups + +* libGL runs "make" straight after the git pull ([[bug 26337|https://bugs.freedesktop.org/show_bug.cgi?id=26337]]). Workaround: shell out, run <del>`./autogen.sh --prefix=$HOME/xorg-build`</del> , exit shell and try again. +* Some drivers don't or shouldn't build (_e.g._ [[geode on 64-bit|https://bugs.freedesktop.org/show_bug.cgi?id=26341]], [[impact not on MIPS|https://bugs.freedesktop.org/show_bug.cgi?id=26342]], [[sunbw2|https://bugs.freedesktop.org/show_bug.cgi?id=26343]]). Abandon module, file bug if you can work out what's wrong. + * There's no facility in jhbuild to mark these modules as only appropriate to some targets, so to permanently avoid building these modules, add the module to the **skip** configuration variable in your jhbuildrc configuration file. e.g. skip = [ 'xf86-video-impact', 'xf86-video-sunbw2' ] +* nouveau won't build unless you already have libdrm_nouveau built. One way to do so is setting temporarily autogenargs = '--enable-nouveau-experimental-api' in jhbuildrc, and use the `buildone libdrm` jhbuild command.
\ No newline at end of file diff --git a/JoeKrahn.mdwn b/JoeKrahn.mdwn new file mode 100644 index 00000000..f8ed397b --- /dev/null +++ b/JoeKrahn.mdwn @@ -0,0 +1,13 @@ + + +## Joe Krahn + +Email: Joseph.Krahn AT SPAMFREE gmail DOT com + +Nothing here but an email link for now. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/JohnChee.mdwn b/JohnChee.mdwn new file mode 100644 index 00000000..a77a5ce6 --- /dev/null +++ b/JohnChee.mdwn @@ -0,0 +1,13 @@ + + +## John Chee + +Email: chee AT SPAMFREE cs DOT pdx DOT edu + +[[http://web.cecs.pdx.edu/~chee/|http://web.cecs.pdx.edu/~chee/]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/KnowledgeBase.mdwn b/KnowledgeBase.mdwn new file mode 100644 index 00000000..f518e3e3 --- /dev/null +++ b/KnowledgeBase.mdwn @@ -0,0 +1,6 @@ + + +# Video Drivers + + * [[Projects/Drivers|Projects/Drivers]] lists the currently supported video drivers and provides useful links +-- Main.[[EgbertEich|EgbertEich]] - 15 Apr 2004 diff --git a/KristianHoegsberg.mdwn b/KristianHoegsberg.mdwn new file mode 100644 index 00000000..3d662866 --- /dev/null +++ b/KristianHoegsberg.mdwn @@ -0,0 +1,15 @@ + + +## Kristian Høgsberg + +In the future we'll have wikis that allow UTF-8 in page names. + +Email: [[krh@bitplanet.net|mailto:krh@bitplanet.net]] + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/KristianHøgsberg.mdwn b/KristianHøgsberg.mdwn new file mode 100644 index 00000000..0f9131b5 --- /dev/null +++ b/KristianHøgsberg.mdwn @@ -0,0 +1,17 @@ + + +## Kristian Høgsberg + +Blog: hoegsberg.blogspot.com + +Email: [[krh@bitplanet.net|mailto:krh@bitplanet.net]] + +... + + + +--- + + + +* [[CategoryHomepage|CategoryHomepage]]
\ No newline at end of file diff --git a/LarryLehman.mdwn b/LarryLehman.mdwn new file mode 100644 index 00000000..17e4371b --- /dev/null +++ b/LarryLehman.mdwn @@ -0,0 +1,13 @@ + + +## Larry Lehman + +Email: larry.lehman AT SPAMFREE windriver DOT com + +Larry Lehman is a Principal Technologist at Wind River Systems in Sunnyvale, California. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/LarsDɪᴇᴄᴋᴏᴡ.mdwn b/LarsDɪᴇᴄᴋᴏᴡ.mdwn new file mode 100644 index 00000000..298106d0 --- /dev/null +++ b/LarsDɪᴇᴄᴋᴏᴡ.mdwn @@ -0,0 +1,10 @@ + +[[https://metalab.at/wiki/user:daxim|https://metalab.at/wiki/user:daxim]] + +[[Events/XDC2012|Events/XDC2012]]: TBA + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/LinuxTag2005Infos.mdwn b/LinuxTag2005Infos.mdwn new file mode 100644 index 00000000..8250f694 --- /dev/null +++ b/LinuxTag2005Infos.mdwn @@ -0,0 +1,32 @@ + + +# Useful Information for our LinuxTag meeting + + +## Travel: + + * Travel information [[in German|http://www.linuxtag.org/typo3site/travel.html?&L=0]] [[in English|http://www.linuxtag.org/typo3site/travel.html?&L=1]] + +## Karlsruhe City Map + +* [[City Map|http://geodaten.karlsruhe.de/stadtplan/]] + [[Map|http://hydra.linuxtag.uni-kl.de/~joey/ka-shopping/]] of the area around the LinuxTag location with useful infos on shopping and eating places. + [[Area Map|http://www.infodrom.org/Debian/events/LinuxTag2002/lageplan.html]] and [[version for printing|http://hydra.hq.linuxtag.net/~joey/LT2005/akk.ps]]. + +## Karlsruhe City Info + + * City Information [[in German|http://www.linuxtag.org/typo3site/cityinfo.html?&L=0]] [[in English|http://www.linuxtag.org/typo3site/cityinfo.html?&L=1]] + +## Information on Public Transportation + + * [[local transportation|http://www.efa-bw.de/nvbw/en_index.htm]] + * [[Railroad|http://reiseauskunft.bahn.de/bin/query.exe/en?to=76137/Karlsruhe,%20Kongresszentrum]] + * Infos on flights etc. [[in German|http://www.linuxtag.org/typo3site/travel.html?&L=0]] [[in English|http://www.linuxtag.org/typo3site/travel.html?&L=1]] + +## Accommodations + + * The Karlsruhe LUG is providing limited free space at AKK to stay over night. Please visit [[their web page|http://www.akk.org/]] for further information. This space is only available during the show, not for the X developers meeting. However there are other inexpensive alternatives: + * [[youth hostel|http://www.jugendherberge-karlsruhe.de/]] (booked out for the show) + * very inexpensive: [[ETAP hotel Karlsruhe-Ost.|http://www.etaphotel.com/etaphotel/fichehotel/gb/etp/3179/fiche_hotel.shtml]] (Booked out for the show.) + * Official [[LinuxTag|LinuxTag]] hotel is the Novotel Dorint Karlsruhe Kongress Reservations can be made either thru the LinuxTag reservation page [[in German|http://www.linuxtag.org/typo3site/hotels.html?&L=0]] [[in English|http://www.linuxtag.org/typo3site/hotels.html?&L=1]] or [[directly|http://www.accorhotels.com/accorhotels/fichehotel/de/nov/5400/fiche_hotel.shtml]]. The weekend are usually lower however one will have to expect to pay special rates during the show. + * The Tourist Information has a [[web site|http://www.karlsruhe.de/Tourismus/ukv/]] for online search/registration
\ No newline at end of file diff --git a/LinuxTagMeeting2005.mdwn b/LinuxTagMeeting2005.mdwn new file mode 100644 index 00000000..9c85c0b8 --- /dev/null +++ b/LinuxTagMeeting2005.mdwn @@ -0,0 +1,102 @@ + + +# The European X.Org Developers Meeting + +* Time: Sunday June 19th and Monday June 20th 2005 +* Place: **[[LinuxTag|http://linuxtag.org]]** in Karlsruhe, Germany. +The X.Org Foundation is planning its first European Developers Meeting right before **[[LinuxTag|http://linuxtag.org]]** in Karlsruhe, Germany ** on Sunday June 19th and Monday June 20th**. + +The **purpose** of the conference is to bootstrap a European developers community. + +We expect to have 5-6 **talks** a day, 3 in the morning and 3 in the afternoon. This gives plenty of time to add additional presentations and discussions as well as extensive hacking. + +The **conference language** is English. + + +## Call For Papers + +There are still slots open for presentations so if you are interested in giving a talk please send us the title and a brief abstract to our [[contact address|LinuxTagMeeting2005]]. + +Presentations will be accepted until the first day of the conference, however we encourage you to contact us early as interest is great. + + +## Schedule + +Please check our preliminary [[LinuxTagMeeting2005Schedule|LinuxTagMeeting2005Schedule]]. + + +## Fees + +The conference will have **free entrance**, participants will have to pay travel and accommodation. + +Some **funding** is available to X.Org to sponsor travel and accommodation for people who are unable to take care of these expenses themselves. People applying for this should be prepared to give a talk. When submitting your abstract please indicate if you require funding. + +We are still working on getting free admission to the LinuxTag show for all those who participate in the conference - at least those who give a presentation. + +We've got a number of tickets that we will distribute among those participants who don't have other ways of getting into the show (for example as exhibitors) if they have [[registered|LinuxTagMeeting2005]] with us and indicated their need for a ticket. As the number of ticktets is limited please only get one if you really plan to go to the show. + +X.Org will organize a social event for all those who participate in the meeting. (Don't confuse this with the [[LinuxTag social event|http://www.linuxtag.org/typo3site/socialevent.0.html?L=1]]!) Admission is free for those who are giving a presentation on the meeting. Please see [[below|LinuxTagMeeting2005]] for further information. + + +## Location + +The meeting will take palce in room **S1** in the **upper level** of the **Konzerthaus**. Please check the [[area map|http://www.infodrom.org/Debian/events/LinuxTag2002/lageplan.html]] for the exact location. You can find links to further maps and information in our [[LinuxTag2005Infos|LinuxTag2005Infos]]. + + +_Please NOTE:_ The location of the room may still change, therefore make sure to check this page for updated information. + There is a [[list of participants|LinuxTagMeeting2005Participants]]. + + +# X.Org on LinuxTag + +X.Org is also going to have booth on [[LinuxTag|http://linuxtag.org]] from Wednesday, June 22, to Saturday, June 25. + +This booth is ment to be a gathering place where developers can meet and talk. At the same time people will be available on the booth to give demonstrations and to talk to the public. + + +## Presentations + +We are still looking for people who would like to give an X Window System related presentation on the show. Please indicate if you are willing to do so and what you would like to present. + +Tuesday, June 21 is planned for booth setup for all those who would like to give a presentation. + We expect that not all presentations can run simultaneously so once we get a rough idea of what you have planned to demo we will make up a schedule. + You should be prepared to bring your own equipment for your demo (ie. Laptop etc.), monitors or flat screens should be available on the booth, also there will be connectivity on the booth. If you need other special equipment that you won't be able to bring along we will do our best to provide it. Please indicate with your registration if you have special needs. + +If you have a **logo and/or a poster** in your demo please send us a PostScript file. We will try to print it and put it on display on the booth. + + +## Social Event + +<a name="social_event"></a> Everybody deserves a break! + +There will be a social event (not to be confused with the [[LinuxTag social event|http://www.linuxtag.org/typo3site/socialevent.0.html?L=1]]) for the people attending our meeting or participating in the booth activities to get together, eat, drink and talk. It will take place during LinuxTag right after the show. + +We don't know the exact location and date, yet. This information will be given when available + +The **costs** will be around EUR 20, for all those who give a presentation on our meeting or on the booth, or otherwise help with our booth activities admission will be free. If you are interested in coming - please let us know! + + +## Booth Helpers + +We are looking for volunteers to help out with booth duty. If you are interested please let us know. You will receive a free X.Org LinuxTag T-shirt as a little thank you. + + +## Further Information + +Please check the [[LinuxTag2005Infos|LinuxTag2005Infos]] for useful information concerning travel and accomodiations. + + +## Documentation + +Please send us your ideas and notes from the conference. As for pictures - please upload them to you website and send us its address. Thankyou! + + +## Organizers + +* The X.Org Foundation +* Leon Shiman +* Egbert Eich + +## Contacts + +<a name="contact"></a> Please feel free to contact the organizers at [[linuxtag-org_AT_lists_x_DOT_org|mailto://<linuxtag-org_AT_lists_x_DOT_org>]] if you have further questions. diff --git a/LinuxTagMeeting2005Daniel.mdwn b/LinuxTagMeeting2005Daniel.mdwn new file mode 100644 index 00000000..2f2db9fe --- /dev/null +++ b/LinuxTagMeeting2005Daniel.mdwn @@ -0,0 +1,7 @@ + + +# Modularisation (m12n) + +Daniel Stone + +In this talk, I will give an overview of the modular architecture as it stands, and the tools and methods we'll need to get there. I'll also try to cover the current release status and what we need to achieve to get to a workable [[X11R7|X11R7]] in a decent timeframe. diff --git a/LinuxTagMeeting2005DavidR.mdwn b/LinuxTagMeeting2005DavidR.mdwn new file mode 100644 index 00000000..3d595a9d --- /dev/null +++ b/LinuxTagMeeting2005DavidR.mdwn @@ -0,0 +1,9 @@ + + +# Xgl + +David Reveman + +Xgl is an modern X server architecture layered on top of OpenGL. Xgl can take advantage of the latest in graphics hardware and provides an efficient and seamless integration of GLX. + +This talk will give an introduction to the design of Xgl and a brief history of the work that led to the current implementation of Xgl. It will present an overview of the current state of Xgl, near-term plans for 2005 and a long-term vision for how Xgl will take the X window system into the next generation of desktop graphics. diff --git a/LinuxTagMeeting2005GianFilippo.mdwn b/LinuxTagMeeting2005GianFilippo.mdwn new file mode 100644 index 00000000..1daaa171 --- /dev/null +++ b/LinuxTagMeeting2005GianFilippo.mdwn @@ -0,0 +1,7 @@ + + +# NoMachine NX + +Gian Filippo Pinzari + +NoMachine NX is a fast terminal server system based on the X11 protocol. In addition, NX also translates and embeds the MS Windows Terminal Server and VNC protocols into X/NX, enabling users to compress and accelerate remote Windows and VNC sessions on links as narrow as 10 kBit/sec. NoMachine provides to the OSS community a suite of libraries and X11 proxying agents under the GPL license, used, for example, by the FreeNX project to implement a fully GPLed NX system. The workshop will start with a demonstration of the NX capabilities and will later offer an introduction to the technical problems and the solutions that the NX developers have implemented to offer advanced functions like persistence of sessions, display migration, streaming of images, lazy encoding and, in a general extent, effective use of the X11 protocol over the Internet. diff --git a/LinuxTagMeeting2005Gunnar.mdwn b/LinuxTagMeeting2005Gunnar.mdwn new file mode 100644 index 00000000..4f162fd5 --- /dev/null +++ b/LinuxTagMeeting2005Gunnar.mdwn @@ -0,0 +1,10 @@ + +[[RenamePage|RenamePage]] +# Magnification with X.Org 6.8: + + +## What is possible and where do you need to extend the X Server + +Gunnar Schmidt + +This talk will show how the technologies of the X server can be used for writing a decent screen magnifier. It will explore the potentials of the current X server and it will explain where the X server needs to be extended in order to write a full-featured screen-magnifier. diff --git a/LinuxTagMeeting2005KaiUwe.mdwn b/LinuxTagMeeting2005KaiUwe.mdwn new file mode 100644 index 00000000..252d3edf --- /dev/null +++ b/LinuxTagMeeting2005KaiUwe.mdwn @@ -0,0 +1,9 @@ + + +# X and colour management + +Kai-Uwe Behrmann + +On several examples I will show where the currently assumed sRGB monitor space will fail [WWW, hardware technologie, art/printing]. Why did the build in possibilities in X not suffice in the past? The edges to have a consistent and versatile desktop are explained from a colour management point of view. + +If it is enough time, an proposal for an CMS architecture can follow as well as a demo about current speed and other details. (A colour managed workplace can been seen on the OfficeProductivity booth during LinuxTag - CinePaint) diff --git a/LinuxTagMeeting2005Lars.mdwn b/LinuxTagMeeting2005Lars.mdwn new file mode 100644 index 00000000..ee2abf83 --- /dev/null +++ b/LinuxTagMeeting2005Lars.mdwn @@ -0,0 +1,9 @@ + + +# Improving and Extending Render + +Lars Knoll + +The X11 Render extension has been around for a few years and has proven to be the way to bring new graphic features to X11. Render has a history for being extended with new features from time to time. + +From a toolkit developers perspective Render still misses some features. This talk will show some work that has been done to add them, and present some of the ideas for future work. diff --git a/LinuxTagMeeting2005Luc.mdwn b/LinuxTagMeeting2005Luc.mdwn new file mode 100644 index 00000000..3e38376b --- /dev/null +++ b/LinuxTagMeeting2005Luc.mdwn @@ -0,0 +1,7 @@ + + +# What needs to happen in the DDX? + +Luc Verhaegen + +The current DDX model does not support modern graphics cards well. This talk will present what needs to happen in the DDX for mode setting and output wise; making drivers VBE independent and keeping them like that, making output devices like TV/LVDS/TMDS encoders modular and shared between drivers. Furthermore current efforts are presented. diff --git a/LinuxTagMeeting2005Matthias.mdwn b/LinuxTagMeeting2005Matthias.mdwn new file mode 100644 index 00000000..ff0305c0 --- /dev/null +++ b/LinuxTagMeeting2005Matthias.mdwn @@ -0,0 +1,9 @@ + + +# XVideo in Xgl + +Matthias Hopf + +One drawback of using OpenGL instead of XAA/KAA is the lack of Y![[CrCb|CrCb]] based surface formats which are typically used for video. + +This talk will show how the programmable fragment pipeline of modern graphics cards can be used for color space conversion and scaling, and how this is being integrated into glitz and the new XVideo extension of Xglx. diff --git a/LinuxTagMeeting2005Participants.mdwn b/LinuxTagMeeting2005Participants.mdwn new file mode 100644 index 00000000..114032e6 --- /dev/null +++ b/LinuxTagMeeting2005Participants.mdwn @@ -0,0 +1,25 @@ + + +# List of Participants + +Gian Filippo Pinzari + Matthias Hopf + David Reveman + Gunnar Schmidt + Luc Verhaegen + Zack Rusin + Kai-Uwe Behrmann + Alan Hourihane + Keith Packard + Leon Shiman + Daniel Stone + Egbert Eich + Harald Koenig + Dirk Mueller + Marc Lehmann + Amir Bukhari + Lars Knoll + Matthieu Herrb + Waldo Bastian + Nicolai Hähnle + Roland Mainz diff --git a/LinuxTagMeeting2005Schedule.mdwn b/LinuxTagMeeting2005Schedule.mdwn new file mode 100644 index 00000000..eac1a63d --- /dev/null +++ b/LinuxTagMeeting2005Schedule.mdwn @@ -0,0 +1,39 @@ + + +# Meeting Schedule + + +## Sunday (June 19, 2005) + +15:00 + + * Leon Shiman: The X.Org Foundation - an Overview + Luc Verhaegen: [[What needs to happen in the DDX?|LinuxTagMeeting2005Luc]] + Egbert Eich: Migrating to a new driver model. [[slides|LinuxTagMeeting2005EgbertEich.pdf]] + Alan Hourihane: ACPI, how it works and what we need to do. + Leon Shiman: Managing media with X + +18:00 + + +## Monday (June 20, 2005) + +9:30 + + * Gunnar Schmidt: [[Magnification with X.Org 6.8|LinuxTagMeeting2005Gunnar]]. + Daniel Stone: [[The Modularisation Project|LinuxTagMeeting2005Daniel]] [[Slides (HTML)|http://people.freedesktop.org/~daniels/exdctalk]]. + Kai Uwe Behrmann: [[X and colour management|LinuxTagMeeting2005KaiUwe]]. + +12:30 + + * Lunch +14:00 + + * Keith Packard: What's new about Cairo?. + Zack Rusin: [[A redesign of the acceleration architecture|LinuxTagMeeting2005Zack]]. + Lars Knoll: [[Improving and extending Render|LinuxTagMeeting2005Lars]]. + David Reveman: [[Xgl|LinuxTagMeeting2005DavidR]]. + Matthias Hopf: [[Xvideo auf Xgl|LinuxTagMeeting2005Matthias]]. + Gian Filippo Pinzari: [[NoMachine NX|LinuxTagMeeting2005GianFilippo]]. + +19:00 diff --git a/LinuxTagMeeting2005Schedule/LinuxTagMeeting2005EgbertEich.pdf b/LinuxTagMeeting2005Schedule/LinuxTagMeeting2005EgbertEich.pdf Binary files differnew file mode 100644 index 00000000..dffd8d69 --- /dev/null +++ b/LinuxTagMeeting2005Schedule/LinuxTagMeeting2005EgbertEich.pdf diff --git a/LinuxTagMeeting2005Zack.mdwn b/LinuxTagMeeting2005Zack.mdwn new file mode 100644 index 00000000..9d45375c --- /dev/null +++ b/LinuxTagMeeting2005Zack.mdwn @@ -0,0 +1,7 @@ + + +# Acceleration Architecture + +Zack Rusin + +The currently used acceleration architecture in Xorg (XAA) is unsuitable for modern desktop usage. As a result of heavily using the card's 2D engine to accelerate mostly rarely used operations (like patterned fills and Bresenham lines) it invalidates any backing store you might have on a region. Furthermore accelerating the Render extension using XAA is rather complicated and severely limited by its memory manager. In this talk I'd like to describe the problems and solutions used in the new acceleration architecture designed for X.org that has been based on KAA. The goal of the talk is to give X.Org developers full overview of the new architecture. diff --git a/LookingGlassIntegration.mdwn b/LookingGlassIntegration.mdwn new file mode 100644 index 00000000..7dacf732 --- /dev/null +++ b/LookingGlassIntegration.mdwn @@ -0,0 +1,19 @@ + + +# LookingGlass Integration + +This page describes the effort to migrate the some changes for Looking Glass into the Xserver for a future X.Org release. Note: This is not an effort to migrate all of the Looking Glass technology into the X.Org source tree - only those infrastructural pieces needed by the Xserver to operate with the other Looking Glass components. + + +## What is Project Looking Glass? + +Project Looking Glass is a Java-based 3D desktop. You can learn more about the overall technology by reading the [[Overview|http://www.freedesktop.org/~pma/doc/J1-TS1586-final.pdf]]. + + +## More information + +Additional information about Looking Glass and the proposed changes to the X.Org tree are available at the links below: + + * [[The Looking Glass Event Pipeline|http://www.freedesktop.org/~pma/doc/lg_event_trip.pdf]] + * [[Proposed Modifications|http://www.freedesktop.org/~pma/doc/lg_xorg_mods.pdf]] + * [[Looking Glass Extension Protocol Specification|http://www.freedesktop.org/~pma/doc/lge_protocol.pdf]]
\ No newline at end of file diff --git a/LucVerhaegen.mdwn b/LucVerhaegen.mdwn new file mode 100644 index 00000000..44ff7618 --- /dev/null +++ b/LucVerhaegen.mdwn @@ -0,0 +1,13 @@ + + +## Luc Verhaegen + +Email: libv AT SPAMFREE freedesktop DOT org + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MakingReleases.mdwn b/MakingReleases.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/MakingReleases.mdwn diff --git a/MarcBalmer.mdwn b/MarcBalmer.mdwn new file mode 100644 index 00000000..264661ff --- /dev/null +++ b/MarcBalmer.mdwn @@ -0,0 +1,21 @@ + + +## Marc Balmer + +Entrepreneur and owner of Micro Systems, a consulting, development and outsourcing company for 18 years in Basel, Switzerland ([[http://www.msys.ch/|http://www.msys.ch/]]). + +OpenBSD developer, mostly working on time related stuff (Time Signal Station Receivers, GPS), and maintaining ports like OpenLDAP, [[OpenMotif|OpenMotif]], PostgreSQL etc. + +Licensed radio amateur (HB9SSB), paraglider- and glider-pilot, motorbike rider and adventuror (Land Rover enthusiast). Former lecturor and member of the board of the department [[HyperWerk|HyperWerk]] of the Basel University of Applied Sciences. + +Organizer and chairman of the 2005 European BSD Developers Conference at the University of Basel, Switzerland and organizer and chairman of the 2007 OpenBSD Developers Conference OpenCON in Venice, Italy. + +Project administrator / general contact for X.Org Google Summer of Code 2008 projects + +Email: marc AT SPAMFREE msys DOT ch + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MartinPeres.mdwn b/MartinPeres.mdwn new file mode 100644 index 00000000..fe906f86 --- /dev/null +++ b/MartinPeres.mdwn @@ -0,0 +1,23 @@ + + +## Martin Peres + +Email: martin.peres AT SPAMFREE ensi-bourges DOT fr Nickname: mupuf + +Martin Peres is PhD student at LaBRI. His thesis topic is on Power consumption and security in wireless networks. Martin was an engineering student at the 'ENSI de Bourges' where he studied and researched on computer security. + +Martin has been interested in programmation since the age of 12. He as first work on several game projects but moved to more low-level stuffs. He is the creator of PPassKeeper([[http://ppasskeeper.mupuf.org|http://ppasskeeper.mupuf.org]]), a library meant to abstract password storing. + +His interest upon X.org because of the lack of support of my ATI XPress 200M card. He then followed the development of the radeon driver and have been an happy tester on the xpress 200M and, more recently, on my AMD HD4770. He also happen to have caught interest in the nouveau project when he was given a laptop with an nvidia graphic card by his school. His involvement in X.org has got stronger when he was proposed to help in nouveau's development. + +At the moment, Martin is working on power management for nouveau. + +His real homepage with CV & portfolio: [[http://mupuf.org/contact/mupuf|http://mupuf.org/contact/mupuf]] + +His research page is located at : [[http://phd.mupuf.org|http://phd.mupuf.org]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MattDew.mdwn b/MattDew.mdwn new file mode 100644 index 00000000..1a24f0cd --- /dev/null +++ b/MattDew.mdwn @@ -0,0 +1,64 @@ +[[!table header="no" class="mointable" data=""" +**TODO**|| +Item | Status +Enable crosslinking | done +Enable profiling | no-profiling for now. +Adding crosslinks in documents | done +Master databases for website target | done +Pretty up xorg.css | done +Pretty up xorg.xsl | done +Hyphenation warning during build | Figured out. Uses jarfile but need to look more into .jar file licensing +Conversion of .gif to .svg | ? +New Index page | 20% +Initial Docbook conversion | done +Linking to doxygen | not started +Set colwidth in tables to .0 (floating point)' | 80% +Either change fonts in xorg.xsl or figure out which fonts are needed. | not started +Table warnings on <literallayout> during build | not started +epub generation (with dbtoepub) | not started +Catch up with [[http://tronche.com/gui/x/|http://tronche.com/gui/x/]] in regards to niceness of webpages. | not started +change <literallayout class='monospaced'> to <informaltable> with tgroups | not started +change <function>...</function> to <emphasis role='bold'>...</emphasis> for bolding | not started +use <simplelist type='vert' columns='N'><member> where appropriate (see x11proto/sect1-9.xml for example) | not started +Key Action's table in xkbproto, bulleted items offset. (~pg 24) | not started +gifs in xkbproto, scaled wrong | not started +"""]] + +Link collection: + + * [[http://www.youtube.com/watch?NR=1&v=j4REAaY2_-c|http://www.youtube.com/watch?NR=1&v=j4REAaY2_-c]] [[http://en.wikibooks.org/wiki/Guide_to_X11|http://en.wikibooks.org/wiki/Guide_to_X11]] +--- Not so frequently asked questions: + +1) How to play a sound on xterm event (using xkbevd): + + * A) [[http://ubuntuforums.org/showthread.php?t=1632133|http://ubuntuforums.org/showthread.php?t=1632133]] +2) Prevent pointer from going outside screens in a multiscreen environment. + + * A) [[https://bugs.freedesktop.org/show_bug.cgi?id=32731|https://bugs.freedesktop.org/show_bug.cgi?id=32731]] +3) XEvIE = Event Interception Extension, EVI = Extended Visual Information EVIE != EVI + +'ssh -X' vs 'ssh -Y' [12:46] <marcoz> general question. any real different between ssh -X and ssh -Y, '-Y' is for trusted connections but what does that actually mean? [12:47] <drago01> -X limits what you can do [12:47] <drago01> for security reason [12:47] <drago01> (to block key loggers etc) [12:47] <pharris> marcoz: -X uses the XSECURITY extension to create an "untrusted" magic cookie. Clients that connect via -X can't do certain things (eg. [[GetImage|GetImage]] from the root window) [12:47] == gustavold [gustavold@nat/ibm/x-bdcunkwjseyyztxg] has quit [Ping timeout: 245 seconds] [12:47] <drago01> while -Y is pretty much like a local connection [12:49] == jg_ [~[[jg@135.245.8.6|mailto:jg@135.245.8.6]]] has quit [Read error: Connection reset by peer] [12:49] <marcoz> ok, so default should be -X and not -Y then. [12:50] <marcoz> do you regularly use them? just curious if in practice you normally have trouble with -X where -Y works or vice versay [12:51] <ajax> -X breaks many things if you're running a server that actually supports the security extension. [12:51] <pharris> -X is a good default, but there are a few corner cases where -X doesn't work. eg. running an Xephyr with no other clients, SSH connects, creates a new magic cookie, disconnects, the server resets and forgets the cookie, the x client connects and the server rejects it. [12:51] <ajax> gtk mostly gets it right but i don't think xaw or motif do [12:52] <ajax> also the additional "security" created by -X is pretty much illusory anyway [12:52] <pharris> Also, the obvious things that -X intentionally prevents. It prevents screen captures, so you can't (usefully) run a screen capture over it. [12:52] <ajax> the attack it prevents is people being able to override file MAC on the remote machine, but if your attacker can do _that_ they can just replace the binary you think you're running. [12:53] <ajax> so any interaction you're having with the forwarded app is already suspect [13:30] <jturney> -X also breaks things if you don't have the security extension now, as since OpenSSH 5.6 it enforces [[ForwardX11Timeout|ForwardX11Timeout]] even when falling back to a trusted connection... + +EVoC/GSoC email to students to drum up interest: Work in progress. + +--- + + + + * My name is Matt Dew and I work on the X.org project. X.org[1] is the X windowing system for Linux, BSD, UNIX. If you run a GUI on linux or one of the BSDs or UNIXs then you most likely are using X.org. + * Google Summer of Code[2] is approaching and X.org is looking for bright, capable students who are interested in working on the Linux graphics stack. Google hasn't officially announced GSoC for 2012, but now is the time to start looking around to see if you're interested. For those who aren't aware, GSoC is a program where google pays students to work on open source projects. X.org has a complementary program called Endless Vacation of Code[3] (EVoC) for students whose schedules don't fit with GSoC. We have work in OpenGL/Mesa, graphics shaders, graphics drivers, state trackers, code refactoring, multi-touch and gestures work, automated testing, documentation, color management, etc.[4] You'll get to work with developers at AMD, Intel, NVidia, [[RedHat|RedHat]], Canonical, as well as others. I won't kid you. The work is challenging, not everyone's application is accepted and you will have to work hard to pass. But the people on the project are very smart and willing to help people who are genuinely interested in learning and wanting to participate and contribute. +Any and all interested students, please contact either me or hop on the irc channel at: irc.freenode.net #xorg or #xorg-devel + +Sincerely, Matt Dew Endless Vacation of Code Coordinator, X.org + +[1] [[http://www.x.org/wiki|http://www.x.org/wiki]] [2] [[http://code.google.com/soc/|http://code.google.com/soc/]] [3] [[http://www.x.org/wiki/XorgEVoC|http://www.x.org/wiki/XorgEVoC]] [4] [[http://www.x.org/wiki/SummerOfCodeIdeas|http://www.x.org/wiki/SummerOfCodeIdeas]] + +--- + + + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MattDew/docbooktest.mdwn b/MattDew/docbooktest.mdwn new file mode 100644 index 00000000..998a468a --- /dev/null +++ b/MattDew/docbooktest.mdwn @@ -0,0 +1,11 @@ + +<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE book PUBLIC "-//OASIS//DTD [[DocBook|DocBook]] XML V4.4//EN" "[[http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">|http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">]] <?xml-stylesheet href="[[http://somewebsite.com/html/docbook.xsl|http://somewebsite.com/html/docbook.xsl]]" type="text/xml"?> <book> + + * <title>Title of my next book</title> <chapter> + * <title>Chapter Title</title> <section> + * <title>First Heading</title> <para>Some Text</para> +</section> + +</chapter> + +</book> diff --git a/Matt_Turner.mdwn b/Matt_Turner.mdwn new file mode 100644 index 00000000..fa07e4da --- /dev/null +++ b/Matt_Turner.mdwn @@ -0,0 +1,12 @@ + + +## Matt Turner + +Email: mattst88 at gmail, gentoo. + [[http://mattst88.com/|http://mattst88.com/]] ... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MatthiasHopf.mdwn b/MatthiasHopf.mdwn new file mode 100644 index 00000000..30863651 --- /dev/null +++ b/MatthiasHopf.mdwn @@ -0,0 +1,13 @@ + + +## Matthias Hopf + +Email: [[mat@mshopf.de|mailto:mat@mshopf.de]], [[matthias.hopf@ohm-hochschule.de|mailto:matthias.hopf@ohm-hochschule.de]] + +Homepage: [[www.mshopf.de|http://www.mshopf.de/]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MatthieuHerrb.mdwn b/MatthieuHerrb.mdwn new file mode 100644 index 00000000..9fd87d0d --- /dev/null +++ b/MatthieuHerrb.mdwn @@ -0,0 +1,13 @@ + + +## Matthieu Herrb + +Email: matthieu.herrb AT SPAMFREE laas DOT fr + +See [[my real home page|http://www.laas.fr/~matthieu]]. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/Membership.mdwn b/Membership.mdwn new file mode 100644 index 00000000..a990e978 --- /dev/null +++ b/Membership.mdwn @@ -0,0 +1,18 @@ + + +# Membership + +If you are a contributor to the X Window System technology as shipped by X.Org (developer, documentation writer etc) you may apply for membership in the [[X.Org Foundation|XorgFoundation]]. Membership entitles you to + +* Vote in [[elections|BoardOfDirectors/Elections]] for the [[X.Org Foundation Board|BoardOfDirectors]]. +* Vote on changes to the [[By-Laws|BylawReview]] and the Membership Agreement. +* Vote on other topics as required by the By-Laws or Membership Agreement. +* Chair X.Org Foundation Committees. +* Host X.Org related events. +Furthermore Membership may be required to access certain copyrighted material which the X.Org Foundation is not allowed to distribute publicly. + +The Foundation Bylaws state that "In order to qualify as a Member, a person must, at the time of their application and during the tenure of their membership: (i) be actively involved in the activities relating to the technologies of X.Org, as set forth in the Membership Agreement, and, who, in the consideration of the Board, supports the objects, purposes, aims and objectives of X.Org; and (ii) maintain current and accurate contact information as may be needed for delivery of Notices." + +Membership is aimed at people with a more than casual involvement in X.Org's work. It is not required in order to participate in X.Org's ongoing activities, to access our source code repositories or to subscribe to our mailing lists. Neither does membership provide you with additional information about X.Org's activities and ways you may want to get involved. If you are new to X.Org you probably just want to find out how you can participate. Visit [[XorgMailingLists|XorgMailingLists]] and join one of the mailing lists, or go to [[XorgIRC|XorgIRC]] to find out about the available IRC channels, for more information. + +To apply for membership, or to update or edit your membership record, please visit [[http://members.x.org|http://members.x.org]] diff --git a/MichaelDales.mdwn b/MichaelDales.mdwn new file mode 100644 index 00000000..841c44cb --- /dev/null +++ b/MichaelDales.mdwn @@ -0,0 +1,15 @@ + + +## Michael Dales + +Email: mwd AT SPAMFREE ndiyo DOT org + +I work at the not-for-profit organisation [[Ndiyo|http://ndiyo.org]] and Ndiyo's for-profit sister company [[Cambridge Visual Networks|http://camvine.com]] (known as Cam Vine for short). + +I've been writing Xorg drivers for things like the Ndiyo ethernet thin client, and for the USB Monitors from Samsung and LG based on [[Display Link|http://displaylink.com]] chip sets. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MichaelKerrisk.mdwn b/MichaelKerrisk.mdwn new file mode 100644 index 00000000..f00d1662 --- /dev/null +++ b/MichaelKerrisk.mdwn @@ -0,0 +1,13 @@ + + +## Your Name + +Email: mtk AT SPAMFREE lwn DOT net + +[[http://man7.org/mtk|http://man7.org/mtk]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MichaelLarabel.mdwn b/MichaelLarabel.mdwn new file mode 100644 index 00000000..e947586b --- /dev/null +++ b/MichaelLarabel.mdwn @@ -0,0 +1,15 @@ + + +## Michael Larabel + +Email: michael AT SPAMFREE michaellarabel DOT com + +Webpage: [[http://www.michaellarabel.com/|http://www.michaellarabel.com/]] + +Twitter: [[http://twitter.com/michaellarabel|http://twitter.com/michaellarabel]] [I will be tweeting my locations when showing various XDC Chicago 2011 attendees around the days prior to the event, for those interested in meeting up.] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MichaelVerret.mdwn b/MichaelVerret.mdwn new file mode 100644 index 00000000..026ac989 --- /dev/null +++ b/MichaelVerret.mdwn @@ -0,0 +1,7 @@ +## Michael Verret + +X11 Maintainer for Zenwalk GNU/Linux + +Administrator & Webmaster for Zenwalk GNU/Linux + +Email: michael DOT verret ~AT~ gmail DOT com diff --git a/MichelDaenzer.mdwn b/MichelDaenzer.mdwn new file mode 100644 index 00000000..0a173548 --- /dev/null +++ b/MichelDaenzer.mdwn @@ -0,0 +1,13 @@ + + +## Michel Dänzer + +Email: michel AT SPAMFREE daenzer DOT net + +Working on Radeon drivers. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/MiodVallat.mdwn b/MiodVallat.mdwn new file mode 100644 index 00000000..81fb87ce --- /dev/null +++ b/MiodVallat.mdwn @@ -0,0 +1,9 @@ + + +## Miod Vallat + +Email: [[miod@openbsd.org]] + +Senior OpenBSD developer, responsible for input and video drivers in the kernel (as a punishment for having written too many of them). Unfortunately I am too busy to spend quality time on X as well. + +[[CategoryHomepage|CategoryHomepage]] diff --git a/Mirrors.mdwn b/Mirrors.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Mirrors.mdwn diff --git a/ModeSetting.mdwn b/ModeSetting.mdwn new file mode 100644 index 00000000..baf1f7d4 --- /dev/null +++ b/ModeSetting.mdwn @@ -0,0 +1,57 @@ + +_**Mode Setting Design Discussion**_ + +**Contents:** [[!toc ]] + + +## Introduction + +The current design of having the X server drivers/frame buffer drivers all doing mode setting in the system is starting to cause issues, especially around areas like suspend/resume and with the development of new types of rendering mechanisms for X (like Xgl). + +Mode setting in the kernel is possible for most cards, however a few cards require the use of VBE to set modes especially with external LVDS/TMDS and tv-out controller chips that are undocumented. Mode setting in userspace causes other issues such as at times like suspend/resume and interaction with kernel drivers. + +It looks like a userspace modesetting system with an in-kernel component driver is the best possible solution. Current and future drawing system can interface to this modesetting library and use it to all their modesetting leaving the rendering application (X or Xgl) free to just render. This will also need to tie in with an in-kernel memory management system possibly. + +This document will be in two sections, Modesetting API and some ideas for an implementation of it. + + +## Terminology + +**setter**: application using the modesetting library (not the human sitting at the machine) + +**screen**: a physically viewable object (monitor, TV, the Matrix) + +**device**: a piece of hardware or software that provides access to 0..n screens (0 screens means nothing plugged in at the moment) + + +## API + + +### Requirements + +1. Must be extensible and allow new types of display not handled by the core. + +2. Allow user to enumerate current devices, and screens attached to those devices. + +3. For each screen, allow the setter to enumerate the currently available modes and enable/disable output. + + +### Currently open questions + +1. Show screen surface setup go via the modesetting library? + +the EGL_MESA_screen_surface has the ideas of setting up screen surfaces on a particular screen, in my mind this is more to do with memory management than mode setting. A unified namespace between parties is definitely needed so we can tell what a modesetting device corresponds to. The memory manager would need to be told, that the setter needs an area of VRAM of a certain size and then the mode setter needs to be told to set the mode on the screen and point to the VRAM. + +Comment by [[MichelDaenzer|MichelDaenzer]]: EGL_MESA_screen_surface is intended to be the connection between memory management and mode setting. IMO, neither should the mode setting instance do any memory management, nor should the memory manager (have to) know anything about mode setting. + + +## Implementation + + +### Decisions made so far + +1. Initial implementation can be backended onto a fbdev driver, while an cut-down X server can be worked on to just modeset and not render. + +2. The DRI is necessary for this to work. You don't need a full DMA implementation for a card or anything just a stub driver doing memory management. + +-- [[DavidAirlie|DavidAirlie]] diff --git a/ModularDevelopersGuide.mdwn b/ModularDevelopersGuide.mdwn new file mode 100644 index 00000000..8452db23 --- /dev/null +++ b/ModularDevelopersGuide.mdwn @@ -0,0 +1,388 @@ + + +# The X.Org Modular Tree Developer's Guide + +[[!toc ]] + + +## Introduction + +This guide is for developers who wish to build the X Window System from source. If your area of interest is limited to a single package, like a driver or an application, check with your O/S first for development facilities. + +<a name="RequiredTools"></a> +## Required Tools + +The most common cause of build failures for first time builders is the lack of required tools. There are over 30 tools required to build all of X 200+ packages and half of them are not installed by default on most O/S or Linux distributions. Some tools are only needed by dependent projects: + +* [[Mesa|http://www.mesa3d.org/]] ` ` The Mesa 3D Graphics Library +* [[Pixman|http://cgit.freedesktop.org/pixmanpixman/]] ` ` Low Level Pixel Manipulation Library +* [[XKeyboardConfig|http://www.freedesktop.org/wiki/Software/XKeyboardConfig]] ` ` X Keyboard Configuration Database +It is strongly advised you install such packages from your O/S official packaging system. Check the [[RequiredPackages|RequiredPackages]] for your O/S. Some of the tools may not be required to build some areas of X. Some GNU utility, like make, have native O/S equivalent on non GNU systems. + + +### Source Code Version Control + +* [[git|http://git-scm.com/]] ` ` The fast version control system +<a name="GNUBuildSystem"></a> +### GNU Build System + +* [[autoconf (2.60)|http://www.gnu.org/software/autoconf/]] ` ` Produce shell scripts that automatically configure software source code packages +* [[automake (1.10)|http://www.gnu.org/software/automake/]] ` ` Create GNU standards-compliant Makefiles from template files +* [[gmake|http://www.gnu.org/software/make/]] ` ` The GNU version of the "make" utility to maintain groups of programs +* [[libtool (1.5)|http://www.gnu.org/software/libtool/]] ` ` Provide generic shared library support +* [[pkg-config (0.22)|http://pkg-config.freedesktop.org/wiki/]] ` ` Return metainformation about installed libraries + +### Development Tools + +* [[yacc|http://en.wikipedia.org/wiki/Yacc]] ` ` The original AT&T parser generator or an upward compatible version such as [[bison|http://www.gnu.org/software/bison/]] or [[byacc|http://invisible-island.net/byacc/]] whitout using its specific features +* [[lex|http://en.wikipedia.org/wiki/Lex_%28software%29]] ` ` The original AT&T lexical analyser generator or an upward compatible version such as [[flex|http://flex.sourceforge.net/]] whitout using its specific features +* [[gcc (2.95)|http://www.gnu.org/software/gcc/]] ` ` The GNU C compiler +* [[gettext|http://www.gnu.org/software/gettext/]] ` ` GNU Internationalization utilities +* [[gperf (3.0.1)|http://www.gnu.org/software/gperf/]] ` ` Perfect hash function generator +* [[m4 (1.4)|http://www.gnu.org/software/m4/]] ` ` A macro processing language +* [[ncurses (5)|http://www.gnu.org/software/ncurses/]] ` ` Basic terminal type definitions + +### Development Tools/Libraries + +* [[perl (5)|http://www.perl.org/]] ` ` Larry Wall's Practical Extraction and Report Language +* [[intltool (0.30)|http://freedesktop.org/wiki/Software/intltool]] ` ` Utility scripts for internationalizing XML +* [[libpng (1.2.44)|http://www.libpng.org/pub/png/]] ` ` Reading and writing PNG (Portable Network Graphics) format files +* [[llvm|http://www.llvm.org/]] ` ` The Low-Level Virtual Machine (LLVM) +* [[libtalloc|http://talloc.samba.org/talloc/doc/html/index.html]] ` ` A hierarchical pool based memory allocator with destructors +* [[zlib (1.2.5)|http://zlib.net/]] ` ` Software library used for data compression + +### Cryptography + +The X server requires one of the following cryptographic libraries. + +* [[libgcrypt|http://directory.fsf.org/project/libgcrypt/]] ` ` General purpose cryptographic library +* [[libcrypto|http://www.openssl.org/docs/crypto/crypto.html]] ` ` OpenSSL cryptographic library +* [[libsha1|https://github.com/dottedmag/libsha1]] ` ` Tiny SHA1 implementation for embedded devices +* [[libmd|http://martin.hinner.info/libmd/]] ` ` Cryptographic message digest library +* [[CommonCrypto|http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/Common%20Crypto.3cc.html]] ` ` libSystem digest library on MAC OS X + +### Fonts + +* [[fontconfig (2.2.3)|http://www.freedesktop.org/wiki/Software/fontconfig]] ` ` A library for configuring and customizing font access +* [[freetype (2.2)|http://freetype.sourceforge.net/index2.html]] ` ` A Free, High-Quality, and Portable Font Engine + +### Documentation/XML Tools + +These tools are optionals. If they are missing, the documentation will not be generated. + +* [[Asciidoc|http://www.methods.co.nz/asciidoc/index.html]] ` ` Highly configurable text format for writing documentation +* [[Doxygen (1.6.1)|http://www.stack.nl/~dimitri/doxygen/]] ` ` Documentation system for C, C++, Java, Python and other languages +* [[Xmlto (0.0.22)|https://fedorahosted.org/xmlto/]] ` ` XML-to-any converter +* [[Xsltproc (1.1.26)|http://xmlsoft.org/XSLT/xsltproc2.html]] ` ` XSLT command line processor + +## Selecting a Build Process + +We are assuming you have installed the [[required tools|ModularDevelopersGuide]] but nothing else. There are two maintained build processes you can use. One is based on a simple Bourne script and one is a customization of the Gnome JHBuild process. + + +### Build Process Based on a Script + +This build process simply runs a `build.sh` script that downloads the source code from the git repositories and builds each package in dependency order. + +The _source tree_ is where the source code is extracted from git. It would typically be something like $HOME/src. The _installation tree_ is where the build generated objects (binaries, scripts, etc...) are created, typically $HOME/build. + +The script is itself part of a package which needs to be obtained from a git repository. The following command will extract the source code from git: +[[!format txt """ +cd $HOME/src +git clone git://anongit.freedesktop.org/git/xorg/util/modular util/modular +"""]] +You are now ready to launch a full build by invoking the build script. <a name="FullBuild"></a> +[[!format txt """ +mkdir $HOME/build +cd $HOME/src +./util/modular/build.sh --clone $HOME/build +"""]] +There are a good number of environment variables to be set and directories to be created. The script does a good job of setting default values. The `--help` option will list those variables and what they are used for. A common one is PREFIX which you may set to the installation directory. There is no variable for the source tree, you invoke commands from the top of the tree. + +Take a look at the features available in that script. You will certainly appreciate the `--autoresume` when the build stops on error. If you do not need to build all the packages, you can customize a list using the `-L` and use it with the `--modfile` options. + + +#### Building from Archive Files + +Alternatively, the script can build the source from archive files. X.Org regularly publishes versions of the source code in the form of [[tarballs|http://www.x.org/releases/X11R7.6/src/]]. The example shown involves tarballs from the X11R7.6 release. The script can also build a mixture of tarballs and source from git. + +You must first download the tarballs before running the build script. An input file containing URLs to read can be provided. You do not need to extract the tarballs. A sample command: +[[!format txt """ +wget http://www.x.org/releases/X11R7.6/src/util/util-macros-1.11.0.tar.gz +"""]] +You are now ready to launch a full build by invoking the build script. You can leave the `--clone` option in, any missing source will be obtained from git, at the current development level. +[[!format txt """ +mkdir $HOME/build +cd $HOME/src +./util/modular/build.sh $HOME/build +"""]] + +### Build Process Based on JHBuild + +The second build process uses [[jhbuild|http://www.freedesktop.org/wiki/Software/jhbuild]], a program written by James Henstridge that can be used to automatically download module components from Git and then build them in the correct dependency order. Refrer to the [[JhBuildInstructions|JhBuildInstructions]]. + + +## Features of the Build Script + +The `build script` first sets up environment variables and creates missing directories. It then cycles through a list of packages in dependency order to download them and run the Autotools from the [[GNU Build System|ModularDevelopersGuide]]. Some of the features require a conceptual understanding of Autoconf and Automake. Use the `--help` for a complete list of options. + + +### Environment Variables + +You normally do not need to have any environment variable set to run a full build. The script assigns reasonable defaults. The `--help` option will list those variables and what they are used for. + + +### Downloading and Updating Source Code + +As seen when launching a [[full build|ModularDevelopersGuide]], the `--clone` option will download the source code from git if it is missing on disk. The `-p` option will issue a `git -pull --rebase` to obtain the latest code currently in git. + + +### Stop/Continue/Resume On Error + +All builds eventually stop due to errors, sooner rather than later. The `-n` option allows the build script to continue the build with the next module. When the script terminates, it reports which ones failed. The `--autoresume` option writes a list of modules and can restart where it left off after you fixed the build error. + + +### Specifying Modules to Build + +The build script contains a full list of all X.Org modules and its dependent projects. That's a lot, over 200. You will most likely not need all of them. The `-L` will write this list to a file which you can edit and feed back to script using `--modfile` option. Make sure you understand the dependencies so as not to remove critical modules. + + +### Making Tarballs + +The X.Org modules are published as tarballs on the web. To create such tarballs, one can simply specify the `-D` option, but preferably `-d` as it performs a number of tests while creating the tarballs. + + +### Debug Mode + +The Automake default CFLAGS are -g and -O2. Using the -g option will add -g3 -O0 for additional debugging. + +The Automake silent rules are enabled by default at version 1.11 and higher. You may need additional context to debug the error. The `--retry-v1` will cause a rebuild of the module with the silent rules disabled. + + +### Advanced Commands and Configuration + +The build script provides additional flexibility in letting you specify arbitrary commands. You need more internal knowledge of the script and good experience with configuring and building modules. There is no checking to ensure that what you are trying to do _makes sense_. + +The `-a` option will skip the Autoconf configuration. This speeds up the build when you know that all modules have already been configured and do not need their source to be updated. You can rely, up to a point, on the make build rules to reconfigure the module if it is out of date. + +The `--cmd` option allows you to invoke a custom make or git command. You may want to run `git status` on all modules to ensure there are no local code changes for example. + +The `--confflags` option allows you to supply any Autoconf `configure` option. One example that comes to mind is `--disable-docs` which will suppress the building of user documention. These may conflict will default values assigned to environment variables set by the script. + + +### Building Individual Modules Yourself + +The build script does not mind if you cd to an individual module and build it yourself. It will have no adverse affect on the build when you resume the use of the script. You just need some basic understanding of the Autotools. Beware that the build script sets environment variables for you which are not available when you type the commands yourself in the terminal. + +Let's set those variables the way the script does it for you: + + +[[!format txt """ +export PREFIX=$HOME/build +export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/share/pkgconfig +export ACLOCAL="aclocal -I $PREFIX/share/aclocal" +export LD_LIBRARY_PATH=$PREFIX/lib +export PATH=$PREFIX/bin:$PATH +"""]] +Now that have exported those variables, the build script will use them in lieu of its internal defaults. You can now switch back and forth between the build script and the terminal and keep the same environment. + +The script also creates directories for you: +[[!format txt """ +mkdir -p $PREFIX/share/aclocal +mkdir -p $PREFIX/var/log +"""]] +Download the font/util module and its dependency util/macros from git. +[[!format txt """ +cd $HOME/src +git clone git://anongit.freedesktop.org/git/xorg/util/macros util/macros +git clone git://anongit.freedesktop.org/git/xorg/font/util font/util +"""]] +Run the `autogen.sh` script, which will create and run the Autoconf configuration, and invoke the make command. +[[!format txt """ +cd $HOME/src/util/macros +./autogen.sh --prefix $PREFIX && make install +cd $HOME/src/font/util +./autogen.sh --prefix $PREFIX && make install +"""]] +This is exactly what the script does for you, note the order and the importance of running the _install_ target. Without it, the font util module would not be able to use xorg-macros.m4 in $PREFIX/share/aclocal. For complete details on the packaging structure of a module read the INSTALL file in the root directory of the module. + +When building from tarballs, the configuration has already been created and only needs to be run. The commands would be: +[[!format txt """ +cd $HOME/src/util/macros +./configure --prefix $PREFIX && make install +cd $HOME/src/font/util +./configure --prefix $PREFIX && make install +"""]] +The autogen.sh script is not part of the GNU Build System architecture and is kept for historical reasons. Other projects have different name and content for it. It should not be included in the tarball. If you need to recreate the configuration, `autoreconf -vfi` will do and is only what autogen.sh calls. + + +## Using the modular tree + +This section describes how to use the newly compiled X libraries, applications and X server. + + +### X libraries + +The X libraries which are built will typically be in $PREFIX/lib. + +To use them you have to configure the linker to find them. On GNU/Linux systems you do: + + +[[!format txt """ +export LD_LIBRARY_PATH=$PREFIX/lib +"""]] +Alternately, you might edit the `/etc/ld.so.conf` file and run `ldconfig`. There may be other ways to configure the linker on other systems. + +Once this is done X applications should use the newly compiled libraries. + + +### X applications + +The X client programs which are built will be found in $PREFIX/bin. Generally, these programs can be run with the default user permissions. + + +### Running the X server + +Verify that the Xorg binary that will get executed is really the one you just build. If not, adjust $PATH. +[[!format txt """ +ls -l `which Xorg` +"""]] +The Xorg binary needs to be _suid root_ which requires root privilege. +[[!format txt """ +chown root Xorg +chmod 4711 Xorg +"""]] +Run the new X server using the most basic command. Your computer screen will blank out and your desktop will be replaced with a small X terminal window with no borders. To return to your desktop, you can type `exit` or you can press `Ctrl Alt F7` (on most platforms). + +**Please read the above paragraph carefully before issuing the following command.** +[[!format txt """ +Xorg :1 -terminate & sleep 2 ; DISPLAY=:1 xterm +"""]] + +## Working with git submodules + +Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit. This section assumes you are comfortable with the similar tasks when performed without git submodules. You might be interested in the [[Kernel Git Submodule Tutorial|https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial]]. + + +### Cloning a module with submodules + +After cloning the module, the git submodule command will clone and initialize the submodules specified in the .gitmodules file. In this example, the submodule path is _m4_. Git keeps track of which submodule commit to checkout. Later versions of the _git clone_ command have a _--recursive_ option. +[[!format txt """ +git clone git://anongit.freedesktop.org/xcb/util +git submodule update --init +"""]] + +### Updating a module + +It may be that only the module has changed since the last update, or that both the module and the submodule have changed. +[[!format txt """ +git pull --rebase +git submodule update +"""]] + +### Rolling back a module + +It may happen you need to revert the state of a module and a submodule to a previous point in time. The module should then point to the matching commit of the submodule. The commit numbers are valid, you can run the commands. +[[!format txt """ +git reset --hard 02289ca +git submodule update +"""]] +You should see this output: +[[!format txt """ +HEAD is now at 02289ca Bump version to 0.3.8 +Submodule path 'm4': checked out '55e8069773efd794a91d5fb37bfceeebae2e378a' +"""]] +The log [[http://cgit.freedesktop.org/xcb/util/log/m4|http://cgit.freedesktop.org/xcb/util/log/m4]] will show the commit history for the submodule. + + +### Hooking up a submodule to a module + +A submodule has a git repository like any other module. It is only different in the way it gets used. Several modules can _include_ the submodule containing reusable code. +[[!format txt """ +git submodule add git://anongit.freedesktop.org/xcb/util-common-m4 m4 +git submodule update --init +"""]] +You should see this output from _git status_: +[[!format txt """ +# On branch master +# Changes to be committed: +# (use "git reset HEAD <file>..." to unstage) +# +# new file: .gitmodules +# new file: m4 +# +"""]] + +### Detaching a submodule from a module + +There is no git submodule remove command. Given our example where the submodule path is _m4_, +[[!format txt """ +git config --remove-section submodule.m4 +git config --file .gitmodules --remove-section submodule.m4 +git rm --cached m4 +rm -fr m4 +"""]] +Create a commit for the changes incurred by the module and you are done. Note that the submodule still exists at fdo.org, you have only detached and deleted your module copy. + + +### Applying changes to a submodule + + +#### Working from within a submodule + +To directly modify sources referenced by a submodule, just change to the directory of the submodule and work with it like with a normal repository. Note however, that the state of a submodule is controlled by the supermodule and that under certain conditions it might even be possible to loose unpublished work. For more, see the Gotchas section of the [[Kernel Git Submodule Tutorial|https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial#Gotchas]]. + + +#### Using a local clone of a submodule + +It is also possible to separately clone the repository and redirect the upstream URL of the submodule to the local version. For example, the configuration of a submodule m4 in ` m4/.git/config ` could look like: + + +[[!format txt """ +[remote "origin"] + fetch = +refs/heads/*:refs/remotes/origin/* + url = git://anongit.freedesktop.org/xcb/util-common-m4.git +"""]] +Simply set the value of `url` to the path of the local repository. + + +[[!format txt """ +[remote "origin"] + fetch = +refs/heads/*:refs/remotes/origin/* + url = /path/to/util-common-m4.git +"""]] +Note, that we are changing the configuration of the submodule at ` m4/.git/config ` and not the configuration of the supermodule at `.git/config`. + + To use a different location from the start, it is also possible to change the submodule configuration in the supermodule before updating the submodule for the first time. The file `.gitmodules` specifies the official location of the submodule and changes to it are being tracked. But that file does not need to be changed for our purpose. The following command copies the contents of `.gitmodules` to the configuration of the supermodule at `.git/config`: + + +[[!format txt """ +git submodule init +"""]] +The submodule has not been checked out yet, and so it is possible to select a different location. For example, the configuration in `.git/config` could look like: + + +[[!format txt """ +[submodule "m4"] + url = git://anongit.freedesktop.org/xcb/util-common-m4.git +"""]] +Insert the preferred location like above and then update the submodule with: + + +[[!format txt """ +git submodule update +"""]] + +### Creating a submodule + +A git submodule is created just like any other git module. The reasons for using a module as a submodule is beyond the scope of this section. In the XCB example, the goal was code reuse. + + +## Crosscompiling + +There is a separate page dedicated to issues around [[CrossCompilingXorg|CrossCompilingXorg]]. + + +## New Modules + +When adding modules to the tree, you may want to read the [[NewModuleGuidelines|NewModuleGuidelines]]. diff --git a/ModularDevelopersGuide/git_xorg b/ModularDevelopersGuide/git_xorg new file mode 100644 index 00000000..6153a5c1 --- /dev/null +++ b/ModularDevelopersGuide/git_xorg @@ -0,0 +1,136 @@ +#! /bin/sh +# +# Copyright (c) 2006 Matthieu Herrb +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +# +# Some updates by Brian Paul + + +gitbase="git://anongit.freedesktop.org/git/xorg" + +app="appres bdftopcf beforelight bitmap compiz constype editres fonttosfnt\ + fslsfonts fstobdf glxcompmgr iceauth ico lbxproxy listres luit\ + makepsres mkcfm mkfontdir mkfontscale oclock pclcomp proxymngr\ + rendercheck rgb rstart scripts sessreg setxkbmap showfont smproxy\ + twm viewres x11perf xauth xbiff xcalc xclipboard xclock xcmsdb\ + xcompmgr xconsole xcursorgen xdbedizzy xditview xdm xdpyinfo\ + xdriinfo xedit xev xeyes xf86dga xfd xfindproxy xfontsel xfs\ + xfsinfo xfwp xgamma xgc xhost xinit xkbcomp xkbevd xkbprint\ + xkbutils xkill xload xlogo xlsatoms xlsclients xlsfonts xmag\ + xman xmessage xmh xmodmap xmore xphelloworld xplsprinters xpr\ + xprehashprinterlist xprop xrandr xrdb xrefresh xrestop xrx xset\ + xsetmode xsetpointer xsetroot xshowdamage xsm xstdcmap xtrap \ + xvidtune xvinfo xwd xwininfo xwud" + +data="bitmaps cursors" + +doc="xorg-docs xorg-sgml-doctools" + +driver="xf86-input-acecad xf86-input-aiptek xf86-input-calcomp\ + xf86-input-citron xf86-input-digitaledge xf86-input-dmc\ + xf86-input-dynapro xf86-input-elo2300 xf86-input-elographics\ + xf86-input-evdev xf86-input-fpit xf86-input-hyperpen\ + xf86-input-jamstudio xf86-input-joystick xf86-input-keyboard\ + xf86-input-magellan xf86-input-magictouch xf86-input-microtouch\ + xf86-input-mouse xf86-input-mutouch xf86-input-palmax\ + xf86-input-penmount xf86-input-sample xf86-input-spaceorb\ + xf86-input-summa xf86-input-tek4957 xf86-input-ur98\ + xf86-input-vmmouse xf86-input-void xf86-video-apm\ + xf86-video-ark xf86-video-ast xf86-video-ati\ + xf86-video-chips xf86-video-cirrus xf86-video-cyrix\ + xf86-video-dummy xf86-video-fbdev xf86-video-glide\ + xf86-video-glint xf86-video-i128 xf86-video-i740\ + xf86-video-impact xf86-video-imstt xf86-video-intel\ + xf86-video-mga xf86-video-neomagic xf86-video-newport\ + xf86-video-nsc xf86-video-nv xf86-video-rendition\ + xf86-video-s3 xf86-video-s3virge xf86-video-savage\ + xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb\ + xf86-video-sunbw2 xf86-video-suncg14 xf86-video-suncg3\ + xf86-video-suncg6 xf86-video-sunffb xf86-video-sunleo\ + xf86-video-suntcx xf86-video-tdfx xf86-video-tga\ + xf86-video-trident xf86-video-tseng xf86-video-v4l\ + xf86-video-vesa xf86-video-vga xf86-video-via\ + xf86-video-vmware xf86-video-voodoo xf86-video-wsfb" + +font="adobe-100dpi adobe-75dpi adobe-utopia-100dpi adobe-utopia-75dpi\ + adobe-utopia-type1 alias arabic-misc bh-100dpi bh-75dpi\ + bh-lucidatypewriter-100dpi bh-lucidatypewriter-75dpi\ + bh-ttf bh-type1 bitstream-100dpi bitstream-75dpi\ + bitstream-speedo bitstream-type1 cronyx-cyrillic\ + cursor-misc daewoo-misc dec-misc encodings ibm-type1\ + isas-misc jis-misc micro-misc misc-cyrillic misc-ethiopic\ + misc-meltho misc-misc mutt-misc schumacher-misc \ + screen-cyrillic sony-misc sun-misc util winitzki-cyrillic\ + xfree86-type1" + +lib="libAppleWM libFS libICE libSM libWindowsWM libX11 libXRes\ + libXScrnSaver libXTrap libXau libXaw libXcomposite libXcursor\ + libXdamage libXdmcp libXevie libXext libXfixes libXfont\ + libXfontcache libXft libXi libXinerama libXmu libXp\ + libXpm libXprintAppUtil libXprintUtil libXrandr libXrender\ + libXt libXtst libXv libXvMC libXxf86dga libXxf86misc\ + libXxf86rush libXxf86vm libdmx libfontenc liblbxutil\ + liboldX libpciaccess libxkbfile libxkbui libxtrans" + +proto="applewmproto bigreqsproto compositeproto damageproto\ + dmxproto evieproto fixesproto fontcacheproto\ + fontsproto glproto inputproto kbproto panoramixproto\ + pmproto printproto randrproto recordproto renderproto\ + resourceproto scrnsaverproto trapproto videoproto \ + windowswmproto x11proto xcmiscproto xextproto\ + xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto\ + xf86rushproto xf86vidmodeproto xineramaproto" + +util="cf gccmakedep imake install-check lndir macros makedepend\ + modular xmkmf" + + +do_dir () { + dir=$1 + if [ ! -d ${dir} ]; then + echo "creating ${dir}" + mkdir ${dir} + fi + for d in $2; do + if [ -d "${dir}/$d" ]; then + echo "${dir}/$d exists, pulling" + (cd "${dir}/$d" ; git pull) + else + echo "cloning ${dir}/${d}" + if [ ${dir} == '.' ] ; then + src="${gitbase}/$d" + else + src="${gitbase}/${dir}/$d" + fi + (cd "${dir}" ; git clone ${src}) + fi + done +} + +do_dir app "${app}" +do_dir data "${data}" +do_dir doc "${doc}" +do_dir driver "${driver}" +do_dir lib "${lib}" +do_dir proto "${proto}" +do_dir util "${util}" +do_dir . xserver + +# DRM doesn't fit into above +if [ -d drm ] ; then + (cd drm ; git pull ) +else + git clone git://anongit.freedesktop.org/git/mesa/drm +fi + diff --git a/ModularDevelopersGuide/git_xorg.sh b/ModularDevelopersGuide/git_xorg.sh new file mode 100644 index 00000000..28413c51 --- /dev/null +++ b/ModularDevelopersGuide/git_xorg.sh @@ -0,0 +1,144 @@ +#! /bin/sh +# +# Copyright (c) 2006 Matthieu Herrb +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +# +# Some updates by Brian Paul +# XCB update and some cleanup by Peter Hutterer + + +gitbase="git://anongit.freedesktop.org/git" + +app="appres bdftopcf beforelight bitmap compiz constype editres fonttosfnt\ + fslsfonts fstobdf glxcompmgr iceauth ico lbxproxy listres luit\ + makepsres mkcfm mkfontdir mkfontscale oclock pclcomp proxymngr\ + rendercheck rgb rstart scripts sessreg setxkbmap showfont smproxy\ + twm viewres x11perf xauth xbiff xcalc xclipboard xclock xcmsdb\ + xcompmgr xconsole xcursorgen xdbedizzy xditview xdm xdpyinfo\ + xdriinfo xedit xev xeyes xf86dga xfd xfindproxy xfontsel xfs\ + xfsinfo xfwp xgamma xgc xhost xinit xinput xkbcomp xkbevd xkbprint\ + xkbutils xkill xload xlogo xlsatoms xlsclients xlsfonts xmag\ + xman xmessage xmh xmodmap xmore xphelloworld xplsprinters xpr\ + xprehashprinterlist xprop xrandr xrdb xrefresh xrestop xrx xset\ + xsetmode xsetpointer xsetroot xshowdamage xsm xstdcmap xtrap \ + xvidtune xvinfo xwd xwininfo xwud" + +data="bitmaps cursors" + +doc="xorg-docs xorg-sgml-doctools" + +driver="xf86-input-acecad xf86-input-aiptek xf86-input-calcomp\ + xf86-input-citron xf86-input-digitaledge xf86-input-dmc\ + xf86-input-dynapro xf86-input-elo2300 xf86-input-elographics\ + xf86-input-evdev xf86-input-fpit xf86-input-hyperpen\ + xf86-input-jamstudio xf86-input-joystick xf86-input-keyboard\ + xf86-input-magellan xf86-input-magictouch xf86-input-microtouch\ + xf86-input-mouse xf86-input-mutouch xf86-input-palmax\ + xf86-input-penmount xf86-input-sample xf86-input-spaceorb\ + xf86-input-summa xf86-input-tek4957 xf86-input-ur98\ + xf86-input-vmmouse xf86-input-void xf86-video-apm\ + xf86-video-ark xf86-video-ast xf86-video-ati\ + xf86-video-chips xf86-video-cirrus xf86-video-cyrix\ + xf86-video-dummy xf86-video-fbdev xf86-video-glide\ + xf86-video-glint xf86-video-i128 xf86-video-i740\ + xf86-video-impact xf86-video-imstt xf86-video-intel\ + xf86-video-mga xf86-video-neomagic xf86-video-newport\ + xf86-video-nsc xf86-video-nv xf86-video-rendition\ + xf86-video-s3 xf86-video-s3virge xf86-video-savage\ + xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb\ + xf86-video-sunbw2 xf86-video-suncg14 xf86-video-suncg3\ + xf86-video-suncg6 xf86-video-sunffb xf86-video-sunleo\ + xf86-video-suntcx xf86-video-tdfx xf86-video-tga\ + xf86-video-trident xf86-video-tseng xf86-video-v4l\ + xf86-video-vesa xf86-video-vga xf86-video-via\ + xf86-video-vmware xf86-video-voodoo xf86-video-wsfb" + +font="adobe-100dpi adobe-75dpi adobe-utopia-100dpi adobe-utopia-75dpi\ + adobe-utopia-type1 alias arabic-misc bh-100dpi bh-75dpi\ + bh-lucidatypewriter-100dpi bh-lucidatypewriter-75dpi\ + bh-ttf bh-type1 bitstream-100dpi bitstream-75dpi\ + bitstream-speedo bitstream-type1 cronyx-cyrillic\ + cursor-misc daewoo-misc dec-misc encodings ibm-type1\ + isas-misc jis-misc micro-misc misc-cyrillic misc-ethiopic\ + misc-meltho misc-misc mutt-misc schumacher-misc \ + screen-cyrillic sony-misc sun-misc util winitzki-cyrillic\ + xfree86-type1" + +lib="libAppleWM libFS libICE libSM libWindowsWM libX11 libXRes\ + libXScrnSaver libXTrap libXau libXaw libXcomposite libXcursor\ + libXdamage libXdmcp libXevie libXext libXfixes libXfont\ + libXfontcache libXft libXi libXinerama libXmu libXp\ + libXpm libXprintAppUtil libXprintUtil libXrandr libXrender\ + libXt libXtst libXv libXvMC libXxf86dga libXxf86misc\ + libXxf86rush libXxf86vm libdmx libfontenc liblbxutil\ + liboldX libpciaccess libxkbfile libxkbui libxtrans" + +proto="applewmproto bigreqsproto compositeproto damageproto\ + dmxproto evieproto fixesproto fontcacheproto\ + fontsproto glproto inputproto kbproto panoramixproto\ + pmproto printproto randrproto recordproto renderproto\ + resourceproto scrnsaverproto trapproto videoproto \ + windowswmproto x11proto xcmiscproto xextproto\ + xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto\ + xf86rushproto xf86vidmodeproto xineramaproto" + +util="cf gccmakedep imake install-check lndir macros makedepend\ + modular xmkmf" + +xcb="proto libxcb pthread-stubs" + +# $1 is the main project path in the git repository (e.g. xorg). +# $2 is the module's directory (e.g. lib) +# $3 is the module name (e.g. libXi) +# $1 and $2 can be '.', in which case they are ignored. +# The path for git clone will be $gitbase/$1/$2/$3 +do_dir () { + dir=$2 + if [ ! -d ${dir} ]; then + echo "creating ${dir}" + mkdir -p ${dir} + fi + for d in $3; do + if [ -d "${dir}/$d" ]; then + echo "${dir}/$d exists, pulling" + (cd "${dir}/$d" ; git pull) + else + echo "cloning ${dir}/${d}" + if [ $1 = '.' ] ; then + src="${gitbase}" + else + src="${gitbase}/$1" + fi + + if [ ${dir} = '.' ] ; then + src="${src}/$d" + else + src="${src}/${dir}/$d" + fi + (cd "${dir}" ; git clone ${src}) + fi + done +} + +do_dir xorg app "${app}" +do_dir xorg data "${data}" +do_dir xorg doc "${doc}" +do_dir xorg driver "${driver}" +do_dir xorg lib "${lib}" +do_dir xorg proto "${proto}" +do_dir xorg util "${util}" +do_dir . . pixman +do_dir xorg . xserver +do_dir mesa . drm +do_dir . xcb "${xcb}" diff --git a/ModularizationDevelPlan.mdwn b/ModularizationDevelPlan.mdwn new file mode 100644 index 00000000..a36c53da --- /dev/null +++ b/ModularizationDevelPlan.mdwn @@ -0,0 +1,112 @@ + + +# Modularization Development Plan + +Kevin E. Martin + +[[!toc ]] + + +## Platform support + +We need to find out who will be working on modularization so that we can get an idea of the platform coverage. For the 6.8 release, I created a wiki page for the platforms that we wanted to test, and I would like to do the same for modularization. Below is the list of those platforms that people signed up to test from the previous release and the current one: + + * AIX (no arch listed) + * Cygwin (IA-32) + * Dragon``Fly/BSD + * FreeBSD (Alpha, AMD64, IA-32, IA-64) + * HP-UX (PA-RISC) + * IRIX (MIPS) + * Linux (Alpha, AMD64, ARM, IA-32, IA-64, M68k, MIPS, PPC, PPC64, PA-RISC, S/390, Sparc) + * MacOS (PPC) + * MacOS/Darwin (IA-32, PPC) + * NetBSD (IA-32) + * OpenBSD (AMD64, IA-32) + * SCO (no arch listed) + * Solaris (AMD64, IA-32, Sparc) + * Unix``Ware (no arch listed) +Other platforms that were listed, but didn't have anyone signed up to test were: + + * LynxOS + * OS/2 +Ideally, we would like to see at least one person and preferably more signed up to work on each of these platforms; however, it is more likely that we will get fairly good coverage on a subset of them. I expect good coverage on Linux, but we need much more than that. So, if you are interested in working on a platform and have the hardware available, please speak up now so that we can get an idea of where we stand. + + +## Development steps + +The Architecture Working group has given their approval, and we are now in the process of working out the development plan described here. Once we answer the remaining questions (see below) and agree to the plan outlined here, we can begin work. + +There are two parts to this project: dividing the tree into separate modules, and then autotooling those modules. These are described in the next two sections below. + + +### Module creation + +Here are the steps that for creating the modules: + + 1. Determine where each piece of code from the monolithic tree will go in the modular tree. + * See [[ModuleComponentList|ModuleComponentList]] for the current list. + * Nearly complete + 1. Create the top level modules (i.e., app, lib, proto, xserver, driver, font, doc and util) as peers to xc. + 1. Create the directory hierarchy for the modularization within each module based on the breakdown determined in step #1. + 1. Write a script that creates a symlink tree on the developer's local system from a checked out monolithic CVS tree. +Steps #2 and #3 should fall directly out of #1. The directory hierarchy can be filled in as modules are created in the dependency order (see below). Another developer has already started working on #4. + + +### Autotooling the modules + +We have a few people that have worked on previous autotooling efforts and many more that have not. Based on feedback from those previous efforts, much of the work will become routine once everyone understands exactly what needs to be done and how to do it. The question is how to fill this knowledge gap so that everyone can be productive initially (i.e., how do we bootstrap ourselves). + +My initial thought is that we should learn from the past efforts by having those involved explain the autotooling process that they used. We can then discuss it here on the list, make suggestions and come to consensus on how we want to proceed for our project. By discussing it openly, I think that many more developers will be able to become involved at an earlier stage since they will understand what is involved and how to make it happen. Also, this discussion will form the basis for part of the guide described in the proposal (see documents section below for more info). + +What I have in mind here is a simple brain dump of the process used to autotool in the xapps, xlibs, xserver and Debrix projects. I'd also like to see us discuss any common conventions that everyone should follow so that we have a consistent build system and config options name space. + +I expect as more people become involved in the modularization effort, the information here will be written and included in the developer's guide. + + +## Dependencies + +Note that while there are some dependencies that we need to follow for certain modules to work (lib, xserver, driver), others can be developed independently by using the monolithic tree for bootstrapping (app, font, doc, util). Here's the dependencies: + + * proto: no dependencies + * lib: depends on proto + * xserver: depends on proto and lib, but the lib dependency can be bootstrapped from the monolithic tree + * driver: depends on the xserver module headers + * app: depends on lib, but can be bootstrapped + * font: depends on app, which will contain the tools that build fonts, but can be bootstrapped + * doc: depends on (external?) tools to build docs + * util: no dependencies? +In order for bootstrapping to work, we need to have the capability to install and use missing pieces from a monolithic build. However, many libraries in the monolithic tree do not have pkg-config metadata files, which will make this difficult. Therefore, we recommend creating the modules in the dependency order listed above. + + +## Documents + +In the Modularization Proposal, we committed to create the following documents: + + * [[X.Org Modular Tree Developer's Guide|ModularDevelopersGuide]]: + * Required tools (Partially complete) + * Building and using the new modular tree (TBD) + * Standardized configuration options (TBD) + * Guidelines for module components (mostly complete) + * Converting code from Imake to Autotools (TBD) + * Component dependencies (included within component -- see developer's guide) + * Licenses (documented within component in COPYING -- see developer's guide) +Note that in the proposal, this guide was called the "Transition Guide", but it should have been called the a "Developer's Guide" instead since that is a better description of the doc. Using "transition" implies that the guide is only useful during the transition period, which does not reflect the life of this document. This doc is the place where new developers go to find out how to use and develop within the modular tree and will be kept up to date with the latest information. + +The initial outline for the developer's guide has been written. During development, we can fill in any new or missing information. To enable it to be easily updated, the developer's guide was placed in the wiki (see link above). + + +## Success Criteria + +Ideally, we should be able to build the exact same binaries and install them in the exact same place from either the monolithic and modular trees on the same system, but in reality the compiler options will probably differ and produce slightly different code. + +The next best solution would be to run through the same set of tests on both installed trees. The testing procedure used in for the 6.8 release is a good starting point for the set of tests used for the combined 6.9/7.0 release. These test should be updated to use the latest X Test Suite available (see the [[Test Working Group's wiki page|TestGroup]] for more info). Here's a link describing the procedure: + + * [[http://wiki.x.org/wiki/XorgTesting|http://wiki.x.org/wiki/XorgTesting]] +In addition, we should make sure that the installed trees look very similar and provide reasons for any discrepancies. + +Other success criteria would be the coverage we get on the platforms we support in the initial release. As noted above, Linux will most likely be the best supported, but we need others to make this a successful project. I agree with ajax that we should support at least Linux, Solaris, one of the BSDs, Darwin and Cygwin initially since we have active participation by people working on these platforms. However, my hope is that we will have several others supported as well. + + +## Open Questions + +None at this time. diff --git a/ModularizationProposal.mdwn b/ModularizationProposal.mdwn new file mode 100644 index 00000000..bfe84b33 --- /dev/null +++ b/ModularizationProposal.mdwn @@ -0,0 +1,217 @@ + + +# Modularization Proposal + +Paul Anderson, Alan Coopersmith, Egbert Eich, Adam Jackson, Kevin E. Martin and Keith Packard + +[[!toc ]] + + +<a name="intro"></a> +## Introduction + +Traditionally, the X Window System source code has been comprised of many different components that are brought together into a single monolithic source tree. We propose to split the tree into logical modules that can be developed, built and maintained separately, but still fit together coherently into the larger source code base as they have in the monolithic tree. + +This proposal provides rationale for modularization, attempts to address the known concerns people have raised, provides background on other modularization efforts, explains what the modularized source tree would look like, outlines the steps required to take this idea from concept to release, and suggests how future modular releases can be handled. + + +<a name="proscons"></a> +## The pros and cons of modularization + + +### The pros + + * There are many open source developers that are intimidated by the large X code base. Working on smaller self-contained modules with well defined ABIs, is much less intimidating. + * Most other open source projects use autotools, so it's something that many people know. Imake is known in our community but it's a barrier to entry for most others. + * Lowering the barriers to entry will both attract new developers and help them to become productive members of the community more quickly. More developers means progress speeds up, and bugs are found and fixed quicker. + * You no longer have to build and install the entire tree just to work on one small part of it. + * Creating releases from modules is automated with the autotools, along with the ability to automatically verify that the release is correct. + * Bug fixes in one part of the tree can be made available to vendors in a more timely fashion. For example, a bug fix in the Radeon driver module could be checked in on a stable development branch and released as an update for vendors. + * Finer grained access control to the source code; each module should have its own maintainer and access controls. Global developers will still have universal access. + * It should be easier to use technology that's not under the X license. Right now, we have the `xc/extras` directory, because the code there is either not under the X license or maintained externally. These _extras_ are often out of date and conflict with the installed versions on vendors' installations. + +### The cons + + * The autotools are a new build technology, which throws away existing knowledge of the current imake build system. People that are not already familiar with the autotools will need to learn a new build system. That could slow some developers down for a while. + * To address this issue, we need people who understand both imake and autotools well to write a transition guide for the benefit of all. + * Some platforms may not "come along" if there are no maintainers. + * This should be treated as an opportunity for us to contact the old maintainers and see if they are interested joining the community, or for us to encourage to new maintainers to step forward to support platforms if the old maintainer is no longer interested or available. + * Some platforms may not "come along" if the current build maintainers don't have time to learn the new build system during the initial release. + * The X.Org Foundation has been very good about having regular releases of our software and we are aggressively working to ensure that this continues. This regular release policy gives maintainers that don't have the time at present to complete the transition confidence that they will have opportunities in the near future to add their platforms to the new modular tree. + * Autodetection can add dependencies that you didn't intend. For example, a developer may have a library on their build system that isn't available on the target system. + * Dependencies will be explicitly listed and documented. Configure options will be used to control which dependencies are enabled or disabled. These configure options will be standardized and documented in the transition guide. + * Autotools are very version-dependent, and some OSes might not have the most up-to-date versions available. For example, some OSes might use an OS-specific libtool, which might need to be updated to includes the latest patches to properly handle "so" versions (see below). + * For developers who do not have the required autotools versions installed and don't want to overwrite their vendor-supported versions, it is possible to install them in out-of-the-way locations (e.g., not in $PATH) and still easily script the build process. + * Autotools are not very easy to understand (e.g., libtool). + * Imake is also not very easy to understand for new developers. The autotools have the advantage that there are many sources for good information. The transition guide will also help. Many of the more complex tools (e.g., libtool) can be ignored almost all of the time as other tools (e.g., automake, in the case of libtool) manage the whole interaction. + * The various servers have different (and possibly incompatible) build options, which means that they may not be able to share the same build of the code. For example, one server might build DIX with XINPUT support, while another one might require that XINPUT be disabled. + * This problem also affects the monolithic tree, and it is not easily solvable in either case without rebuilding the affected parts. This rebuilding task is simple with autotools. + * The configure scripts take a long time to complete; you have to run multiple "configures" from scratch, and it will take a while. + * Configure caches can be used to speed up multiple configure runs, and jhbuild or scripts can be used to automate them. + * With the imake build system, you can build and test in place with the link directory inside the tree. Building self-contained user environments are more difficult with autotools. + * jhbuild solves this since it runs a self-contained environment. Other solutions using chroot, LD_LIBRARY_PATH, etc. are also in use today with autotools. + * Legacy imake-only applications will need to be converted. + * Imake is not going away and will still be needed for legacy applications maintained outside of our source tree. The transition guide that we use internally will be made available externally to help others become familiar with how the new autotool build system works so that they can convert their applications as time permits. + +<a name="background"></a> +## Background + +During the past two years, several research projects have explored how to modularized and autotool the source tree. We can learn a great deal from these projects. Below is a description of the projects from two of those directly involved. + + +### Keith Packard's experiences + +The modularization work that Keith did was to split the sources up so that no distribution would have to break one of his packages apart in order to build their distribution -- i.e., no modules would need to be split across package boundaries. Distributing the software is then a matter collecting the pieces, rather than cutting things apart. To do that, he cut it pretty finely. He split it into three main chunks: xapps, xlibs, xserver. They are logically separate from a functionality standpoint. Also, he could control access to these separately. + +In doing this, Keith found that the header files were done incorrectly for many extensions. He now has many small packages that only have the specification and the header for the extension. We can learn from the experience that Keith has had in this area for the libraries. The protocol headers are the foundation of the system. We have to get those working/structured properly for the rest to work. + +Keith had to get a change made to 'libtool' (v1.5) so that the correct "so" versions could be specified. This is an absolute requirement for our product, but the change was made long enough ago that most people have it. There is an issue where certain OSes use a different libtool that may not have this change. + +Keith did less work with the xapps, since he doesn't use many of them. Plus, autotooling an X application is simple; autotooling the libraries was a longer process. + +Keith hasn't split the Xserver into pieces, since he treated it as just an application. However, for our modularization project, he pointed out that shipping individual drivers as separate modules is a fundamental goal, so we will need to do additional work along the lines of what was done with Debrix. + + +### Adam Jackson's experiences with Debrix + +Debrix was started by Daniel Stone as a second attempt at autotooling the Xorg server. The previous attempt was named "Xizzle" and floundered due to the DDX build-time dependence on various DIX config options discussed elsewhere. Daniel did most of the initial bootstrapping design, I imported most of the driver and input modules, and Jakub Stachowski contributed several autotooled extension modules. + +The Debrix model split the server into four basic components: + + * server core (cvs module name 'debrix') + * video drivers ('debrix-driver-ati' etc.) + * input drivers ('debrix-input-mouse' etc.) + * dynamically loadable extensions ('debrix-extension-dbe' etc.) +Some of the design decisions made in Debrix: + + * The server component consisted of the xfree86 DDX, including the core dynamic modules like int10 and ddc. + * The video/input/extension modules were split off on the assumption that those would be the pieces users would be most likely to want to replace piecewise. + * To enable the non-server modules to build, the server component installed server API headers to $(PREFIX)/include/xorg. The "config.h" generated during the server build was installed as "debrix.h", so drivers could see the options used to build the server. +Some of the issues we encountered: + + * Debrix was used as a staging area for the dlloader work that eventually landed in Xorg. We considered using libtool's 'ltdl' library instead, since some platforms don't have libdl but have their own APIs for dynamically loading modules, but this was quickly rejected. ltdl places some strange constraints on module usage and would require major ABI changes in basically every driver to accommodate ltdl's rather absurd symbol naming requirements. The executive decision was that platforms that didn't have libdl could implement it in 50 lines of API wrappers for much less pain. + * GLX support was hard to factor out. The server's GLcore software rasterizer requires a copy of the Mesa source to build, as well as some server-specific code. Jakub did have this working but it required telling the build process where to find a Mesa source tree via a configure option. This is unwieldy and will need to be addressed for 7.0. + * int10 support was initially through vm86 only. The x86emu version was added later, but x86emu lives under extras and thus might present a special case for the modular tree structure. Debrix simply imported it whole, but this is clearly wrong. + * No other DDXes besides the xfree86 DDX were attempted. The xnest, xwin, and xgl DDXes have been autotooled in Keith's xserver project. The darwin, dmx, sun, sunlynx, vfb, and xprint DDXes have not (to my knowledge) ever been autotooled. sun and sunlynx can probably be dropped at this point, but any lurking issues in the remaining imake-only DDXes are therefore still lurking. + * Docs and fonts are also logically separate, and were not attempted in Debrix. + +<a name="modulartree"></a> +## The monolithic and modular source trees + +This section outlines a proposal for what the modular source tree could look like. It provides details on each module's contents, the public interfaces, the dependencies between modules, and rationale. This and the next two sections are the heart of this proposal, and the parts that need to be accepted by the community before begin the modularization work. + +It is important to note that the modular source tree is expected to contain the same code as the monolithic tree, but will be organized and built in a different way. For example, the code will be organized into logical modules. Autotools ([[http://sources.redhat.com/autobook/|http://sources.redhat.com/autobook/]]) will be used to build the modular sources individually, and with the help of jhbuild and other support tools, we will continue to be able to create completely self-contained builds. + +The monolithic source tree will continue to exist as a self-contained source tree that can be built with imake, but it is expected that people will transition to the modular tree for future development (see the next section). We propose that both trees should co-exist side-by-side in the xorg CVS project hosted on freedesktop.org (see Figure 1 below). + +[[!img http://www.freedesktop.org/~kem/modular/figure1.gif] + +From the Figure above, the monolithic source tree will continue in the `xc` hierarchy within the xorg project. Along side of it will be several separate modules: **app**, **lib**, **proto**, **xserver**, **driver**, **font**, **doc**, and **util**. Each of these modules will be detailed below. Not shown in Figure 1 are the _extras_, which will exist outside of the source tree and contain only those source tarballs required to build the tree, but for which xorg is not the canonical source repository. + +The applications module: **app** + + * Applications are relatively straight forward to autotool. + * Each app will be placed into a subdirectory of its own within the **app** module, and will not depend on any other apps being present within the checked-out module. + * Each app will have its own dependencies on specific libraries from the **lib** module being installed. +The libraries module: **lib** + + * The libraries are one of the more difficult parts of the tree to modularize since they depend on both the API headers as well as the protocol headers, and other modules require them to be built and installed. + * The API headers and protocol are the public interface to our system. + * The API headers will be included with their respective libraries in this module. + * The protocol headers are required by both the **lib** and **xserver** modules and will be split into a **proto** module (see below). + * After these dependencies were worked out, the libraries become relatively straightforward to autotool. + * As with the other modules, each library will be placed into a separate subdirectory within the **lib** module and will not have any build-time source dependencies on other libs being present within the checked-out module. + * Library revisions have 3 component revisions, x.y.z, where: + * x changes when the ABI is incompatible with the previous revision + * y changes when the ABI is changed, but remains compatible + * z changes when bugs are fixed that don't change the ABI + * Note that some platforms only have 1 or 2 component revisions for their libraries. On these systems, either the second component (y) could be bumped, or symbol versioning could be used by vendors who package the libraries. + * By default, all libraries are built as shared objects; however, with other build options, static, profiled and debug versions can be built. +The protocol module: **proto** + + * As noted above, this module contains the protocol headers that are required to build the **lib** and **xserver** modules. + * In addition, the protocol specifications will be included in this module. +The X server module: **xserver** + + * The X server is also one of the more difficult parts of the tree to modularize since it also has external dependencies, there is a strong desire among the vendors to separate the drivers into their own modules, and the different DDXs support different build options. + * The XFree86 drivers depend on the X server headers, and since we are splitting the drivers into a separate module, these headers will need to be installed before the **driver** module can built. These headers will installed in /usr/include/.../xserver as part of the normal install target. A special DDK install could also be added, if that proved useful. + * At some point we may want to investigate splitting each of the DDXs into separate modules, but not at this time. The current design does not preclude doing this research in the future. + * The **xserver** module depends on the **proto** module, and some of the DDXs depend on the **lib** module (e.g., Xnest, DMX). + * As noted above, some DDXs require different built options, which implies that not all DDXs will be able to use the same dix, os, mi, etc. compile. However, they can and should share the same source code. For example, the kdrive server does not support XINPUT whereas the Xorg server does, so dix (and other subdirs) will need to be built differently for each server. Note that these conflicts can be detected at configure time. + * The basic tree structure in the **xserver** module will look similar to the one used in the monolithic tree under `xc/programs/Xserver`. Notable exceptions include the drivers that will be moved to their own module (see below), and support programs that could be moved to the **app** module. +The XFree86 drivers module: **driver** + + * Vendors have expressed a strong desire to be able to ship updates to individual drivers as bugs are fixed, so they have been split out into their own module. + * The drivers consist of both input and output (i.e., video) drivers. + * Each driver will be completely self-contained and placed in a separate subdir within the module, with the subdir name reflecting the driver interface and the device that it supports (e.g., `xaa-mga`, `kaa-ati`, `xf86input-mouse`, etc.). + * The **driver** module depends on the headers from the **xserver** module being installed. + * Vendors can choose to distribute the entire **driver** module as a whole, or they can subdivide this module into finer components if desired. +The font module: **font** + + * This module contains the fonts traditionally distributed with the monolithic releases. + * Note that some fonts have more restrictive licenses and these should be fully documented in this module. + * The **font** module depends on the font tools that will be included in the **app** module be installed. +The documentation module: **doc** + + * This module contains the documentation traditionally distributed with the monolithic releases that has not been moved to another module. + * The majority of documentation in `xc/doc` will be relocated to the module that they document. For example, the protocol specifications will be moved to the **proto** module and the library docs will be moved to the **lib** module. +The build utilities module: **util** + + * This module contains the build tools and configuration files for legacy applications and libraries that have not been converted to use the autotools. + * Other utilities will also be placed here (e.g., makedepend, lndir and mkshadow). +The _extras_: + + * This is not a module, but rather a separate cache of known working tarballs required to build various modules (e.g., Mesa, freetype). + * It is expected that the vendors will include known working and supported versions of these extras in their OS releases. + * By default, the modules described above will build using the installed versions, but can be overridden when necessary. + * These tarballs are made available as a convenience to those doing development on OSes that don't have the latest known working versions. + +<a name="transition"></a> +## Transitioning from monolithic to modular + +Now that we've seen what the modular source tree could look like in the section above, we can explain how to transition from our current monolithic tree to the proposed modular one. The transition can begin once this proposal has been finalized and accepted. Figure 2 shows the outline of how this transition will happen. + +[[!img http://www.freedesktop.org/~kem/modular/figure2.gif] + +The modularization effort will begin by creating the top level modules. The order in which to create them is implicit in their dependencies (see previous section). During this development period, our goal is to share source files between both the monolithic and modular trees. + +Several options were investigated for how to share source files during this development period including copying the ,v files as each module is created, creating symlinks within the CVS repository, and modifying the pre- and/or post-checkin scripts. Each of these options had significant downsides. + +The solution we propose to share the source files is for developers working on modularization to use a script to populate their local modular trees with symlinks from a checked out version of the monolithic tree. During the initial development phase, the only files that will be checked directly into the modular tree -- and not in the monolithic tree -- are the ones related to the autotool build environment (e.g., configure.ac, Makefile.am). The symlink script will be updated as new modules are added or as files are moved around. If source file changes are required, then the developer working on modularization can make and test those changes in their local modular tree, and when the changes are ready to be checked in, they do so from the monolithic tree. + +While this initial modular development occurs, development will continue as normal in the monolithic HEAD. Once the modular tree reaches a suitably stable point in all of the modules, both trees will be frozen for new features (Devel Freeze in Figure 2). We expected that this freeze will be announced several weeks before it takes place. At that time, the first release candidate (RC1) will be tagged, and we will begin to stabilize both trees for release. + +During this stabilization phase, release testing will begin on both the modular and monolithic trees. The script that populates the modular tree with symlinks will continue to be used, and files will continue to be checked in from the monolithic tree. Additional release candidates will be tagged as bugs are fixed and the release stabilizes. + +When the modular and monolithic trees reach the point where they could be released, the ,v files that have been symlinked will be copied within the CVS repository and a release candidate will be tagged (RCn in Figure 2). Additional testing will occur and any bugs caused by the copying of the ,v files will be fixed. Only major show stopper bug fixes will be accepted at that time, and they will need to be checked into both the monolithic and modular source trees. + +When both releases are ready (Release Tag in Figure 2), the monolithic tree will be tagged with XORG-6_9_0 and the modular tree will be tagged with XORG-7_0_0. In addition, the 6.9 and 7.0 branches will created in their respective trees. + +This plan was designed to ensure that the actual content of both the X11``R6.9 and X11``R7 releases are the same, so that no new features currently under development in the monolithic tree HEAD are left behind. Also, it allows those vendors who are not ready to move to a modular tree to have access to all of the latest features in the X11``R6.9 release. + + +<a name="future"></a> +## Future modular releases + +Looking forward to the time after the initial release, modularization will change the way packages are added to the CVS tree and the release process. This section proposes how these tasks could be handled in the future. + +Future X.Org Foundation releases can be constructed from an official list of the packages in the modular tree (along with specific package versions). This official release list should be maintained by the [[Architecture Working Group|ArchitectureWorkingGroup]]. The initial modular release will contain only what is included in the corresponding monolithic release. + +After the initial release, we will open up the modules for new code and packages to be included. Each package will be placed in the most appropriate module. For example, applications can be added to the **app** module, libraries can be added to the **lib** module, etc. The maintainers will be responsible for freezing, stabilizing, and tagging for release their packages and can do so on their own schedules. This should help simply the official release process. + +As new code or packages are added to the modular tree, the maintainers will need to request that their packages be added to the official release list, if they want them included in an official release. By default, their packages will not be included. A formal process for package maintainers to follow in order to have their code included in future official X.Org Foundation releases needs to be defined. This process is not something that we can work out in this proposal as it should be handled within the [[Architecture Working Group|ArchitectureWorkingGroup]]. + +Official releases will be announced well in advance and with specific deadlines, so that both individual package maintainers whose packages are already included on the official release list can get their latest stable packages ready for inclusion, and package maintainers who want to have their packages included have the opportunity to discuss them with the [[Architecture Working Group|ArchitectureWorkingGroup]] before the feature freeze deadline. + +Once the feature freeze deadline is reached, the release wranglers can determine which packages are included by looking at the official release list for the current release. Only packages within a module that are on the release list will be included in the release. However, if code within a package already on release list is not ready to ship (e.g., a new extension in the **xserver** module), then what is included in the official release becomes more complicated. The solution we propose is to require that unfinished development code live only on a branch until it is ready to be released. This solution will allow the new code to be developed on its own schedule and not hold up official releases. It will also help us to minimize the possibility of having to back out code during the release process. + +During the stabilization phase of a release, inter-package testing and debugging can be done by installing the packages from the official package list. If problems are found during testing, bugs can be filed for the package maintainers to fix. Other details of how this process will happen should be worked out within the [[Release Wranglers|ReleaseWorkingGroup]]. + +Once the bugs have been resolved and the release wranglers feel the release is ready to ship, tarballs from the final packages on the official release list will be created and released. + + +<a name="updates"></a> +_Updated 2005-03-31 in preparation to present to Architecture Working Group_ +_Updated 2005-04-11 and 2005-04-22 to remove inaccurate statements_ +_Updated 2005-04-29 to add anchors for external reference_ +_Updated 2005-05-13 to fix typo_ diff --git a/ModularizationWorkingGroup.mdwn b/ModularizationWorkingGroup.mdwn new file mode 100644 index 00000000..d7fadd65 --- /dev/null +++ b/ModularizationWorkingGroup.mdwn @@ -0,0 +1,41 @@ + + +# X.Org Foundation Modularization Working Group + + +## Purpose + +The purpose of this working group is to create a detailed design plan for how to modularize the X.Org Foundation source tree and then implement the plan once it has been approved by the Architecture Working Group. Participation is open to all interested developers. Participants are expected to actively participate in the design discussions, write proposals and other documentation, etc. + +As chair of this working group, my purpose is to organize the discussions, participate in the design and generally facilitate the group's progress toward creating a design and an eventual release. + + +## Status + +A few weeks ago the Modularization Working Group was announced, and several people expressed interest in helping out. Many of them attended the recent X Developers Conference meeting in Boston and talked about how modularization might be accomplished. Since there had not been very much discussion on the mailing lists after the initial announcement, we decided to take advantage of our face to face time to lay the groundwork for creating a proposal. We have now worked through the issues that we discovered in an effort to create a strawman proposal that describes the rationale for modularization, attempts to address the known concerns people have raised, provides background on other modularization efforts, explains what the modularized source tree would look like, outlines the steps required to take this idea from concept to release, and suggests how future modular releases can be handled. + +Since then the Modularization Working Group has discussed the initial strawman proposal, made modifications, and reached consensus that it should be presented to the Architecture Working Group for approval. The proposal was presented to the ArchWG on 4 Apr 2005 and no objections were raised during the discussion period, so it was approved. We are currently discussing implementation plans and have now begun the development phase. If you are interested in joining in this discussion or participating in the development effort, please join us on the mailing list (below). + + +## Mailing list + +A mailing list has been created on our new mailing list system for those who are interested in discussing the strawman proposal and working on modularizing the source tree. To subscribe to this list, please visit: + + * [[http://lists.x.org/mailman/listinfo/xorg-modular|http://lists.x.org/mailman/listinfo/xorg-modular]] +Mail can be sent to this list at **[[xorg-modular@lists.x.org|mailto:xorg-modular@lists.x.org]]** + + +## Modularization resources + +* [[ModularizationProposal|ModularizationProposal]] -- Current modularization proposal. +* [[ModularizationDevelPlan|ModularizationDevelPlan]] -- Current modularization development plan. +* [[ModuleComponentList|ModuleComponentList]] -- List of the proposed module components. +* [[ModularDevelopersGuide|ModularDevelopersGuide]] -- Guide for developers that work in the modular source tree. +* [[X11R7and69TODO|X11R7and69TODO]] -- List of tasks to complete before release + +## Past modularization efforts + +* [[GoingModular|GoingModular]] -- How to get the X.org tree from here to there. +* [[X Libraries|http://www.freedesktop.org/Software/xlibs]] is a project containing modular, autotooled version of X Window System libraries. +* [[X Server|http://www.freedesktop.org/Software/xserver]] is a project containing a modular, autotooled X server implementation. +* [[xapps|http://www.freedesktop.org/Software/xapps]] is a project containing modular, autotooled X applications.
\ No newline at end of file diff --git a/ModuleComponentList.mdwn b/ModuleComponentList.mdwn new file mode 100644 index 00000000..b72eed41 --- /dev/null +++ b/ModuleComponentList.mdwn @@ -0,0 +1,329 @@ + + +# List of X.Org Module Components + +[[!toc ]] + + +## General guidelines + + * Components should be put into the module that best reflects the primary interface for the code. For example, many packages, like Xpm, build both applications and libraries, but the primary interface for Xpm is the library. The applications included, cxpm and sxpm, are ancillary tools. + * Documentation should be included with the primary component. For example, the Xt library man pages which previous existed in xc/doc/man/Xt will be moved to the Xt component in the lib module. + +## app + + * xc/programs/appres + * xc/programs/bdftopcf + * xc/programs/beforelight + * xc/programs/bitmap + * xc/programs/cxpm + * xc/programs/dpsexec + * xc/programs/dpsinfo + * xc/programs/editres + * xc/programs/fonttosfnt + * xc/programs/fslsfonts + * xc/programs/fstobdf + * xc/programs/iceauth + * xc/programs/ico + * xc/programs/lbxproxy + * xc/programs/listres + * xc/programs/luit + * xc/programs/makepsres + * xc/programs/mkcfm + * xc/programs/mkfontdir + * xc/programs/mkfontscale + * xc/programs/oclock + * xc/programs/pclcomp + * xc/programs/proxymngr + * xc/programs/rgb + * xc/programs/rstart + * xc/programs/scripts + * xc/programs/setxkbmap + * xc/programs/showfont + * xc/programs/smproxy + * xc/programs/sxpm + * xc/programs/texteroids + * xc/programs/twm + * xc/programs/viewres + * xc/programs/x11perf + * xc/programs/xauth + * xc/programs/xbiff + * xc/programs/xcalc + * xc/programs/xclipboard + * xc/programs/xclock + * xc/programs/xcmsdb + * xc/programs/xconsole + * xc/programs/xcursorgen + * xc/programs/xdbedizzy + * xc/programs/xditview + * xc/programs/xdm + * xc/programs/xdpyinfo + * xc/programs/xdriinfo + * xc/programs/xedit + * xc/programs/xev + * xc/programs/xeyes + * xc/programs/xf86dga + * xc/programs/xfd + * xc/programs/xfindproxy + * xc/programs/xfontsel + * xc/programs/xfs + * xc/programs/xfsinfo + * xc/programs/xfwp + * xc/programs/xgamma + * xc/programs/xgc + * xc/programs/xhost + * xc/programs/xinit + * xc/programs/xkbcomp + * xc/programs/xkbevd + * xc/programs/xkbprint + * xc/programs/xkbutils + * xc/programs/xkill + * xc/programs/xload + * xc/programs/xlogo + * xc/programs/xlsatoms + * xc/programs/xlsclients + * xc/programs/xlsfonts + * xc/programs/xmag + * xc/programs/xman + * xc/programs/xmessage + * xc/programs/xmh + * xc/programs/xmodmap + * xc/programs/xmore + * xc/programs/xphelloworld + * xc/programs/xplsprinters + * xc/programs/xpr + * xc/programs/xprehashprinterlist + * xc/programs/xprop + * xc/programs/xrandr + * xc/programs/xrdb + * xc/programs/xrefresh + * xc/programs/xrx + * xc/programs/xset + * xc/programs/xsetmode + * xc/programs/xsetpointer + * xc/programs/xsetroot + * xc/programs/xsm + * xc/programs/xstdcmap + * xc/programs/xtrap + * xc/programs/xvidtune + * xc/programs/xvinfo + * xc/programs/xwd + * xc/programs/xwininfo + * xc/programs/xwud + +## lib + + * xc/doc/man (_See note above about including documentation in corresponding library component_) + * xc/lib/FS + * xc/lib/GL + * xc/lib/GLU + * xc/lib/GLw + * Some of the GL libraries may be provided by Mesa instead. + * xc/lib/ICE + * xc/lib/Xaw7 + * xc/lib/SM + * xc/lib/X11 + * xc/include/bitmaps + * xc/nls + * xc/lib/XRes + * xc/lib/XTrap + * xc/lib/Xau + * xc/lib/Xaw + * xc/lib/Xaw6 + * xc/lib/Xbsd + * xc/lib/Xcomposite + * xc/lib/Xcursor + * xc/lib/Xdamage + * xc/lib/Xdmcp + * xc/lib/Xevie + * xc/lib/Xext + * xc/lib/Xfixes + * xc/lib/Xfontcache + * xc/lib/Xft + * xc/lib/Xft1 + * xc/lib/Xi + * xc/lib/Xinerama + * xc/lib/Xmu + * xc/lib/Xmuu + * xc/lib/Xp + * xc/lib/Xpm + * Moved here from xc/extras/Xpm since we are currently the upstream maintainer + * xc/lib/Xprint``App``Util + * xc/lib/Xprint``Util + * xc/lib/Xrandr + * xc/lib/Xrender + * xc/lib/Xss + * xc/lib/Xt + * xc/lib/Xtst + * xc/lib/Xv + * xc/lib/XvMC + * xc/lib/Xxf86dga + * xc/lib/Xxf86misc + * xc/lib/Xxf86rush + * xc/lib/Xxf86vm + * xc/lib/apple + * xc/lib/dmx + * xc/lib/dps + * xc/lib/dpstk + * xc/lib/font + * xc/lib/fontenc + * xc/lib/lbxutil + * xc/lib/misc + * xc/lib/oldX + * xc/lib/psres + * xc/lib/windows + * xc/lib/xkbfile + * xc/lib/xkbui + * xc/lib/xtrans + +## proto + +Note that some of the headers will be moved to the appropriate library component. Only the protocol headers should remain. + + * xc/include + * xc/include/DPS + * xc/include/GL + * xc/include/extensions + * xc/include/fonts + +## xserver + + * xc/programs/Xserver + +## driver + + * xc/programs/Xserver/hw/xfree86/drivers/apm + * xc/programs/Xserver/hw/xfree86/drivers/ark + * xc/programs/Xserver/hw/xfree86/drivers/ati + * xc/programs/Xserver/hw/xfree86/drivers/chips + * xc/programs/Xserver/hw/xfree86/drivers/cirrus + * xc/programs/Xserver/hw/xfree86/drivers/cyrix + * xc/programs/Xserver/hw/xfree86/drivers/dummy + * xc/programs/Xserver/hw/xfree86/drivers/fbdev + * xc/programs/Xserver/hw/xfree86/drivers/glide + * xc/programs/Xserver/hw/xfree86/drivers/glint + * xc/programs/Xserver/hw/xfree86/drivers/i128 + * xc/programs/Xserver/hw/xfree86/drivers/i740 + * xc/programs/Xserver/hw/xfree86/drivers/i810 + * xc/programs/Xserver/hw/xfree86/drivers/i2c + * xc/programs/Xserver/hw/xfree86/drivers/imstt + * xc/programs/Xserver/hw/xfree86/drivers/mga + * xc/programs/Xserver/hw/xfree86/drivers/neomagic + * xc/programs/Xserver/hw/xfree86/drivers/newport + * xc/programs/Xserver/hw/xfree86/drivers/nsc + * xc/programs/Xserver/hw/xfree86/drivers/nv + * xc/programs/Xserver/hw/xfree86/drivers/rendition + * xc/programs/Xserver/hw/xfree86/drivers/s3 + * xc/programs/Xserver/hw/xfree86/drivers/s3virge + * xc/programs/Xserver/hw/xfree86/drivers/savage + * xc/programs/Xserver/hw/xfree86/drivers/siliconmotion + * xc/programs/Xserver/hw/xfree86/drivers/sis + * xc/programs/Xserver/hw/xfree86/drivers/sunbw2 + * xc/programs/Xserver/hw/xfree86/drivers/suncg14 + * xc/programs/Xserver/hw/xfree86/drivers/suncg3 + * xc/programs/Xserver/hw/xfree86/drivers/suncg6 + * xc/programs/Xserver/hw/xfree86/drivers/sunffb + * xc/programs/Xserver/hw/xfree86/drivers/sunleo + * xc/programs/Xserver/hw/xfree86/drivers/suntcx + * xc/programs/Xserver/hw/xfree86/drivers/tdfx + * xc/programs/Xserver/hw/xfree86/drivers/tga + * xc/programs/Xserver/hw/xfree86/drivers/trident + * xc/programs/Xserver/hw/xfree86/drivers/tseng + * xc/programs/Xserver/hw/xfree86/drivers/v4l + * xc/programs/Xserver/hw/xfree86/drivers/vesa + * xc/programs/Xserver/hw/xfree86/drivers/vga + * xc/programs/Xserver/hw/xfree86/drivers/via + * xc/programs/Xserver/hw/xfree86/drivers/sisusb + * xc/programs/Xserver/hw/xfree86/drivers/vmware + * xc/programs/Xserver/hw/xfree86/drivers/voodoo + * xc/programs/Xserver/hw/xfree86/drivers/wsfb + * xc/programs/Xserver/hw/xfree86/input/acecad + * xc/programs/Xserver/hw/xfree86/input/aiptek + * xc/programs/Xserver/hw/xfree86/input/calcomp + * xc/programs/Xserver/hw/xfree86/input/citron + * xc/programs/Xserver/hw/xfree86/input/digitaledge + * xc/programs/Xserver/hw/xfree86/input/dmc + * xc/programs/Xserver/hw/xfree86/input/dynapro + * xc/programs/Xserver/hw/xfree86/input/elo2300 + * xc/programs/Xserver/hw/xfree86/input/elographics + * xc/programs/Xserver/hw/xfree86/input/fpit + * xc/programs/Xserver/hw/xfree86/input/hyperpen + * xc/programs/Xserver/hw/xfree86/input/jamstudio + * xc/programs/Xserver/hw/xfree86/input/joystick + * xc/programs/Xserver/hw/xfree86/input/keyboard + * xc/programs/Xserver/hw/xfree86/input/magellan + * xc/programs/Xserver/hw/xfree86/input/magictouch + * xc/programs/Xserver/hw/xfree86/input/microtouch + * xc/programs/Xserver/hw/xfree86/input/mouse + * xc/programs/Xserver/hw/xfree86/input/mutouch + * xc/programs/Xserver/hw/xfree86/input/palmax + * xc/programs/Xserver/hw/xfree86/input/penmount + * xc/programs/Xserver/hw/xfree86/input/sample + * xc/programs/Xserver/hw/xfree86/input/spaceorb + * xc/programs/Xserver/hw/xfree86/input/summa + * xc/programs/Xserver/hw/xfree86/input/evdev + * xc/programs/Xserver/hw/xfree86/input/tek4957 + * xc/programs/Xserver/hw/xfree86/input/ur98 + * xc/programs/Xserver/hw/xfree86/input/void + * xc/programs/Xserver/hw/xfree86/input/wacom + +## font + + * xc/fonts/bdf + * xc/fonts/bdf/100dpi + * xc/fonts/bdf/75dpi + * xc/fonts/bdf/cyrillic + * xc/fonts/bdf/misc + * xc/fonts/encodings + * xc/fonts/encodings/large + * xc/fonts/scaled + * xc/fonts/scaled/CID + * xc/fonts/scaled/TTF + * xc/fonts/scaled/Ethiopic + * xc/fonts/scaled/Meltho + * xc/fonts/scaled/Speedo + * xc/fonts/scaled/Type1 + * xc/fonts/util + +## doc + + * xc/doc/misc + * xc/doc/util + * xc/doc/hardcopy + * xc/doc/specs +Note that we plan to keep the specs and related docs that have not yet been converted to a modern format in the doc module temporarily. Then, as they are converted to a new format, we will move them to the appropriate component in the proto or lib modules. + + +## util + + * xc/config/cf + * xc/config/util + * xc/config/util/mkshadow + * xc/config/docbook + * xc/config/imake + * xc/config/makedepend + * xc/config/pswrap + * xc/util/memleak + * xc/util/misc + +## Tarballs + +This is not another module, but rather a list of software we depend on that is maintained outside of the X.Org project. In the monolithic tree, they were put into xc/extras. For the modular tree, we will make specific versions of this third-party software available on the website as a convenience for those who don't have the latest know working versions available from their OS vendor. + + * xc/extras/Mesa + * Includes xc/programs/glxgears and xc/programs/glxinfo + * xc/extras/drm + * xc/extras/expat + * xc/extras/fontconfig + * Includes xc/programs/fc-cache, xc/programs/fc-lang and xc/programs/fc-list + * xc/extras/fonts + * We will be the upstream for arabic24 and ClearlyU + * The Bitstream-Vera fonts can be found here: [[http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/|http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/]] + * xc/extras/freetype2 + * xc/extras/ogl-sample + * xc/extras/regex + * xc/extras/rman + * xc/extras/ttf2pt1 + * xc/extras/x86emu + * xc/extras/zlib + * xc/programs/xterm
\ No newline at end of file diff --git a/ModuleDescriptions.mdwn b/ModuleDescriptions.mdwn new file mode 100644 index 00000000..1a6efd45 --- /dev/null +++ b/ModuleDescriptions.mdwn @@ -0,0 +1,298 @@ + +The X11``R7.0 release broke the X Window System source tree into many different modules for each application, library, major protocol extensions, and so on. This page lists what all those modules are. + +The categories I've broken them into are: +Core X11 runtime +: Things every basic desktop system should have to run. You could run specialized/embedded environments with less, but a general purpose desktop should probably have them all. + +Core X11 build/development/install +: Things you don't need for running X, but need to build the Xorg modular tree, or to build/install additional X software or fonts. + +Extended X11 platform +: Additional useful utilities that many general purpose desktops will want to have installed, but not everyone will. + +Legacy X11 platform +: Utilities used in classic X desktops, but which desktops like GNOME and KDE generally provide their own versions of, so you may not need if you plan to exclusively use/support one of those desktops, but would want for users with existing desktop environments. Also, software you may need to build and/or run legacy third-party apps, like apps using Xt-based toolkits like Motif/Xaw or software built with Imakefiles. + +Experimental +: Stuff which will likely become part of the X Core in the future but isn't quite there yet. + +Obsolete/deprecated +: +Things we shipped in this release to complete the monolith -> modular transition, but don't recommend most people use and which will probably not be included in the future. Suggested replacements are shown for each of these. + + +Sample/demo/test apps +: Primarily useful to developers or people needing to test that various extensions are working properly. + + + + +--- + + + + +## Core X11 runtime: + +* app/iceauth - _ICE authority file utility_ +* app/rgb - _X colorname -> RGB mapping database_ +* app/sessreg - _Register X sessions in system utmp/utmpx databases_ +* app/setxkbmap - _set the keyboard using the X Keyboard Extension_ +* app/smproxy - _Session Manager Proxy_ +* app/xauth - _X authority file utility_ +* app/xdpyinfo - _display information utility for X_ +* app/xev - _print contents of X events_ +* app/xhost - _server access control program for X_ +* app/xinit - _X Window System initializer (includes startx)_ +* app/xkbcomp - _compile XKB keyboard description_ +* app/xkill - _kill a client by its X resource_ +* app/xlsatoms - _list interned atoms defined on server_ +* app/xlsclients - _list client applications running on a display_ +* app/xlsfonts - _list X fonts available on X server_ +* app/xmodmap - _utility for modifying keymaps and button mappings_ +* app/xprop - _property displayer for X_ +* app/xrandr - _primitive command line interface to RandR extension_ +* app/xrdb - _X server resource database utility_ +* app/xrefresh - _refresh all or part of an X screen_ +* app/xset - _user preference utility for X_ +* app/xsetmode - _set the mode for an X Input device_ +* app/xsetpointer - _set an X Input device as the main pointer_ +* app/xsm - _X Session Manager_ +* app/xvinfo - _Print out X-Video extension adaptor information_ +* app/xwininfo - _window information utility for X_ +* data/bitmaps - _standard set of X bitmaps_ +* data/cursors - _standard set of X cursors_ +* lib/FS - _X Font Service client library_ +* lib/ICE - _Inter-Client Exchange library_ +* lib/SM - _Session Management library_ +* lib/X11 - _X11 Client library_ +* lib/Xau - _X Authorization routines_ +* lib/Xdmcp - _X Display Manager Control Protocol routines_ +* lib/Xext - _common X Extensions library_ +* lib/Xfont - _X font handling library for server & utilities_ +* lib/Xfontcache - _X-[[TrueType|TrueType]] font cache extension client library_ +* lib/Xft - _Client side font rendering library_ +* lib/Xi - _X Input Extension library_ +* lib/Xinerama - _Xinerama protocol library_ +* lib/Xmu - _X miscellaneous utility routines_ +* lib/Xpm - _XPM format pixmap library_ +* lib/Xrandr - _Xrandr extension library_ +* lib/Xrender - _RENDER extension library_ +* lib/Xv - _Xvideo extension library_ +* lib/Xxf86misc - _XFree86-MISC extension library_ +* lib/Xxf86vm - _XFree86-[[VidMode|VidMode]] extension library_ +* lib/fontenc - _font encoding library_ +* lib/lbxutil - _LBX utility routines_ +* lib/xkbfile - _XKB file handling routines_ +* xserver/xorg - _X servers (including Xorg, Xprt, Xvfb, Xnest, & Xdmx)_ + +### Platform specific: + +* lib/AppleWM - _(MacOS)_ +* lib/WindowsWM - _(Win32)_ +* app/xdriinfo - _query configuration information of DRI drivers (DRI-supporting platforms)_ + + +--- + + + + +## Core X11 build/development/install: + +* app/bdftopcf - _convert X font from Bitmap Distribution Format to Portable Compiled Format_ +* app/mkcfm - _create summaries of CID font metric files_ +* app/mkfontdir - _create an index of X font files in a directory_ +* app/mkfontscale - _create an index of scalable font files for X_ +* app/xcursorgen - _create an X cursor file from PNG images_ +* doc/xorg-sgml-doctools - _document format conversion tools for SGML docs_ +* lib/xtrans - _X Network Transport layer shared code_ +* proto/BigReqs +* proto/Fontcache - _font cache header files_ +* proto/Fonts - _font library header files_ +* proto/GL - _GL/GLX (3D) header files_ +* proto/Input - _Xinput header files_ +* proto/KB - _XKB (keyboard) extension header files_ +* proto/PM - _X Proxy Management header files_ +* proto/Xinerama +* proto/Randr +* proto/Render +* proto/Resource +* proto/ScrnSaver - _X [[ScreenSaver|ScreenSaver]] extension header files_ +* proto/Video +* proto/X11 +* proto/XCMisc +* proto/XExt +* proto/XF86Misc +* proto/XF86VidMode +* util/macros - _autoconf macros used in X modular configure.ac files_ + +### Platform specific: + +* proto/AppleWM - _(MacOS)_ +* proto/WindowsWM - _(Win32)_ +* proto/XF86DRI - _(DRI-supporting platforms)_ + + +--- + + + + +## Extended X11 platform: + +* app/bitmap - _XBM format bitmap editor and converter utilities_ +* app/scripts (xauth_switch_to_sun-des-1) - _Secure RPC (SUN-DES-1) helper script_ +* app/xcmsdb - _Device Color Characterization utility for X Color Management System_ +* app/xfd - _display all the characters in an X font_ +* app/xfontsel - _point and click selection of X11 font names_ +* app/xgamma - _Alter a monitor's gamma correction through the X server_ +* app/xkbprint - _print an XKB keyboard description_ +* app/xload - _system load average display for X_ +* app/xmag - _magnify parts of the screen_ +* app/xman - _Unix manual page viewer_ +* app/xmore - _plain text display program for the X Window System_ +* app/xpr - _print an X window dump from xwd_ +* app/xrx - _"Broadway"_ +* app/xvidtune - _video mode tuner for Xorg_ +* app/xwd - _dump current contents of X window or screen to file_ +* app/xwud - _display an X window dump from xwd_ +* lib/XRes - _X Resource extension_ +* lib/XScrnSaver - _MIT-SCREEN-SAVER extension_ +* lib/XTrap - _X Trap extension_ +* lib/Xcursor +* lib/Xtst +* lib/XvMC +* lib/Xxf86dga +* lib/dmx +* lib/xkbui +* proto/DMX +* proto/Record +* proto/Trap +* proto/XF86BigFont +* proto/XF86DGA +* proto/XF86Rush + +### X Font Server & related tools: + +* app/fslsfonts - _list fonts served by X font server_ +* app/fstobdf - _generate BDF font from X font server_ +* app/showfont - _show information about X font from font server_ +* app/xfs - _X Font Server_ +* app/xfsinfo - _X font server information utility_ + +### Xprint & related software: + +* app/pclcomp - _Compress PCL printer image output files_ +* app/xplsprinters - _List Xprint printers_ +* app/xprehashprinterlist - _Rehash list of Xprint printers_ +* lib/Xp - _Xprint client library_ +* lib/XprintAppUtil - _Xprint application utility routines_ +* lib/XprintUtil - _Xprint application utility routines_ +* proto/Print - _Xprint Protocol_ + +### Platform specific: + +* app/constype - _print type of console_ (SPARC & Sun/3 platforms, plus Solaris x86) + + +--- + + + + +## Legacy X11 platform: + +* app/luit - _Convert terminal i/o from legacy encodings to UTF-8_ +* app/oclock - _round X clock_ +* app/twm - _simple window manager_ +* app/xbiff - _watch mailboxes for new message delivery_ +* app/xcalc - _scientific calculator for X_ +* app/xclipboard - _X clipboard manager_ +* app/xclock - _X clock_ +* app/xconsole - _monitor system console messages with X_ +* app/xditview - _display ditroff output_ +* app/xdm - _X Display Manager / XDMCP server_ +* app/xedit - _simple text editor for X_ +* app/xmessage - _display a message or query in a window_ +* app/xsetroot - _root window parameter setting utility for X_ +* app/xstdcmap - _X standard colormap utility_ +* lib/Xaw - _Athena Widgets toolkit_ + +### Xt Toolkit Intrinsics and related software: + +* app/appres - _list X application resource database_ +* app/editres - _dynamic resource editor for X Toolkit applications_ +* app/listres - _list resources in widgets_ +* app/viewres - _graphical class/resource browser for Xt_ +* lib/Xt - _X Toolkit Intrinsics library_ + +### X Network Proxies & Remote Start: + +(Preferred replacements: ssh and/or NX) + +* app/lbxproxy - _Low [[BandWidth|BandWidth]] X proxy_ +* app/proxymngr - _proxy manager service_ +* app/rstart - _Remote Start client_ +* app/xfindproxy - _locate proxy services_ +* app/xfwp - _X Firewall Proxy_ + +### Imake build system: + +* util/cf - _Imake config files_ +* util/imake - _Imake utility_ +* util/makedepend - _makefile dependency listing generator_ +* util/xmkmf - _Imake helper utility_ + + +--- + + + + +## Experimental: + +* app/fonttosfnt - _Wrap a bitmap font in a sfnt ([[TrueType|TrueType]]) wrapper_ +* lib/Xcomposite - _Composite extension_ +* lib/Xdamage - _Damage extension_ +* lib/Xevie - _XEvIE extension_ +* lib/Xfixes - _X-Fixes extension_ +* proto/Composite - _Composite extension_ +* proto/Damage - _Damage extension_ +* proto/EvIE - _XEvIE extension_ +* proto/Fixes - _X-Fixes extension_ + + +--- + + + + +## Obsolete/Deprecated: + +* app/scripts (xon) - _run X command on another system via rsh_ (Preferred replacement: ssh) +* app/xmh - _X interface to MH mail tools_ (Preferred replacement: exmh) +* data/xkbdata - _XKB keyboard configuration data_ (Preferred replacement: xkb-config) +* lib/oldX - _X version 10 backwards compatibility_ (Preferred replacement: X11!) + + +--- + + + + +## Sample/demo/test applications: + +* app/beforelight - _MIT-SCREEN-SAVER sample_ +* app/ico - _animate an icosahedron or other polyhedron_ +* app/x11perf - _simple X server performance benchmarker_ +* app/xdbedizzy - _DBE sample_ +* app/xeyes - _follow the mouse/SHAPE extension X demo_ +* app/xf86dga - _test program for the XFree86-DGA extension_ +* app/xgc - _X graphics demo_ +* app/xkbevd - _XKB event daemon demo_ +* app/xkbutils - _XKB utility demos_ +* app/xlogo - _Draw (old) X logo_ +* app/xphelloworld - _Xprint sample applications_ +* app/xtrap - _XTrap sample clients_
\ No newline at end of file diff --git a/NVIDIAProprietaryDriver.mdwn b/NVIDIAProprietaryDriver.mdwn new file mode 100644 index 00000000..75ae9157 --- /dev/null +++ b/NVIDIAProprietaryDriver.mdwn @@ -0,0 +1,47 @@ + + +# NVIDIA Proprietary Driver + +This page describes the closed-source, proprietary driver created by nVidia themselves. See the [[nv|nv]] page for a description of the open-source driver created by Mark Vojkovich and maintained now by Aaron Plattner. + +The new proprietary driver from Nvidia is easier to install than prior versions as Nvidia has shifted to a single file for installation. They have attempted to make the setup as simple as possible with the installation script attempting to determine which kernel version you need. This has helped a lot but there are still some common problems. The best place to look for information about the Nvidia driver is [[Nvidia's website|http://www.nvidia.com/]]. + + + +--- + + + +The following is a common problem: (excerpted from Nvidia's docs) + +Q: My X server fails to start, and my Xorg log file contains the error: `"(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!"` + +A: Nothing will work if the NVIDIA kernel module doesn't function properly. If you see anything in the X log file like "(EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!" then there is most likely a problem with the NVIDIA kernel module. First, you should verify that if you installed from rpm that the rpm was built specifically for the kernel you are using. You should also check that the module is loaded ('/sbin/lsmod'); if it is not loaded try loading it explicitly with 'insmod' or 'modprobe' (be sure to exit the X server before installing a new kernel module). If you receive errors about unresolved symbols, then the kernel module has most likely been built using header files for a different kernel revision than what you are running. You can explicitly control what kernel header files are used when building the NVIDIA kernel module with the --kernel-include-dir option (see `sh NVIDIA-Linux-x86-1.0-4349.run --advanced-options` for details). + +Please note that the convention for the location of kernel header files changed approximately at the time of the 2.4.0 kernel release, as did the location of kernel modules. If the kernel module fails to load properly, modprobe/insmod may be trying to load an older kernel module (assuming you've upgraded). cd'ing into the directory with the new kernel module and doing 'insmod ./nvidia.o' may help. + +Another cause may be that the /dev/nvidia* device files may be missing. To recreate this files simply run this script (as root). It assumes your users who have GUI access are in group "video"): +[[!format txt """ +for i in 0 1 2 3 4 5 6 7; do + node="/dev/nvidia$i" + rm -f $node + mknod $node c 195 $i || echo "mknod \"$node\"" + chmod 0660 $node || echo "chmod \"$node\"" + chown :video $node || echo "chown \"$node\"" +done + +node="/dev/nvidiactl" +rm -f $node +mknod $node c 195 255 || echo "mknod \"$node\"" +chmod 0666 $node || echo "chmod \"$node\"" +chown :video $node || echo "chown \"$node\"" +"""]] +Finally, the NVIDIA kernel module may print error messages indicating a problem -- to view these messages please check /var/log/messages, or wherever syslog is directed to place kernel messages. These messages are prepended with "NVRM". + + +## Some links to additional information on this driver + +* [[Nvidia's ReadMe for version 8756|ftp://download.nvidia.com/XFree86/Linux-x86/1.0-8756/README/index.html]] +* [[Nvidia's ReadMe for version 4349|ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4349/README.txt]] +* [[Download Nvidia drivers for Linux, FreeBSD, and Solaris|http://www.nvidia.com/object/unix.html]] +* [[A Forum for Nvidia users|http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=13]]
\ No newline at end of file diff --git a/NewModuleGuidelines.mdwn b/NewModuleGuidelines.mdwn new file mode 100644 index 00000000..cbcd5e9a --- /dev/null +++ b/NewModuleGuidelines.mdwn @@ -0,0 +1,368 @@ + + +## New Module Guidelines + +This text was written for developers converting to modular structure during the 7.0 bootstrap. It may still be useful to people adding new modules to the tree. + +[[!toc ]] + + +## Guidelines for module components + +It is impossible to pre-specify all possible structures for every module component, so guidelines are given and should be followed whenever possible. In the next section, general guidelines are given for what should be included in all module components, general style, etc. Following that section are guidelines for the basic structure of each module and their module components. + + +### General guidelines for all module components + +All module components should have the following files: + +* ChangeLog: list of changes automatically generated from git by Makefile.am +* COPYING: the correct license for the package +* INSTALL: standard instructions for the building and installing package, automatically generated +* README: a brief description and appropriate URLs +* autogen.sh: script that invokes Autotools to build and configure the package +* configure.ac: Autoconf input file +* Makefile.am: top level Automake input file (others will be added to each subdir within the component) +* .gitignore: tells Git to ignore files that are not tracked in the package repository + +### Configuration files content guidelines + +The GNU Build System is composed of user hand written _input_ files (e.g. configure.ac, Makefile.am) from which _output_ files (e.g. configure, Makefile.in, Makefile, etc...) are generated. The former are checked-in the source tree while the latter are not. For a complete list of generated files, refer to the defaults section in the .gitignore file. + +**NOTE:** All X.Org modules are currently being revisited to follow these guidelines. +#### configure.ac + +This is a fictitious configuration to illustrate the most common statements encountered in the configure.ac file. +[[!format txt """ +# Initialize Autoconf +AC_PREREQ([x.yy]) +AC_INIT([xsample], [1.0.1], + [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [xsample]) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_MACRO_DIR([m4]) +AC_CONFIG_HEADERS([config.h]) + +# Initialize Automake +AM_INIT_AUTOMAKE([foreign dist-bzip2]) +AM_MAINTAINER_MODE + +# Initialize libtool +AC_PROG_LIBTOOL + +# Require xorg-macros minimum of 1.10 for DocBook/XML +m4_ifndef([XORG_MACROS_VERSION], + [m4_fatal([must install xorg-macros 1.10 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.10) +XORG_DEFAULT_OPTIONS + +# Checks for programs. +AC_PROG_LN_S + +# Obtain compiler/linker options for dependencies +PKG_CHECK_MODULES(XPM, xproto x11) + +AC_CONFIG_FILES([Makefile + src/Makefile]) +AC_OUTPUT +"""]] +An explanation of some of the statements: + +**AC_PREREQ([_x.yy_])** + +This will prevent a version older than _x.yy_ of Autoconf to create the package configuration. It is set to the minimum version at which all X.Org modules will configure correctly. This can be found in the [[ModularDevelopersGuide#GNUBuildSystem|ModularDevelopersGuide]] wiki. + +**AC_INIT (package, version, [bug-report], [tarname])** + +Parameters: + +1. The package short descriptive name or the tar name which is often the source subdirectory. +1. The package version number as advised by release management. See [[X.Org and XFree86 Version Numbering Schemes.|http://www.x.org/releases/X11R7.5/doc/Versions.html/]] +1. Exactly this URL: [[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg|https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]] +1. The name (lower case) of the tarball. If omitted, the default value is the first parameter, lower cased by Autoconf. +**AC_CONFIG_SRCDIR([Makefile.am])** + +This statement tells Autoconf where the configuration is and provides a safety check when using --srcdir in case the directory does not exist. The filename supplied should be the one you are exists. Given all modules have Makefile.am, this filename is preferred so all modules have the same code. + +**AC_CONFIG_MACRO_DIR([m4])** + +Libtool recommends this statement and will store its macros there. Other Autotools may use this statement to find macros. If the module has created its own macros, they should be stored in git under the m4 directory. A common one is _AX_DEFINE_DIR_ from the [[Autoconf Archive.|http://www.gnu.org/software/autoconf-archive/]] + +Do not add `"ACLOCAL_AMFLAGS = -I m4"` in Makefile.am unless the module has a macro checked-in git. Aside from being useless, running the configuration will fail on a freshly cloned module as the m4 directory does not yet exists. + +**AC_CONFIG_HEADERS ([config.h])** + +This macro generates a config.h header file containing C preprocessor #define statements. Macros like AC_CHECK_HEADERS and AC_CHECK_FUNCS causes these #define statements to be created. + +Do not use the deprecated and undocumented _AC_CONFIG_HEADER_ (singular) version. + +**AM_INIT_AUTOMAKE([foreign dist-bzip2])** + +The `foreign` Automake option defines the strictness level. Xorg is not a GNU project, so their rules will not be enforced. The `dist-bzip2` option causes Automake to generate both a GNU zip and bzip2 compressed archive. + +**AM_MAINTAINER_MODE** + +This disables the _maintainer build rules_ for files that are usually distributed and that users should normally not have to update. The autogen.sh script enables them through --enable-maintainer-mode. + +**AC_PROG_LIBTOOL** + +This statement is not a program check as its name implies, it initializes the libtool library-building support services. It is sometimes preceded by `AC_DISABLE_STATIC` to prevent the creation of a static version of the library. In version 2 of libtool, this statement is more appropriately named `LT_INIT`. + +**AC_PROG_`XXX`** + +A number of program checks are performed to insure the desired program is available on the platform and invoked with the appropriate options. Most of the common tools such as `grep` and `sed` have already been checked by the compiler or by the various macros contained in `XORG_DEFAULT_OPTIONS`. + +**XORG_DEFAULT_OPTIONS** + +This macro expands into several macros and provide several build functions. Refer to the module generated aclocal.m4 file as this is subject to change. + +* XORG_CWARNFLAGS: platform adjusted compiler warning flags +* XORG_STRICT_OPTION: additional warning flags +* XORG_RELEASE_VERSION: defines variables for major, minor and patch level +* XORG_CHANGELOG: contains a makefile rule which creates the ChangeLog file from Git +* XORG_INSTALL: contains a makefile rule which provides the INSTALL file in the module root directory +* XORG_MANPAGE_SECTIONS: platform adjusted man page section number +The above macros invoke the following Autoconf macros: + +* AC_PROG_INSTALL +* AC_PROG_CC_C99 +* AC_PROG_SED +* AC_CANONICAL_HOST + +#### Makefile.am + +This is the minimum top level Makefile.am input file. It must contain targets to generate the ChangeLog and INSTALL files. It invokes the Makefile.am from the src subdirectory. The macro `XORG_DEFAULT_OPTIONS` is required in configure.ac. + + +[[!format txt """ +SUBDIRS = src + +.PHONY: ChangeLog INSTALL +INSTALL: + $(INSTALL_CMD) +ChangeLog: + $(CHANGELOG_CMD) + +dist-hook: ChangeLog INSTALL +"""]] + +#### autogen.sh + +It's role is to initiate the build of the package without the knowledge of the Autotools commands and options. It enables the _maintainer build rules_ in the package that are otherwise turned off by default. + + +#### .gitignore + +The .gitignore is part of the Git source code repository. It's role is to tell Git which file patterns to ignore (e.g *.o). Xorg has created a template with a defaults section which covers all generated files by the Autotools, complier, linker, lex, yacc, etc... Those generated file names will be ignored in all the subdirectories as well. + +What is left for you to do is to add file names or name patterns at the bottom of the file that are specific to your modules. You can have a .gitignore in subdirectories as well. + + +#### README + +The README file should contain, at a minimum, the package short descriptive name, a brief description and the X.Org project URLs. + + +[[!format txt """ + X Sample Module + +This module provides a sample for the creation and maintenance of an X Window System module. + +All questions regarding this software should be directed at the +Xorg mailing list: + + http://lists.freedesktop.org/mailman/listinfo/xorg + +Please submit bug reports to the Xorg bugzilla: + + https://bugs.freedesktop.org/enter_bug.cgi?product=xorg + +The master development code repository can be found at: + + git://anongit.freedesktop.org/git/xorg/sample/module + + http://cgit.freedesktop.org/xorg/sample/module + +For patch submission instructions, see: + + http://www.x.org/wiki/Development/Documentation/SubmittingPatches + +For more information on the git code manager, see: + + http://wiki.x.org/wiki/GitPage + +"""]] + +#### A Warning About Autotools Warnings and Suggestions + +The version of the Autotools you are currently working with is most likely to be a lot more recent than the minimum version required by X.Org. This means your version contains features that are not available on earlier versions. Autoconf may issue warnings or make suggestions, but you should not implement them if they use features unavailable in the minimum version. + +One example is the silent rules feature from Automake 1.11 which is not available in 1.10. Because is was a popular feature, a backward compatibility workaround was introduced in util-macros which made this feature a noop on 1.10. + + +### Guidelines for proto + +The proto module's directory structure is as follows: + + +[[!format txt """ + proto/x11proto + proto/compositeproto + proto/damageproto + proto/dmxproto + proto/evieproto + proto/fixesproto + ... +"""]] +Core protocol headers and protocol docs are in the X11 component. Extension protocol headers and protocol docs are put into a component named the same as the extension. + +Please note that all changes to the protocol of one of the official X.Org Foundation components must be discussed with the [[Architecture Working Group|ArchitectureWorkingGroup]] before changes are checked into the trunk. + +The basic structure of each component is as follows: + +* _extensionname_proto.h: protocol headers +* _extensionname_proto.txt: description of protocol +* _extensionname_proto.pc.in: pkg-config metadata file for use with the autotools (note that the core protocol metadata file will be named xproto.pc.in to be more descriptive and not conflict with xlib's metadata file) +* specs: the protocol specifications when available in DocBook/XML format +* plus the files listed in the general guidelines above + +### Guidelines for lib + +The lib module's directory structure is as follows: + + +[[!format txt """ + lib/libX11 + lib/libXt + lib/libXcomposite + lib/libICE + lib/libSM + lib/libdmx + ... +"""]] +Some libraries will have corresponding protocol headers that are kept in the proto module, while others will be standalone libraries. + +The basic structure of each component should be: + +* doc: any library documentation (e.g., howto's, specs, books, etc.) +* include: the library's public headers, which are placed in a subdir corresponding to where they go in the system (e.g., the Xlib headers go in `include/X11`, and the Xv headers go in `include/X11/extensions`). +* man: man pages for library +* src: source code +* specs: specification documents +* doc: other documentation +* _library-name_.pc.in: pkg-config metadata file for use with the autotools +* plus the files listed in the general guidelines above +Note that some libraries do not have any documentation or man pages, so those subdirs should not be created until they are needed. + + +### Guidelines for server + +The server module's directory structure is as follows: + + +[[!format txt """ + xserver/dix + xserver/hw + xserver/mi + xserver/os + xserver/mi + xserver/Xext + ... +"""]] +Within the xserver module, the structure is the same as found in the monolithic tree in `xc/programs/Xserver` except that the drivers are not included in this module. Instead, the drivers have been moved to the driver module (see below). + + +### Guidelines for driver + +The driver module's directory structure is as follows: + + +[[!format txt """ + driver/xf86-video-ati + driver/xf86-video-mga + driver/xf86-video-i810 + driver/xf86-input-mouse + driver/xf86-input-keyboard + driver/xf86-input-spaceorb + ... +"""]] +The name of each component is created from the DDX, driver interface, and device(s) that it supports. Currently, there is one DDX (xf86) and two driver interfaces (video and input). As other driver interfaces are developed, they should be added to the list above. + +The basic structure of each component should be: + +* doc: any driver documentation (e.g., howto's, info files, etc.) +* man: man pages for the driver +* src: source code +* util: special utilities used by the driver developers and/or users +* plus the files listed in the general guidelines above +Note that some drivers do not have any docs, man pages or utilities, so those subdirs should not be created until they are needed. Also, other directories may be necessary that contain code for examples, config tools, etc. + + +### Guidelines for app + +The app module's directory structure is as follows: + + +[[!format txt """ + app/xdpyinfo + app/xwd + app/xwud + app/twm + ... +"""]] +The name of most components will be the application name, but when not, it should be descriptive of the component contents. + +Note that it is very difficult to specify a structure for all apps since they vary greatly in complexity and organization, but when no other structure is already available, the one below could be adopted: + +* doc: any application documentation (e.g., howto's, info files, etc.) +* man: man pages for the app +* src: source code for the app +* plus the files listed in the general guidelines above + +### Guidelines for font + +The font module's directory structure is as follows: + + +[[!format txt """ + font/util + font/adobe-100dpi + font/adobe-utopia-100dpi + font/bitstream-type1 + ... +"""]] +The fonts are modularized along foundry and type boundaries, where type is 100dpi, 75dpi, misc, cyrillic, type1, ttf, etc., and the font module components are named _foundary-type_. Note that some fonts have special licenses and should be put into separate components. These separate components should be listed by _foundary-family*-type_. For example, most of the adobe foundry fonts have the same license with the exception of the utopia family fonts, so for the 100dpi adobe fonts, the ones that share the same license are placed in the `adobe-100dpi` component and the utopia fonts are placed in the `adobe-utopia-100dpi` component. + +Note that the license for the fonts in each component should be reflected in the `COPYING` file. + + +### Guidelines for doc + +The doc module's directory structure is as follows: + + +[[!format txt """ + doc/xorg-docs + doc/xorg-sgml-doctools +"""]] +A special case is the documentation that has not yet been converted to a modern format, which will be kept in the doc module until they are converted. At present, these are contained within the xorg-docs component. + + +### Guidelines for util + +The util module's directory structure is as follows: + + +[[!format txt """ + util/macros + util/modular + util/cf + util/gccmakedep + util/imake + util/lndir + util/makedepend +"""]] +This module contains the build tools for the modular tree as well as the build tools and configuration files that were used in the monolithic tree. These are kept around for legacy applications that have not yet been converted to use autotools. + +The build tools for the modular tree are contained in the `modular` component, and the m4 macros used across the entire modular build are contained in the macros component. **Important:** note that when changes are made to the m4 macros, all of the packages in the modular tree that use the macros that you changed are affected, and those packages will need to be rebuilt, have their version numbers bumped and released during the next release cycle. + +Many of the common utilities that are used mainly with imake are contained in the imake component. Others that have uses outside of imake are in their own component directories (e.g., `gccmakedep`, `lndir` and `makedepend`). diff --git a/News.mdwn b/News.mdwn new file mode 100644 index 00000000..977e499d --- /dev/null +++ b/News.mdwn @@ -0,0 +1,25 @@ + +(Listing mode: latest news first) + +* 2010-12-20: [[X11R7.6 released|Other/Press/X11R76Released]] +* 2009-10-26: [[X11R7.5 released|Other/Press/X11R75Released]] +* 2009-02-01: [[Results of Google/X.Org Summer of Code 2008|SummerOfCodeResults2008]] +* 2008-09-23: [[X11R7.4 released|Releases/7.4]] +* 2008-03-20: [[X.Org takes part in in Google Summer of Code 2008|SummerOfCodeIdeas2008]] +* 2007-09-06: [[X11R7.3 released|Releases/7.3]] +* 2007-02-15: [[X11R7.2 released|Other/Press/X11R72Released]] +* 2006-05-22: [[X11R7.1 Released|Other/Press/X11R71Released]] +* 2006-03-20: [[xorg-server 1.0.2 Released|http://lists.freedesktop.org/archives/xorg/2006-March/013993.html]] +* 2006-03-20: [[X.Org Security Advisory: privilege escalation and DoS in X11R6.9, X11R7.0|http://lists.freedesktop.org/archives/xorg/2006-March/013992.html]] +* 2005-12-21: [[X11R6.9 and X11R7.0 Released|PressReleases/X11R6970Released]] +* 2005-02-11: [[X11R6.8.2 Released|PressReleases/X11r682Released]] +* 2004-11-17: [[X.Org Foundation Security Advisory For The X Window System|ftp://ftp.x.org/pub/X11R6.8.1/patches/README.xorg-681-CAN-2004-0914.patch]] +* 2004-09-17: [[X11R6.8.1 Released|http://x.org/XOrg_Foundation_X11R6.8.1.pdf]] +* 2004-09-09: [[X11R6.8.0 Released|News200409091135]] +* 2004-05-07: [[XDevConf 2004|News200405070808]] +* 2004-04-24: [[Ongoing development moved to HEAD|News200404240744]] +* 2004-04-08: [[X.Org Foundation releases X11R6.7.0|News200404080917]] +* 2004-02-25: [[Report on platform compatibility|News20040225]] +You can find a bit more X11 related news at [[freedesktop.org's News page|http://freedesktop.org/wiki/News]]. + +You can find more detailed info on the releases at [[XorgReleases|XorgReleases]]. diff --git a/News20040225.mdwn b/News20040225.mdwn new file mode 100644 index 00000000..2f37c28d --- /dev/null +++ b/News20040225.mdwn @@ -0,0 +1,11 @@ + +The -CURRENT tree of the CVS repository is known to build on the following platforms: + +* Linux (SUSE Linux 9.0) +* Solaris 9 +* Mac OS X 10.3 +* FreeBSD 5.1R +* AIX 5.2 +More platforms are coming soon + +-- Main.[[KalebKeithly|KalebKeithly]] - 25 Feb 2004 diff --git a/News200404080917.mdwn b/News200404080917.mdwn new file mode 100644 index 00000000..2121e934 --- /dev/null +++ b/News200404080917.mdwn @@ -0,0 +1,7 @@ + + +### News heading + +The X.Org Foundation releases X11R6.7.0. + +-- Main.[[KeithPackard|KeithPackard]] - 08 Apr 2004 diff --git a/News200404240744.mdwn b/News200404240744.mdwn new file mode 100644 index 00000000..415f9f8e --- /dev/null +++ b/News200404240744.mdwn @@ -0,0 +1,11 @@ + + +## Ongoing development moved to HEAD + +On April, 23rd 2004 the development branch XORG-CURRENT was moved to the trunk of the CVS repository. If you currently have XORG-CURRENT checked out you can move the HEAD by doing: +[[!format txt """ +cvs update -A -dP +"""]] +The XORG-CURRENT branch has been declared closed. Please don't commit to XORG-CURRENT any more. If you have a branch on XORG-CURRENT and have problems merging back to the development branch (or mreging in new versions of the development branch) please ask on the [[[mailto:xorg''@''freedesktop.org|[mailto:xorg''@''freedesktop.org]][!X.Org mailing list]]. + +-- Main.[[EgbertEich|EgbertEich]] - 24 Apr 2004 diff --git a/News200405070808.mdwn b/News200405070808.mdwn new file mode 100644 index 00000000..10900114 --- /dev/null +++ b/News200405070808.mdwn @@ -0,0 +1,4 @@ + +Federico Mena-Quintero has posted <a href="[[http://primates.ximian.com/~federico/news-2004-04.html#30">his|http://primates.ximian.com/~federico/news-2004-04.html#30">his]] notes</a> of XDevConf 2004 on his web site. There are virtually no tech reporters interested in X much less ones who understand it so we have to make the most of people who care about X and who enjoy writing about it on their own web sites. X has been undergoing a true renaissance of late and can play a unique role in the future as Linux & BSD supporters begin to understand the value and advantage of using X to broadcast content to ubiquitous interactive displays which are attached to wireless networks instead of PC's. + +-- Main.[[GeneMosher|GeneMosher]] - 07 May 2004 diff --git a/News200409091135.mdwn b/News200409091135.mdwn new file mode 100644 index 00000000..6a8f5e2b --- /dev/null +++ b/News200409091135.mdwn @@ -0,0 +1,4 @@ + +[[X11R6|X11R6]].8 Released! + +-- Main.[[JimGettys|JimGettys]] - 09 Sep 2004 diff --git a/OrphanedPages.mdwn b/OrphanedPages.mdwn new file mode 100644 index 00000000..9b60b737 --- /dev/null +++ b/OrphanedPages.mdwn @@ -0,0 +1,2 @@ + +A list of pages no other page links to: [[!orphans ]] diff --git a/Other/Press.mdwn b/Other/Press.mdwn new file mode 100644 index 00000000..ad7b3f1c --- /dev/null +++ b/Other/Press.mdwn @@ -0,0 +1,12 @@ + +This page lists press releases issued by the X.Org Foundation, regarding X.Org. + +* 9th August, 2012: [[X.Org Foundation joins Open Invention Network (OIN) patent non-aggression community|Other/Press/XorgOIN]] +* 2nd August, 2012: [[Call for Proposals 2012|Other/Press/CFP2012]], [[supplement|Other/Press/CFP2012_supplemental]] +* 20th July, 2012: [[X.Org Foundation achieves non-profit public charity status|Other/Press/501c3StatusDetermination]] +* 26th October, 2009: [[X11R7.5 released|Other/Press/X11R75Released]] +* 15th February, 2007: [[X11R7.2 released|Other/Press/X11R72Released]] +* 22nd May, 2006: [[X11R7.1 released|Other/Press/X11R71Released]] +* 21st December, 2005: [[X11R6.9 & X11R7.0 Released|Other/Press/X11R6970Released]] +* 18th April, 2005: [[X Window System Test Suite Released|Other/Press/XTSReleased]] +* 9th February, 2005: [[X11R6.8.2 Released|Other/Press/X11R682Released]]
\ No newline at end of file diff --git a/Other/Press/501c3StatusDetermination.mdwn b/Other/Press/501c3StatusDetermination.mdwn new file mode 100644 index 00000000..45edac8d --- /dev/null +++ b/Other/Press/501c3StatusDetermination.mdwn @@ -0,0 +1,18 @@ + +20 JULY 2012: The X.Org Foundation is pleased to announce that the U.S. Internal Revenue Service has determined that the [[X.Org Foundation|XorgFoundation]] qualifies as a public charity under section 501(c)(3) of the U.S. Internal Revenue Code. This allows for contributions to the Foundation to be considered tax deductible for U.S. taxpayers. + +The Foundation's Board offers our deep gratitude to our legal counsel at the [[Software Freedom Law Center (SFLC)|http://www.softwarefreedom.org/]], including Karen Sandler, Justin Colannino, and Aaron Williamson, for their hard work, guidance, and assistance throughout the multi-year process of applying for this status. + +Contributions to the X.Org Foundation are used to further our mission to support the development of the open source graphics stack based on the X Window System, and to educate students and developers about the technology in the stack. The X Window System is one of the oldest Open Source software projects in the world, since its creation at MIT in 1984, and has become the standard graphical interface across Linux & Unix workstations and servers, and has been included in a number of mobile phones and tablets as well. Foundation members and contributing developers continue to enhance and maintain the existing X software base, while also researching and developing next generation open source graphics technologies such as the [[Wayland project|http://wayland.freedesktop.org]]. + +The Foundation is currently funding stipends for several students to learn about open source development, developer community participation, and the various portions of the graphics stack via [[X.Org's “Endless Vacation of Code” program|XorgEVoC]], which allows students to spend breaks between semesters participating in open source development on the graphics stack. + +Funding from the Foundation will also be used to hold the [[2012 X.Org Developer Conference|Events/XDC2012]], hosted by SUSE Linux GmbH, in Nuremberg, Germany from September 19 through 21, including helping cover travel and lodging expenses for developers and students who could not otherwise afford to attend. This year's conference will include a celebration of the 25th anniversary of the release of X11, the current core standard upon which the window system is based. + +Since its founding, the Foundation has also supported "hackfests" to gather developers together for focused meetings to advance specific areas, held a book sprint to create documentation to better educate users & developers, helped members and students travel to other open source conferences such as FOSDEM to present their work to wider audiences, and obtained access to standards documentation and technical specifications for members to use. + +Membership in the Foundation is open to those who have contributed in some way to the X Window System. Members may vote in annual elections for the Board of Directors and other questions put to the Foundation membership. Further details are available at [[Membership|Membership]]. + +Significant funding for the Foundation has come from Intel, Google, and Oracle (previously Sun Microsystems), as well as from the previous X.Org industry group that was run by The Open Group. With the determination of charitable non-profit status, we will be looking for contributions from a wider range of donors. To contribute, or for any other questions about the Foundation, please contact the [[X.Org Board of Directors|BoardOfDirectors]] at [[board@foundation.x.org|mailto:board@foundation.x.org]]. + +Public information about the Foundation and its projects may be found on the web site [[http://www.x.org/|http://www.x.org/]] - public disclosure of such documents as required by the Internal Revenue Code is at [[http://www.x.org/foundation/|http://www.x.org/foundation/]]. diff --git a/Other/Press/CFP2012.mdwn b/Other/Press/CFP2012.mdwn new file mode 100644 index 00000000..2166c0de --- /dev/null +++ b/Other/Press/CFP2012.mdwn @@ -0,0 +1,15 @@ + +# Call For Proposals **2012 X.Org Developers Conference (XDC 2012)** **19-21 September 2012** **Nürnberg (Nuremberg), Germany** + +The [2012 X.Org Developers Conference] ([[http://www.x.org/wiki/Events/XDC2012|http://www.x.org/wiki/Events/XDC2012]]) is the annual technical meeting for [X Window System]([[http://x.org|http://x.org]]) and [Free Desktop]([[http://freedesktop.org|http://freedesktop.org]]) developers. The attendees will gather to discuss outstanding technical issues related to X and to plan the direction of the X Window System and its software ecosystem. The event is free of charge and open to the general public. + +The XDC 2012 Technical Program Committee (TPC) is requesting proposals for papers and presentations at XDC 2012. While any serious proposal will be gratefully considered, topics of interest to X.org and [[FreeDesktop|FreeDesktop]].org developers are encouraged. There are three particular types of proposal the TPC is seeking: + + 1. Technical talk abstracts: 250-1000 words describing a presentation to be made at XDC 2012. This can be anything: a work-in-progress talk, a proposal for change, analysis of trends, etc. + 1. Informal white papers: 1000+ words on something of interest or relevance to X.org developers, [[FreeDesktop|FreeDesktop]].org developers or the X community at large. These papers will appear in the online conference proceedings of XDC 2012, and are unrefereed (beyond basic checks for legitimacy and relevance). Papers can be refereed if requested in advance. + 1. Technical research papers: 2500+ words in a format and style suitable for refereed technical publication. Papers that are judged acceptable by the TPC and its referees will be published in the printed conference proceedings of XDC 2012, available on a print-on-demand basis online. +XDC 2012 technical presenters will be chosen from the authors of any of these submissions (as well as other presenters invited by the TPC). + +Normally, there is time for everyone who wants to present to do so, but one can never tell. As much as possible, presenters will be selected from those who submit before the deadline. We also may be able to offer financial assistance for travel for presenters who could not otherwise afford to attend and who submit before the deadline. Please do submit your proposal in a timely fashion. + +**Proposals due:** Wednesday 15 August 2012 17:00 UTC *Accepted formats: PDF and ASCII text. **Notification of acceptance:** Monday 3 September 2012 **E-mail:** board at foundation.x.org diff --git a/Other/Press/CFP2012_supplemental.mdwn b/Other/Press/CFP2012_supplemental.mdwn new file mode 100644 index 00000000..74520142 --- /dev/null +++ b/Other/Press/CFP2012_supplemental.mdwn @@ -0,0 +1,28 @@ + + +# 2012 X.Org Developers Conference (XDC 2012) + + +### 19-21 September 2012 + + +### Nürnberg (Nuremberg), Germany + + +### Call for Proposals - supplemental + +On Aug 4, 2012, X.Org released a Call for Proposals (CFP) for the X.Org Developers Conference 2012 (XDC2012). This CFP is meant to be complementary to the original XDC2012 announcement made on Mar 29[1]. + +The original announcement references the submission process for informal talks and presentations in which the submitter/presenter signs up for a slot on the X.Org wiki page[2] + +The CFP is for more formal proposals and presentations such as academic or commercial research, or where the submitter is interested in the formal review and publication aspect. Papers submitted via the formal CFP have the option to be published (online) by the X.Org Foundation. + +Proposals that have already been submitted do not need to be resubmitted. Their place on the event calendar is not affected by the CFP nor by any proposals received therefrom. + +The CFP deadline only applies to proposals submitted via the CFP process. Informal talks and presentations will still be accepted after the CFP deadline until the Friday before the conference, Sept. 14. + +For more information, please contact: board at foundation.x.org eich at suse.com + +[1] [[http://lists.x.org/archives/xorg-devel/2012-March/030164.html|http://lists.x.org/archives/xorg-devel/2012-March/030164.html]] + +[2] [[http://wiki.x.org/wiki/Events/XDC2012/Program|http://wiki.x.org/wiki/Events/XDC2012/Program]] diff --git a/Other/Press/SecAdvSept2005.mdwn b/Other/Press/SecAdvSept2005.mdwn new file mode 100644 index 00000000..25d990f3 --- /dev/null +++ b/Other/Press/SecAdvSept2005.mdwn @@ -0,0 +1,44 @@ + + +# X.Org Foundation SECURITY ADVISORY + +_Brookline MA, September 12, 2005_ + +X.Org has been made aware of a possible security vulnerability in the XCreatePixmap function of the X Server, which is shipped as part of the X Window System. The affected code is used to create and reserve memory for a new pixmap in the X Server. + +Due to missing range checks for the pixel size of the pixmap subsequent pixmap read/write functions can access memory outside of the allocated pixmap by any X client that can connect to the affected Xserver. This way any user having access to the server can access memory that is accessible from within the Xserver and/or crash the server. + +The CVE number for these vulnerabilities is CAN20052495. Please check also: [[http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2495|http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2495]] + +X.Org has tracked this issue in: [[https://bugs.freedesktop.org/show_bug.cgi?id=594|https://bugs.freedesktop.org/show_bug.cgi?id=594]] + +This advisory affects all known versions and releases of the X Window System whether from X.Org or other vendors. Therefore users are strongly recommended to upgrade. + +A fix is available under: [[http://www.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch|http://www.x.org/pub/X11R6.8.2/patches/xorg-CAN-2005-2495.patch]] + +All future versions of X.Org will have this security vulnerability fixed. Vendors shipping releases of the X Window System have been informed and will provide updates for their software. + +The X.Org Foundation would like to thank Luke Hutchinson for identifying the security exploit as well as Soeren Sandmann for investigating the issue and providing a patch. + + +## About participation and membership in X.Org: + +Membership in the X.Org foundation is free and open to all participants. Active participants in the further development of the X Window System are invited to visit: [[http://www.x.org/XOrg_Foundation_Membership.html|http://www.x.org/XOrg_Foundation_Membership.html]] to complete a membership application. Participation in the Foundation's Sponsor Group is also available to those who wish to financially support the activities of the X.Org Foundation. Current Sponsors include Hewlett Packard, Sun Microsystems, Hummingbird, IBM, Starnet Communications, WRQ, and Integrated Computer Solutions (ICS). + + +## About the X.Org Foundation: + +X.Org Foundation L.L.C. is a Delaware company organized to operate as a scientific charity under IRS code 501(c)(3), chartered to develop and execute effective strategies that provide worldwide stewardship of the X Window System technology and standards. The website for the X.Org Foundation can be found at [[http://www.x.org/|http://www.x.org/]]. + + +## About The X Window System: + +The X Window System provides the only common networked windowing environment bridging the heterogeneous platforms in today's computing. The X Window System is one of the most successful open-source, collaborative technologies developed to date and is the standard graphical window system for the Linux® and UNIX® operating systems. The inherent independence of the X Window System from the operating system, the network and the hardware, as well as its successful interoperability, have made it widely available and deployed with more than 30 million users worldwide. All major hardware vendors support the X Window System and many third parties provide technologies for integrating X Window System applications into the networked computer or personal computer environments including Microsoft Windows®, UNIX, Linux and Mac OS® X. Further, thousands of software developers provide X Window System applications, and with the continued growth of Linux and the emergence of Mac OS X, the number of users is growing rapidly. + +_Notes to Editors:_ + +UNIX is a registered trademark of The Open Group in the US and other countries. LINUX is a registered trademark of Linus Torvalds. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and/or other countries. Mac OS is a registered trademark of Apple Computer, Inc., registered in the U.S. and other countries. All other company names are trademarks of the registered owners. + +For questions, please contact: Leon Shiman, Secretary, X.Org Foundation, at: + +* Shiman Associates Inc (00)1.617.277.0087 [[leon@shiman.com|mailto:leon@shiman.com]]
\ No newline at end of file diff --git a/Other/Press/X11R682Released.mdwn b/Other/Press/X11R682Released.mdwn new file mode 100644 index 00000000..8e8e1274 --- /dev/null +++ b/Other/Press/X11R682Released.mdwn @@ -0,0 +1,66 @@ + + +# X11R6.8.2 Officially Released + + +### X.Org Foundation Releases Update + + +### For X Window System Release X11R6.8.0 + +_Brookline Massachusetts, February 9, 2005_ The X.Org Foundation today announced the fourth release of the X Window System since the formation of the Foundation in January of 2004. + +The new X.Org release, called X Window System Version 11, Release 6.8.2 ([[X11R6|X11R6]].8.2) builds on the work of X.org [[X11R6|X11R6]].8.0 and [[X11R6|X11R6]].8.1 released in 2004. [[X11R6|X11R6]].8.2 combines the latest developments from many people and companies working with the X Window System and an open X.Org Foundation Release Team. All Official X.Org Releases are available for download from [[ftp://www.x.org/pub|ftp://www.x.org/pub]] and at mirror-sites world-wide. + + +## About this Release: + +The [[X11R6|X11R6]].8.2 release is intended to be a stable bug fix release ("Maintenance update") for the [[X11R6|X11R6]].8.0 and [[X11R6|X11R6]].8.1 X11 releases of the Xorg Foundation, containing bug fixes, security updates and a small set of new features, which include the following: + +* ATI R100 video driver +* ATI "radeon" video driver +* ATI Rage128 video driver +* CYGWIN infrastructure update +* DMX Library updates +* Intel i810 video driver +* libXpm security update (CAN-2004-0914) +* Mesa (OpenGL) update to release 6.2 +* Fixes to the pseudocolor emulation layer (currently only used by the Neomagic driver.) +* "nv" (Nvidia) video driver +* Postscript print driver +* Xprint infrastructure update +Please refer to the [[X11R6|X11R6]].8.2 Release Notes at [[http://www.x.org/|http://www.x.org/]] for further details. The full list of changes between the initial [[X11R6|X11R6]].8.0 and this release can be found in the Changelog. + + +## About participation and membership in X.Org: + +Membership in the X.Org foundation is free and open to all participants. Active participants in the further development of the X Window System are invited to visit: [[http://www.x.org/XOrg_Foundation_Membership.html|http://www.x.org/XOrg_Foundation_Membership.html]] to complete a membership application. Participation in the Foundation's Sponsor Group is also available to those who wish to financially support the activities of the X.Org Foundation. Current Sponsors include Hewlett Packard, Sun Microsystems, Hummingbird, IBM, Starnet Communications, WRQ, and Integrated Computer Solutions (ICS). + + +## About the X.Org Foundation: + +X.Org Foundation L.L.C. is a Delaware company organized to operate as a scientific charity under IRS code 501(c)(3), chartered to develop and execute effective strategies that provide worldwide stewardship of the X Window System technology and standards. The group is currently managed by its Board of Directors that includes: Stuart Anderson (Free Standards Group), Egbert Eich (Novell), Jim Gettys (HP), Stuart Kreitman (SUN Microsystems), Kevin Martin (Red Hat), Jim [[McQuillan|McQuillan]] (Linux Terminal Server Project), Keith Packard (HP), and Leon Shiman (Shiman Associates). The website for the X.Org Foundation can be found at [[http://www.x.org/|http://www.x.org/]]. + + +## About Community Participation: + +This release was built on [[X11R6|X11R6]].8.0 by the direct contributions of 66 developers, with the support of X.Org's Release Wranglers. Names of all contributors can be found in the Release Notes. + + +## About The X Window System: + +The X Window System provides the only common networked windowing environment bridging the heterogeneous platforms in today's computing. The X Window System is one of the most successful open-source, collaborative technologies developed to date and is the standard graphical window system for the Linux® and UNIX® operating systems. The inherent independence of the X Window System from the operating system, the network and the hardware, as well as its successful interoperability, have made it widely available and deployed with more than 30 million users worldwide. All major hardware vendors support the X Window System and many third parties provide technologies for integrating X Window System applications into the networked computer or personal computer environments including Microsoft Windows®, UNIX, Linux and Mac OS® X. Further, thousands of software developers provide X Window System applications, and with the continued growth of Linux and the emergence of Mac OS X, the number of users is growing rapidly. + +_Notes to Editors:_ + +(1) Distributed Multihead X Project: [[http://dmx.sourceforge.net/|http://dmx.sourceforge.net/]] + +(2) The Mesa 3D Graphics Library: [[http://www.mesa3d.org|http://www.mesa3d.org]] + +(3) The Xprint Project: [[http://xprint.mozdev.org/|http://xprint.mozdev.org/]] + +UNIX is a registered trademark of The Open Group in the US and other countries. LINUX is a registered trademark of Linus Torvalds. Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States and/or other countries. Mac OS is a registered trademark of Apple Computer, Inc., registered in the U.S. and other countries. All other company names are trademarks of the registered owners. + +For questions, please contact: Leon Shiman, Secretary, X.Org Foundation, at: + +* Shiman Associates Inc (00)1.617.277.0087 [[leon@shiman.com|mailto:leon@shiman.com]]
\ No newline at end of file diff --git a/Other/Press/X11R6970Released.mdwn b/Other/Press/X11R6970Released.mdwn new file mode 100644 index 00000000..a340f060 --- /dev/null +++ b/Other/Press/X11R6970Released.mdwn @@ -0,0 +1,20 @@ + + +# X11R6.9 and X11R7.0 Officially Released + + +### Landmark version X11R7.0 released today with X11R6.9 by the X.Org Foundation + +_Brookline, Massachusetts, December 21 2005._ The first major version release of the X Window System in more than a decade, X11R7.0 is the first release of the complete modularized and autotooled source code base for the X Window System. X11R6.9, its companion release, contains identical features, and uses the exact same source code as X11R7.0, but with the traditional imake build system. + +These changes in source code management, giving openness and transparency to the source code base and employing current technology, invite a new generation of developers to contribute, building on the long tradition of the X Window System. The new modular format offers focused development, and rapid and independent updates and distribution of tested modular components as they are ready, freed from the biennial maintenance release timetable. + +X11R6.9 comprises many distinct components bonded in a single tree, based on imake. X11R7.0 splits that set of components into logically distinct modules, separately developed, built, and maintained by the community of X.Org developers. This simulaneous release gives a transition point for developers, builders, and vendors to adapt their practices to the new X.Org modular process. X11R7.0 supports Linux and Solaris at this time, with other support pending. X11R7.1, the first modular roll-up release, is scheduled mid-2006. While the monolithic tree will continue to be fully supported and released, new feature development is expected to be concentrated in the modular code base. + +The X11R7.0 and X11R6.9 releases are the work of more than fifty volunteer contributors worldwide, working under the release management team of Kevin Martin (Head), Alan Coopersmith, and Adam Jackson, with the support of Red Hat, Sun Microsystems, and the unsupported generous contribution of effort by Adam Jackson.* + +All X Window System Releases are available from [[http://ftp.X.Org|http://ftp.X.Org]] and mirror sites worldwide (see [[http://wiki.x.org/Mirrors|http://wiki.x.org/Mirrors]]). They are distributed under the MIT ("X") License by the X.Org Foundation LLC. Information concerning organization, activities, and mailing lists can be found at [[http://www.X.Org|http://www.X.Org]]. Membership is free and open to contributors. Sponsorship is encouraged to support the global activities of the X.Org Foundation. Current X.Org Sponsors include Sun Microsystems, HP, IBM, StarNet Communications, AttachmateWRQ, Hummingbird, and Integrated Computer Solutions Incorporated [ICS].* + +In continuous use for over 20 years, the X Window System provides the only standard platform-independent networked graphical window system bridging the heterogeneous platforms in today's enterprise: from network servers to desktops, thin clients, laptops, and hand-helds, independent of operating system and hardware. + +* LINUX is a registered trademark of Linus Torvalds. "Solaris" is a tradmark of Sun Microsystems. Company names are trademarks of their registered owners. diff --git a/Other/Press/X11R71Released.mdwn b/Other/Press/X11R71Released.mdwn new file mode 100644 index 00000000..6a84c9e2 --- /dev/null +++ b/Other/Press/X11R71Released.mdwn @@ -0,0 +1,24 @@ + + +# X.Org Foundation Releases X11R7.1 + + +### First Modular Source Code Roll-up Release of the X Window System + +_Brookline, Massachusetts, May 22 2006._ Five months after release of X11R7.0, the modularized and autotooled release of the MIT ("X") Licensed X Window System source code, the X.Org Foundation has issued its first modular roll-up release. + +X11R7.1 supports Linux, Solaris, and BSD systems. It includes important new server and driver features for embedded systems, 64 bit platforms, enhanced operating system support, and accelerated indirect GLX support. It most importantly demonstrates to developers and industry immediate benefits of modularization. + +The full source code is free and available from ftp.X.Org and [[Mirrors|Mirrors]] worldwide. For a complete list of features in the new release and the contributors, please visit: [[http://ftp.x.org/pub/X11R7.1/|http://ftp.x.org/pub/X11R7.1/]]. + +The X Window System is distributed under the MIT ("X") License by the X.Org Foundation LLC. All X Window System Releases are the work of volunteer contributors. + +All X11R7.0 derivative ("modularized") releases divide the source code into logically distinct modules, separately developed, built, and maintained by the community of X.Org developers. This concentrates and accelerates development time, supporting continuous modification, testing, and publication of each module.The new modular format offers focused development, and rapid and independent updates and distribution of tested modular components as they are ready, freed from the biennial maintenance release timetable. These changes in source code management, giving openness and transparency to the source code base and employing current technology, invite a new generation of developers to contribute, building on the long tradition of the X Window System. + +Twice yearly, roll-up releases collect and publish a new reference source code version. X11R7.1 is the first of these regular releases, demonstrating the success of the new development environment. The last monolithic tree released, X11R6.9.0, will continue to be be supported with security patches, as are all past X.Org Foundation releases, while new feature development is concentrated on the X11R7.* modular code base. + +Membership is free and open to contributors. Sponsorship is encouraged to support the global activities of the X.Org Foundation. Current X.Org Sponsors include Sun Microsystems, HP, IBM, StarNet Communications, AttachmateWRQ, Hummingbird, and Integrated Computer Solutions Incorporated [ICS].* Information concerning organization, activities, and mailing lists can be found at [[http://www.X.Org|http://www.X.Org]]. + +In continuous use for over 20 years, the X Window System provides the only standard platform-independent networked graphical window system bridging the heterogeneous platforms in today's enterprise: from network servers to desktops, thin clients, laptops, embedded systems, and hand-helds, independent of operating system and hardware. + +* LINUX is a registered trademark of Linus Torvalds. "Solaris" is a trademark of Sun Microsystems. Company names are trademarks of their registered owners. diff --git a/Other/Press/X11R72Released.mdwn b/Other/Press/X11R72Released.mdwn new file mode 100644 index 00000000..2ce70e5e --- /dev/null +++ b/Other/Press/X11R72Released.mdwn @@ -0,0 +1,13 @@ + + +# X.Org community releases X11R7.2 + +_February 15, 2007._ The X.Org community is proud to announce the release of X11R7.2, the third modular release of the X Window System. + +X11R7.2 supports Linux, BSD, Solaris, Microsoft Windows and GNU Hurd systems. It incorporates significant stability and correctness fixes, including improved autoconfiguration heuristics, enhanced support for GL-based compositing managers such as Compiz and Beryl, and improved support for PCI systems with multiple domains. It also incorporates the new, more extensible XACE security policy framework. + +The full source code is free to use, modify and redistribute and is available from [[http://ftp.x.org/pub/X11R7.2/|http://ftp.x.org/pub/X11R7.2/]] and mirrors worldwide. + +For more information on the X Window System, including how to get involved with development, please see [[http://wiki.x.org|http://wiki.x.org]]. + +* Linux is a registered trademark of Linus Torvalds. Solaris is a trademark of Sun Microsystems. Windows is a trademark of Microsoft Corporation. Company names are trademarks of their registered owners. diff --git a/Other/Press/X11R75Released.mdwn b/Other/Press/X11R75Released.mdwn new file mode 100644 index 00000000..401dc28f --- /dev/null +++ b/Other/Press/X11R75Released.mdwn @@ -0,0 +1,32 @@ + +**26 October 2009** -- The [[X.Org Foundation|XorgFoundation]] and the global community of X.Org developers announce the release of [[X11R7.5 - Release 7.5 of the X Window System, Version 11|Releases/7.5]]. This release is the sixth modular release of the X Window System. The next full release will be [[X11R7.6|Releases/7.6]] and is expected in 2010. + +X11``R7.5 supports Linux, BSD, Solaris, MacOS X, Microsoft Windows and GNU Hurd systems. It incorporates new features, and stability and correctness fixes, including improved autoconfiguration heuristics, enhanced support for input devices, and new options for reconfiguring the screen geometry while the system is running. + +The full source code is free to use, modify and redistribute, under open source licenses, and is available from [[http://www.x.org/releases/X11R7.5/|http://www.x.org/releases/X11R7.5/]] and mirrors worldwide. + +For more information on the X Window System, including how to get involved with development, please see [[http://www.x.org|http://www.x.org]]. + + * +--- + + + + +## Summary of new features in X11R7.5 + +This is a sampling of the new features in X11``R7.5. A more complete list of changes can be found in the Change``Log files that are part of the source of each X module and on the [[http://www.x.org/releases/X11R7.5/|http://www.x.org/releases/X11R7.5/]] website. + +More information on the contents of X11``R7.5 and changes from previous releases can also be found in the release notes posted at: + + * [[http://www.x.org/releases/X11R7.5/doc/RELNOTES.html|http://www.x.org/releases/X11R7.5/doc/RELNOTES.html]] + * **Multi-Pointer X (MPX)** provides the user with multiple independent mouse cursors and multiple independent keyboard foci. Each cursor is a true system cursor and different pointers can operate in multiple applications simultaneously. + * **Input device properties** allow you to attach properties to a device. These properties can be of arbitrary type and can be changed without the server having to know their details. + * The **X Input Extension version 2.0 (XI2)** is designed to replace both core input processing and prior versions of the X Input Extension. Besides MPX, it provides a number of other enhancements over version 1.5, including: + * explicit device hierarchy of master and slave devices. + * the ability for devices to change capabilities at runtime. + * raw device events + * **Resize, Rotate and Reflect Extension (RANDR) version 1.3** builds on the changes made with version 1.2 and adds some new capabilities without fundmentally changing the extension again. The following features are added in this version: + * _Projective Transforms_: The implementation work for general rotation support made it trivial to add full projective transformations. These can be used to scale the screen up/down as well as perform projector keystone correct or other effects. + * _Panning_: Panning was removed with RandR 1.2 because the old semantics didn't fit any longer. With RandR 1.3 panning can be specified per crtc. + * The **DRI2** extension is designed to associate and access auxillary rendering buffers with an X drawable. It is a essentially a helper extension to support implementation of direct rendering drivers/libraries/technologies. The first consumer of this extension is a direct rendering OpenGL driver, but the DRI2 extension is not designed to be OpenGL specific. Work is underway to utilize DRI2 for the Video Decode and Presentation API for Unix (VDPAU) as well. Direct rendering implementations of OpenVG, Xv, cairo and other graphics APIs should find the functionality exposed by this extension helpful and hopefully sufficient.
\ No newline at end of file diff --git a/Other/Press/X11R76Released.mdwn b/Other/Press/X11R76Released.mdwn new file mode 100644 index 00000000..3d664250 --- /dev/null +++ b/Other/Press/X11R76Released.mdwn @@ -0,0 +1,37 @@ + +**20 December 2010** -- The [[X.Org Foundation|XorgFoundation]] and the global community of X.Org developers announce the release of [[X11R7.6 - Release 7.6 of the X Window System, Version 11|Releases/7.6]]. This release is the seventh modular release of the X Window System. The next full release will be [[X11R7.7|Releases/7.7]] and is expected in 2011. + +X11``R7.6 supports Linux, BSD, Solaris, MacOS X, Microsoft Windows and GNU Hurd systems. It incorporates new features, and stability and correctness fixes, including improved autoconfiguration heuristics, enhanced support for input devices, better documentation, and takes the next step in migrating to the [[XCB client APIs|http://xcb.freedesktop.org]]. + +The full source code is free to use, modify and redistribute, under open source licenses, and is available from [[http://www.x.org/releases/X11R7.6/|http://www.x.org/releases/X11R7.6/]] and mirrors worldwide. + +For more information on the X Window System, including how to get involved with development, please see [[http://www.x.org|http://www.x.org]]. + + * +--- + + + + +## Summary of new features in X11R7.6 + +This is a sampling of the new features in X11``R7.6. A more complete list of changes can be found in the Change``Log files that are part of the source of each X module and on the [[http://www.x.org/releases/X11R7.6/|http://www.x.org/releases/X11R7.6/]] website. + +More information on the contents of X11``R7.6 and changes from previous releases can also be found in the release notes posted at: + + * [[http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html|http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html]] + * **Input``Class** sections in Xorg configuration files are used to apply configuration options to any input device matching specified rules, such as device path, type of device, device manufacturer, or other data provided by the input hotplug backend. Details can be found in the INPUTCLASS section of the xorg.conf(5) manual page. + * **Xorg configuration directories** are used to allow fragments of the X server configuration to be delivered in individual files. For instance, the input device driver matching rules previously provided in HAL `.fdi` files are now provided as [[InputClass|InputClass]] sections in .conf files in a `xorg.conf.d` directory. + * **udev** is now used by the X server on Linux systems for input device discovery and hot-plug notification. Other platforms continue to use the **HAL** framework for these tasks for now. + * **X protocol C-language Binding (XCB)** is now included in the katamari, and is required by several client-side modules, including libX11, xlsatoms, xlsclients and xwininfo. XCB is a replacement for Xlib featuring a small footprint, latency hiding, direct access to the protocol, improved threading support, and extensibility. More information can be found on the XCB website at [[http://xcb.freedesktop.org/|http://xcb.freedesktop.org/]]. + * Major progress has been made on the **[[X.Org Documentation modernization|Development/Documentation/WritingDocumentation]]** - most of the library and protocol specifications are now included in the modules for those libraries and protocols so they can be updated in sync with new versions, and many have been converted to Doc``Book XML from the variety of formats they were previously in. On most systems these documents will be installed under `/usr/share/doc/`. They are also posted on the X.Org website at [[http://www.x.org/releases/X11R7.6/doc/index.html|http://www.x.org/releases/X11R7.6/doc/index.html]] +<ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins><ins></ins> + + +## Dedication + +Two of the early leaders of the X Window System community were lost to cancer this year -- **Smokey Wallace**, who led the DEC WSL team which created the initial implementation of X11, and **Hideki Hiura** from Sun Microsystems, who helped design the X11``R6 internationalization framework. The X11``R7.6 release is dedicated to their memory. + +Jim Gettys [[remembers|http://gettys.wordpress.com/2010/11/16/so-they-dont-pass-unnoticed/]] that “_Without Smokey, it is not clear that X11 would have ever existed: he and I drafted a memo that proposed developing X11 in Digital’s WSL and making the result freely available, as X11 would require more resources than we had available at MIT. This was one of the seminal moments in free and open source software, though few know of it._” + +Alan Coopersmith, who worked with Hideki at Sun, noted that “_Hideki’s contributions to the X Window System and leadership in forums such as openi18n.org will leave a lasting legacy on the millions of users who are able to use their native languages to interact with computers and portable devices running the Unix and Linux families of operating system._” diff --git a/Other/Press/XTSReleased.mdwn b/Other/Press/XTSReleased.mdwn new file mode 100644 index 00000000..ba666d63 --- /dev/null +++ b/Other/Press/XTSReleased.mdwn @@ -0,0 +1,46 @@ + + +# X Window System Test Suite + + +# Contributed by ApTest and The Open Group to The X.Org Foundation + + +# Released under "X" Open Source License. + +_Brookline Massachusetts, 18 April 2005._ + +The X.Org Foundation, global steward of the X Window System* and Standards, announced today that [[ApTest|ApTest]] and The Open Group have together donated their VSW5 Test Suite to The X.Org Foundation, where it shall be released under their standard Open Source license as XTS 5.0.2. The X Window System is released by the X.Org Foundation under the MIT ("X") License. The VSW5 Test Suite is the industry best practice in testing the X Window System. + +All Official X.Org releases are free and available for download from [[ftp://www.x.org/pub|ftp://www.x.org/pub]] and at mirror-sites world-wide. + +"[[ApTest|ApTest]] is excited by the opportunity X.Org offers the X community. We are pleased to contribute our technology and look forward to participating in ensuring the ongoing quality of X releases" said Shane [[McCarron|McCarron]], Managing Director of [[ApTest|ApTest]] Minnesota + +"The Open Group congratulates the X.Org Foundation on making the free availability of the X Window System Test Suite (VSW5) under an open source license possible and establishing a test working group" said Andrew Josey, Director of Certification at The Open Group. "This initiative will further enhance the quality of the X Window System and we look forward to working with X.Org. As part of that cooperation we plan to contribute a number of patches to the code base." + +To support the development of this critical and unique testing technology in tandem with the X Window System itself, the X.Org Foundation also announces the formation of a Testing Workgroup, to be lead by Stuart Anderson, for maintenance and extension of the test suites. Information about this workgroup can be found at [[http://www.x.org/TestGroup|http://www.x.org/TestGroup]]. Membership in all X.Org work groups is open and free. + + +## About VSW5: + +The VSW5 Test Suite is the latest in an evolutionary series of test suites for the X Window System that began in the early 1990's. The VSW Test Suite is built on the The Open Group's Test Environment Toolkit (TET) framework ([[http://tetworks.opengroup.org/|http://tetworks.opengroup.org/]]). The VSW test suite is a part of the certification program for both the UNIX system and the Linux Standard Base (LSB). The software can be downloaded from [[http://www.x.org/pub/XTS5.0.2|http://www.x.org/pub/XTS5.0.2]]. + + +## About ApTest: + +Applied Testing and Technology has provided testing analysis, design, development, and execution services to its clients since 1993. [[ApTest|ApTest]] specializes in outsourced product testing and the development of automated test suites, test tools, and test technology. We also develop and market the [[ApTest|ApTest]] Manager test management system - a web-based product for managing QA testing across the enterprise. Further information on [[ApTest|ApTest]] can be found at [[http://www.aptest.com|http://www.aptest.com]] or from Andy Silverman at 408-399-1930. + + +## About The Open Group: + +The Open Group is a specialist in the development and operation of certification programs for software specifications endorsed by industry standards bodies. The Open Group has a fifteen-year history of the provision of high quality test suites and certification related services to the software industry, and has been the active maintainer of VSW5 and X Window System certification for a number of years. Further information on The Open Group can be found at [[http://www.opengroup.org|http://www.opengroup.org]]. + +==About the X.Org Foundation: == + +X.Org Foundation L.L.C. is a Delaware company organized to operate as a scientific charity under IRS code 501(c)(3), chartered to develop and execute effective strategies that provide worldwide stewardship of the X Window System technology and standards. The group is currently managed by its Board of Directors that includes: Stuart Anderson (Free Standards Group), Egbert Eich (Novell), Jim Gettys (HP), Stuart Kreitman (SUN Microsystems), Kevin Martin (Red Hat), Jim [[McQuillan|McQuillan]] (Linux Terminal Server Project), Keith Packard (HP), and Leon Shiman (Shiman Associates). The website for the X.Org Foundation can be found at [[http://www.x.org/|http://www.x.org/]]. + +_Notes to Editors:_ + +For questions, please contact: Leon Shiman, Secretary, X.Org Foundation, at: + +* Shiman Associates Inc (00)1.617.277.0087 [[leon@shiman.com|mailto:leon@shiman.com]]
\ No newline at end of file diff --git a/Other/Press/XorgOIN.mdwn b/Other/Press/XorgOIN.mdwn new file mode 100644 index 00000000..f0c5977a --- /dev/null +++ b/Other/Press/XorgOIN.mdwn @@ -0,0 +1,32 @@ + +9 AUGUST 2012: The [[X.Org Foundation|XorgFoundation]] has joined the [[Open Invention Network (OIN)|http://www.openinventionnetwork.com/]] patent non-aggression community in order to better protect the future of the X Window System. OIN has granted the Foundation a license to use all of the patents they control or which are covered by agreements with other [[OIN community members and licensees|http://www.openinventionnetwork.com/licensees.php]], in exchange for a pledge from the Foundation to license back any patents which the Foundation may come into possession of. (Currently the Foundation owns no patents, but if we ever do, they will be covered by this agreement.) + +This will help protect the Foundation's resources and donations made to it against patent claims, allowing the Foundation to devote those resources and donations to the improvement of the window system itself. The OIN definition of the "Linux System" for which patent claims are covered by the agreement has long included X Window System software packages, and thus the X.Org Foundation receives coverage for many of 1the software packages we release. + +Due to the reciprocal nature of the OIN agreement, the Foundation can only enter to this agreement on behalf of the Foundation, as we cannot pledge anyone else's patents to the OIN community. Any vendors, distributors, or contributing organizations which wish to obtain similar protection should contact OIN directly about joining the OIN non-aggression community on their own, as described on [[http://www.openinventionnetwork.com/pat_license.php|http://www.openinventionnetwork.com/pat_license.php]]. + +In order to more broadly protect the open source desktop software systems, the X.Org Foundation is also asking our members and contributors to participate in the defensive patent programs sponsored by OIN, the Software Freedom Law Center, and the Linux Foundation, under the Linux Defenders umbrella, including Defensive Publication to establish prior art citations for new techniques, and helping the X.Org Foundation locate and publish prior art references from our archives of computer graphics and window system research and development stretching back over 25 years, through the original X Consortium back to the project's founding at MIT. Those who wish to help can learn about Defensive Publications at [[http://www.defensivepublications.org/|http://www.defensivepublications.org/]] and can contact the X.Org Foundation Board at [[board@foundation.x.org|mailto:board@foundation.x.org]] to be included in discussions about how to best utilize the X development archives. + + + +--- + + + +The X.Org Foundation is a non-profit public charity dedicated to supporting and defending the ongoing development of open source graphics and window system software, centered around the X Window System, one of the oldest and most successful open source software projects in existence. The X Window System software has become the standard graphical interface across Linux & Unix workstations and servers, and has been included in a growing number of mobile phones and tablets in recent years. More information about the X.Org Foundation and X Window System may be found at [[http://www.x.org/|http://www.x.org/]]. + + + +--- + + + +Open Invention Network® is an intellectual property company that was formed to promote Linux by using patents to create a collaborative environment. It promotes a positive, fertile ecosystem for Linux, which in turns drives innovation and choice in the global marketplace. This helps ensure the continuation of innovation that has benefited software vendors, customers, emerging markets and investors. More information about OIN is available at [[http://www.openinventionnetwork.com/|http://www.openinventionnetwork.com/]]. + + + +--- + + + +Conceptualized by Open Invention Network and co-sponsored with the Software Freedom Law Center and The Linux Foundation, Linux Defenders is a first-of- its-kind program which combines free online intellectual property (IP) publication with defensive patent tools to provide the Linux and open source community an effective vehicle to reduce future patent concerns. Linux Defenders serves as a portal for the Linux and broader open source community and seamlessly links to the Peer to Patent and Post-Issue Peer to Patent platforms that New York Law School manages. The Linux Defenders web site is located at [[http://linuxdefenders.org/|http://linuxdefenders.org/]]. diff --git a/OtherFAQs.mdwn b/OtherFAQs.mdwn new file mode 100644 index 00000000..3de705d4 --- /dev/null +++ b/OtherFAQs.mdwn @@ -0,0 +1,10 @@ + + +# Other X-related FAQs on the Internet + + * [[Remote X Apps mini-HOWTO|http://www.xs4all.nl/~zweije/xauth.html]] + * [[Multiseat X Under X11R6.9/7.0 How-To|http://blog.chris.tylers.info/index.php?/archives/14-Multiseat-X-Under-X11R6.97.0.html]] + * [[How-To setup A 2nd Mouse|http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/XFree86-Second-Mouse]] + * [[Direct Color FAQ|http://www.dpmms.cam.ac.uk/~werdna/XFree86-Overlay-FAQ.txt]] written by Dr. Andrew C. Aitchison + * [[Lots O' X FAQs|http://www.rahul.net/kenton/xsites.html#FAQ]] :) courtesy of Kenton Lee's site + * [[Even More FAQs|http://tldp.org/HOWTO/HOWTO-INDEX/apps.html#GUI]]
\ No newline at end of file diff --git a/OwainAinsworth.mdwn b/OwainAinsworth.mdwn new file mode 100644 index 00000000..4fbf492d --- /dev/null +++ b/OwainAinsworth.mdwn @@ -0,0 +1,15 @@ + + +## Owain Ainsworth + +Email: oga AT SPAMFREE openbsd DOT org + +IRC: oga on freenode + +OpenBSD DRM subsystem maintainer, VM system/buffercache hacker and secondary X maintainer. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/PauloZanoni.mdwn b/PauloZanoni.mdwn new file mode 100644 index 00000000..3a099869 --- /dev/null +++ b/PauloZanoni.mdwn @@ -0,0 +1,29 @@ + + +## Paulo Ricardo Zanoni + +[[http://www.inf.ufpr.br/prz05|http://www.inf.ufpr.br/prz05]] + +Interested in multiseat X: + +* Multiseats with MPX +* Multiseats with multiple instances of X +[[GrabsProcessing|GrabsProcessing]] + +prz05#c3sl*ufpr*br + +C3SL - Centro de Computação Científica e Software Livre + +(Center for Scientific Computing and Free Software) + +[[http://www.c3sl.ufpr.br|http://www.c3sl.ufpr.br]] + +... + + + +--- + + + +* [[CategoryHomepage|CategoryHomepage]]
\ No newline at end of file diff --git a/PciReworkHowto.mdwn b/PciReworkHowto.mdwn new file mode 100644 index 00000000..301baf5d --- /dev/null +++ b/PciReworkHowto.mdwn @@ -0,0 +1,416 @@ + + +## PCI Rework HOWTO + +Here's a list of steps you need to take to convert a video driver to the new libpciaccess library. Please feel free to fix this page where you find it inaccurate or incomplete. The examples here are from the intel driver and assume that you want to continue allowing the driver to be built with older X servers by making all of the changes conditional on whether the server uses libpciaccess. + + +### configure.ac changes + +This patch adds a check to see if the X server is using libpciaccess (the server will have XSERVER_LIBPCIACCESS defined in xorg-server.h), then makes sure the pciaccess package is installed and available. + + +[[!format txt """ + save_CFLAGS="$CFLAGS" + CFLAGS="$XORG_CFLAGS" + AC_CHECK_HEADER(xf86Modes.h,[XMODES=yes],[XMODES=no],[#include "xorg-server.h"]) ++AC_CHECK_DECL(XSERVER_LIBPCIACCESS, ++ [XSERVER_LIBPCIACCESS=yes],[XSERVER_LIBPCIACCESS=no], ++ [#include "xorg-server.h"]) + CFLAGS="$save_CFLAGS" + ++if test x$XSERVER_LIBPCIACCESS = xyes; then ++ PKG_CHECK_MODULES([PCIACCESS], [pciaccess >= 0.8.0]) ++fi ++ ++AM_CONDITIONAL(XSERVER_LIBPCIACCESS, test "x$XSERVER_LIBPCIACCESS" = xyes) + AM_CONDITIONAL(XMODES, test "x$XMODES" = xno) + + if test "x$XSERVER_SOURCE" = x; then +"""]] + + +Note: I have always encountered the xorg header files in /usr/include/xorg/, so i corrected the include. If this is not the usual location, please revert it. + + +### pciVideoPtr → struct pci_device * + +In the [[ScrnInfoRec|ScrnInfoRec]] driver private structure, there is a pointer to the pciVideoPtr structure which contains identification information about the associated PCI device. libpciaccess has a parallel structure, struct pci_device which contains the same information using different names. Another change here is to compute (and store) the PCI base address register indices in this structure; mapping PCI space now requires using these register indices instead of just the physical address of the hardware. + + +[[!format txt """ +@ -61,6 +61,11 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + #include "xf86Crtc.h" + #include "xf86RandR12.h" + ++#include "xorg-server.h" ++#ifdef XSERVER_LIBPCIACCESS ++#include <pciaccess.h> ++#endif ++ + #ifdef XF86DRI + #include "xf86drm.h" + #include "sarea.h" +@@ -360,8 +365,15 @@ typedef struct _I830Rec { + unsigned long MMIOAddr; + IOADDRESS ioBase; + EntityInfoPtr pEnt; ++#if XSERVER_LIBPCIACCESS ++ struct pci_device *PciInfo; ++ int mmio_bar; ++ int fb_bar; ++ int gtt_bar; ++#else + pciVideoPtr PciInfo; + PCITAG PciTag; ++#endif + CARD8 variant; + + unsigned int BR[20]; +"""]] + +### Macros to fetch PCI device ids + +Instead of changing the code to have conditional use of these new structures everywhere, we create macros to fetch various PCI identification data from either the old or new structures. Now, everywhere the driver used to refer to one of the old fields, just replace that using one of these macros. Placing these macros in your header file keeps the driver building against older servers. + + +[[!format txt """ +#if XSERVER_LIBPCIACCESS ++#define I810_MEMBASE(p,n) (p)->regions[(n)].base_addr ++#define VENDOR_ID(p) (p)->vendor_id ++#define DEVICE_ID(p) (p)->device_id ++#define SUBVENDOR_ID(p) (p)->subvendor_id ++#define SUBSYS_ID(p) (p)->subdevice_id ++#define CHIP_REVISION(p) (p)->revision ++#else ++#define I810_MEMBASE(p,n) (p)->memBase[n] ++#define VENDOR_ID(p) (p)->vendor ++#define DEVICE_ID(p) (p)->chipType ++#define SUBVENDOR_ID(p) (p)->subsysVendor ++#define SUBSYS_ID(p) (p)->subsysCard ++#define CHIP_REVISION(p) (p)->chipRev ++#endif +"""]] + +### DRI interface changes + +This change is simple; DRI needs to know the PCI address of the video card in several places, as these values are now stored in a new structure, the code must change to reflect the new names. + + +[[!format txt """ + } else { + pDRIInfo->busIdString = xalloc(64); + sprintf(pDRIInfo->busIdString, "PCI:%d:%d:%d", ++#if XSERVER_LIBPCIACCESS ++ ((pI810->PciInfo->domain << 8) | pI810->PciInfo->bus), ++ pI810->PciInfo->dev, pI810->PciInfo->func ++#else + ((pciConfigPtr) pI810->PciInfo->thisCard)->busnum, + ((pciConfigPtr) pI810->PciInfo->thisCard)->devnum, +- ((pciConfigPtr) pI810->PciInfo->thisCard)->funcnum); ++ ((pciConfigPtr) pI810->PciInfo->thisCard)->funcnum ++#endif ++ ); + } + pDRIInfo->ddxDriverMajorVersion = I810_MAJOR_VERSION; + pDRIInfo->ddxDriverMinorVersion = I810_MINOR_VERSION; +@@ -972,12 +978,20 @@ I810DRIScreenInit(ScreenPtr pScreen) + + if (!pI810DRI->irq) { + pI810DRI->irq = drmGetInterruptFromBusID(pI810->drmSubFD, ++#if XSERVER_LIBPCIACCESS ++ ((pI810->PciInfo->domain << 8) | ++ pI810->PciInfo->bus), ++ pI810->PciInfo->dev, ++ pI810->PciInfo->func ++#else + ((pciConfigPtr) pI810-> + PciInfo->thisCard)->busnum, + ((pciConfigPtr) pI810-> + PciInfo->thisCard)->devnum, + ((pciConfigPtr) pI810-> +- PciInfo->thisCard)->funcnum); ++ PciInfo->thisCard)->funcnum ++#endif ++ ); + if ((drmCtlInstHandler(pI810->drmSubFD, pI810DRI->irq)) != 0) { + xf86DrvMsg(pScrn->scrnIndex, X_INFO, + "[drm] failure adding irq handler, there is a device " +@@ -991,7 +1005,7 @@ I810DRIScreenInit(ScreenPtr pScreen) + xf86DrvMsg(pScrn->scrnIndex, X_INFO, + "[drm] dma control initialized, using IRQ %d\n", pI810DRI->irq); + +- pI810DRI->deviceID = pI810->PciInfo->chipType; ++ pI810DRI->deviceID = DEVICE_ID(pI810->PciInfo); + pI810DRI->width = pScrn->virtualX; + pI810DRI->height = pScrn->virtualY; + pI810DRI->mem = pScrn->videoRam * 1024; +"""]] + +### Mechanical API conversions + +Where your driver code calls various pci access functions, you need to mechanically convert them to using functions from libpciaccess +[[!table header="no" class="mointable" data=""" +Mapping built-in PCI functions to libpciaccess functions||| + Built-in | libpciaccess + xf86ReadPciBIOS | pci_device_read_rom + pciReadByte | pci_device_cfg_read_u8 + pciReadWord | pci_device_cfg_read_u16 + pciReadLong | pci_device_cfg_read_u32 +"""]] + + +### Listing the supported devices + +The device probing function will now relies on the libpciaccess code to identify all devices automatically. The match works much like the kernel; you fill in a description of which devices your driver supports and the library finds the available devices on the system. + +Here's a list of all of the devices supported by the intel driver: + + +[[!format txt """ ++#if XSERVER_LIBPCIACCESS ++ ++#define INTEL_DEVICE_MATCH(d,i) \ ++ { 0x8086, (d), PCI_MATCH_ANY, PCI_MATCH_ANY, 0, 0, (i) } ++ ++static const struct pci_id_match intel_device_match[] = { ++#ifndef I830_ONLY ++ INTEL_DEVICE_MATCH (PCI_CHIP_I810, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I810_DC100, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I810_E, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I815, 0 ), ++#endif ++ INTEL_DEVICE_MATCH (PCI_CHIP_I830_M, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_845_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I855_GM, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I865_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I915_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_E7221_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I915_GM, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I945_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I945_GM, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I945_GME, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I965_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I965_G_1, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I965_Q, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I946_GZ, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I965_GM, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_I965_GME, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_G33_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_Q35_G, 0 ), ++ INTEL_DEVICE_MATCH (PCI_CHIP_Q33_G, 0 ), ++ { 0, 0, 0 }, ++}; ++ ++#endif /* XSERVER_LIBPCIACCESS */ +"""]] + +### DriverRec changes + +The exported [[DriverRec|DriverRec]] has some new fields that refer to the above list of devices and a new libpciaccess-compatible probe function. Note that the structure places NULL for the old Probe field while listing the new probe function in the new slot. + + +[[!format txt """ +_X_EXPORT DriverRec I810 = { + I810_VERSION, + I810_DRIVER_NAME, + I810Identify, ++#if XSERVER_LIBPCIACCESS ++ NULL, ++#else + I810Probe, ++#endif + I810AvailableOptions, + NULL, +- 0 ++ 0, ++ NULL, ++#if XSERVER_LIBPCIACCESS ++ intel_device_match, ++ intel_pci_probe ++#endif + }; +"""]] + +### Registering the driver with the system + +In your setup function, you'll be adding a driver to the system. To make the server know that your [[DriverRec|DriverRec]] contains the new fields for libpciaccess, you need to pass the [[HaveDriverFuncs|HaveDriverFuncs]] flag or the server will never call your new probe function: + + +[[!format txt """ +@@ -429,7 +483,13 @@ i810Setup(pointer module, pointer opts, int *errmaj, int *errmin) + */ + if (!setupDone) { + setupDone = 1; +- xf86AddDriver(&I810, module, 0); ++ xf86AddDriver(&I810, module, ++#if XSERVER_LIBPCIACCESS ++ HaveDriverFuncs ++#else ++ 0 ++#endif ++ ); +"""]] + +### The new probe function + +The hardest part of the conversion is building a new probe function. This will replace your existing probe function when the server uses libpciaccess as the two mechanisms are incompatible. + +Here's the new intel probe function + + +[[!format txt """ +/* ++ * intel_pci_probe -- ++ * ++ * Look through the PCI bus to find cards that are intel boards. ++ * Setup the dispatch table for the rest of the driver functions. ++ * ++ */ ++static Bool intel_pci_probe (DriverPtr driver, ++ int entity_num, ++ struct pci_device *device, ++ intptr_t match_data) ++{ ++ ScrnInfoPtr scrn = NULL; ++ EntityInfoPtr entity; ++ I830EntPtr i830_ent = NULL; ++ DevUnion *private; ++ ++ scrn = xf86ConfigPciEntity (scrn, 0, entity_num, I810PciChipsets, ++ NULL, ++ NULL, NULL, NULL, NULL); ++ if (scrn != NULL) ++ { ++ scrn->driverVersion = I810_VERSION; ++ scrn->driverName = I810_DRIVER_NAME; ++ scrn->name = I810_NAME; ++ scrn->Probe = NULL; ++ ++ entity = xf86GetEntityInfo (entity_num); ++ ++ switch (DEVICE_ID(device)) { ++#ifndef I830_ONLY ++ case PCI_CHIP_I810: ++ case PCI_CHIP_I810_DC100: ++ case PCI_CHIP_I810_E: ++ case PCI_CHIP_I815: ++ scrn->PreInit = I810PreInit; ++ scrn->ScreenInit = I810ScreenInit; ++ scrn->SwitchMode = I810SwitchMode; ++ scrn->AdjustFrame = I810AdjustFrame; ++ scrn->EnterVT = I810EnterVT; ++ scrn->LeaveVT = I810LeaveVT; ++ scrn->FreeScreen = I810FreeScreen; ++ scrn->ValidMode = I810ValidMode; ++ break; ++#endif ++ case PCI_CHIP_845_G: ++ case PCI_CHIP_I865_G: ++ /* ++ * These two chips have only one pipe, and ++ * cannot do dual-head ++ */ ++ I830InitpScrn(scrn); ++ break; ++ default: ++ /* ++ * Everything else is an i830-ish dual-pipe chip ++ */ ++ xf86SetEntitySharable(entity_num); ++ ++ /* Allocate an entity private if necessary */ ++ if (I830EntityIndex < 0) ++ I830EntityIndex = xf86AllocateEntityPrivateIndex(); ++ ++ private = xf86GetEntityPrivate(scrn->entityList[0], ++ I830EntityIndex); ++ i830_ent = private->ptr; ++ if (!i830_ent) ++ { ++ private->ptr = xnfcalloc(sizeof(I830EntRec), 1); ++ i830_ent = private->ptr; ++ i830_ent->lastInstance = -1; ++ } ++ ++ /* ++ * Set the entity instance for this instance of the driver. ++ * For dual head per card, instance 0 is the "master" ++ * instance, driving the primary head, and instance 1 is ++ * the "slave". ++ */ ++ i830_ent->lastInstance++; ++ xf86SetEntityInstanceForScreen(scrn, ++ scrn->entityList[0], ++ i830_ent->lastInstance); ++ I830InitpScrn(scrn); ++ break; ++ } ++ } ++ return scrn != NULL; ++} +"""]] + +### Mapping device regions + +The final changes here affect how the driver maps bus regions into the server address space. This is a fairly mechanical change, except that the driver must know which BAR refers to each portion of the card address space. + +Here's a sample patch that maps the intel MMIO region: + + +[[!format txt """ + { + int mmioFlags; + I810Ptr pI810 = I810PTR(pScrn); ++#if XSERVER_LIBPCIACCESS ++ struct pci_device *const device = pI810->PciInfo; ++ int err; ++#endif + + #if !defined(__alpha__) + mmioFlags = VIDMEM_MMIO | VIDMEM_READSIDEEFFECT; +@@ -1211,11 +1408,23 @@ I810MapMMIO(ScrnInfoPtr pScrn) + mmioFlags = VIDMEM_MMIO | VIDMEM_READSIDEEFFECT | VIDMEM_SPARSE; + #endif + ++#if XSERVER_LIBPCIACCESS ++ err = pci_device_map_region (device, pI810->mmio_bar, TRUE); ++ if (err) ++ { ++ xf86DrvMsg (pScrn->scrnIndex, X_ERROR, ++ "Unable to map mmio BAR. %s (%d)\n", ++ strerror (err), err); ++ return FALSE; ++ } ++ pI810->MMIOBase = device->regions[pI810->mmio_bar].memory; ++#else + pI810->MMIOBase = xf86MapPciMem(pScrn->scrnIndex, mmioFlags, + pI810->PciTag, + pI810->MMIOAddr, I810_REG_SIZE); + if (!pI810->MMIOBase) + return FALSE; ++#endif + return TRUE; + } +"""]] +Unmapping requires similar changes: + + +[[!format txt """ +@ -1246,8 +1472,12 @@ I810UnmapMMIO(ScrnInfoPtr pScrn) + { + I810Ptr pI810 = I810PTR(pScrn); + ++#if XSERVER_LIBPCIACCESS ++ pci_device_unmap_region (pI810->PciInfo, pI810->mmio_bar); ++#else + xf86UnMapVidMem(pScrn->scrnIndex, (pointer) pI810->MMIOBase, + I810_REG_SIZE); ++#endif + pI810->MMIOBase = NULL; + } +"""]] + +### That's it + +The steps above are all that I found necessary to convert the intel driver; of course there are lots of other changes than the short patch excerpts here, but they're all available by looking at the intel driver git log. diff --git a/PciReworkProposal.mdwn b/PciReworkProposal.mdwn new file mode 100644 index 00000000..a059be40 --- /dev/null +++ b/PciReworkProposal.mdwn @@ -0,0 +1,287 @@ + + +# PCI Subsystem Rework for X.org v.next Proposal + +This wiki entry details a proposal for reworking the PCI handling code in X.org for the 7.1 release. + + +## Background + +It is fairly common knowledge in the X.org developer community that the PCI handling code in X.org 7.0 (and earlier) is a big, ugly mess. The code is complex, understood by very few developers, and does things that only the kernel should do. In fact, most of the existing code originates from a time before most kernels implemented the required functionality. Since that time, kernels have greatly expanded the functionality provided to user space for probing and accessing PCI devices. + +The PCI bus has also changed (e.g., multiple PCI domains, complex PCI-PCI bridges, AGP, and PCI-Express). This has required that the code to support probing and accessing PCI devices has also needed to change. Unfortuantely these changes tend to be platform specific. Certain features, such as multiple domains, are only supported on certain platforms by X.org. These features tend to be supported universally by the kernels on those platforms. + +Rather than duplicating the efforts of kernel developers, X.org needs to use the interfaces provided by the kernel as much as possible. It is currently unclear as to whether X.org still needs to support any platforms with kernels that do not export this functionality to user mode. + + +## Required Functionalty + +There are seven broad pieces of functionality that X.org needs to work with devices on the PCI bus. These are: + +1. Get a list of all devices matching some criteria. This criteria is typically either the device class (i.e., find all devices of the class "display" or "multimedia") or the device vendor. +1. Reading the device's expansion ROM. +1. Accessing the device's IO ports. +1. Accessing the device's memory regions (BARs). +1. Reading the device's capabilities (i.e., determine if the device is AGP). +1. Power management. +1. [[VgaArbiter|VgaArbiter]]. Ultimately this should be in the kernel, but it isn't currently. Devices thatdecode legacy VGA IO and MEM need to be identified. In addition, their IO/MEM enable/disable bits need to be toggled (along with the VGA forwarding enables on any bridges on the path to the devices). This is needed to prevent multiple devices from decoding legacy access. Drivers need to disable legacy decoding completely on their hardware, which most modern cards can do. The driver must be able to inform the arbiter of that fact to take out the card from the picture. This must be done carefuly since bad things will happen if the card generates an interrupt when the arbiter has disabled MEM decoding on the card. The arbiter needs to either forbid cards to use interrupts if they are set to decode legacy space (and thus can be disabled at any time) or have a driver callback for disabling IRQ emission on a given card when it's being disabled by the arbiter. IO and MEM can't be treated separately since there is only one VGA forward bit on PCI-to-PCI bridges. +In the best case scenario, nearly all of this functionality is trivially provided by Linux's sysfs interface. A certain amount of this functionality is also provided by the libpci.a library in the pciutils package. The missing functionality and license issues (libpci.a is GPL) prevent use of libpci.a from being a viable option. + + +## Proposed Implementation + +The current proposal is to implement a new library that implements the require functionality in a generic way. The existing code for accessing PCI devices would then be removed, in its entirety, from the X-server and the drivers. At this time the X-server and drivers would be ported to the new interface. The remainder of this section describes the interface to the proposed new library. + +The interface consists of a set of initialization / cleanup routines and a single primary data type. The overall structures is intentionally similar to that of libpci.a, but there are some significant differences. The initialization / cleanup routines are roughly analogous to `pci_access`. `pci_device` is roughly analogous to `pci_dev`. + + +### Initialization / Cleanup + +Access to the PCI system is obtained by calling `pci_system_init`. This function returns a either zero on success or an errno value on failure. It initializes global data that is private to the library. + +When access to the PCI system is no longer needed `pci_system_cleanup` is called. This destroys all of the internal data used by the library and all of the structures created by the library for the application. That is, all `pci_device`, `pci_device_iterator`, `pci_agp_info`, etc. are destroyed by calling `pci_system_cleanup`. + + +### Device Iteration + +Lists of PCI devices are obtained by creating a `pci_device_iterator` structure. This structure is created by calling either `pci_slot_match_iterator_create` or `pci_id_match_iterator_create`. + + +[[!format txt """ +struct pci_slot_match { + /* + * Device slot matching controls + * + * Control the search based on the domain, bus, slot, and function of + * the device. Setting any of these fields to PCI_MATCH_ANY will cause + * the field to not be used in the comparison. + */ + uint32_t domain; + uint32_t bus; + uint32_t dev; + uint32_t func; + + intptr_t match_data; +}; + +struct pci_device_iterator *pci_slot_match_iterator_create(const struct pci_slot_match *match); + +struct pci_id_match { + /* + * Device / vendor matching controls + * + * Control the search based on the device, vendor, subdevice, or subvendor + * IDs. Setting any of these fields to PCI_MATCH_ANY will cause the + * field to not be used in the comparison. + */ + uint32_t vendor_id; + uint32_t device_id; + uint32_t subvendor_id; + uint32_t subdevice_id; + + /* + * Device class matching controls + */ + uint32_t device_class; + uint32_t device_class_mask; + + intptr_t match_data; +}; + +struct pci_device_iterator *pci_id_match_iterator_create(const struct pci_id_match *match); +"""]] +This allows devices to be iterated either by bus location, by vendor, by class, or by function. These interfaces roughly match similar interfaces available within the Linux kernel. + +If the `match` parameter to either function is `NULL`, all devices will be matched. + +Devices are iterated by calling `pci_device_next` with the `pci_device_iterator`. After the last device has been returned, the next call to `pci_device_next` will return `NULL`. + + +[[!format txt """ +struct pci_device *pci_device_next(struct pci_device_iterator *iter); +"""]] +When an iterator will not be used any further, it must be destroyed using `pci_iterator_destroy`. + + +[[!format txt """ +void pci_iterator_destroy(struct pci_device_iterator *iter); +"""]] + +### pci_device + +The `pci_device` structure contains all of the expected fields and is very similar to libpci.a's `pci_dev` structure. Some fields that are important to X (e.g., `subvendor_id`) have been added, and some fields that are unnecessary (e.g., `rom_base_addr`) have been removed. + + +[[!format txt """ +struct pci_mem_region { + void * memory; + pciaddr_t bus_addr; + pciaddr_t base_addr; + pciaddr_t size; +}; + +struct pci_device { + uint16_t domain; + uint8_t bus; + uint8_t dev; + uint8_t func; + + uint16_t vendor_id; + uint16_t device_id; + uint16_t subvendor_id; + uint16_t subdevice_id; + + uint32_t device_class; + + struct pci_mem_region regions[6]; + + pciaddr_t rom_size; + + int irq; + + void * user_data; +}; +"""]] +Once a pointer to a device has been obtained, memory regions of the device can be mapped via `pci_device_map_region`. Mapped regions can be unmapped with `pci_device_unmap_region`. Once a region is mapped, it can be accessed via the `pci_mem_region::memory` pointer. + + +[[!format txt """ +int pci_device_map_region( struct pci_device * dev, unsigned region, + int write_enable ); + +int pci_device_unmap_region( struct pci_device * dev, unsigned region ); +"""]] +**ISSUE:** Should special routines for reading / writing MMIO regions ala xf86WriteMmio8 be added? + +The device's expansion ROM is treated specially. Rather than mapping the ROM and reading it, a special function, `pci_device_read_rom`, is provided. The supplied buffer must be at least `pci_device::rom_size` bytes. + + +[[!format txt """ +int pci_device_read_rom( struct pci_device * dev, void * buffer ); +"""]] +Device configuration and capability data can be accessed via traditional, libpci.a style read and write routines. + + +[[!format txt """ +int pci_device_cfg_read_u8 ( struct pci_device * dev, unsigned offset, uint8_t * val ); +int pci_device_cfg_read_u16 ( struct pci_device * dev, unsigned offset, uint16_t * val ); +int pci_device_cfg_read_u32 ( struct pci_device * dev, unsigned offset, uint32_t * val ); +int pci_device_cfg_read_block( struct pci_device * dev, unsigned offset, void * val, unsigned length ); +int pci_device_cfg_write_u8 ( struct pci_device * dev, unsigned offset, uint8_t val ); +int pci_device_cfg_write_u16 ( struct pci_device * dev, unsigned offset, uint16_t val ); +int pci_device_cfg_write_u32 ( struct pci_device * dev, unsigned offset, uint32_t val ); +int pci_device_cfg_write_block( struct pci_device * dev, unsigned offset, const void * val, + unsigned length ); +"""]] +In addition, specific routines and data types exist for common capabilities that are important to X. The `pci_device_get_agp_info` function parses the device's configuration header and returns a fully popluated `pci_agp_info` structure. If the device does not have an AGP capability entry, `NULL` is returned. + + +[[!format txt """ +struct pci_agp_info { + unsigned config_offset; + + uint8_t major_version; + uint8_t minor_version; + + uint8_t rates; + + uint8_t fast_writes:1; + uint8_t addr64:1; + uint8_t htrans:1; + uint8_t gart64:1; + uint8_t coherent:1; + uint8_t sideband:1; + uint8_t isochronus:1; + + uint8_t async_req_size; + uint8_t calibration_cycle_timing; + uint8_t max_requests; +}; + +const struct pci_agp_info * pci_device_get_agp_info( struct pci_device * dev ); +"""]] +In the future, similar routines may be added for other common device capabilities (e.g., power management, PCI-Express, etc.). + + +# Status + + +## Core X-server Status + +The core X-server portion of the PCI-rework is, essentially, finished. It lives in the pci-rework branch. + + +## libpciaccess Status +[[!table header="no" class="mointable" data=""" +**OS** | **Status** | **Point of Contact** +Linux | Working with sysfs | idr +FreeBSD | Working (7.x+) | anholt +NetBSD | ? | - +OpenBSD | Working | herrb +Solaris | Prototyping | [[edward.shu@sun.com|mailto:edward.shu@sun.com]] +AIX | ? | - +"""]] + + +## Driver Status +[[!table header="no" class="mointable" data=""" +**Driver** | **Status** | **Point of Contact** + apm | Not ported | - + ark | Not ported | - + ast | Not ported | - + ati/ati | [[Bugzilla|https://bugs.freedesktop.org/show_bug.cgi?id=9600]] | fufutos + ati/atimisc | [[Bugzilla|https://bugs.freedesktop.org/show_bug.cgi?id=9600]] | fufutos + ati/r128 | Not ported | - + ati/radeon | Not ported | - + chips | Not ported | - + cirrus | Not ported | - + cyrix | Not ported | - + dummy | Not ported | - + fbdev | Trunk | idr + glide | Not ported | - + glint | Not ported | - + i128 | Not ported | - + i740 | Not ported | - + impact | Not ported | - + imstt | Not ported | - + intel | Not ported | - + mga | Trunk | idr + neomagic | Not ported | - + newport | Not ported | - + nsc | Not ported | - + nv | Not ported | - + rendition | Trunk | idr + s3 | Not ported | - + s3virge | Not ported | - + savage | pci-rework branch | idr + siliconmotion | Not ported | - + sis | Not ported | - + sisusb | Not ported | - + sunbw2 | Not ported | - + suncg14 | Not ported | - + suncg3 | Not ported | - + suncg6 | Not ported | - + sunffb | Not ported | - + sunleo | Not ported | - + suntcx | Not ported | - + tdfx | In progress | idr + tga | Not ported | - + trident | Not ported | - + tseng | Not ported | - + v4l | Not ported | - + vesa | Trunk | idr + vga | Not ported | - + via | Not ported | - + vmware | Not ported | - + voodoo | Not ported | - + wsfb | Not ported | - + xgi | Not ported | - + xgixp | Not ported | - +"""]] + +Status key: + +* Trunk: Driver is ported to the new interface, and the port resides in the driver's trunk. +* pci-rework branch: Driver is ported to the new interface, and the port resides in the driver's pci-rework branch. +* In progress: The driver is being ported. +* Not ported: Work has not yet begun on porting driver to new interface.
\ No newline at end of file diff --git a/PersonalTrees.mdwn b/PersonalTrees.mdwn new file mode 100644 index 00000000..9a7e6ee9 --- /dev/null +++ b/PersonalTrees.mdwn @@ -0,0 +1,117 @@ + +This is a list of X server maintainer repositories. If you want to hack on the server, pick the most appropriate repository and branch and follow it. See the development process description on the [[XServer|XServer]] wiki page for more detail. + + +[[!format txt """ +URL: git://people.freedesktop.org/~ajax/xserver.git +MAINTAINER: Adam Jackson +DESCRIPTION: EDID, loader, Fedora, shatter, misc, other +NOTE: Branches may be non-fast-forward +BRANCHES: + - edid: EDID/DisplayID/general mode setup fixes +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~alanc/xserver.git +CGIT: http://cgit.freedesktop.org/~alanc/xserver/ +MAINTAINER: Alan Coopersmith +DESCRIPTION: Solaris & OpenSolaris port & upstreaming, general build system & dix work +NOTE: Branches may be non-fast-forward +BRANCHES: + - master: branch to be merged into xserver git master +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~daniels/xserver +CGIT: http://cgit.freedesktop.org/~daniels/xserver +MAINTAINER: Daniel Stone [daniel@fooishbar.org] +DESCRIPTION: XKB and Xi development, general patches +NOTES: Branches generally do not fast-forward +BRANCHES: + - master: general patches (mostly from the list and Bugzilla), rebased against upstream master + - misc-next: various WIP patches, rebased against master + - ge: GeneralEvents extension v1.1, rebased against master (depends on the ge branch of ~daniels/xextproto) + - xkbcommon: Port of the X server to libxkbcommon, rebased against master (depends on master of libxkbcommon) + - multitouch: Xi 2.1 multitouch support , rebased against master(depends on the multitouch branch of ~daniels/inputproto) + - input-next: Amalgamation of various input branches +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~dottedmag/xserver +CGIT: http://cgit.freedesktop.org/~dottedmag/xserver +MAINTAINER: Mikhail Gusarov <dottedmag@dottedmag.net> +DESCRIPTION: janitorial work, optimizations +BRANCHES: + - for-keithp: branch to be merged into xserver git master + - fixes: WIP fixes, often rebased +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~herrb/xserver +CGIT: http://cgit.freedesktop.org/~herrb/xserver +MAINTAINER: Matthieu Herrb <matthieu.herrb@laas.fr> +DESCRIPTION: OpenBSD patches +BRANCHES: + - master: branch with patches to be merged into xserver git master + - obsd: branch with all OpenBSD local changes tracking master + - obsd-server-1.9-branch: id. tracking server-1.9-branch + - obsd-server-1.10-branch: id. tracking server-1.10-branch +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~jcristau/xserver +CGIT: http://cgit.freedesktop.org/~jcristau/xserver +MAINTAINER: Julien Cristau +DESCRIPTION: random stuff +BRANCHES: + - libudev: udev-based input-hotplug backend +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~jeremyhu/xserver.git +CGIT: http://cgit.freedesktop.org/~jeremyhu/xserver +MAINTAINER: Jeremy Huddleston +DESCRIPTION: XQuartz development +BRANCHES: + - master: branch to be merged into xserver git master + - xorg-server-1.7-apple: Stable release branch for XQuartz based on server-1.7-branch + - xorg-server-1.6-apple: Stable release branch for XQuartz based on server-1.6-branch + - xorg-server-1.5-apple: Stable release branch for XQuartz based on server-1.5-branch + - xorg-server-1.4-apple: Stable release branch for XQuartz based on server-1.4-branch +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~mattst88/xserver.git +MAINTAINER: Matt Turner +DESCRIPTION: DEC Alpha work +BRANCHES: + - master: branch to be merged into xserver git master +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~vignatti/xserver.git +MAINTAINER: Tiago Vignatti +DESCRIPTION: General work mostly driven for embedded devices +BRANCHES: + - for-keith: branch to be merged into xserver git master +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~whot/xserver.git +MAINTAINER: Peter Hutterer +DESCRIPTION: General input work +BRANCHES: + - for-keith: branch to be merged into xserver git master (may rebase if I screw up, but should be the exception) +"""]] + +[[!format txt """ +URL: git://people.freedesktop.org/~yselkowitz/xserver.git +MAINTAINER: Yaakov (Cygwin/X) +DESCRIPTION: Cygwin/X development +NOTE: Some branches may be non-fast-forward +BRANCHES: + - cygwin: Cygwin/X experimental release branch based on master + - cygwin-release-1.8: Cygwin/X stable release branch on server-1.8-branch + - master: branch to be merged into xserver git master + - server-1.8-branch: branch to be merged into xserver git server-1.8-branch +"""]]
\ No newline at end of file diff --git a/PressReleases/X11R6970Released.mdwn b/PressReleases/X11R6970Released.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/PressReleases/X11R6970Released.mdwn diff --git a/PressReleases/X11R71Released.mdwn b/PressReleases/X11R71Released.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/PressReleases/X11R71Released.mdwn diff --git a/PressReleases/X11R72Released.mdwn b/PressReleases/X11R72Released.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/PressReleases/X11R72Released.mdwn diff --git a/PressReleases/X11r682Released.mdwn b/PressReleases/X11r682Released.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/PressReleases/X11r682Released.mdwn diff --git a/PressReleases/XtsReleased.mdwn b/PressReleases/XtsReleased.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/PressReleases/XtsReleased.mdwn diff --git a/ProgrammingDocumentation.mdwn b/ProgrammingDocumentation.mdwn new file mode 100644 index 00000000..afaa83f7 --- /dev/null +++ b/ProgrammingDocumentation.mdwn @@ -0,0 +1,25 @@ + +Most programmers who write applications for X will use third party toolkits. + +If you are interested in writing an application that uses X primitives directly without the use of a toolkit, you can use the Xlib interface, painful though it is. + +The documentation for the Xlib interface can be found here: + +* [[html version|http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html]] +* [[pdf version|http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.pdf]] +* [[text version|http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.txt]] +O'Reilly & Associates have also made freely available online some of their classic X programming manuals. These are a bit older, dating from the [[X11R3|X11R3]], R4, or R5 eras, and the toolkit ones cover Xt-based toolkits which are no longer in widespread use for new applications, but much of the Xlib documentation still applies, it just doesn't cover all the new additions: + +Xlib: + +* [[X Series Volume 2: Xlib Reference Manual (1989, covers X11R3)|http://www.archive.org/details/xlibretmanver1102nyemiss]] +* [[X Series Volume 2: Xlib Reference Manual, 2nd Edition (1990, covers X11R4)|http://www.archive.org/details/xlibrefmanv115ed02nyemiss]] +Xt & Xt-based toolkits: + +* [[X Series Volume 4: X Toolkit Intrinsics Programming Manual, 1st Edition (1990, covers X11R3)|http://www.archive.org/details/xtoolkitintrsin20400nyemiss]] +* [[X Series Volume 4: X Toolkit Intrinsics Programming Manual, 2nd Edition (1990, covers X11R4)|http://www.archive.org/details/xtoolkitintrinsi04nyemiss]] +* [[X Series Volume 4: X Toolkit Intrinsics Programming Manual, Motif Edition (1990, covers X11R4/Motif 1.1)|http://www.archive.org/details/xtoolktintrmotif04nyemiss]] +* [[X Series Volume 4: X Toolkit Intrinsics Programming Manual, 3rd Edition (1993, covers X11R5)|http://www.archive.org/details/xtoolkitintrinsic04nyemiss]] +* [[X Series Volume 5: X Toolkit Intrinsics Reference Manual (1990, covers X11R4)|http://www.archive.org/details/xtoolkitintrinsi04nyemiss]] +* [[X Series Volumes 6A & 6B: Motif Programming & Reference Manuals|http://www.oreilly.com/openbook/motif/]] +* [[X Series Volumes 7A & 7B: XView Programming & Reference Manuals|http://www.oreilly.com/openbook/openlook/]]
\ No newline at end of file diff --git a/Projects/Drivers.mdwn b/Projects/Drivers.mdwn new file mode 100644 index 00000000..a1012aba --- /dev/null +++ b/Projects/Drivers.mdwn @@ -0,0 +1,66 @@ + +Look here to check if your graphics card / chipset is supported. The pages are named like the driver modules and sorted by manufacturer. Hint: see also `man <drivername>` and `/usr/share/doc/`. + +* 3Dfx + * [[tdfx|tdfx]] - Voodoo Banshee, Voodoo3,4,5 + * [[glide|glide]] - for 2D on Voodoo1 and Voodoo2 cards (uses glide) + * [[voodoo|voodoo]] - for 2D on Voodoo1 and voodoo2 cards (glide not required) +Maintainer: Alan Cox +* [[apm|apm]] - Alliance Promotion chipset (*not* Advanced Power Managment) +* ATI + * [[ati|ati]] - ATI driver wrapper + * [[atimisc|atimisc]] - Mach8/32/64 + * [[r128|r128]] - ATI Rage 128 + * [[radeon|radeon]] - ATI Radeon +_see also [[ATIProprietaryDriver|ATIProprietaryDriver]]_ + * [[radeonhd|radeonhd]] - ATI Radeon X1000, HD1000, HD2000 series +* [[chips|chips]] - Chips and Technologies (CT64200,CT64300,CT65520,CT65525,CT65530, CT65535, CT65540, CT65545, CT65546, CT65548, CT65550, CT65554, CT65555, CT69000, CT69030) +_Maintainer:_ [[Egbert Eich|mailto:eich_at__freedesktop.org]] +* [[cirrus|cirrus]] - Cirrus Logic +* [[cyrix|cyrix]] - Cyrix MediaGX (MediaGX, MediaGXi, MediaGXm) +* [[fbdev|fbdev]] - a Framebuffer device based X server +* [[geode|geode]] (formerly _amd_) - AMD Geode +* [[glint|glint]] - 3Dlabs (GLINT, Permedia) and TI (Permedia) chips - details see link. +* [[i128|i128]] - Number Nine I128 +Maintainer: Adam Jackson +* [[imstt|imstt]] - Integrated Micro Solutions Twin Turbo 128 +* Intel + * [[i740|i740]] - Intel 740 based cards + * [[intel|intel]] (formerly _i810_) - Intel 8xx/9xx motherboards (i810, i810-dc100, i810e, i815, i830, i845, i855, i865, i915, i945, i965) +Maintainer: Intel +* [[mga|mga]] - Matrox Millennium I/II,Mystique, G100,G200,G400,G450,G550,G550 Dual-DVI +* [[neomagic|neomagic]] - Neomagic chips: MagicGraph 128, 128V, 128ZV, 128ZV+, 128XD, 256AV, 256AV+, 256ZX, 256XL+ +_Maintainer:_ [[Egbert Eich|mailto:eich_at_freedesktop.org]] +* [[newport|newport]] - SGI Indy newport cards +* [[nsc|nsc]] - National Semiconductor +* [[nv|nv]] - Nvidia RIVA 128,TNT,TNT2, GeForce, QUADRO, DCC,4, nForce, nForce2 +_see also [[NVIDIAProprietaryDriver|NVIDIAProprietaryDriver]]_ and [[nouveau|http://nouveau.freedesktop.org/]] +* [[rendition|rendition]] - Rendition (Micron) Verité chip (V1000, V2x00) +* S3 + * [[s3|s3]] - Old S3 Chipsets + * [[s3virge|s3virge]] - S3 ViRGE series (ViRGE, ViRGE DX,GX,GX2,MX,MX+,VX and Trio3D,Trio3D/2x) + * [[savage|savage]] - S3 Savage series (Savage 3D,4,2000,/MX,/IX, ProSavage PM133,KM133, Twister, TwisterK +* [[siliconmotion|siliconmotion]] - Silicon Motion, Inc. (SMI) Lynx, Lynx E/3D/EM/EM+/3DM +* [[sis|sis]] - [[SiS|SiS]] 5597/5598, 6326, 530/620, 300/305, 540, 630/730, 315/E/H/PRO, 650/651/M650/740, 661FX/M661FX/M661MX/741, 330 (Xabre), 760; and XGI Volari V3XT, V5, and V8 +_Maintainer:_ [[Thomas Winischhofer|mailto:twini_at_xfree86.org]] +* SUN + * [[sunbw2|sunbw2]] + * [[suncg14|suncg14]] + * [[suncg3|suncg3]] + * [[suncg6|suncg6]] + * [[sunffb|sunffb]] + * [[sunleo|sunleo]] + * [[suntcx|suntcx]] +* [[tga|tga]] - DEC 21030 (TGA) +* [[trident|trident]] - Trident Blade, Image, ProVidia, TGUI, ISA/VL families (details see link) +* [[tseng|tseng]] - Tseng Labs ET4000, ET4000w32, ET6000/6100 +* [[v4l|v4l]] - video4linux driver for video overlay, e.g. bt848/bt878-based TV cards +* [[vesa|vesa]] - Generic VESA video driver +* [[vga|vga]] - Standard VGA +* VIA Integrated Graphics + * [[via|via]] - VIA CLE266/KM400/![[K8M400|K8M400]] video driver + * [[openchrome|http://www.openchrome.org/]] - currently the most complete community based driver for VIA's unichrome[pro] chipsets + * [[unichrome|http://unichrome.sf.net/]] - an apparently abandoned community based driver, used as the base to openchrome + * [[VIA's own ''via'' driver|http://linux.via.com.tw/]] - now also open source, but lacks 3D and TVout support +* [[vmware|vmware]] - for running X under VMware +Maintainer: VMware
\ No newline at end of file diff --git a/Projects/XRandR.mdwn b/Projects/XRandR.mdwn new file mode 100644 index 00000000..fa944caa --- /dev/null +++ b/Projects/XRandR.mdwn @@ -0,0 +1,16 @@ + + +# RandR Documentation + +In addition to the RandR X protocol, an official configuration utility (named `xrandr`) is maintained in the [[freedesktop git repository|http://cgit.freedesktop.org/xorg/app/xrandr/]]. + +* [[Protocol specification|http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt]] +* [[RandR 1.2 overview|http://wiki.debian.org/XStrikeForce/HowToRandR12]] from Debian +* [[X Configuration|https://wiki.ubuntu.com/X/Config]] from Ubuntu +* Documentation from Intel on setting up [[dual head|http://www.intellinuxgraphics.org/dualhead.html]] configuration with RandR 1.2 +* [[XrandR 1.2 HowTo|http://www.thinkwiki.org/wiki/Xorg_RandR_1.2]] from Think``Wiki +* [[A Newbie's Guide|http://www.phoronix.com/scan.php?page=article&item=927]] from Phoronix +* A short how-to on [[writing an X.Org driver|http://wiki.x.org/wiki/DriverDevelopment]], updated to include RandR 1.2. +For Historical (only?) value: + +* The usenix [[paper|http://static.usenix.org/publications/library/proceedings/usenix01/freenix01/gettys.html]] from 2001 describing RANDR 0.91 and it's motivations.
\ No newline at end of file diff --git a/RadeonFeature.mdwn b/RadeonFeature.mdwn new file mode 100644 index 00000000..68a8e052 --- /dev/null +++ b/RadeonFeature.mdwn @@ -0,0 +1,291 @@ + +[[!toc ]] + + +## Feature Matrix for Free Radeon Drivers + +**This page is only for free Radeon drivers using KMS. + [[radeon|radeon]] (xf86-video-ati) for 2D; radeon, r200 Mesa and r300, r600, radeonsi Gallium drivers only. + THIS PAGE IS NOT FOR [[FGLRX/CATALYST|ATIProprietaryDriver]] DRIVERS PROVIDED BY AMD/ATI.** + +**See [[RadeonFeatureUMS|RadeonFeatureUMS]] for radeon in UMS.** + +**See [[radeonhd:feature|radeonhd:feature]] for radeonhd.** + +Also check out the [[RadeonProgram|RadeonProgram]], [[GalliumStatus|GalliumStatus]], and [[ATIRadeon|http://dri.freedesktop.org/wiki/ATIRadeon]] at DRI wiki. + +* "**DONE**" means that it is implemented and relatively bug-free. +* "**MOSTLY**" means that it is implemented but has some known bugs. +* "**WIP**" means that someone has started on the initial implementation. +* "**BIOS**" means only if supported by your BIOS. No software support. Yet. +* "**N/A**" means that the feature is not supported by the hardware. +* "**N/N**" means that the feature will not be implemented, because a better alternative is or will be available. +* "**TODO**" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #radeon if you want to get your feet wet on this. +* "**UNKNOWN**" means that the current status of this item isn't known. You are free to update it if you know. [[!table header="no" class="mointable" data=""" +**2D features** || | **R100** | **R200** | **R300/R400** | **R500** | **R600/700** | **Evergreen** | **N.Islands** | **S.Islands**[^1] +Kernel Modesetting || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Max Supported Displays (Eyefinity)[^2] || | 1-2 | 2 | 2 | 2 | 2 | 2-6 | 4-6 | 6 +DRI2 || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Page Flipping || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +ShadowFB || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +2D Acceleration (EXA) || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | Gallium +2D Acceleration (glamor)[^3] || | N/A | N/A | DONE | DONE | DONE | DONE | DONE | DONE +Textured Xv || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | Gallium +Video Decode (XvMC/VDPAU/VA-API) + on the 3D engine || | TODO | TODO | WIP | WIP | WIP | WIP | WIP | WIP +Video Decode (XvMC/VDPAU/VA-API) + on UVD || | N/A | N/A | N/A | N/A | DONE[^4] | DONE | DONE | DONE +Hybrid Graphics/PowerXpress/Enduro[^5] || | N/A | N/A | N/A | N/A | MOSTLY | MOSTLY | MOSTLY | MOSTLY +**Mesa 3D features** || | **R100** | **R200** | **R300/R400** | **R500** | **R600/700** | **Evergreen** | **N.Islands** | **S.Islands**[^6] +3D Driver || | radeon | r200 | r300g | r300g | r600g | r600g | r600g | radeonsi +Primitives || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Stippled Primitives || | DONE | DONE | TODO | TODO | TODO | TODO | TODO | TODO +Smooth Primitives || | DONE | DONE | TODO | TODO | TODO | TODO | TODO | TODO +Textures || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Hardware TCL || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Vertex Shaders || | N/A | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Fragment (Pixel) Shaders || | N/A | DONE | DONE | DONE | DONE | DONE | DONE | DONE +GLSL || | N/A | N/A | DONE | DONE | DONE | DONE | DONE | DONE +Color Buffer Tiling || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE[^7] +Texture Tiling || | TODO | TODO | DONE | DONE | DONE | DONE | DONE | DONE[^8] +S3TC decompression +<small>(via env variable / drirc)</small> || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE[^9] +full S3TC +<small>(via libtxc_dxtn.so)</small> || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE[^10] +Tessellation Shader Stages || | N/A | N/A | N/A | N/A | N/A | TODO | TODO | TODO +Geometry Shaders || | N/A | N/A | N/A | N/A | TODO | TODO | TODO | TODO +Anti-Aliasing (MSAA) || | N/A | N/A | MOSTLY[^11] | DONE | DONE[^12] | DONE[^13] | DONE[^14] | TODO +Anti-Aliasing (MLAA) || | N/A | N/A | N/A | [[MOSTLY|http://candgsoc.host56.com/]] | [[DONE|http://candgsoc.host56.com/]] | [[DONE|http://candgsoc.host56.com/]] | [[not tested|http://candgsoc.host56.com/]] | [[not tested|http://candgsoc.host56.com/]] +Anisotropic Filtering || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Hyper-Z || | WIP | TODO | MOSTLY[^15] | DONE | DONE | DONE | DONE | TODO +OpenGL Compliance (Driver/Hardware) || | 1.3/1.3 | 1.3/1.4 | 2.1/2.1[^16] | 2.1/2.1[^17] | 3.1/3.3[^18] | 3.1/4.2[^19] | 3.1/4.2[^20] | 2.1/4.2 +**Output** || | **R100** | **R200** | **R300/R400** | **R500** | **R600/700** | **Evergreen** | **N.Islands** | **S.Islands**[^21] +Dual-link DVI || | N/A | DONE | DONE | DONE | DONE | DONE | DONE | DONE +XRandR 1.2 || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +TV Out || | DONE | DONE | DONE | DONE | DONE | DONE | N/A | N/A +[[DisplayPort|DisplayPort]] || | N/A | N/A | N/A | N/A | DONE | DONE | DONE | DONE +HDMI Audio[^22] || | N/A | N/A | N/A | N/A | DONE | DONE[^23] | DONE[^24] | TODO +**Power Saving** || | **R100** | **R200** | **R300/R400** | **R500** | **R600/700** | **Evergreen** | **N.Islands** | **S.Islands**[^25] +Engine reclocking || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Memory reclocking || | TODO | TODO | TODO | DONE | DONE | DONE | DONE | DONE +Voltage adjusting || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +Thermal sensors || | N/A | N/A | DONE[^26] | DONE[^27] | DONE[^28] | DONE[^29] | DONE[^30] | DONE[^31] +**Other** || | **R100** | **R200** | **R300/R400** | **R500** | **R600/700** | **Evergreen** | **N.Islands** | **S.Islands**[^32] +Suspend Support || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +[[CrossFire|CrossFire]] (multi-card) || | N/A | N/A | N/A | TODO | TODO | TODO | TODO | TODO +Compute (OpenCL)[^33] || | N/A | N/A | N/A | N/A | TODO | WIP | WIP | WIP +Asynchronous DMA || | N/A | N/A | N/A | N/A | DONE | DONE | DONE | DONE +"""]] + +[^34] + + +## VSYNC + +There are several mechanisms involved in tear-free rendering due to limitations in X. + + +### 3D driver environment variable + +* vblank_mode - selects whether or not the 3D application should synchronize to vblank. + +### DDX driver options + +* [[EnablePageFlip|EnablePageFlip]] - This option enables the use of pageflipping (switching the display controller's base address pointer) rather than blits for GL buffer swaps. It only applies to fullscreen GL apps. Pageflipping is always synced to vblank at the moment. +* [[SwapBuffersWait|SwapBuffersWait]] - This option prevents tearing for GL buffer swaps by waiting to update the front buffer until scanout has passed the area of the screen the GL buffer swap is going to blit to. +* EXAVSync - This option prevents tearing for EXA operations by waiting to update the front buffer until scanout has passed the area of the screen the EXA operation is going to render to. + +### Xv Attribute + +* XV_VSYNC - This option prevents tearing when playing back videos using Xv by waiting to update the video image until scanout has passed the area of the screen displaying the video. It only prevents tearing if Xv is rendering directly to the front buffer. If you are using a compositer, this does not prevent tearing because Xv is rendering to an offscreen buffer and the compositor copied it to the front buffer. + +## KMS Power Management Options + +Kernel 2.6.35 or newer is required. The pm code supports two basic methods: + +1. "dynpm" +1. "profile" +You can select the methods via sysfs. Echo "dynpm" or "profile" to /sys/class/drm/card0/device/power_method. + +Controlling the fan speed directly is not possible (and would be very dangerous), but it can be lowered by setting lower power profile. + +The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The reclocking is attemped during vertical blanking periods, but due to the timing of the reclocking functions, doesn't not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active. + +The "profile" method exposes five profiles that can be selected from: + +1. "default" +1. "auto" +1. "low" +1. "mid" +1. "high" +Select the profile by echoing the selected profile to /sys/class/drm/card0/device/power_profile. + +* "default" uses the default clocks and does not change the power state. This is the default behavior. +* "auto" selects between "mid" and "high" power states based on the whether the system is on battery power or not. The "low" power state are selected when the monitors are in the dpms off state. +* "low" forces the gpu to be in the low power state all the time. Note that "low" can cause display problems on some laptops; this is why auto does not use "low" when displays are active. +* "mid" forces the gpu to be in the "mid" power state all the time. The "low" power state is selected when the monitors are in the dpms off state. +* "high" forces the gpu to be in the "high" power state all the time. The "low" power state is selected when the monitors are in the dpms off state. +The "profile" method is not as agressive as "dynpm," but is currently much more stable and flicker free and works with multiple heads active. + +Power management is supported on all asics (r1xx-evergreen) that include the appropriate power state tables in the vbios; not all boards do (especially older desktop cards). + +Thermal sensors are implemented via external i2c chips or via the internal thermal sensor (rv6xx-evergreen only; supported in 2.6.36 or newer); not all OEMs implement a thermal sensor. To get the temperature on asics that use i2c chips, you need to load the appropriate hwmon driver for the sensor used on your board (lm63, lm64, etc.). The drm will attempt to load the appropriate hwmon driver. On boards that use the internal thermal sensor, the drm will set up the hwmon interface automatically. When the appropriate driver is loaded, the temperatures can be accessed via lm_sensors tools or via sysfs in /sys/class/hwmon. + + +## Linux kernel parameters + +Try _modinfo -p radeon_ to find up-to-date parameters. To check default values look at _drivers/gpu/drm/radeon/radeon_drv.c_ in Linux kernel source. To check current values look at _/sys/class/drm/card*/device/driver/module/holders/radeon/parameters/*_ +[[!table header="no" class="mointable" data=""" +Option | Values | Default value<sup>1</sup> | Explanation +radeon.agpmode | 1, 2, 4, 8, -1 | 0 | AGP mode, -1 for PCI/PCIe mode +radeon.audio | 0, 1 | 0 | Disable/enable HDMI audio +radeon.benchmark | | 0 | Run benchmark +radeon.connector_table | | 0 | Force connector table +radeon.disp_priority | 0, 1, 2 | 0 | Display Priority (0 = auto, 1 = normal, 2 = high) +radeon.dynclks | 0, 1, -1 | -1 | Disable/Enable dynamic clocks, -1 for auto +radeon.gartsize | 32, 64, etc. | 512 | Size of PCIe/IGP gart to setup in megabytes +radeon.hw_i2c | 0, 1 | 0 | Disable/enable hw i2c engine +radeon.modeset | 0, 1, -1 | -1 | Disable/enable modesetting, -1 for auto +radeon.msi | 0, 1, -1 | -1 | Disable/enable MSI support, -1 for auto +radeon.no_wb | 0, 1 | | Disable/enable AGP writeback for scratch registers +radeon.pcie_gen2 | 0, 1 | -1 | Disable/enable PCIe 2.0 support, -1 for auto +radeon.r4xx_atom | 0, 1 | 0 | Disable/enable ATOMBIOS modesetting for R4xx +radeon.test | | 0 | Run tests +radeon.tv | 0, 1 | 1 | Disable/enable TV +radeon.vramlimit | 32, 64, etc. | 0 | Restrict VRAM for testing +"""]] + +<sup>1</sup> For Linux kernel 3.6 + + +## Decoder ring for engineering vs marketing names +[[!table header="no" class="mointable" data=""" +Family | Engineering Names | Marketing Names +R100 | R100, RV100, RV200, RS100, RS200 | 7xxx, 320-345 +R200 | R200, RV250, RV280, RS300 | 8xxx - 9250 +R300 | R300, R350, RV350, RV380, RS400, RS480 | 9500 - 9800, X300 - X600, X1050 - X1150, 200M +R400 | R420, R423, RV410, RS600, RS690, RS740 | X700 - X850, X12xx, 2100 +R500 | RV515, R520, RV530, RV560, RV570, R580 | X1300 - X2300, HD2300 +R600 | R600, RV610, RV630, RV620, RV635, RV670, RS780, RS880 | HD2400 - HD4290 +R700 | RV770, RV730, RV710, RV740 | HD4330 - HD5165, HD5xxV +Evergreen | CEDAR, REDWOOD, JUNIPER, CYPRESS, PALM (Wrestler), SUMO, SUMO2 | HD5430 - HD5970, all HD6000 not listed under _Northern Islands_, HD7350 +Northern Islands | ARUBA, BARTS, TURKS, CAICOS, CAYMAN | HD6450, HD6570, HD6670, HD6790 - HD6990, HD64xxM, HD67xxM, HD69xxM, HD7450 - HD7670 +Southern Islands | CAPE VERDE, PITCAIRN, TAHITI, OLAND, HAINAN | HD7750 - HD7970 +Sea Islands | BONAIRE, KABINI, KAVERI | HD7790 +"""]] + + +## Radeon 3D Hardware +[[!table header="no" class="mointable" data=""" +3D Core | Engineering Names | Shader Model | DX | OpenGL | Max Texture Size | Max Renderbuffer Size +R1xx | R100, RV100, RV200, RS100, RS200 | NA | 7 | 1.3 | 2048 | 2048 +R2xx | R200, RV250, RV280, RS300 | 1 | 8 | 1.4 | 2048 | 2048 +R3xx | R300, R350, RV350, RV380, RS400, RS480 | 2 | 9 | 2.1 | 2048 | 2560 +R4xx | R420, R423, RV410, RS600, RS690, RS740 | 2 | 9 | 2.1 | 2048 | 4021 +R5xx | RV515, R520, RV530, RV560, RV570, R580 | 3 | 9 | 2.1 | 4096 | 4096 +R6xx | R600, RV610, RV630, RV620, RV635, RV670, RS780, RS880 | 4 | 10 | 3.3 | 8192 | 8192 +R7xx | RV770, RV730, RV710, RV740 | 4 | 10 | 3.3 | 8192 | 8192 +R8xx | CEDAR, REDWOOD, JUNIPER, CYPRESS, PALM (Wrestler), SUMO, SUMO2, BARTS, TURKS, CAICOS | 5 | 11 | 4.2 | 16384 | 16384 +R9xx | CAYMAN, ARUBA | 5 | 11 | 4.2 | 16384 | 16384 +RAxx | CAPE VERDE, PITCAIRN, TAHITI, OLAND, HAINAN | 5 | 11 | 4.2 | 16384 | 16384 +RBxx | BONAIRE, KABINI, KAVERI | 5 | 11 | 4.2 | 16384 | 16384 +"""]] + + +## Radeon Display Hardware +[[!table header="no" class="mointable" data=""" +Display Core | Engineering Names | Display Controllers | DACs | TV Encoder | DVO | Digital | Notes +Classic Radeon | Rage128, R1xx-R4xx | 1-2 | 1-2 | 0-1 | 1 | 2 (1 TMDS, 1 LVDS) | +DCE1/Avivo | R5xx | 2 | 2 | 1 | 1 | 2 (1 TMDS, 1 LVDS/TMDS) | +DCE2 | R600, RV610, RV630, RV670, RS600, RS690, RS740 | 2 | 2 (R600, RV610, RV630, RV670), 1 (RS600, RS690, RS740) | 1 | 1 | 2 (1 TMDS, 1 LVDS/TMDS) | Adds HDMI 1.2 Support +DCE3 | RV620, RV635, RS780, RS880 | 2 | 2 (RV620, RV635), 1 (RS780, RS880) | 1 | 1 | 3 (LVDS/TMDS/DP) | Adds support for [[DisplayPort|DisplayPort]], HDMI 1.3 Support +DCE3.1 | RV770 | 2 | 2 | 1 | 1 | 3 (LVDS/TMDS/DP) | +DCE3.2 | RV710, RV730, RV740 | 2 | 2 | 1 | 1 | 5 (LVDS/TMDS/DP) | Adds support for up to 5 digital outputs +DCE4 | CEDAR, REDWOOD, JUNIPER, CYPRESS | 4-6 | 2 | 1 | 1 | 6 (LVDS/TMDS/DP) | Adds support for up to 6 independant displays (max of 2 non-[[DisplayPort|DisplayPort]] displays) +DCE4.1 | PALM (Wrestler), SUMO, SUMO2 | 2 | 1 (PALM), 0 (SUMO, SUMO2) | 1 | 1 | 6 (LVDS/TMDS/DP) | VGA and LVDS are implemented via DP bridge chips +DCE5 | BARTS, TURKS, CAICOS, CAYMAN | 4-6 | 1 | 0 | 1 | 6 (LVDS/TMDS/DP) | Adds improved gamma correction, HDMI 1.4 support, [[DisplayPort|DisplayPort]] 1.2 support +DCE6 | CAPE VERDE, PITCAIRN, TAHITI | 6 | 1 | 0 | 1 | 6 (LVDS/TMDS/DP) | HDMI 4K modes +DCE6.1 | ARUBA | 4 | 0 | 0 | 1 | 6 (TMDS/DP) | VGA and LVDS are implemented via DP bridge chips +DCE6.4 | OLAND | 2 | 1 | 0 | 1 | 2 (TMDS/DP) | +DCE8.1 | KAVERI | 4 | 0 | 0 | 0 | 7 (TMDS/DP) | VGA and LVDS are implemented via DP bridge chips +DCE8.2 | BONAIRE | 6 | 1 | 0 | 1 | 6 (LVDS/TMDS/DP) | +DCE8.3 | KABINI | 2 | 1 | 0 | 0 | 2 (LVDS/TMDS/DP) | +"""]] + + +## Where to get the drivers + +* Xorg radeon DDX ([[xf86-video-ati|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]]) +* Mesa 3D driver ([[radeon, r200, r300c/g, r600c/g|http://cgit.freedesktop.org/mesa/mesa/]]) +* KMS DRM ([[Linux Kernel|http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary]]) +* libdrm ([[libdrm_radeon|http://cgit.freedesktop.org/mesa/drm/]]) + +## Where to file defect reports + +[[http://bugs.freedesktop.org|http://bugs.freedesktop.org]] using the following values for Product : Component... + +* Xorg radeon DDX - xorg : Driver/Radeon +* Mesa 3D driver (1xx) - Mesa : Drivers/DRI/Radeon +* Mesa 3D driver (2xx) - Mesa : Drivers/DRI/r200 +* Mesa 3D driver (3xx-5xx) - Mesa : Drivers/Gallium/r300 +* Mesa 3D driver (6xx-NI) - Mesa : Drivers/Gallium/r600 +* Mesa 3D driver (SI) - Mesa : Drivers/Gallium/radeonsi +* KMS DRM aka Kernel graphics driver - DRI : DRM/Radeon + +## Documentation + +* [[A presentation about R600 for very beginners|R600_pres_carli2.pdf]] +* [[AMD R3xx 3D Register Reference|http://www.x.org/docs/AMD/R3xx_3D_Registers.pdf]] +* [[AMD R5xx Acceleration|http://www.x.org/docs/AMD/R5xx_Acceleration_v1.5.pdf]] +* [[AMD R6xx/R7xx 3D Register Reference|http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf]] +* [[AMD R6xx+ Acceleration|http://www.x.org/docs/AMD/R6xx_R7xx_3D.pdf]] +* [[AMD rv630|http://www.x.org/docs/AMD/42589_rv630_rrg_1.01o.pdf]] +* [[AMD rs690|http://www.x.org/docs/AMD/43372_rs690_rrg_3.00o.pdf]] +* [[AMD M56|http://www.x.org/docs/AMD/RRG-216M56-03oOEM.pdf]] +* [[AMD m76|http://www.x.org/docs/AMD/42590_m76_rrg_1.01o.pdf]] +* [[AMD R6xx shader ISA|http://developer.amd.com/wordpress/media/2012/10/R600_Instruction_Set_Architecture.pdf]] +* [[AMD R7xx shader ISA|http://developer.amd.com/wordpress/media/2012/10/R700-Family_Instruction_Set_Architecture.pdf]] +* [[AMD Evergreen shader ISA|http://developer.amd.com/wordpress/media/2012/10/AMD_Evergreen-Family_Instruction_Set_Architecture.pdf]] +* [[AMD Cayman/Trinity shader ISA|http://developer.amd.com/wordpress/media/2012/10/AMD_HD_6900_Series_Instruction_Set_Architecture.pdf]] +* [[AMD OpenCL and Compute Resources|http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/documentation/]] +* [[AMD Developer Guides (RS780/RS880, SB7xx, etc.)|http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/]] +* [[AMD Southern Islands Series ISA|http://developer.amd.com/wordpress/media/2012/12/AMD_Southern_Islands_Instruction_Set_Architecture.pdf]] + +## Links + +* [[Wikipedia AMD GPUs|http://en.wikipedia.org/wiki/Ati_gpu]] + +[^1] Kernel 3.4 required +[^2] Depends on the OEM board. Max of 2 non-Displayport displays. +[^3] Requires a 3D driver with shader support +[^4] DONE for R7xx, TODO for R6xx +[^5] There are two versions of hybrd graphics: MUXed and MUX-less. MUXed have a display MUX to switch the displays between the discrete and integrated cards. MUXed systems can be switched using vgaswitcheroo. MUX-less do not have a display MUX and the displays are only connected to the integrated card. On MUX-less systems, the discrete card is solely for rendering, not display. X Server 1.14 is required to support rendering and display from different cards. Most new laptops (2011+) are MUX-less. +[^6] Kernel 3.4 required +[^7] Kernel 3.10 required +[^8] Kernel 3.10 required +[^9] Kernel 3.10 required +[^10] Kernel 3.10 required +[^11] Needs piglit testing before enabling by default, see mesa commit 8ed6b1400 +[^12] Kernel 3.6 required +[^13] Kernel 3.6 required +[^14] Kernel 3.6 required +[^15] Needs piglit and Lightsmark testing before enabling by default, see mesa commit 12dcbd595 +[^16] Hardware doesn't support ARB NPOT textures fully. +[^17] Hardware doesn't support ARB NPOT textures fully. +[^18] Kernel 3.6 and xserver 1.13 required +[^19] Kernel 3.6 and xserver 1.13 required +[^20] Kernel 3.6 and xserver 1.13 required +[^21] Kernel 3.4 required +[^22] Requires loading radeon with the audio parameter set to 1 (e.g., add radeon.audio=1 on the kernel command line in grub). +[^23] Kernel 3.3 required +[^24] Kernel 3.5 required +[^25] Kernel 3.4 required +[^26] i2c chip +[^27] i2c chip +[^28] i2c chip or internal sensor +[^29] i2c chip or internal sensor +[^30] i2c chip or internal sensor +[^31] i2c chip or internal sensor +[^32] Kernel 3.4 required +[^33] See http://dri.freedesktop.org/wiki/GalliumCompute +[^34] None diff --git a/RadeonFeature/R600_pres_carli2.pdf b/RadeonFeature/R600_pres_carli2.pdf Binary files differnew file mode 100644 index 00000000..07da91c3 --- /dev/null +++ b/RadeonFeature/R600_pres_carli2.pdf diff --git a/RadeonFeatureUMS.mdwn b/RadeonFeatureUMS.mdwn new file mode 100644 index 00000000..c3400df2 --- /dev/null +++ b/RadeonFeatureUMS.mdwn @@ -0,0 +1,52 @@ + + +## Feature Matrix for Free Radeon Drivers + +**This page is only for free Radeon drivers. [[radeon|radeon]] (xf86-video-ati) for 2D; radeon, r200, r300, r600 Mesa and r300, r600 Gallium drivers only. THIS PAGE IS NOT FOR [[FGLRX/CATALYST|ATIProprietaryDriver]] DRIVERS PROVIDED BY AMD/ATI.** + +**See [[RadeonFeature|RadeonFeature]] For KMS** + +**See [[radeonhd:feature|radeonhd:feature]] for radeonhd.** + +Also check out the [[RadeonProgram|RadeonProgram]], [[GalliumStatus|GalliumStatus]], and [[ATIRadeon|http://dri.freedesktop.org/wiki/ATIRadeon]] at DRI wiki. + + * "**DONE**" means that it is implemented and relatively bug-free. + * "**MOSTLY**" means that it is implemented but has some known bugs. + * "**WIP**" means that someone has started on the initial implementation. + * "**BIOS**" means only if supported by your BIOS. No software support. Yet. + * "**N/A**" means that the feature is not supported by the hardware. + * "**N/N**" means that the feature will not be implemented, because a better alternative is or will be available. + * "**TODO**" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #radeon if you want to get your feet wet on this. + * "**UNKNOWN**" means that the current status of this item isn't known. You are free to update it if you know. [[!table header="no" class="mointable" data=""" + **2D features** || | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + DDX (X server) Modesetting || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | MOSTLY + Console restore || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | TODO + DRI || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | N/N + ShadowFB || | N/N | N/N | N/N | N/N | N/N | N/N | DONE | DONE | DONE + Old 2D Acceleration (XAA) || | DONE | DONE | DONE | DONE | DONE | DONE | N/N | N/N | N/N + 2D Acceleration (EXA) || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | N/N + Overlay Xv || | DONE | DONE | DONE | DONE | N/N | N/N | N/N | N/N | N/N + Textured Xv || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | N/N + Video Decode (XvMC/VDPAU/VA-API) using the 3D engine || | TODO | TODO | TODO | TODO | TODO | TODO | TODO | TODO | TODO + Video Decode (XvMC/VDPAU/VA-API) using UVD || | N/A | N/A | N/A | N/A | N/A | N/A | TODO | TODO | TODO + **Mesa 3D features** || | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + Primitives || | DONE | DONE | DONE | DONE | DONE | DONE | MOSTLY | MOSTLY | N/N + Textures || | DONE | DONE | DONE | DONE | DONE | DONE | MOSTLY | MOSTLY | N/N + Hardware TCL || | DONE | DONE | DONE | DONE | N/A | DONE | MOSTLY | MOSTLY | N/N + Vertex Shaders || | N/A | DONE | DONE | DONE | N/A | DONE | MOSTLY | MOSTLY | N/N + Fragment (Pixel) Shaders || | N/A | DONE | DONE | DONE | DONE | DONE | MOSTLY | MOSTLY | N/N + GLSL || | N/A | N/A | WIP | WIP | WIP | WIP | MOSTLY | MOSTLY | N/N + Antialiasing || | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN + OpenGL Compliance (Driver/Hardware) || | 1.3/1.3 | 1.3/1.4 | 1.5/2.0<sup>1</sup> | 1.5/2.0<sup>1</sup> | 1.5/2.0<sup>1</sup> | 1.5/2.0<sup>1</sup> | 2.0/3.3 | 2.0/3.3 | N/N/4.0 + **Output** || | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + Dual-link DVI || | N/A | BIOS | BIOS | DONE | DONE | DONE | DONE | DONE | DONE + XRandR 1.2 || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE + TV Out || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE + [[DisplayPort|DisplayPort]] || | N/A | N/A | N/A | N/A | N/A | N/A | DONE | DONE | DONE + HDMI Audio || | N/A | N/A | N/A | N/A | TODO | N/A | TODO | TODO | TODO + **Other** || | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + Power Saving (Powerplay) || | MOSTLY | MOSTLY | MOSTLY | MOSTLY | MOSTLY | MOSTLY | MOSTLY | MOSTLY | MOSTLY + Suspend Support || | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE | DONE +"""]] + +<sup>1</sup> Hardware doesn't support ARB NPOT textures fully. diff --git a/RadeonProgram.mdwn b/RadeonProgram.mdwn new file mode 100644 index 00000000..703bc321 --- /dev/null +++ b/RadeonProgram.mdwn @@ -0,0 +1,283 @@ + + +## Supported Program List for Free Radeon Drivers + +**This page is only for the open source Xorg Radeon drivers. [[radeon|radeon]] (xf86-video-ati) for 2D; radeon, r200 Mesa Classic drivers and r300, r600 Gallium drivers only. THIS PAGE IS NOT FOR THE CLOSED-SOURCE [[FGLRX/CATALYST|ATIProprietaryDriver]] DRIVER PROVIDED BY AMD/ATI.** + +Also check out the [[RadeonFeature|RadeonFeature]] page. + +This list works on the same principle as the Wine game list, but there are some important differences. + +The biggest difference is that we are tracking driver capabilities, not performance. It doesn't matter if your game runs at 1680x1050 with everything cranked up, what matters is whether or not it is rendering properly. + +The entries in the table are "**STATUS (N.M)**", where **N.M** is the latest version / stable branch of Mesa on which the application was tested, and **STATUS** is one of the following (you can copy color codes from here): +[[!table header="no" class="mointable" data=""" +PLATINUM (N.M) | it works without any graphical bugs or problems, with all features enabled (no footnote is needed) +G0LD (N.M) | it works well, but not every little eye-candy feature works. For some chipsets, this might be due to hardware limitations. Please add a footnote why it is not PLATINUM (preferably with a link to a reported bug at freedesktop.org) +SILVER (N.M) | it works, but has serious graphical errors. For some chipsets, this might be due to hardware limitations. Please add a footnote why it is not G0LD (preferably with a link to a reported bug at freedesktop.org) +GARBAGE (N.M) | it just doesn't work, due to driver problems. Please add a footnote why it is not SILVER (preferably with a link to a reported bug at freedesktop.org) +TOO OLD | it just doesn't work at all, due to known hardware limitations. +UNKNOWN | the current status of this item isn't known. Please update it if you know. +"""]] + +Note that the level of support for R300-R500 is roughly on the same level because those chips all use the same driver. This means that if the status is known for e.g. R300, then it is likely that the status for R500 is the same or at least similar, but please refrain from changing this in the table unless you really did test the application using that chip. A similar thing is true for R600-R700. + +Here are some guidelines for this page: + +* We do not distinguish between different versions of a stable branch of Mesa. So Mesa 7.n, 7.n.1, 7.n.2, etc. all count as 7.n. +* If this page claims that an application works in Mesa 7.n, and you tested it using stable Mesa release 7.(n+1) and it still works, please update the table accordingly. +* If this page claims that an application works in Mesa 7.n, but you experience problems in stable Mesa release 7.(n+1), please notify the developers before changing the table. If we do not fix the problem within a reasonable time frame, feel free to change the corresponding entry in the table. +* If this page claims that an application fails in Mesa 7.n, but you have tested it using stable Mesa release 7.(n+1) and it works fine, please update the table accordingly. +* If the page makes claim about how well an application works in Mesa 7.n and you disagree about it, please discuss it in the community (see information on the [[Radeon 3D portal page|http://dri.freedesktop.org/wiki/Radeon]]). +* _Note on bugs:_ please prefers opening a [[new bug on freedesktop bugzilla|https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa]] and link it here rather than reporting directly the bug here. +* When experiencing issues on Apple hardware, refer to [[mac-how.net|http://www.mac-how.net]] +* Mesa version numbers do not apply to **UNKNOWN** or **TOO OLD** +* _Development (git) versions:_ When running Mesa from a git checkout, use the following format for version numbering: **X.Y-dev**. You can obtain the version number by running **glxinfo | grep version** and examining the OpenGL version string; it will say something like "1.5 Mesa 7.7-devel". +* The classic DRI drivers have been obsoleted by the newer Gallium3D ones, r300g is the default for r300-r500 since 7.9 and r600g for r600- since 7.10. Add no more test results with the classic drivers for these chips, please. +* When adding a footnote, please qualify it with the time it was written, so that we may in the future more easily decide whether the footnote is out of date. +* _Comments and changelogs:_ When editing this page, **please add** an explanatory note to the Comment field! We need to know what changed and why with a quick glance, to keep up with the driver progress. +* an <sup>S3</sup> after the name of the program indicates that it won't work at all without S3TC support (libtxc_dxtn.so) [[!table header="no" class="mointable" data=""" +**Native** | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** | **Northern Islands** +[[0 A.D.|http://www.wildfiregames.com/0ad/]]<sup>S3</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.11<sup>G</sup>)<sup>1</sup> | G0LD (7.9)<sup>32</sup> | PLATINUM (8.0) | UNKNOWN | PLATINUM (7.11) +[[Alien Arena 2011|http://red.planetarena.org/index.html]] | UNKNOWN | UNKNOWN | G0LD (7.11-dev)<sup>76</sup> | G0LD (7.6) | UNKNOWN | G0LD (7.6) | PLATINUM (7.11-dev) | PLATINUM (7.11) | UNKNOWN | PLATINUM (7.11) +[[Amnesia: The Dark Descent|http://www.amnesiagame.com/#main]]<sup>S3</sup> | UNKNOWN | UNKNOWN | UNKNOWN | SILVER (7.9)<sup>66</sup> | UNKNOWN | SILVER (7.10) | PLATINUM (7.11-dev) | PLATINUM (7.12-dev)<sup>3</sup> | UNKNOWN | UNKNOWN +[[AndYetItMoves|http://www.andyetitmoves.net/]] | UNKNOWN | UNKNOWN | PLATINUM (8.0) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Aquaria|http://www.bit-blot.com/aquaria/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.8) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Assault Cube|http://assault.cubers.net/]] | UNKNOWN | G0LD (7.5)<sup>15</sup> | UNKNOWN | PLATINUM (7.6) | UNKNOWN | PLATINUM (7.6) | G0LD (8.04)<sup>44</sup> | G0LD (7.9)<sup>44</sup> | UNKNOWN | UNKNOWN +[[AstroMenace|http://www.viewizard.com/]] | UNKNOWN | G0LD (7.11-dev)<sup>75</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (8.04)<sup>63</sup> | G0LD (7.9)<sup>63</sup> | UNKNOWN | UNKNOWN +[[Battle of Wesnoth|http://wesnoth.org/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | UNKNOWN | UNKNOWN | UNKNOWN +[[Blender3d|http://www.blender.org/]] | UNKNOWN | UNKNOWN | G0LD (7.6)<sup>18</sup> | G0LD (7.6) | UNKNOWN | GARBAGE (7.6)<sup>23</sup> | SILVER (7.7)<sup>18</sup> | G0LD (7.10) | PLATINUM (7.12-dev) | UNKNOWN +[[Blocks that matter|http://www.swingswingsubmarine.com/games/blocks-that-matter/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | UNKNOWN | UNKNOWN | UNKNOWN +[[Braid|http://www.braid-game.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11-dev) | UNKNOWN | PLATINUM (7.12-dev) | PLATINUM (8.1-dev) +[[Caster|http://www.elecorn.com/caster3d/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | SILVER (7.7)<sup>51</sup> | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN | UNKNOWN +[[Celestia|http://www.shatters.net/celestia/]] | UNKNOWN | UNKNOWN | PLATINUM (7.11) | UNKNOWN | UNKNOWN | G0LD (7.6) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | PLATINUM (7.11) +[[Cogs|http://www.cogsgame.com/]] | UNKNOWN | UNKNOWN | G0LD (8.0)<sup>100</sup> | UNKNOWN | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>102</sup> | UNKNOWN | PLATINUM (7.12-dev) | UNKNOWN +[[ColdWar|http://www.linuxgamepublishing.com/info.php?id=24]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>89</sup> | UNKNOWN | UNKNOWN | UNKNOWN +[[Compiz Fusion|http://www.compiz-fusion.org/]] | UNKNOWN | G0LD (7.5) | PLATINUM (7.5) | PLATINUM (7.6) | PLATINUM (7.5) | PLATINUM (7.7) | PLATINUM (7.10) | PLATINUM (7.10) | UNKNOWN | PLATINUM (7.11) +[[CoreBreach|http://corebreach.corecode.at/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | GOLD (7.11)<sup>96</sup> | UNKNOWN | UNKNOWN | UNKNOWN +[[Darwinia|http://www.introversion.co.uk/darwinia]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[Doom 3|http://zerowing.idsoftware.com/linux/doom/]]<sup>78</sup> <sup>81</sup> | UNKNOWN | G0LD (7.5) | PLATINUM (7.11-dev) | GARBAGE (7.5) | UNKNOWN | UNKNOWN | PLATINUM (7.11-dev) | PLATINUM (7.11-dev) | UNKNOWN | PLATINUM (7.11) +[[Eduke32|http://eduke32.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.10) | UNKNOWN | UNKNOWN | UNKNOWN +[[Enemy Territory: Quake Wars|http://zerowing.idsoftware.com/linux/etqw/]]<sup>S3</sup> <sup>78</sup> <sup>85</sup> | TOO OLD | TOO OLD | PLATINUM (7.10) | GARBAGE (7.5) | UNKNOWN | UNKNOWN | G0LD (7.11-dev) | PLATINUM (8.0) | UNKNOWN | PLATINUM (7.11) +[[ePSXe|http://www.epsxe.com/]] | UNKNOWN | UNKNOWN | PLATINUM (7.5) | UNKNOWN | UNKNOWN | G0LD (7.5) | G0LD (7.9) | G0LD (7.9) | UNKNOWN | UNKNOWN +[[Eschalon: Book I|http://basiliskgames.com/downloads]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.8)<sup>48</sup> | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Family Farm|http://www.familyfarmgame.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (8.04)<sup>103</sup> | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[FlightGear v2.0.0|http://www.flightgear.org/]] | UNKNOWN | UNKNOWN | G0LD (7.10)<sup>84</sup> | UNKNOWN | UNKNOWN | UNKNOWN | SILVER (7.8-dev)<sup>37</sup> | G0LD (7.10) | UNKNOWN | PLATINUM (7.11) +[[FooBillard|http://foobillard.sourceforge.net/]] | UNKNOWN | UNKNOWN | PLATINUM (7.12-dev)<sup>77</sup> | PLATINUM (7.9) | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | PLATINUM (7.11) +[[Frets On Fire|http://fretsonfire.sourceforge.net/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9)<sup>62</sup> | PLATINUM (7.9)<sup>62</sup> | UNKNOWN | UNKNOWN +[[Google Earth|http://earth.google.com/]] | UNKNOWN | G0LD (7.5) | PLATINUM (7.10) | G0LD (7.5) | G0LD (7.5) | PLATINUM (7.11<sup>G</sup>) | G0LD (7.9)<sup>56</sup> | G0LD (7.9)<sup>56</sup> | PLATINUM<sup>56</sup> (7.12-dev) | PLATINUM (7.11) +[[Gish|http://www.chroniclogic.com/gish.htm]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.8) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Glest|http://www.glest.org]] | UNKNOWN | UNKNOWN | PLATINUM (7.11) | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9)<sup>46</sup> | G0LD (7.9)<sup>46</sup> | UNKNOWN | UNKNOWN +[[Hedgewars|http://www.hedgewars.org/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Heroes of Newerth|http://www.heroesofnewerth.com/]] | TOO OLD | TOO OLD | G0LD (8.0)<sup>101</sup> | UNKNOWN | UNKNOWN | G0LD (7.10) | G0LD (7.10) | G0LD (7.10) | UNKNOWN | UNKNOWN +[[KWin|http://techbase.kde.org/Projects/KWin]] | UNKNOWN | PLATINUM (7.9-dev) <sup>28</sup> | PLATINUM (7.10) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9)<sup>59</sup> | PLATINUM (7.10) | UNKNOWN | PLATINUM (8.1-dev) +[[Lightsmark 2008|http://dee.cz/lightsmark/]] | UNKNOWN | UNKNOWN | SILVER (7.11-dev)<sup>79</sup> | UNKNOWN | UNKNOWN | SILVER (7.10) | PLATINUM (7.11-dev) | PLATINUM (7.11-dev) | UNKNOWN | PLATINUM (7.11) +[[Lightspark|http://launchpad.net/lightspark]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN +[[Lugaru HD|http://www.wolfire.com/lugaru]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | UNKNOWN | G0LD (7.8) | PLATINUM (7.11-dev) | PLATINUM (7.11-dev) | PLATINUM (7.12-dev) | UNKNOWN +[[MegaGlest|http://megaglest.org/]] | UNKNOWN | UNKNOWN | PLATINUM (7.11) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | UNKNOWN | UNKNOWN | UNKNOWN +[[Mupen64Plus|http://code.google.com/p/mupen64plus/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9) | G0LD (7.9) | UNKNOWN | UNKNOWN +[[Neverball|http://neverball.org/]] | UNKNOWN | PLATINUM (7.5) | PLATINUM (7.5) | PLATINUM (7.5) | PLATINUM (7.5) | PLATINUM (7.7) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | PLATINUM (7.10) +[[Neverwinter Nights|http://icculus.org/~ravage/nwn/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | UNKNOWN | UNKNOWN | UNKNOWN +[[Nexuiz|http://www.alientrap.org/nexuiz/]] | PLATINUM (7.6) | PLATINUM (7.6) | G0LD (7.10)<sup>80</sup> | G0LD (7.5) | G0LD (7.5) | PLATINUM (7.7) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.10) | PLATINUM (7.10) +[[OilRush|http://www.oilrush-game.com/]] | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | UNKNOWN | UNKNOWN | G0LD (7.11-dev) | UNKNOWN | SILVER (8.0.3)<sup>99</sup> +[[OpenArena|http://www.openarena.ws/]] ([[ioquake3|http://ioquake3.org/]]) | PLATINUM (7.6) | PLATINUM (7.6) | PLATINUM (7.5) | PLATINUM (7.5) | SILVER (7.5) | PLATINUM (7.7) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.12-dev) | PLATINUM (7.10) +[[OpenBVE|http://openbve.trainsimcentral.co.uk/]] | UNKNOWN | PLATINUM (7.9-dev) | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Osmos|http://www.hemispheregames.com/osmos/]] | UNKNOWN | UNKNOWN | PLATINUM (8.0) | UNKNOWN | UNKNOWN | PLATINUM (7.8) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.11) | PLATINUM (8.03) +[[Penumbra Collection|http://www.penumbragame.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | UNKNOWN | G0LD (7.8)<sup>55</sup> | G0LD (7.11-dev) | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN +[[Piglit|http://people.freedesktop.org/~nh/piglit/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN +[[PlaneShift|http://www.planeshift.it/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.10) | UNKNOWN | UNKNOWN +[[Postal 2|http://www.postal2.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9) | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[Prey|http://icculus.org/prey/]]<sup>S3</sup> <sup>78</sup> <sup>81</sup> | UNKNOWN | G0LD (7.5) | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN | PLATINUM (7.11<sup>G</sup>) | G0LD (7.8) | PLATINUM (7.11-dev) | UNKNOWN | PLATINUM (7.11) +[[Racer|http://www.racer.nl/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9)<sup>47</sup> | G0LD (7.9)<sup>47</sup> | UNKNOWN | UNKNOWN +[[Quake Live|http://www.quakelive.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Quake 4|http://zerowing.idsoftware.com/linux/quake4/]]<sup>78</sup> <sup>81</sup> | UNKNOWN | G0LD (7.5) | PLATINUM (7.11-dev) | GARBAGE (7.5) | UNKNOWN | GARBAGE (7.7) | PLATINUM (7.11-dev) | PLATINUM (7.11-dev) | PLATINUM (7.11-dev) | PLATINUM (7.11) +[[Regnum Online|http://www.regnumonlinegame.com/index.php?l=0&sec=6]]<sup>S3</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.12)<sup>98</sup> | G0LD (7.12)<sup>98</sup> | G0LD (7.12)<sup>98</sup> | G0LD (7.12)<sup>98</sup> | UNKNOWN | UNKNOWN +[[Return To Castle Wolfenstein|http://zerowing.idsoftware.com/linux/wolf/]] | UNKNOWN | PLATINUM (7.6) | UNKNOWN | PLATINUM (7.6) | UNKNOWN | PLATINUM (7.6) | PLATINUM (8.04) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[rRootage|http://rrootage.sourceforge.net/]] | UNKNOWN | PLATINUM (7.11-dev) | PLATINUM (7.5) | PLATINUM (7.5) | UNKNOWN | PLATINUM (7.5) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Ryzom|http://www.ryzom.com/en/index.html]] | UNKNOWN | UNKNOWN | SILVER (7.9)<sup>65</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9)<sup>65</sup> | UNKNOWN | UNKNOWN +[[Savage: The Battle For Newerth|http://www.s2games.com/savage/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | SILVER (8.0.4)<sup>107</sup> | G0LD (7.10) | UNKNOWN | UNKNOWN +[[Savage 2: A Tortured Soul|http://www.savage2.com/]] | TOO OLD | TOO OLD | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>108</sup> | G0LD (7.10) | UNKNOWN | PLATINUM (7.11-dev) +[[Sauerbraten|http://sauerbraten.org/]] | UNKNOWN | G0LD (7.5) | PLATINUM (7.10) | G0LD (7.5) | G0LD (7.5) | PLATINUM (7.11<sup>G</sup>) | G0LD (7.9)<sup>49</sup> | PLATINUM (7.11-dev)<sup>49</sup> | UNKNOWN | PLATINUM (7.11) +[[Scorched 3D|http://www.scorched3d.co.uk/]] | UNKNOWN | UNKNOWN | PLATINUM (7.6.1) | UNKNOWN | UNKNOWN | PLATINUM (7.10) | G0LD (7.11)<sup>57</sup> | G0LD (7.10) | UNKNOWN | G0LD (8.03) +[[Second Life|http://www.secondlife.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.5) | SILVER (7.7) | UNKNOWN | UNKNOWN | UNKNOWN +[[Secret Maryo Chronicles|http://www.secretmaryo.org/]] | UNKNOWN | PLATINUM (7.5) | SILVER (7.5) | PLATINUM (7.6) | UNKNOWN | PLATINUM (7.7) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Shadowgrounds|http://shadowgroundsgame.com/]]<sup>S3</sup> | UNKNOWN | UNKNOWN | PLATINUM (7.12-dev)<sup>92</sup> | UNKNOWN | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>105</sup> | PLATINUM (7.11-dev) | G0LD<sup>91</sup> (7.12-dev) | UNKNOWN +[[Shadowgrounds: Survivor|http://shadowgroundsgame.com/survivor/]]<sup>S3</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>105</sup> | PLATINUM (7.11-dev) | G0LD<sup>91</sup> (7.12-dev) | UNKNOWN +[[Shank|http://www.shankgame.com/]]<sup>S3</sup> | TOO OLD | TOO OLD | TOO OLD | TOO OLD | UNKNOWN | UNKNOWN | GARBAGE (8.04)<sup>106</sup> | PLATINUM (8.0-rc2) | UNKNOWN | UNKNOWN +[[Shogo: Mobile Armor Division|http://www.hyperion-entertainment.com/index.php?option=com_content&view=article&id=51&Itemid=57]] | PLATINUM (7.6) | PLATINUM (7.6) | PLATINUM (7.6) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Smokin' Guns|http://www.smokin-guns.net/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (8.04)<sup>104</sup> | G0LD (7.10) | UNKNOWN | UNKNOWN +[[Soldier of Fortune|http://www.lokigames.com/products/sof/]] | UNKNOWN | PLATINUM (7.6) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.6) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Spring RTS|http://springrts.com/]] [[(mod: CA)|http://springrts.com/wiki/Complete_Annihilation]] | UNKNOWN | UNKNOWN | SILVER (7.5) | UNKNOWN | UNKNOWN | SILVER (7.7) | SILVER (7.9)<sup>58</sup> | SILVER (7.9)<sup>58</sup> | UNKNOWN | UNKNOWN +[[Stellarium|http://www.stellarium.org/]] | UNKNOWN | G0LD (7.10) | G0LD (7.5) | UNKNOWN | G0LD (7.5) | PLATINUM (7.5) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.10) | UNKNOWN +[[Steel Storm: Burning Retribution|http://one.steel-storm.com/]] | UNKNOWN | UNKNOWN | PLATINUM (8.0) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[SuperTuxKart|http://supertuxkart.sourceforge.net/]] | PLATINUM (7.6) | PLATINUM (7.6) | PLATINUM (7.5) | UNKNOWN | UNKNOWN | PLATINUM (7.7) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.12-dev) | UNKNOWN +Team Fortress 2 Beta | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (9.0) +[[Teeworlds|http://www.teeworlds.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11<sup>G</sup>) | GARBAGE (7.12-dev) | UNKNOWN +[[Tiny & Big in: Grandpa's Leftovers|http://tinyandbig.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN | UNKNOWN +[[TORCS|http://torcs.sourceforge.net/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11<sup>G</sup>) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Transfusion|http://www.transfusion-game.com/]] | UNKNOWN | PLATINUM (7.6) | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Tremulous|http://tremulous.net/]] | UNKNOWN | UNKNOWN | PLATINUM (7.6) | UNKNOWN | G0LD (7.5) | PLATINUM (7.6) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.12-dev) | UNKNOWN +[[Trine|http://trine-thegame.com/site//]]<sup>S3</sup> | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | GARBAGE (8.04) | PLATINUM (7.11-dev) | PLATINUM (7.12-dev) | UNKNOWN +[[Trine 2|http://trine2.com/site/]]<sup>S3</sup> | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | UNKNOWN | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[True Combat: Elite|http://www.truecombatelite.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[UFO:AI|http://ufoai.ninex.info/wiki/index.php/News]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | G0LD (7.9) | UNKNOWN | UNKNOWN +[[Unigine: Sanctuary 2.3|http://www.unigine.com/products/sanctuary/]] | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | SILVER (7.9-dev)<sup>50</sup> | SILVER (7.11-dev) | SILVER (7.10) | UNKNOWN | PLATINUM (8.1-dev) +[[Unigine: Tropics 1.3|http://unigine.com/products/tropics/]] | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | UNKNOWN | SILVER (7.11-dev) | SILVER (7.11-dev) | UNKNOWN | PLATINUM (7.11) +[[Unigine: Heaven 2.5|http://unigine.com/products/heaven/]] | TOO OLD | TOO OLD | TOO OLD | TOO OLD | TOO OLD | UNKNOWN | GARBAGE (7.9)<sup>64</sup> | GOLD (7.12-dev)<sup>35</sup> | UNKNOWN | G0LD (7.11)<sup>95</sup> +[[Unknown Horizons|http://www.unknown-horizons.org/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11) | PLATINUM (7.11<sup>G</sup>) | UNKNOWN | UNKNOWN +[[Unreal Tournament 2004|http://www.unrealtournament2003.com/ut2004/]]<sup>82</sup> | G0LD (7.6) | G0LD (7.6) | PLATINUM (7.10) | G0LD (7.5) | UNKNOWN | G0LD (7.6) | PLATINUM (7.9)<sup>31</sup> | PLATINUM (7.9)<sup>31</sup> | PLATINUM (7.10) | PLATINUM (7.11) +[[Urban Terror|http://www.urbanterror.net]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.10) | UNKNOWN | PLATINUM (7.6) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.12-dev) | UNKNOWN +[[Warsow|http://www.warsow.net/]] | UNKNOWN | UNKNOWN | PLATINUM (7.10) | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | PLATINUM (7.11-dev) | PLATINUM (7.10) | UNKNOWN +[[Warzone 2100|http://wz2100.net/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (8.04) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[Wolfenstein:Enemy Territory|http://www.planetwolfenstein.com/enemyterritory/]] | PLATINUM (7.5) | PLATINUM (7.5) | PLATINUM (7.5) | PLATINUM (7.5) | UNKNOWN | PLATINUM (7.5) | PLATINUM (8.04) | PLATINUM (7.9)<sup>61</sup> | PLATINUM (7.9) | UNKNOWN +[[World of Goo|http://2dboy.com/games.php]] | UNKNOWN | PLATINUM (7.5) | PLATINUM (7.5) | UNKNOWN | PLATINUM (7.5) | PLATINUM (7.8) | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.11) | UNKNOWN +[[World of Padman|http://www.worldofpadman.com]] | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.10) | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | UNKNOWN +[[XBMC|http://www.xbmc.org]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.9) | PLATINUM (7.9) | PLATINUM (7.10) | PLATINUM (7.11) +[[Yo Frankie!|http://www.yofrankie.org/]] | UNKNOWN | UNKNOWN | G0LD (7.10)<sup>83</sup> | UNKNOWN | UNKNOWN | PLATINUM (7.6) | PLATINUM (7.9) | PLATINUM (7.9) | UNKNOWN | PLATINUM (7.11) +[[Vendetta Online|http://www.vendetta-online.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.9-dev) | UNKNOWN | PLATINUM (7.10) | UNKNOWN | UNKNOWN +"""]] + +Please verify that the application/game is marked as Platinum in [[Wine AppDB|http://appdb.winehq.org/]] before adding it here. +[[!table header="no" class="mointable" data=""" +**Wine** | **R100** | **R200** | **R300** | **R400** | **RS690** | **R500** | **R600** | **R700** | **Evergreen** | **Northern Islands** +[[Crysis 2|www.ea.com/pl/crysis2]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | SILVER (7.12-dev)<sup>90</sup> | UNKNOWN | UNKNOWN +[[EVE Online:Incursion|http://www.eve-online.com]]<sup>S3</sup> | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.11-dev)<sup>87</sup> | UNKNOWN | UNKNOWN +[[Max and the Magic Marker|http://http://maxandthemagicmarker.com//]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN | UNKNOWN +[[Max Payne|http://http://www.maxpayne.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11) | UNKNOWN | UNKNOWN +[[Multi Theft Auto|http://www.mtasa.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11-dev) | UNKNOWN | UNKNOWN +[[Perpetuum|http://www.perpetuum-online.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.11-dev)<sup>86</sup> | UNKNOWN | UNKNOWN +[[Portal 2|http://www.thinkwithportals.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.12-dev)<sup>93</sup> | UNKNOWN | UNKNOWN +[[Team Fortress 2|http://www.teamfortress.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.10) | UNKNOWN | UNKNOWN +[[World of Warcraft:Cataclysm|http://us.battle.net/wow]]<sup>S3</sup> | UNKNOWN | UNKNOWN | SILVER (7.9)<sup>29</sup> | UNKNOWN | GARBAGE (7.5) | SILVER (7.5) | PLATINUM (7.12)² | SILVER (7.10) | UNKNOWN | UNKNOWN +[[Victoria 2|http://www.victoria2.com/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | PLATINUM (7.11) +[[CivCity: Rome|http://www.2kgames.com/civcityrome/]] | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | UNKNOWN | G0LD (7.11)<sup>97</sup> +"""]] + + +### Game notes + +<sup>1</sup> Game minimap is corrupted ([[bug #36762|https://bugs.freedesktop.org/show_bug.cgi?id=36762]]). + +² S3TC support is needed. + +<sup>3</sup> (19 September 2011) All graphics features work except antialiasing, to enable advanced post process shaders like SSAO you have to compile mesa with --enable-texture-float. + +<sup>15</sup> Rendering is good on rV280; water reflection need to be turned off due performance reason (just like as in other Cube engine games) + +<sup>18</sup> (Blender) 2.49 requires low impact fallbacks to draw all interface symbols (looped stipple lines for lamp types, etc), but that affects speed. 2.50 requiries changing triple buffer mode to something else, or unusable (app problem, it seems to happen with other brands and operating systems too). + +<sup>23</sup> (26 Oct 2009) [mesa-git] Crashes on many operations and does not update it's interface correctly. + +<sup>28</sup> (14 Set 2010) Works perfectly [ATI Radeon 9000 AGP], just a bit slow due to hardware limitations. + +<sup>31</sup> (13 Dec 2009) Turn off s3tc in driconf, runs smooth in 1280x960 on a Radeon HD 4670. OpenGL renderer string: Mesa DRI R600 (RV730 9490) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2. Turn off s3tc in driconf, runs smooth in 1920x1200 on a 4670, all s3tc textures broken (white terrain, half the units), turn off advanced unit shading to fix menu and smoke corruption, water shader works and looks awesome. (tested with GPLed Complete Annihilation.) + +<sup>32</sup> (19 November 2010) It needs S3TC to show textures properly by default but it can be disabled. + +<sup>34</sup> (22 Jan 2010) Minor clipping issues, but totally playable. + +<sup>35</sup> (19 September 2011) Graphics look great but performance isn't so good, antialiasing doesn't work, the benchmark requires --enable-texture-float to be enabled in mesa compilation. [[Video/description|http://www.youtube.com/watch?v=Z9oLZwmO0L8]]. + +<sup>37</sup> (14 Mar 2010) Slow (4 Fps), if "Material shaders" and "3D Clouds" are enabled; if eye-candy is disabled fps of ~15-20 on a RV 635 Mobility (KMS enabled) + +<sup>43</sup> (09 May 2010) Works fine in 1440x900 with detail : high; blood : on (low detail); Blur Effects : disabled; Decals : disabled. + +<sup>44</sup> (09 May 2010) Anti-Aliasing not supported. + +<sup>46</sup> (09 May 2010) With Shadow Mapping the game is too slow to be playable, though it should works as there is GL_ARB_shadow_ambient support. + +<sup>47</sup> (28 November 2010) Racer runs fine, but i couldn't change the graphics settings since it crashes everytime i click it in options, so i could not say if it is platinum material. + +<sup>48</sup> (19 May 2010) The game is too slow to be playable and scaling is not correctly supported with a 1440*900 native screen and the game in 800*600. + +<sup>49</sup> (19 September 2011) Everything works except antialiasing. [[Video/description|http://www.youtube.com/watch?v=l6cyPrSXDNc]]. + +<sup>50</sup> (26 June 2010) Lots of warnings in terminal about incomplete attachements, and some problems with the interface, but it runs + +<sup>51</sup> (30 June 2010) Motion Blur and Glow are too slow. Water Reflection leads to graphical glitches. With these three effects disabled, there is still some graphical glitches. + +<sup>55</sup> (14 October 2010) Medium shaders cause lighting to flash. High shaders seem to leave awesome fresnel shadows. + +<sup>56</sup> (18 November 2010) Works fine except texture compression and antialiasing. + +* (6 August 2011) (Evergreen, 7.12-dev) Works fine except for antialiasing. Haven't visually confirmed anisotropic filtering works. Texture compression works with libtxc_dxtn. +<sup>57</sup> (18 November 2010) Runs fine but if you turn on all details and/or up your resolution a bit it is slow/unplayable on my HD3870 GDDR4. Shouldn't happen. + +* (30 October 2011) Runs slow on HD3450 with Normal settings. +<sup>58</sup> (18 November 2010) It seems to work fine, the major problem is the lack of S3TC compression support, i suppose when this support is implemented this would be a G0LD or PLATINUM. + +<sup>61</sup> (19 November 2010) It is ok, if only a little slow. Needs S3TC by default but this can be disabled. + +<sup>62</sup> (19 November 2010) It runs really good. In its settings Antialiasing x4 is selected by default, although it doesn't work yet. Doesn't affect anything. + +<sup>63</sup> (19 November 2010) It runs fine and relatively fast. Cannot enable all quality settings, most notably antialiazing and for some reason shading language, although it should be supported. + +<sup>64</sup> (19 November 2010) It crushes because: required extension GL_ARB_map_buffer_range is not supported. This benchmark needs OpenGL 3.x support. + +<sup>65</sup> (06 December 2010) The interface to create the avatar works well, but game need unsupported texture (probably S3TC) if graphics are set too high : Works well with "Normal" setting on R700, work correctly with "Low" settings on R300 (too slow to play if set better). + +<sup>66</sup> (07 January 2011 ) Tested on Fedora 14 i686 with r300g, mesa-7.9 20101219 snapshot. Game is a little bit slow with native resolution (1280x800), but works ok with 800x600. Still have some weird artifacts on some levels, other than that game is playable. + +<sup>75</sup> (23 April 2011) Works nicely, except that it's a bit slow even at low settings. + +<sup>76</sup> (23 April 2011) Normal maps, dynamic lights and some other effects result in blackness (also on windows) + +<sup>77</sup> (23 April 2011) Line stipple of the crosshairs is not supported by Mesa, but it's no big deal + +<sup>78</sup> (23 April 2011) If it refuses to start, because libGL.so cannot be opened, try removing libgcc_s.so and libstdc++.so.5 from the game's directory + +<sup>79</sup> (7 May 2011) Some fragment programs run out of hw temporaries (results in complete blackness), but most of the test seem OK, might be HW limitation (TOO OLD?) + +<sup>80</sup> (23 April 2011) Offset mapping is full black (Too many texture indirections) (How can it be PLATINUM on r100-r200???) + +<sup>81</sup> (23 April 2011) It seems to set very low texture size limits on unknown GPUs, have to edit its config manually (set image_*Limit to 1024, image_downSize* to 0) + +<sup>82</sup> (23 April 2011) Setting UseVBO=True in ut2004.ini adds substantial performance increase on Mesa, but it misrenders the sky, the foliage and some lightmaps. It is False by default, because it is a known bug of the game. + +<sup>83</sup> (24 April 2011) None of the shaders compile (Ran out of hardware temporaries, Too many ALU instructions), with disabled shaders it runs fine, but looks horrible + +<sup>84</sup> (24 April 2011) Material shaders cannot be enabled (tons of these on stderr: r300: ERROR: FS input generic 17 unassigned, not enough hardware slots. r300: ERROR: FS input FACE unassigned.), otherwise playable + +<sup>85</sup> (27 April 2011) Make sure that r_useIndexBuffers is set to 1 in .etqwctl/base/etqwconfig.cfg, or it will crash (sometimes the game resets it to 0) + +<sup>86</sup> (5 May 2011) GLSL must be disabled or big graphics corruption you will get when your outside of station. After the game is started, vsync must be disabler or enabled to stop the flickering. + +<sup>87</sup> (5 May 2011) Lower setting recommended, Highest setting work with shadow/hdr off but it become slower and slower after time pass. With everything in minimum, the fps stay constant over time. + +<sup>89</sup> (28 Feb 2013) It runs very slow. After Level loads you see onyl hud and black screen. No level is loaded. + +<sup>90</sup> (19 September 2011) The game freezes when loading some missions (e.g. 2nd mission), The game freezes when shooting enemies. Graphically looks ok It runs with about 20 fps. May require s3tc and texture-float to work. Tested with wine 1.3.28. [[Video/description|http://www.youtube.com/watch?v=XZ_T_xepfW8]]. + +<sup>91</sup> (6 August 2011) Some shadow glitches (foliage shadows flickers square) and decal flickers. As usual, no antialiasing, not sure about anisotropic filtering (doesn't look like it). + +<sup>92</sup> (6 August 2011) Tried only medium and high detail; if it crashes with 'Got signal 11 at (nil) from (nil)', remove all files from the lib directory and add back only the ones it misses + +<sup>93</sup> (6 August 2011) It's playable, missing dynamic shadows. + +<sup>95</sup> (2 December 2011) tesselation is not yet supported by Mesa + +<sup>96</sup> (2 December 2011) some rendering errors, see [[https://bugs.freedesktop.org/show_bug.cgi?id=43520|https://bugs.freedesktop.org/show_bug.cgi?id=43520]] + +<sup>97</sup> The game does not have any artifacts, but it is significantly slower than under then the old geforce cards. + +<sup>98</sup> (17 February 2012) The game needs S3TC to run. It can be playable perfectly on "safe mode". with mesa 8.1 dev it can be playable on fixed as per bug resolution[[https://bugs.freedesktop.org/show_bug.cgi?id=44701|https://bugs.freedesktop.org/show_bug.cgi?id=44701]]. Developers are working in order to improve the shader compatibility. [[https://bugs.freedesktop.org/show_bug.cgi?id=41152|https://bugs.freedesktop.org/show_bug.cgi?id=41152]] + +<sup>99</sup> (01 July 2012) Version 1.11, needs S3TC, anti aliasing needs to be disabled in the launcher or it shows disorted coloured boxes rather than the game and menu, works on low (<20 fps), mid (<15 fps) and high (<10 fps) settings 1920x1080 full screen on AMD6970M + +<sup>100</sup> (09 October 2012) Refuses to start when MSAA enabled in game. + +<sup>101</sup> (09 October 2012) Cannot set shader effect quality to highest settings or you will get graphical glitches in the water, cannot run MSAA. + +<sup>102</sup> (28 Feb 2013) Crash because missing GLX functions -> Your OpenGL drivers lack S3TC support + +<sup>103</sup> (28 Feb 2013) AA not supported so the fonts look ugly + +<sup>104</sup> (28 Feb 2013) AA not supported also no Antostrophic filtering. + +<sup>105</sup> (28 Feb 2013) Got signal 11 at (nil) from 0xf5ffddfb. Also some lookup error in /usr/lib/libXrandr.so.2: undefined symbol: _XGetRequest + +<sup>106</sup> (28 Feb 2013) ERROR: Missing required OpenGL extensions:GL_ARB_vertex_buffer_object GL_EXT_framebuffer_blit GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_fragment_shader GL_ARB_shading_language_100 + +<sup>107</sup> (1 Mar 2013) No textures are drawn on the objects in-game. It's all white, cursor and menu not properly drawn. Many glitches. + +<sup>108</sup> (1 Mar 2013) openGl 2.0 not available but my card is able to do it...... Game does not start. diff --git a/RadeonTVbuildHowto.mdwn b/RadeonTVbuildHowto.mdwn new file mode 100644 index 00000000..f405507f --- /dev/null +++ b/RadeonTVbuildHowto.mdwn @@ -0,0 +1,20 @@ + +According to a [[post by Alex Deucher|http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2007-August/039867.html]], the canonical way to build the ATI driver with TV Out support that he maintains is: + +1. First make sure you back up the existing radeon (**radeon_drv.so**) and ati (**ati_drv.so**) drivers. +1. install the **xorg-dev**, **mesa-dev**, **libdrm-dev** and **xserver-dev** packages for your distro. The usual build tools are needed too (**autoconf**, **automake**, **libtool**, **gcc** and others) +1. **git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati** +1. **cd xf86-video-ati** +1. **./autogen.sh --prefix=/usr** +1. **make** +1. **sudo make install** or **make install** as root +If you get this error after running **autogen.sh**, you forgot to install **libtool**: + + +[[!format txt """ +configure.ac:38: error: possibly undefined macro: AC_DISABLE_STATIC + If this token and others are legitimate, please use m4_pattern_allow. + See the Autoconf documentation. +configure.ac:39: error: possibly undefined macro: AC_PROG_LIBTOOL +autoreconf: /usr/bin/autoconf failed with exit status: 1 +"""]]
\ No newline at end of file diff --git a/RandomPage.mdwn b/RandomPage.mdwn new file mode 100644 index 00000000..ff80db49 --- /dev/null +++ b/RandomPage.mdwn @@ -0,0 +1,2 @@ + +A list of 25 random pages (out of [[!pagecount ]] total): diff --git a/RelatedProjects.mdwn b/RelatedProjects.mdwn new file mode 100644 index 00000000..0b9522c4 --- /dev/null +++ b/RelatedProjects.mdwn @@ -0,0 +1,16 @@ + +The X.Org project exists as part of a family of related projects that contribute to the development of the X Window System. + +* [[freedesktop.org|http://www.freedesktop.org]] +* [[DRI Wiki|http://dri.freedesktop.org/wiki/]] useful information about using Direct Rendering with Xorg +* [[Cairo|http://cairographics.org/]] +* [[The XFree86 Project, Inc.|http://www.xfree86.org]] +* [[Gnome|http://www.gnome.org/]] +* [[The K Desktop Environment|http://www.kde.org/]] +* [[Enlightenment|http://enlightenment.org/]] +* [[Linux Terminal Server Project|http://www.ltsp.org/]] +* [[Cygwin/X|http://x.cygwin.com/]] +* [[Compiz|http://compiz.org/]] +* [[Croquet Project|http://www.opencroquet.org]] +* [[Project Looking Glass|https://lg3d-core.dev.java.net/]] +* [[The freedesktop.org info page|http://www.freedesktop.org/wiki/Info]] has links to many worthwhile projects.
\ No newline at end of file diff --git a/ReleaseWorkingGroup.mdwn b/ReleaseWorkingGroup.mdwn new file mode 100644 index 00000000..a6250f54 --- /dev/null +++ b/ReleaseWorkingGroup.mdwn @@ -0,0 +1,44 @@ + + +## History and Motivation + +Starting with Xorg 6.7, we used a fairly heavyweight release process, in which the entire source tree was frozen for stabilisation during a one to three month process. This led to excessively long release cycles, and frustrated developers who had to wait until the cycle was complete before commiting new code. With the move to modular X, the release process has become more decentralized and asynchronous. Maintainers for individual modules are able to release their subsystems as needed, rather than waiting up to a year or more for a monolithic release. + +There is still value in providing accumulated releases on a periodic basis. Much like releases in the Gnome project, these releases indicate that the indicated versions of each module have been tested and are known to work well together. Release management in the modular world is therefore mostly a matter of reviewing the various modules and selecting the appropriate branch to badge as released. + + +## Status + +Adam Jackson is currently lead RM, but ideally this will become merely a ceremonial title. + +7.1 has been released. This seems to have gone reasonably well for a first effort, but there have been some notable issues. + +* The katamari process was almost entirely manual. This needs to be made point-and-shoot. Some inconsistencies in the archive were found afterwards, which is a bit embarassing. ajax is working on scripting this process and placing the scripts and data in CVS so it's all public and easy-access. +* Still poor communication regarding how releases are to be composed by downstream. How do you know which modules to include? How do you know what modules have been deprecated? etc. + +## Schedule and work in progress + +See the [[proposed schedule|http://lists.freedesktop.org/archives/xorg/2006-May/015476.html]]. + + +## Future issues + +Current open questions regarding the release management process. + + +### Release-wrangler calls + +We did this in 6.x, and tried it during the start of the 6.9/7.0 effort, but it was impossible to schedule and the calls burned a lot of time. If 7.1 is anything to go by, they don't seem to be needed. + +There is some issue of process transparency during the RC cycle; again, automation should help with this next time around. + + +### Is the six month cycle too aggressive, or not aggressive enough + +No one's complained yet, so the working assumption is that it's Just Right. + + +### Where in the world is Carmen Sandiego + + +### What defines X11R8 diff --git a/Releases.mdwn b/Releases.mdwn new file mode 100644 index 00000000..8124df57 --- /dev/null +++ b/Releases.mdwn @@ -0,0 +1,32 @@ + + +## Current release + +**The latest release of X.Org was [[X11R7.7|Releases/7.7]]**, on June 6, 2012. Of note, this release added multitouch input support, Fence synchronization primitives, and pointer barriers. Read more in the [[Release Notes|http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNotes.html]]. + + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.7/]]. + +## General + +* List of [[module versions in various roll-up releases|Releases/ModuleVersions]]. +* Individual releases of Xorg modules are [[here|http://www.x.org/releases/individual]]. +* [[6.8.0 post-partum|X11R68PostPartumNotes]]: lessons learned. +* For module maintainers: [[HOWTO Make a release|Development/Documentation/ReleaseHOWTO]]. + +## Old releases + +* [[X11R7.6|Releases/7.6]] (Released: 2010-12-20) [[Release Notes|http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html]]. Of note, this release added xorg.conf.d directories, Input``Class configuration sections, udev support on Linux, improved documentation, and integrated xcb. + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.6/]]. +* [[X11R7.5|Releases/7.5]] (Released: 2009-10-26) [[Release Notes|http://www.x.org/archive/X11R7.5/doc/RELNOTES.txt]]. Of note, this release added [[Multi-Pointer X (MPX)|http://wearables.unisa.edu.au/mpx/]], RandR 1.3, E-EDID support and DRI2. + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.5/]]. +* [[X11R7.4|Releases/7.4]] (Released: 2008-09-23) [[Release Notes|http://www.x.org/archive/X11R7.4/doc/RELNOTES.txt]] + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.4/]]. +* [[X11R7.3|Releases/7.3]] (Released: 2007-09-06) [[Release Notes|http://www.x.org/archive/X11R7.3/doc/RELNOTES.txt]] Of note, this release added [[RandR 1.2|Projects/XRandR]] and [[input hotplug|XInputHotplug]] support. + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.3/]]. +* [[X11R7.2|Releases/7.2]] (Released: 2007-02-15) Of note, this release added autoconfiguration support, and enhanced support for GL-based compositing managers, such as Compiz and Beryl. + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.2/]]. +* [[X11R7.1|Releases/7.1]] (Released: 2006-05-22) [[Release Notes|http://www.x.org/archive/X11R7.1/doc/RELNOTES.html]] + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.1/]]. +* [[X11R7.0|Releases/7.0]] (Released: 2005-12-21) + * Download: [[mirrors|Releases/Download]], [[master site|http://www.x.org/releases/X11R7.0/]]. +For more complete information, including a release history, please see the [[historical releases|Releases/History]] page. diff --git a/Releases/7.2.mdwn b/Releases/7.2.mdwn new file mode 100644 index 00000000..b1a35bc2 --- /dev/null +++ b/Releases/7.2.mdwn @@ -0,0 +1,21 @@ + +The X.Org Foundation released 7.2.0 (aka X11R7.2) on February 15th, 2007. + + +## Features + +* Autoconfiguration: The X server can now start without an xorg.conf file in most cases. +* GL compositing managers: A number of improvements were merged that better enable the use of GL-based compositing managers such as Compiz and Beryl. +* i965: Intel i965 chipsets (aka X3000) are supported in this release. +* [[XACE|Projects/XACE]]: The XACE security framework has been merged, allowing the development of new, extensible, security models. +* [[XCB|http://xcb.freedesktop.org]]: XCB is part of the 7.2 release, including libX11 based on XCB for its transport. +* xdm: Among other improvements, xdm now supports PAM, for better authentication. + +## Download + +You can download 7.2.0 from either a [[mirror|Releases/Mirrors]], or the [[master site|http://xorg.freedesktop.org/releases/X11R7.2/]]. + + +## Documentation + +Due to bugs in the documentation toolchain, documentation for this release is not available online at the moment. The [[press release|PressReleases/X11R72Released]] is available. diff --git a/Releases/7.3.mdwn b/Releases/7.3.mdwn new file mode 100644 index 00000000..aae8006f --- /dev/null +++ b/Releases/7.3.mdwn @@ -0,0 +1,117 @@ + +7.3 was released on 2007-09-06. + + +## Features + +* Xorg server 1.4 - see [[Server14Branch|Server14Branch]] for more details. Highlights: + * [[RandR 1.2|Projects/XRandR]]: RandR 1.2 offers output hotplug, as well as on-the-fly output reconfiguration and mode switching. + * [[Input hotplug|XInputHotplug]]: Input hotplug allows hotplugging of input devices, and also adds enhanced support for touchscreens and tablets, through either HAL or D-Bus. + * KDrive: Numerous enhancements have been made to the KDrive codebase, including better support for multiple input devices. + * [[DTrace|http://people.freedesktop.org/~alanc/dtrace/]]: When running on Open``Solaris, DTrace support is available in the X server, allowing detailed accounting of operations inside the server. + * EXA: A great deal of work has been done on the EXA framework to make it more usable. +* New applications: xbacklight +* New drivers: xf86-video-glide, xf86-video-vermilion +* New man pages for API's: libXinerama, libXcomposite, XKB functions in libX11, Xtest functions in libXtst +* Support for [[font catalogue directories|http://lists.freedesktop.org/archives/xorg/2007-June/025744.html]] in font path +* xdm: Xft support added + +## Download + +All source tarballs are available at [[http://xorg.freedesktop.org/archive/X11R7.3/src|http://xorg.freedesktop.org/archive/X11R7.3/src]] The release notes are available at [[http://xorg.freedesktop.org/archive/X11R7.3/doc/RELNOTES.txt|http://xorg.freedesktop.org/archive/X11R7.3/doc/RELNOTES.txt]] + + +## Security Fixes + +* [[CVE-2007-1003/CVE-2007-1351/CVE-2007-1352/CVE-2007-1667|http://lists.freedesktop.org/archives/xorg-announce/2007-April/000286.html]]: various integer overflow vulnerabilites in xserver, libX11 and libXfont + +## New/Updated modules + + +### app + +* [[bdftopcf 1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2007-April/000298.html]] +* [[iceauth 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000328.html]] +* [[ico 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000326.html]] +* [[mkfontdir 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000278.html]] +* [[setxkbmap 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000327.html]] +* [[sessreg 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000352.html]] +* [[xbacklight 1.1|http://lists.freedesktop.org/archives/xorg-announce/2007-June/000310.html]] +* [[xcalc 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000359.html]] +* [[xclock 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000333.html]] +* [[xconsole 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000358.html]] +* [[xcursorgen 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000356.html]] +* [[xdm 1.1.6|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000348.html]] +* [[xdriinfo 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000354.html]] +* [[xgamma 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000335.html]] +* [[xhost 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000325.html]] +* [[xinit 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000380.html]] +* [[xload 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000279.html]] +* [[xmag 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000347.html]] +* [[xman 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000344.html]] +* [[xmessage 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000339.html]] +* [[xmodmap 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000334.html]] +* [[xprop 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000342.html]] +* [[xrandr 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000322.html]] +* [[xrdb 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000345.html]] +* [[xset 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000366.html]] +* [[xsetroot 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000338.html]] +* [[xvinfo 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000349.html]] +* [[xwininfo 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000365.html]] + +### driver + + +#### input + +* [[xf86-input-acecad 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2007-April/000301.html]] +* [[xf86-input-joystick 1.2.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000350.html]] +* [[xf86-input-keyboard 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000385.html]] +* [[xf86-input-mouse 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000331.html]] +* [[xf86-input-vmmouse 12.4.1|http://lists.freedesktop.org/archives/xorg-announce/2007-February/000258.html]] + +#### video + +* [[xf86-video-glide 1.0.0|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000266.html]] +* [[xf86-video-intel 2.1.1|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000343.html]] +* [[xf86-video-nsc 2.8.3|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000376.html]] +* [[xf86-video-nv 2.1.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000346.html]] +* [[xf86-video-savage 2.1.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000351.html]] +* [[xf86-video-vermilion 1.0.0|http://lists.freedesktop.org/archives/xorg-announce/2007-April/000288.html]] + +### doc + +* [[xorg-docs 1.4|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000260.html]] +* [[xorg-sgml-doctools 1.2|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000261.html]] + +### lib + +* [[libICE 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000355.html]] +* [[libSM 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-May/000304.html]] +* [[libX11 1.1.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000332.html]] +* [[libXaw 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000360.html]] +* [[libXcomposite 0.4.0|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000320.html]] +* [[libXcursor 1.1.9|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000364.html]] +* [[libXdamage 1.1|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000237.html]] +* [[libXfont 1.3.1|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000383.html]] +* [[libXi 1.1.3|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000384.html]] +* [[libXinerama 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000268.html]] +* [[libXpm 3.5.7|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000362.html]] +* [[libXrandr 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000379.html]] +* [[libXrender 0.9.4|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000386.html]] +* [[libXtst 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000353.html]] +* [[libXxf86dga 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000382.html]] +* [[xtrans 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000361.html]] + +### proto + +* [[compositeproto 0.4|http://lists.freedesktop.org/archives/xorg-announce/2007-July/000319.html]] +* [[damageproto 1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000238.html]] +* [[inputproto 1.4.2.1|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000371.html]] +* [[randrproto 1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2007-February/000255.html]] +* [[renderproto 0.9.3|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000372.html]] +* [[xf86dgaproto 2.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000381.html]] + +### util + +* [[makedepend 1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2007-March/000277.html]]
\ No newline at end of file diff --git a/Releases/7.4.mdwn b/Releases/7.4.mdwn new file mode 100644 index 00000000..68ef2b44 --- /dev/null +++ b/Releases/7.4.mdwn @@ -0,0 +1,152 @@ + +7.4 was released on September 23, 2008 + + +## Features + +* [[PciReworkProposal|PciReworkProposal]]: PCI bus scanning/accessing code replaced with libpciaccess ([[IanRomanick|IanRomanick]]). +* MacOS X updates: Xquartz fixes, launchd support, and more ([[BenByer|BenByer]] and [[JeremyHuddleston|JeremyHuddleston]]) +* x11perf 1.5: Compositing tests added. +* xtrans 1.1: Support for abstract socket namespace under Linux. +* xf86-input-evdev 2.0.x: Many stability and completeness fixes, should work out of the box with a large range of devices, plus middle-button emulation for mice. +* xf86-video-ati 6.9.x: Support for r5xx/r6xx/r7xx (RadeonHD 1xxx/2xxx/3xxx) devices added, including textured video for r5xx. Full RandR 1.2 support for all chipsets. +* EXA: Numerous speedups (inc. font rendering), cleanups, and correctness fixes. +* libX11 1.1.5: Numerous i18n additions and fixes ([[JamesCloos|JamesCloos]]). +* xorg-server 1.5: Faster startup and shutdown, lots of code removal, EDID 1.4, Secure RPC authentication, GLX and DRI passthrough support for Xephyr, smarter autoconfiguration, pervasive and coherent XACE security framework, easier building of GL code, numerous input-related bugfixes. + +## Modules included + +[[Module List|http://cgit.freedesktop.org/xorg/util/modular/tree/module-list.txt?id=XORG-7_4]] + + +## New/updated modules + +_These are just listed for easy reference here, the above link is the canonical list, and this list contains some modules that are no longer included in the full X.Org releases. Only the release announcement for the version to be included in [[X11R7|X11R7]].4 is listed here. Some modules had multiple releases since [[X11R7|X11R7]].3 - see each module's [[ChangeLog|ChangeLog]] for a full list of changes. _ + + +### app + +* [[bitmap 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000243.html]] +* [[luit 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-January/000446.html]] +* [[mkfontdir 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000466.html]] +* [[mkfontscale 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000542.html]] +* [[sessreg 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000580.html]] +* [[x11perf 1.5|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000477.html]] +* [[xauth 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000468.html]] +* [[xdpyinfo 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000548.html]] +* [[xev 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000479.html]] +* [[xinput 1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2008-January/000438.html]] +* [[xkbcomp 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000539.html]] +* [[xpr 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000248.html]] +* [[xprop 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000480.html]] +* [[xrandr 1.2.3|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000475.html]] +* [[xrdb 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000473.html]] +* [[xset 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000474.html]] +* [[xwd 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000597.html]] +* [[xwininfo 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000598.html]] + +### driver + + +#### input + +* [[xf86-input-acecad 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2008-February/000448.html]] +* [[xf86-input-aiptek 1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2008-April/000533.html]] +* [[xf86-input-evdev 2.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000630.html]] +* [[xf86-input-joystick 1.3.2|http://lists.freedesktop.org/archives/xorg-announce/2008-April/000536.html]] +* [[xf86-input-keyboard 1.3.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000554.html]] +* [[xf86-input-mouse 1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000519.html]] +* [[xf86-input-synaptics 0.15.0|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000629.html]] +* [[xf86-input-vmmouse 12.5.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000561.html]] +* [[xf86-input-void 1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2007-September/000391.html]] + +#### video + +* [[xf86-video-apm 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000484.html]] +* [[xf86-video-ark 0.7.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000485.html]] +* [[xf86-video-ast 0.85.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000486.html]] +* [[xf86-video-ati 6.9.0|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000596.html]] +* [[xf86-video-chips 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000487.html]] +* [[xf86-video-cirrus 1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000555.html]] +* [[xf86-video-dummy 0.3.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000507.html]] +* [[xf86-video-fbdev 0.4.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000489.html]] +* [[xf86-video-geode 2.10.1|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000632.html]] ([[renamed from xf86-video-amd|http://lists.freedesktop.org/archives/xorg-announce/2008-April/000530.html]]) +* [[xf86-video-glide 1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000590.html]] +* [[xf86-video-glint 1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000600.html]] +* [[xf86-video-i128 1.3.1|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000642.html]] +* [[xf86-video-i740 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000492.html]] +* [[xf86-video-impact 0.2.0|http://lists.freedesktop.org/archives/xorg-announce/2006-June/000104.html]] +* [[xf86-video-intel 2.4.2|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000645.html]] +* [[xf86-video-mach64 6.8.0|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000582.html]] +* [[xf86-video-mga 1.4.9|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000607.html]] +* [[xf86-video-neomagic 1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000556.html]] +* [[xf86-video-nv 2.1.12|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000636.html]] +* xf86-video-openchrome 0.2.903 (announce mail missing! cf [[NEWS file|http://www.openchrome.org/trac/browser/trunk/NEWS]]) +* [[xf86-video-r128 6.8.0|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000581.html]] +* [[xf86-video-rendition 4.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000494.html]] +* [[xf86-video-s3 0.6.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000495.html]] +* [[xf86-video-s3virge 1.10.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000557.html]] +* [[xf86-video-savage 2.2.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000558.html]] +* [[xf86-video-siliconmotion 1.6.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000498.html]] +* [[xf86-video-sis 0.10.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000499.html]] +* [[xf86-video-sisusb 0.9.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000500.html]] +* [[xf86-video-sunffb 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000637.html]] +* [[xf86-video-sunleo 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000638.html]] +* [[xf86-video-tdfx 1.4.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000501.html]] +* [[xf86-video-tga 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000639.html]] +* [[xf86-video-trident 1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000502.html]] +* [[xf86-video-tseng 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000503.html]] +* [[xf86-video-v4l 0.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000504.html]] +* [[xf86-video-vermilion 1.0.1|http://lists.freedesktop.org/archives/xorg/2007-April/023162.html]] +* [[xf86-video-vesa 2.0.0|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000605.html]] +* [[xf86-video-vmware 10.16.5|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000648.html]] +* [[xf86-video-voodoo 1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000506.html]] +* [[xf86-video-wsfb 0.2.1|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000234.html]] +* [[xf86-video-xgi 1.5.0|http://lists.freedesktop.org/archives/xorg-announce/2007-August/000368.html]] +* [[xf86-video-xgixp 1.7.99.3|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000538.html]] + +### doc + + +### font + +* [[font-xfree86-type1 1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000460.html]] + +### lib + +* [[libFS 1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000559.html]] +* [[libSM 1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000606.html]] +* [[libX11 1.1.5|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000646.html]] +* [[libXScrnSaver 1.1.3|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000481.html]] +* [[libXau 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-August/000634.html]] +* [[libXdamage 1.1.1|http://lists.freedesktop.org/archives/xorg/2007-March/022420.html]] +* [[libXext 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-February/000452.html]] +* [[libXfont 1.3.3|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000610.html]] +* [[libXft 2.1.13|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000613.html]] +* [[libXinerama 1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000463.html]] +* [[libXmu 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-January/000440.html]] +* [[libXrandr 1.2.3|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000609.html]] +* [[libXt 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2007-January/000247.html]] +* [[libXv 1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000483.html]] +* [[libXxf86vm 1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000612.html]] +* [[libpciaccess 0.10.3|http://lists.freedesktop.org/archives/xorg-announce/2008-June/000574.html]] +* [[libxkbfile 1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000482.html]] +* [[pixman 0.10.0|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000529.html]] +* [[xtrans 1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000608.html]] + +### proto + +* [[glproto 1.4.9|http://lists.freedesktop.org/archives/xorg-announce/2007-October/000424.html]] +* [[inputproto 1.4.4|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000622.html]] +* [[randrproto 1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2008-July/000611.html]] +* [[xextproto 7.0.3|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000568.html]] +* xf86driproto 2.0.4 (no announce mail!) +* [[xproto 7.0.13|http://lists.freedesktop.org/archives/xorg-announce/2008-May/000567.html]] + +### xserver + +* [[xorg-server 1.5.1|http://lists.freedesktop.org/archives/xorg-announce/2008-September/000656.html]] + +### util + +* [[util-macros 1.1.6|http://lists.freedesktop.org/archives/xorg-announce/2008-March/000453.html]]
\ No newline at end of file diff --git a/Releases/7.4/package.zip b/Releases/7.4/package.zip Binary files differnew file mode 100644 index 00000000..45e3a75f --- /dev/null +++ b/Releases/7.4/package.zip diff --git a/Releases/7.5.mdwn b/Releases/7.5.mdwn new file mode 100644 index 00000000..15381c34 --- /dev/null +++ b/Releases/7.5.mdwn @@ -0,0 +1,228 @@ + +[[X11R7.5 was released on October 26, 2009|Other/Press/X11R75Released]]. + +Release notes, changelogs, downloads, etc. are available at [[http://www.x.org/releases/X11R7.5/|http://www.x.org/releases/X11R7.5/]] + + +## Features Added/Enhanced + +* [[Xserver build no longer needs to symlink to Mesa sources|http://lists.freedesktop.org/archives/xorg/2008-May/035274.html]] +* [[MPX: Multi-Pointer X|http://wearables.unisa.edu.au/mpx/]] ([[PeterHutterer|PeterHutterer]]) +* E-EDID support ([[AdamJackson|AdamJackson]]) +* [[Input device properties|http://who-t.blogspot.com/2008/07/input-device-properties.html]] ([[PeterHutterer|PeterHutterer]]) +* [[predictable pointer acceleration|Development/Documentation/PointerAcceleration]] ([[SimonThum|SimonThum]]) +* xorg-server [[1.7.0|Server17Branch]] +* Add SELinux security module which uses XACE ([[EamonWalsh|EamonWalsh]]). +* RandR 1.3 ([[KeithPackard|KeithPackard]]) + +## Features Removed + +* X server libraries: [[cfb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0dab6fa3582b70ccd0f01459902415c28dbc81ff]], [[afb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=20ea99c655140e101f2d20cfab78fb22765fec62]], [[mfb/xf1bpp|http://cgit.freedesktop.org/xorg/xserver/commit/?id=eabcfce0a68d504d11be9479f09e66f574dd2f21]] +* X server support for obsolete/unused/broken/unmaintained extensions: [[AppGroup|http://cgit.freedesktop.org/xorg/xserver/commit/?id=eafaf40fb3368ca7e4cf48336fdb7a6c9f536bfa]], [[EVI|http://cgit.freedesktop.org/xorg/xserver/commit/?id=13adef8a17d8815f4db2aaac30ae04438e125343]], [[MIT-SUNDRY-NONSTANDARD|http://cgit.freedesktop.org/xorg/xserver/commit/?id=25827fde68d3bb02a2b7e05fae53a1d97edf1f76]], [[TOG-CUP|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a7503615a6893749d512f75d37646273f31b9dbf]], [[XTrap|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cbc20d92de92aad5ca240310a9156ccf97c24a01]], [[XFree86-Misc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=22e64108ec63ba77779891f8df237913ef9ca731]], [[XEvIE|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a]] +* X server command line flags: [[-co|http://cgit.freedesktop.org/xorg/xserver/commit/?id=41b68e0dea9305d66bca2fc4ad96db01f5342c6d]], [[-bestrefresh|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1f416fba994ed7a7e072a9f0a86b515855ea3bac]], [[-showunresolved|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5a72c45d42abc7227c6cf3d14fd7043ea7527c54]] +* X server bundled utilties: [[xorgconfig|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d34430414ac0e77eec61ab0ac9ef427b236eb639]], [[xorgcfg|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5c1e254cc85e9ad409b0217780545c29f62d5feb]], [[ioport|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b74927c3844bc2650d95f604fe782d95ade067f1]], [[kbd_mode|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8c0518379089d230060e9ff672ba5eba34198325]] +* Unmaintained X server variants: [[Xgl|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d15b3790307053587df8daed1936ff6923881b63]], [[Xprt|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c8bd318fbaf65890ef16fe26c76dd5e6f14dfde]] (moved to [[separate xprint git repo|http://cgit.freedesktop.org/xorg/xprint/]]) + +## Modules included + +[[Module List|http://cgit.freedesktop.org/xorg/util/modular/tree/module-list.txt?id=XORG-7_5]] + + +## New/updated modules + +_These are just listed for easy reference here, the above link is the canonical list. Only the release announcement for the version included in X11``R7.5 is listed here. Some modules had multiple releases since X11``R7.4 - see each module's [[ChangeLog|ChangeLog]] or git repository for a full list of changes. _ + + +## New/Updated Modules + + +### xserver + + * [[xorg-server-1.7.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001183.html]] + +### app + + * [[bdftopcf-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001046.html]] + * [[iceauth-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001132.html]] + * [[luit-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001080.html]] + * [[mkfontdir-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001135.html]] + * [[mkfontscale-1.0.7|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001134.html]] + * [[sessreg-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001139.html]] + * [[setxkbmap-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000896.html]] + * [[smproxy-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001160.html]] + * [[x11perf-1.5.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001161.html]] + * [[xauth-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001047.html]] + * [[xbacklight-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001064.html]] + * [[xcmsdb-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001156.html]] + * [[xcursorgen-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001162.html]] + * [[xdpyinfo-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001158.html]] + * [[xdriinfo-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001159.html]] + * [[xev-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001143.html]] + * [[xgamma-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001151.html]] + * [[xhost-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001152.html]] + * [[xinput-1.5.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001148.html]] + * [[xkbcomp-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001095.html]] + * [[xkbevd-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001163.html]] + * [[xkbutils-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001164.html]] + * [[xkill-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001144.html]] + * [[xlsatoms-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001145.html]] + * [[xlsclients-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001165.html]] + * [[xmodmap-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001100.html]] + * [[xpr-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001170.html]] + * [[xprop-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001140.html]] + * [[xrandr-1.3.2|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001027.html]] + * [[xrdb-1.0.6|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001141.html]] + * [[xrefresh-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001166.html]] + * [[xset-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001043.html]] + * [[xsetroot-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001167.html]] + * [[xvinfo-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001168.html]] + * [[xwd-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001169.html]] + * [[xwininfo-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001142.html]] + * [[xwud-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001146.html]] + +### data + + * [[xbitmaps-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001147.html]] + * [[xcursor-themes-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001063.html]] + +### doc + + * [[xorg-docs-1.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001185.html]] + * [[xorg-sgml-doctools-1.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001182.html]] + +### driver + + +#### input + + * [[xf86-input-acecad-1.4.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001029.html]] + * [[xf86-input-aiptek-1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001030.html]] + * [[xf86-input-evdev-2.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001176.html]] + * xf86-input-joystick-1.4.99.2 + * [[xf86-input-keyboard-1.4.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001109.html]] + * [[xf86-input-mouse-1.5.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001104.html]] + * [[xf86-input-synaptics-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001116.html]] + * [[xf86-input-vmmouse-12.6.5|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000956.html]] + * [[xf86-input-void-1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001028.html]] + +#### video + + * [[xf86-video-apm-1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000923.html]] + * [[xf86-video-ark-0.7.2|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001014.html]] + * [[xf86-video-ast-0.89.9|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000924.html]] + * [[xf86-video-ati-6.12.4|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001033.html]] (see also [[radeon|radeon]]) + * [[xf86-video-chips-1.2.2|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000962.html]] + * [[xf86-video-cirrus-1.3.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000925.html]] + * [[xf86-video-dummy-0.3.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000872.html]] + * [[xf86-video-fbdev-0.4.1|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000926.html]] + * [[xf86-video-geode-2.11.6|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001066.html]] + * [[xf86-video-glide-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000987.html]] + * [[xf86-video-glint-1.2.4|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000927.html]] + * [[xf86-video-i128-1.3.3|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000928.html]] + * [[xf86-video-i740-1.3.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000929.html]] + * [[xf86-video-intel-2.9.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001186.html]] + * [[xf86-video-mach64-6.8.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000930.html]] + * [[xf86-video-mga-1.4.11|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000931.html]] + * [[xf86-video-neomagic-1.2.4|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000932.html]] + * [[xf86-video-newport-0.2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001017.html]] + * [[xf86-video-nv-2.1.15|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001031.html]] + * [[xf86-video-r128-6.8.1|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000933.html]] + * [[xf86-video-rendition-4.2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001013.html]] + * [[xf86-video-s3-0.6.3|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000936.html]] + * [[xf86-video-s3virge-1.10.4|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000934.html]] + * [[xf86-video-savage-2.3.1|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000935.html]] + * [[xf86-video-siliconmotion-1.7.3|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000952.html]] + * [[xf86-video-sis-0.10.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000939.html]] + * [[xf86-video-sisusb-0.9.3|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000938.html]] + * [[xf86-video-suncg14-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-May/000836.html]] + * [[xf86-video-suncg3-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-May/000837.html]] + * [[xf86-video-suncg6-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-May/000838.html]] + * [[xf86-video-sunffb-1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001018.html]] + * [[xf86-video-suntcx-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-May/000839.html]] + * [[xf86-video-tdfx-1.4.3|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000937.html]] + * [[xf86-video-tga-1.2.1|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001015.html]] + * [[xf86-video-trident-1.3.3|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000951.html]] + * [[xf86-video-tseng-1.2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001016.html]] + * [[xf86-video-vesa-2.2.1|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000940.html]] + * [[xf86-video-vmware-10.16.8|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001022.html]] + * [[xf86-video-voodoo-1.2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000941.html]] + * [[xf86-video-wsfb-0.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001034.html]] + * [[xf86-video-xgi-1.5.1|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001012.html]] + * [[xf86-video-xgixp-1.7.99.4|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001019.html]] + +### font + + * [[font-util-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001138.html]] + * [[All font modules|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001131.html]] + +### lib + + * [[libAppleWM-1.4.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000988.html]] + * [[libFS-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000893.html]] + * [[libICE-1.0.6|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000995.html]] + * [[libSM-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000958.html]] + * [[libWindowsWM-1.0.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001112.html]] + * [[libX11-1.3.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001184.html]] + * [[libXScrnSaver-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000972.html]] + * [[libXau-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000996.html]] + * [[libXaw-1.0.7|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001172.html]] + * [[libXcomposite-0.4.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001113.html]] + * [[libXcursor-1.1.10|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000997.html]] + * [[libXdamage-1.1.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001105.html]] + * [[libXdmcp-1.0.3|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001057.html]] + * [[libXext-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001181.html]] + * [[libXfixes-4.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001114.html]] + * [[libXfont-1.4.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001129.html]] + * [[libXft-2.1.14|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001127.html]] + * [[libXi-1.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001082.html]] + * [[libXinerama-1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001085.html]] + * [[libXmu-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001060.html]] + * [[libXpm-3.5.8|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001122.html]] + * [[libXrandr-1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-March/000800.html]] + * [[libXrender-0.9.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001086.html]] + * [[libXres-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001121.html]] + * [[libXt-1.0.7|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001126.html]] + * [[libXtst-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001097.html]] + * [[libXv-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001094.html]] + * [[libXvMC-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001107.html]] + * [[libXxf86dga-1.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001103.html]] + * [[libXxf86vm-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001099.html]] + * [[libdmx-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001098.html]] + * [[libfontenc-1.0.5|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000994.html]] + * [[libpciaccess-0.10.9|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001065.html]] + * [[libxkbfile-1.0.6|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001108.html]] + * [[xtrans-1.2.5|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001171.html]] + +### proto + + * [[applewmproto-1.4.1|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000982.html]] + * [[bigreqsproto-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000975.html]] + * [[compositeproto-0.4.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001089.html]] + * [[damageproto-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000984.html]] + * [[dmxproto-2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001073.html]] + * [[dri2proto-2.1|http://lists.freedesktop.org/archives/xorg-announce/2009-June/000861.html]] + * [[fixesproto-4.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001101.html]] + * [[fontsproto-2.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000986.html]] + * [[glproto-1.4.10|http://lists.freedesktop.org/archives/xorg-announce/2009-May/000853.html]] + * [[inputproto-2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001081.html]] + * [[kbproto-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001149.html]] + * [[randrproto-1.3.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001102.html]] + * [[recordproto-1.14|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001076.html]] + * [[renderproto-0.11|http://lists.freedesktop.org/archives/xorg-announce/2009-July/000904.html]] + * [[resourceproto-1.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000970.html]] + * [[scrnsaverproto-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000971.html]] + * [[videoproto-2.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000983.html]] + * [[windowswmproto-1.0.4|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001092.html]] + * [[xcmiscproto-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000977.html]] + * [[xextproto-7.1.1|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000969.html]] + * [[xf86bigfontproto-1.2.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000978.html]] + * [[xf86dgaproto-2.1|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001074.html]] + * [[xf86driproto-2.1.0|http://lists.freedesktop.org/archives/xorg-announce/2009-August/000979.html]] + * [[xf86vidmodeproto-2.3|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001075.html]] + * [[xineramaproto-1.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001077.html]] + * [[xproto-7.0.16|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001058.html]] + +### util + + * [[makedepend-1.0.2|http://lists.freedesktop.org/archives/xorg-announce/2009-October/001133.html]] + * [[util-macros-1.3.0|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001024.html]]
\ No newline at end of file diff --git a/Releases/7.6.mdwn b/Releases/7.6.mdwn new file mode 100644 index 00000000..52511f2f --- /dev/null +++ b/Releases/7.6.mdwn @@ -0,0 +1,23 @@ + +[[X11R7.6|http://www.x.org/releases/X11R7.6/]] development is complete: [[the final release|http://www.x.org/releases/X11R7.6/]] has been posted. (See [[the announcement|Other/Press/X11R76Released]] for further details.) + + +## Features Added/Enhanced + +* [[XCB|http://xcb.freedesktop.org/]] included in the katamari, required by libX11 1.4 and some clients. +* [[Xorg server 1.8 changes|Server18Branch]], including [[new input hotplugging and configuration framework|http://who-t.blogspot.com/2010/01/new-configuration-world-order.html]] +* [[Xorg server 1.9 changes|Server19Branch]] +* [[Documentation|Development/Documentation/WritingDocumentation]]: Most protocol & API docs moved from xorg-docs into individual proto/library modules, converted from legacy formats to DocBook/XML where possible. +* Massive amounts of configure.ac/Makefile.am cleanup & improvement. Lots of previously duplicated bits moved to xorg-macros (requiring recent xorg-macros versions when we build the tarballs, but unless you autoreconf that shouldn't affect people building from tarballs). +* Most of the COPYING file stubs have been replaced with actual copies of the copyright & license notices for easier packaging by distributors who provide such notices in their packages. + +## Features Removed + +* [[Xsdl|http://cgit.freedesktop.org/xorg/xserver/commit/?id=52bc6d944946e66ea2cc685feaeea40bb496ea83]] - experimental kdrive server using SDL that was never finished +* [[Frame buffer support in XF86DGA|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b7c6c728c2e2d8433a188315cc591308a89cd85]] +* [[Multibuffer extension in X servers|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0ba82562eeba8bf3bcd00b6e3ff28ce5b2c8df3c]] - deprecated since the 90's + +## Schedule + +* RC1: 11 November 2010 +* Final Release: 20 December 2010
\ No newline at end of file diff --git a/Releases/7.7.mdwn b/Releases/7.7.mdwn new file mode 100644 index 00000000..6e18b846 --- /dev/null +++ b/Releases/7.7.mdwn @@ -0,0 +1,18 @@ + +X11``R7.7 development is development is complete: the final release has been posted at [[http://www.x.org/releases/X11R7.7/|http://www.x.org/releases/X11R7.7/]] + + +## Features Added/Enhanced + +See also: [[Summary of new features in X11R7.7|http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNotes.html#Summary_of_new_features_in_X11R7.7]], [[Combined ChangeLog for all X11R7.7 components (1.5 Mb)|http://www.x.org/releases/X11R7.7/changelog.html]] + +* [[Xorg server 1.10 changes|Server110Branch]], [[Xorg server 1.11 changes|Server11Branch]], [[Xorg server 1.12 changes|Server112Branch]] +* [[Documentation|Development/Documentation/WritingDocumentation]]: Finish conversions to DocBook/XML, improve integration across doc sets. +* Sync extension 3.1 - adds Fence object support +* Xi 2.2 multitouch support +* XFixes 5.0: Pointer Barriers + +## Schedule + +* RC 1: April 15, 2012 +* Final Release: June 6, 2012
\ No newline at end of file diff --git a/Releases/7.8.mdwn b/Releases/7.8.mdwn new file mode 100644 index 00000000..be1a5464 --- /dev/null +++ b/Releases/7.8.mdwn @@ -0,0 +1,30 @@ + +X11``R7.8 development is underway for release possibly in 2013. + + +## Features Added/Enhanced + +* X Resource extension 1.2 + +## Features Removed + +* TBD + +## TODO + +These have been discussed, but are not yet integrated to the source repos, and may or may not make the release: + +* XWayland integration +* RandR extension 1.4 +* Video driver hotplugging +* Add xf86-video-nested, xf86-video-modesetting to the katamari driver set +* Replace Xephyr, Xvfb, Xnest, Xfake, etc. with Xorg using xf86-video-dummy and xf86-video-nested +* [[Documentation|Development/Documentation/WritingDocumentation]]: Further integration across doc sets. Docs from Book Sprint. +* Referee [[DoubleBuffer|DoubleBuffer]] vs. libfb/Composite +* Add Solaris Trusted Extensions security module which uses XACE ([[AlanCoopersmith|AlanCoopersmith]]). +There are also a number of items on the [[ToDo|ToDo]] list waiting for someone to pick up the work, but those are less likely to make the release without anyone actively working on them. + + +## Schedule + +* TBD
\ No newline at end of file diff --git a/Releases/Development.mdwn b/Releases/Development.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Releases/Development.mdwn diff --git a/Releases/Download.mdwn b/Releases/Download.mdwn new file mode 100644 index 00000000..120821bb --- /dev/null +++ b/Releases/Download.mdwn @@ -0,0 +1,87 @@ + +All releases of X.Org since 7.0 can be downloaded from one of the primary download sites, or from a mirror close to you. Development releases are usually only available on the primary sites. + + +## Primary sites + +* freedesktop.org, Oregon, USA: [[HTTP|http://xorg.freedesktop.org/releases/]] and [[FTP|ftp://ftp.freedesktop.org/pub/xorg]]. +* x.org, Massachusetts, USA: [[HTTP|http://www.x.org/pub/]] and [[FTP|ftp://ftp.x.org/pub]]. + +## Mirrors + + +### North America + +* [[ftp://mirror.csclub.uwaterloo.ca/x.org/|ftp://mirror.csclub.uwaterloo.ca/x.org/]] +* [[ftp://xorg.mirrors.pair.com/|ftp://xorg.mirrors.pair.com/]] +* [[http://mirror.csclub.uwaterloo.ca/x.org/|http://mirror.csclub.uwaterloo.ca/x.org/]] +* [[http://xorg.mirrors.pair.com/|http://xorg.mirrors.pair.com/]] +* [[http://mirror.us.leaseweb.net/xorg/|http://mirror.us.leaseweb.net/xorg/]] + +### Europe + +* [[ftp://artfiles.org/x.org/|ftp://artfiles.org/x.org/]] +* [[ftp://ftp.chg.ru/pub/X11/x.org/|ftp://ftp.chg.ru/pub/X11/x.org/]] +* [[ftp://ftp.fu-berlin.de/unix/X11/FTP.X.ORG/|ftp://ftp.fu-berlin.de/unix/X11/FTP.X.ORG/]] +* [[ftp://ftp.gwdg.de/pub/x11/x.org/|ftp://ftp.gwdg.de/pub/x11/x.org/]] +* [[ftp://ftp.mirrorservice.org/sites/ftp.x.org/|ftp://ftp.mirrorservice.org/sites/ftp.x.org/]] +* [[ftp://ftp.ntua.gr/pub/X11/|ftp://ftp.ntua.gr/pub/X11/]] +* [[ftp://ftp.piotrkosoft.net/pub/mirrors/ftp.x.org/|ftp://ftp.piotrkosoft.net/pub/mirrors/ftp.x.org/]] +* [[ftp://ftp.portal-to-web.de/pub/mirrors/x.org/|ftp://ftp.portal-to-web.de/pub/mirrors/x.org/]] +* [[ftp://ftp.solnet.ch/mirror/x.org/|ftp://ftp.solnet.ch/mirror/x.org/]] +* [[ftp://ftp.sunet.se/pub/X11/|ftp://ftp.sunet.se/pub/X11/]] +* [[ftp://gd.tuwien.ac.at/X11/|ftp://gd.tuwien.ac.at/X11/]] +* [[ftp://mi.mirror.garr.it/mirrors/x.org/|ftp://mi.mirror.garr.it/mirrors/x.org/]] +* [[ftp://mirror.cict.fr/x.org/|ftp://mirror.cict.fr/x.org/]] +* [[ftp://mirror.switch.ch/mirror/X11/|ftp://mirror.switch.ch/mirror/X11/]] +* [[ftp://mirrors.ircam.fr/pub/x.org/|ftp://mirrors.ircam.fr/pub/x.org/]] +* [[ftp://x.mirrors.skynet.be/pub/ftp.x.org/|ftp://x.mirrors.skynet.be/pub/ftp.x.org/]] +* [[http://artfiles.org/x.org/|http://artfiles.org/x.org/]] +* [[http://ftp.chg.ru/pub/X11/x.org/|http://ftp.chg.ru/pub/X11/x.org/]] +* [[http://ftp.gwdg.de/pub/x11/x.org/|http://ftp.gwdg.de/pub/x11/x.org/]] +* [[http://gd.tuwien.ac.at/X11/|http://gd.tuwien.ac.at/X11/]] +* [[http://mi.mirror.garr.it/mirrors/x.org|http://mi.mirror.garr.it/mirrors/x.org]] +* [[http://mirror.cict.fr/x.org/|http://mirror.cict.fr/x.org/]] +* [[http://mirror.switch.ch/ftp/mirror/X11/|http://mirror.switch.ch/ftp/mirror/X11/]] +* [[http://mirrors.ircam.fr/pub/x.org/|http://mirrors.ircam.fr/pub/x.org/]] +* [[http://piotrkosoft.net/pub/mirrors/ftp.x.org/|http://piotrkosoft.net/pub/mirrors/ftp.x.org/]] +* [[http://www.mirrorservice.org/sites/ftp.x.org/|http://www.mirrorservice.org/sites/ftp.x.org/]] +* [[http://www.portal-to-web.de/pub/mirrors/x.org/|http://www.portal-to-web.de/pub/mirrors/x.org/]] +* [[http://x.cybermirror.org/|http://x.cybermirror.org/]] +* [[http://x.europnews.de/|http://x.europnews.de/]] +* [[http://x.mirrors.skynet.be/pub/ftp.x.org/|http://x.mirrors.skynet.be/pub/ftp.x.org/]] +* [[http://xorg.mirror.solnet.ch/|http://xorg.mirror.solnet.ch/]] +* [[https://yehkri.com/mirror/xorg/|https://yehkri.com/mirror/xorg/]] +* [[http://mirror.nl.leaseweb.net/xorg/|http://mirror.nl.leaseweb.net/xorg/]] +* [[http://mirror.de.leaseweb.net/xorg/|http://mirror.de.leaseweb.net/xorg/]] +* rsync://ftp.solnet.ch::X.org/ +* rsync://gd.tuwien.ac.at/X11/ +* rsync://mirrors.ircam.fr/pub/x.org/ +* rsync://piotrkosoft.net/mirrors/ftp.x.org/ +* rsync://rsync.mirrorservice.org/ftp.x.org/ + +### East Asia + +* [[ftp://ftp.cs.cuhk.edu.hk/pub/X11|ftp://ftp.cs.cuhk.edu.hk/pub/X11]] +* [[ftp://ftp.u-aizu.ac.jp/pub/x11/x.org/|ftp://ftp.u-aizu.ac.jp/pub/x11/x.org/]] +* [[ftp://ftp.yz.yamagata-u.ac.jp/pub/X11/x.org/|ftp://ftp.yz.yamagata-u.ac.jp/pub/X11/x.org/]] +* [[ftp://ftp.kaist.ac.kr/x.org/|ftp://ftp.kaist.ac.kr/x.org/]] +* [[ftp://mirrors.go-part.com/xorg/|ftp://mirrors.go-part.com/xorg/]] +* [[http://mirrors.go-part.com/xorg/|http://mirrors.go-part.com/xorg/]] +* [[http://ftp.yz.yamagata-u.ac.jp/pub/X11/x.org/|http://ftp.yz.yamagata-u.ac.jp/pub/X11/x.org/]] +* [[http://ftp.kaist.ac.kr/x.org/|http://ftp.kaist.ac.kr/x.org/]] +* [[http://x.cs.pu.edu.tw|http://x.cs.pu.edu.tw]] +* rsync://ftp.kaist.ac.kr/x.org/ +* rsync://mirrors.go-part.com/xorg/ + +### South Africa + +* [[ftp://ftp.is.co.za/pub/x.org|ftp://ftp.is.co.za/pub/x.org]] + +### South America + +* no known active mirror. + +### Australia + +* no known active mirror.
\ No newline at end of file diff --git a/Releases/History.mdwn b/Releases/History.mdwn new file mode 100644 index 00000000..aa81c82a --- /dev/null +++ b/Releases/History.mdwn @@ -0,0 +1,66 @@ + +This page lists old releases of X. For more current information, please see the [[releases|Releases]] page. + +The [[Wikipedia page on X|http://en.wikipedia.org/wiki/X_Window_System#Release_history]] has some more detailed information on older releases. + + +## X.Org Foundation monolithic releases + +* [[X.Org 6.9|Releases/6.9]] (Released: 2005-12-21) + * [[Master download site|http://xorg.freedesktop.org/releases/X11R6.9.0/]] +* [[X.Org 6.8.2|Releases/6.8.2]] (Released: 2005-02-09) + * [[Master download site|http://xorg.freedesktop.org/releases/X11R6.8.2/]] +* [[X.Org 6.8.1|Releases/6.8.1]] (Released: 2004-09-17, patch release) + * [[Master download site|http://xorg.freedesktop.org/releases/X11R6.8.1/]] +* [[X.Org 6.8.0|Releases/6.8]] (Released: 2004-09-09) + * [[Master download site|http://xorg.freedesktop.org/releases/X11R6.8.0/]] +* [[X.Org 6.7|Releases/6.7]] (Released: about 2004-04-06, based on X.Org X11R6.6 and XFree86 4.4.0 RC2) + * [[Master download site|http://xorg.freedesktop.org/releases/X11R6.7.0/]] + +## XFree86 releases + +Former X11 releases, done by [[XFree86|http://www.xfree86.org]]: + +* XFree86 4.5.0 (Release: 2005-03-16) +* XFree86 4.4.99.18 (snapshot): (Release: 2004-11-27) +* XFree86 4.4.99.9 (develsnap): (Release: 2004-07-12) +* XFree86 4.4.0 (Release: 2004-02-23) +* XFree86 4.4.0 RC2 (Release: ?) +* XFree86 4.3.0 (Release: 2003-02-26) +* XFree86 4.2.1 (Release: 2002-09-03) +* XFree86 4.2.0 (Release: 2002-01-16) +* XFree86 4.1.0 (Release: 2001-06-02) +* XFree86 4.0.3 (Release: 2001-03-02) +* XFree86 4.0.2 (Release: 2000-12-15) +* XFree86 4.0.1 (Release: 2000-06-30) +* XFree86 4.0.0 (Release: 2000-02-26) +* XFree86 3.3.6 (Release: 1999-12-31) +* XFree86 3.3.5 (Release: ?) +* XFree86 2.1.1 (Release: 1994-05-04) +* XFree86 2.1 (Release: 1994-03-11) +* XFree86 2.0 +(This listing might be incomplete. The provided release dates can be slightly deviating from the true release dates.) + +You can find the related packages on misc [[mirrors|http://xfree86.org/mirrors/]]. + + +## X.Org and X Consortium + +Former X11 releases, done by X.Org and the [[X Consortium|XConsortium]]: + +* X.Org X11R6.6 (Released: 2001-04-03) +* X.Org X11R6.5.1 (Released: 2000-08-25) +* X.Org X11R6.4 (Release: 1998-03-31) +* X.Org X11R6.3 (Release: 1997-07-15) +* X.Org X11R6.1 (Release: 1996-03-12) +* X.Org X11R6 (Release: 1995-03-02) +* X.Org X11R5 (Release: 1994-05-18) +* X.Org X11R4 (Release: 1989-01-29) +* X.Org X11R3 (Release: ca. 1988-10-27) +* X.Org X11R2 (Release: ca. 1988-03-24) +* X.Org X11R1 (Release: ca. 1987-09-18) +* X.Org X10R4 (Release: ca. 1986-12-25) +* X.Org X10R3 (Release: ca. 1986-06-07) +(This listing might be incomplete. The provided release dates can be slightly deviating from the true release dates.) + +You can find these older versions on one of the long term of the X.Org site. diff --git a/Releases/Latest.mdwn b/Releases/Latest.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/Releases/Latest.mdwn diff --git a/Releases/ModuleVersions.mdwn b/Releases/ModuleVersions.mdwn new file mode 100644 index 00000000..804d32d5 --- /dev/null +++ b/Releases/ModuleVersions.mdwn @@ -0,0 +1,317 @@ + +This table lists which module versions were included in each X.Org rollup release. + +For descriptions of what each module is, see the [[module descriptions|ModuleDescriptions]] page. +[[!table header="no" class="mointable" data=""" +**Module** | **Directory** | **[[7.0|Releases/7.0]]** | **[[7.1|Releases/7.1]]** | **[[7.2|Releases/7.2]]** | **[[7.3|Releases/7.3]]** | **[[7.4|Releases/7.4]]** | **[[7.5|Releases/7.5]]** | **[[7.6|Releases/7.6]]** | **[[7.7|Releases/7.7]]** +[[applewmproto|http://cgit.freedesktop.org/xorg/proto/applewmproto/]] | proto | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.0.3.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.4.1.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.4.1.tar.bz2]] | [[1.4.2|http://xorg.freedesktop.org/releases/individual/proto/applewmproto-1.4.2.tar.bz2]] +[[appres|http://cgit.freedesktop.org/xorg/app/appres/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/appres-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/appres-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/appres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/appres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/appres-1.0.1.tar.bz2]] | _none_||| +[[bdftopcf|http://cgit.freedesktop.org/xorg/app/bdftopcf/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.1.tar.bz2]] | _none_ | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/bdftopcf-1.0.3.tar.bz2]] +[[beforelight|http://cgit.freedesktop.org/xorg/app/beforelight/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/beforelight-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/beforelight-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/beforelight-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/beforelight-1.0.2.tar.bz2]] | _none_|||| +[[bigreqsproto|http://cgit.freedesktop.org/xorg/proto/bigreqsproto/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/bigreqsproto-1.1.2.tar.bz2]] +[[bitmap|http://cgit.freedesktop.org/xorg/app/bitmap/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/bitmap-1.0.3.tar.bz2]] | _none_||| +[[compositeproto|http://cgit.freedesktop.org/xorg/proto/compositeproto/]] | proto | [[0.2.2|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.2.2.tar.bz2]] | [[0.3.1|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.3.1.tar.bz2]] | [[0.3.1|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.3.1.tar.bz2]] | [[0.4|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.4.tar.bz2]] | [[0.4|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.4.tar.bz2]] | [[0.4.1|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.4.1.tar.bz2]] | [[0.4.2|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.4.2.tar.bz2]] | [[0.4.2|http://xorg.freedesktop.org/releases/individual/proto/compositeproto-0.4.2.tar.bz2]] +[[damageproto|http://cgit.freedesktop.org/xorg/proto/damageproto/]] | proto | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/damageproto-1.2.1.tar.bz2]] +[[dmxproto|http://cgit.freedesktop.org/xorg/proto/dmxproto/]] | proto | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.2.2.tar.bz2]] | [[2.3|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.3.tar.bz2]] | [[2.3|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.3.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/proto/dmxproto-2.3.1.tar.bz2]] +[[dri2proto|http://cgit.freedesktop.org/xorg/proto/dri2proto/]] | proto | _none_||||| | [[2.1|http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.1.tar.bz2]] | [[2.3|http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.3.tar.bz2]] | [[2.6|http://xorg.freedesktop.org/releases/individual/proto/dri2proto-2.6.tar.bz2]] +[[editres|http://cgit.freedesktop.org/xorg/app/editres/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/editres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/editres-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/editres-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/editres-1.0.3.tar.bz2]] | _none_|||| +[[encodings|http://cgit.freedesktop.org/xorg/font/encodings/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.0.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/encodings-1.0.4.tar.bz2]] +[[evieext|http://cgit.freedesktop.org/xorg/proto/evieext/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/evieext-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/evieext-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/evieext-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/evieext-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/evieext-1.0.2.tar.bz2]] | _none_||| +[[fixesproto|http://cgit.freedesktop.org/xorg/proto/fixesproto/]] | proto | [[3.0.2|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-3.0.2.tar.bz2]] | [[4.0|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.0.tar.bz2]] | [[4.0|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.0.tar.bz2]] | [[4.0|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.0.tar.bz2]] | [[4.0|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.0.tar.bz2]] | [[4.1.1|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.1.1.tar.bz2]] | [[4.1.2|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-4.1.2.tar.bz2]] | [[5.0|http://xorg.freedesktop.org/releases/individual/proto/fixesproto-5.0.tar.bz2]] +[[font-adobe-100dpi|http://cgit.freedesktop.org/xorg/font/font-adobe-100dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-adobe-100dpi-1.0.3.tar.bz2]] +[[font-adobe-75dpi|http://cgit.freedesktop.org/xorg/font/font-adobe-75dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-adobe-75dpi-1.0.3.tar.bz2]] +[[font-adobe-utopia-100dpi|http://cgit.freedesktop.org/xorg/font/font-adobe-utopia-100dpi/]] | font | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-100dpi-1.0.4.tar.bz2]] +[[font-adobe-utopia-75dpi|http://cgit.freedesktop.org/xorg/font/font-adobe-utopia-75dpi/]] | font | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-75dpi-1.0.4.tar.bz2]] +[[font-adobe-utopia-type1|http://cgit.freedesktop.org/xorg/font/font-adobe-utopia-type1/]] | font | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-adobe-utopia-type1-1.0.4.tar.bz2]] +[[font-alias|http://cgit.freedesktop.org/xorg/font/font-alias/]] | font | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-alias-1.0.3.tar.bz2]] +[[font-arabic-misc|http://cgit.freedesktop.org/xorg/font/font-arabic-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-arabic-misc-1.0.3.tar.bz2]] +[[font-bh-100dpi|http://cgit.freedesktop.org/xorg/font/font-bh-100dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-100dpi-1.0.3.tar.bz2]] +[[font-bh-75dpi|http://cgit.freedesktop.org/xorg/font/font-bh-75dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-75dpi-1.0.3.tar.bz2]] +[[font-bh-lucidatypewriter-100dpi|http://cgit.freedesktop.org/xorg/font/font-bh-lucidatypewriter-100dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-100dpi-1.0.3.tar.bz2]] +[[font-bh-lucidatypewriter-75dpi|http://cgit.freedesktop.org/xorg/font/font-bh-lucidatypewriter-75dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-lucidatypewriter-75dpi-1.0.3.tar.bz2]] +[[font-bh-ttf|http://cgit.freedesktop.org/xorg/font/font-bh-ttf/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-ttf-1.0.3.tar.bz2]] +[[font-bh-type1|http://cgit.freedesktop.org/xorg/font/font-bh-type1/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bh-type1-1.0.3.tar.bz2]] +[[font-bitstream-100dpi|http://cgit.freedesktop.org/xorg/font/font-bitstream-100dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-100dpi-1.0.3.tar.bz2]] +[[font-bitstream-75dpi|http://cgit.freedesktop.org/xorg/font/font-bitstream-75dpi/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-75dpi-1.0.3.tar.bz2]] +[[font-bitstream-speedo|http://cgit.freedesktop.org/xorg/font/font-bitstream-speedo/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-speedo-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-speedo-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-speedo-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-speedo-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-speedo-1.0.0.tar.bz2]] | _none_||| +[[font-bitstream-type1|http://cgit.freedesktop.org/xorg/font/font-bitstream-type1/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-bitstream-type1-1.0.3.tar.bz2]] +[[font-cronyx-cyrillic|http://cgit.freedesktop.org/xorg/font/font-cronyx-cyrillic/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-cronyx-cyrillic-1.0.3.tar.bz2]] +[[font-cursor-misc|http://cgit.freedesktop.org/xorg/font/font-cursor-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-cursor-misc-1.0.3.tar.bz2]] +[[font-daewoo-misc|http://cgit.freedesktop.org/xorg/font/font-daewoo-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-daewoo-misc-1.0.3.tar.bz2]] +[[font-dec-misc|http://cgit.freedesktop.org/xorg/font/font-dec-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-dec-misc-1.0.3.tar.bz2]] +[[font-ibm-type1|http://cgit.freedesktop.org/xorg/font/font-ibm-type1/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-ibm-type1-1.0.3.tar.bz2]] +[[font-isas-misc|http://cgit.freedesktop.org/xorg/font/font-isas-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-isas-misc-1.0.3.tar.bz2]] +[[font-jis-misc|http://cgit.freedesktop.org/xorg/font/font-jis-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-jis-misc-1.0.3.tar.bz2]] +[[font-micro-misc|http://cgit.freedesktop.org/xorg/font/font-micro-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-micro-misc-1.0.3.tar.bz2]] +[[font-misc-cyrillic|http://cgit.freedesktop.org/xorg/font/font-misc-cyrillic/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-cyrillic-1.0.3.tar.bz2]] +[[font-misc-ethiopic|http://cgit.freedesktop.org/xorg/font/font-misc-ethiopic/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-ethiopic-1.0.3.tar.bz2]] +[[font-misc-meltho|http://cgit.freedesktop.org/xorg/font/font-misc-meltho/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-misc-meltho-1.0.3.tar.bz2]] +[[font-misc-misc|http://cgit.freedesktop.org/xorg/font/font-misc-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.0.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.1.0.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/font/font-misc-misc-1.1.2.tar.bz2]] +[[font-mutt-misc|http://cgit.freedesktop.org/xorg/font/font-mutt-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-mutt-misc-1.0.3.tar.bz2]] +[[font-schumacher-misc|http://cgit.freedesktop.org/xorg/font/font-schumacher-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.0.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.1.0.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/font/font-schumacher-misc-1.1.2.tar.bz2]] +[[font-screen-cyrillic|http://cgit.freedesktop.org/xorg/font/font-screen-cyrillic/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-screen-cyrillic-1.0.4.tar.bz2]] +[[font-sony-misc|http://cgit.freedesktop.org/xorg/font/font-sony-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-sony-misc-1.0.3.tar.bz2]] +[[font-sun-misc|http://cgit.freedesktop.org/xorg/font/font-sun-misc/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-sun-misc-1.0.3.tar.bz2]] +[[font-util|http://cgit.freedesktop.org/xorg/font/font-util/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-util-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-util-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-util-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-util-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-util-1.0.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/font/font-util-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/font/font-util-1.2.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/font/font-util-1.3.0.tar.bz2]] +[[font-winitzki-cyrillic|http://cgit.freedesktop.org/xorg/font/font-winitzki-cyrillic/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/font/font-winitzki-cyrillic-1.0.3.tar.bz2]] +[[font-xfree86-type1|http://cgit.freedesktop.org/xorg/font/font-xfree86-type1/]] | font | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/font/font-xfree86-type1-1.0.4.tar.bz2]] +[[fontcacheproto|http://cgit.freedesktop.org/xorg/proto/fontcacheproto/]] | proto | [[0.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontcacheproto-0.1.2.tar.bz2]] | [[0.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontcacheproto-0.1.2.tar.bz2]] | [[0.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontcacheproto-0.1.2.tar.bz2]] | [[0.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontcacheproto-0.1.2.tar.bz2]] | [[0.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontcacheproto-0.1.2.tar.bz2]] | _none_||| +[[fontsproto|http://cgit.freedesktop.org/xorg/proto/fontsproto/]] | proto | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.0.2.tar.bz2]] | [[2.1.0|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.1.0.tar.bz2]] | [[2.1.1|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.1.1.tar.bz2]] | [[2.1.2|http://xorg.freedesktop.org/releases/individual/proto/fontsproto-2.1.2.tar.bz2]] +[[fonttosfnt|http://cgit.freedesktop.org/xorg/app/fonttosfnt/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fonttosfnt-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fonttosfnt-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/fonttosfnt-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/fonttosfnt-1.0.3.tar.bz2]] | _none_|||| +[[fslsfonts|http://cgit.freedesktop.org/xorg/app/fslsfonts/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fslsfonts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fslsfonts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fslsfonts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fslsfonts-1.0.1.tar.bz2]] | _none_|||| +[[fstobdf|http://cgit.freedesktop.org/xorg/app/fstobdf/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/fstobdf-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/fstobdf-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/fstobdf-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/fstobdf-1.0.2.tar.bz2]] | _none_|||| +[[gccmakedep|http://cgit.freedesktop.org/xorg/util/gccmakedep/]] | util | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/gccmakedep-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/gccmakedep-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/gccmakedep-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/gccmakedep-1.0.2.tar.bz2]] | _none_|||| +[[glproto|http://cgit.freedesktop.org/xorg/proto/glproto/]] | proto | [[1.4.3|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.3.tar.bz2]] | [[1.4.7|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.7.tar.bz2]] | [[1.4.8|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.8.tar.bz2]] | [[1.4.8|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.8.tar.bz2]] | [[1.4.9|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.9.tar.bz2]] | [[1.4.10|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.10.tar.bz2]] | [[1.4.12|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.12.tar.bz2]] | [[1.4.15|http://xorg.freedesktop.org/releases/individual/proto/glproto-1.4.15.tar.bz2]] +[[iceauth|http://cgit.freedesktop.org/xorg/app/iceauth/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/iceauth-1.0.5.tar.bz2]] +[[ico|http://cgit.freedesktop.org/xorg/app/ico/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/ico-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/ico-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/ico-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/ico-1.0.2.tar.bz2]] | _none_|||| +[[imake|http://cgit.freedesktop.org/xorg/util/imake/]] | util | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/imake-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/imake-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/imake-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/imake-1.0.2.tar.bz2]] | _none_|||| +[[inputproto|http://cgit.freedesktop.org/xorg/proto/inputproto/]] | proto | [[1.3.2|http://xorg.freedesktop.org/releases/individual/proto/inputproto-1.3.2.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/proto/inputproto-1.3.2.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/proto/inputproto-1.3.2.tar.bz2]] | [[1.4.2.1|http://xorg.freedesktop.org/releases/individual/proto/inputproto-1.4.2.1.tar.bz2]] | [[1.4.4|http://xorg.freedesktop.org/releases/individual/proto/inputproto-1.4.4.tar.bz2]] | [[2.0|http://xorg.freedesktop.org/releases/individual/proto/inputproto-2.0.tar.bz2]] | [[2.0.1|http://xorg.freedesktop.org/releases/individual/proto/inputproto-2.0.1.tar.bz2]] | [[2.2|http://xorg.freedesktop.org/releases/individual/proto/inputproto-2.2.tar.bz2]] +[[kbproto|http://cgit.freedesktop.org/xorg/proto/kbproto/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/proto/kbproto-1.0.6.tar.bz2]] +[[lbxproxy|http://cgit.freedesktop.org/xorg/app/lbxproxy/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/lbxproxy-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/lbxproxy-1.0.1.tar.bz2]] | _none_|||||| +[[libAppleWM|http://cgit.freedesktop.org/xorg/lib/libAppleWM/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.0.0.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.4.0.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.4.0.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/lib/libAppleWM-1.4.1.tar.bz2]] +[[libFS|http://cgit.freedesktop.org/xorg/lib/libFS/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libFS-1.0.4.tar.bz2]] +[[libICE|http://cgit.freedesktop.org/xorg/lib/libICE/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.4.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.7.tar.bz2]] | [[1.0.8|http://xorg.freedesktop.org/releases/individual/lib/libICE-1.0.8.tar.bz2]] +[[libSM|http://cgit.freedesktop.org/xorg/lib/libSM/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/lib/libSM-1.2.1.tar.bz2]] +[[libWindowsWM|http://cgit.freedesktop.org/xorg/lib/libWindowsWM/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libWindowsWM-1.0.1.tar.bz2]] +[[libX11|http://cgit.freedesktop.org/xorg/lib/libX11/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.0.1.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.1.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.1.3.tar.bz2]] | [[1.1.5|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.1.5.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.3.2.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.4.0.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/lib/libX11-1.5.0.tar.bz2]] +[[libXScrnSaver|http://cgit.freedesktop.org/xorg/lib/libXScrnSaver/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.0.1.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.1.0.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.1.2.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.1.3.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.2.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/lib/libXScrnSaver-1.2.2.tar.bz2]] +[[libXTrap|http://cgit.freedesktop.org/xorg/lib/libXTrap/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXTrap-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXTrap-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXTrap-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXTrap-1.0.0.tar.bz2]] | _none_|||| +[[libXau|http://cgit.freedesktop.org/xorg/lib/libXau/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libXau-1.0.7.tar.bz2]] +[[libXaw|http://cgit.freedesktop.org/xorg/lib/libXaw/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.4.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.7.tar.bz2]] | [[1.0.8|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.8.tar.bz2]] | [[1.0.11|http://xorg.freedesktop.org/releases/individual/lib/libXaw-1.0.11.tar.bz2]] +[[libXcomposite|http://cgit.freedesktop.org/xorg/lib/libXcomposite/]] | lib | [[0.2.2.2|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.2.2.2.tar.bz2]] | [[0.3|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.3.tar.bz2]] | [[0.3|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.3.tar.bz2]] | [[0.4.0|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.4.0.tar.bz2]] | [[0.4.0|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.4.0.tar.bz2]] | [[0.4.1|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.4.1.tar.bz2]] | [[0.4.3|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.4.3.tar.bz2]] | [[0.4.3|http://xorg.freedesktop.org/releases/individual/lib/libXcomposite-0.4.3.tar.bz2]] +[[libXcursor|http://cgit.freedesktop.org/xorg/lib/libXcursor/]] | lib | [[1.1.5.2|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.5.2.tar.bz2]] | [[1.1.6|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.6.tar.bz2]] | [[1.1.8|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.8.tar.bz2]] | [[1.1.9|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.9.tar.bz2]] | [[1.1.9|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.9.tar.bz2]] | [[1.1.10|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.10.tar.bz2]] | [[1.1.11|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.11.tar.bz2]] | [[1.1.13|http://xorg.freedesktop.org/releases/individual/lib/libXcursor-1.1.13.tar.bz2]] +[[libXdamage|http://cgit.freedesktop.org/xorg/lib/libXdamage/]] | lib | [[1.0.2.2|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.0.2.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.0.3.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.1.2.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.1.3.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXdamage-1.1.3.tar.bz2]] +[[libXdmcp|http://cgit.freedesktop.org/xorg/lib/libXdmcp/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXdmcp-1.1.1.tar.bz2]] +[[libXevie|http://cgit.freedesktop.org/xorg/lib/libXevie/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXevie-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXevie-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXevie-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXevie-1.0.2.tar.bz2]] | _none_|||| +[[libXext|http://cgit.freedesktop.org/xorg/lib/libXext/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.0.4.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.2.0.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/lib/libXext-1.3.1.tar.bz2]] +[[libXfixes|http://cgit.freedesktop.org/xorg/lib/libXfixes/]] | lib | [[3.0.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-3.0.1.2.tar.bz2]] | [[4.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.1.tar.bz2]] | [[4.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.1.tar.bz2]] | [[4.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.1.tar.bz2]] | [[4.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.3.tar.bz2]] | [[4.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.4.tar.bz2]] | [[4.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-4.0.5.tar.bz2]] | [[5.0|http://xorg.freedesktop.org/releases/individual/lib/libXfixes-5.0.tar.bz2]] +[[libXfont|http://cgit.freedesktop.org/xorg/lib/libXfont/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.0.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.1.0.tar.bz2]] | [[1.2.7|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.2.7.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.3.1.tar.bz2]] | [[1.3.3|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.3.3.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.4.1.tar.bz2]] | [[1.4.3|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.4.3.tar.bz2]] | [[1.4.5|http://xorg.freedesktop.org/releases/individual/lib/libXfont-1.4.5.tar.bz2]] +[[libXfontcache|http://cgit.freedesktop.org/xorg/lib/libXfontcache/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXfontcache-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXfontcache-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXfontcache-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXfontcache-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXfontcache-1.0.4.tar.bz2]] | _none_||| +[[libXft|http://cgit.freedesktop.org/xorg/lib/libXft/]] | lib | [[2.1.8.2|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.8.2.tar.bz2]] | [[2.1.8.2|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.8.2.tar.bz2]] | [[2.1.12|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.12.tar.bz2]] | [[2.1.12|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.12.tar.bz2]] | [[2.1.13|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.13.tar.bz2]] | [[2.1.14|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.1.14.tar.bz2]] | [[2.2.0|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.2.0.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/lib/libXft-2.3.1.tar.bz2]] +[[libXi|http://cgit.freedesktop.org/xorg/lib/libXi/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.0.2.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.1.3.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.1.3.tar.bz2]] | [[1.3|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.3.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.4.0.tar.bz2]] | [[1.6.1|http://xorg.freedesktop.org/releases/individual/lib/libXi-1.6.1.tar.bz2]] +[[libXinerama|http://cgit.freedesktop.org/xorg/lib/libXinerama/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.0.3.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXinerama-1.1.2.tar.bz2]] +[[libXmu|http://cgit.freedesktop.org/xorg/lib/libXmu/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXmu-1.1.1.tar.bz2]] +[[libXp|http://cgit.freedesktop.org/xorg/lib/libXp/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXp-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXp-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXp-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXp-1.0.0.tar.bz2]] | _none_|||| +[[libXpm|http://cgit.freedesktop.org/xorg/lib/libXpm/]] | lib | [[3.5.4.2|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.4.2.tar.bz2]] | [[3.5.5|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.5.tar.bz2]] | [[3.5.6|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.6.tar.bz2]] | [[3.5.7|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.7.tar.bz2]] | [[3.5.7|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.7.tar.bz2]] | [[3.5.8|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.8.tar.bz2]] | [[3.5.9|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.9.tar.bz2]] | [[3.5.10|http://xorg.freedesktop.org/releases/individual/lib/libXpm-3.5.10.tar.bz2]] +[[libXprintAppUtil|http://cgit.freedesktop.org/xorg/lib/libXprintAppUtil/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintAppUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintAppUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintAppUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintAppUtil-1.0.1.tar.bz2]] | _none_|||| +[[libXprintUtil|http://cgit.freedesktop.org/xorg/lib/libXprintUtil/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintUtil-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXprintUtil-1.0.1.tar.bz2]] | _none_|||| +[[libXrandr|http://cgit.freedesktop.org/xorg/lib/libXrandr/]] | lib | [[1.1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.1.0.2.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.1.2.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.2.2.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.2.3.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.3.0.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.3.1.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/lib/libXrandr-1.3.2.tar.bz2]] +[[libXrender|http://cgit.freedesktop.org/xorg/lib/libXrender/]] | lib | [[0.9.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.0.2.tar.bz2]] | [[0.9.1|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.1.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.2.tar.bz2]] | [[0.9.4|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.4.tar.bz2]] | [[0.9.4|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.4.tar.bz2]] | [[0.9.5|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.5.tar.bz2]] | [[0.9.6|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.6.tar.bz2]] | [[0.9.7|http://xorg.freedesktop.org/releases/individual/lib/libXrender-0.9.7.tar.bz2]] +[[libXres|http://cgit.freedesktop.org/xorg/lib/libXres/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libXres-1.0.6.tar.bz2]] +[[libXt|http://cgit.freedesktop.org/xorg/lib/libXt/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.0.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.2.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.5.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.5.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.5.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.7.tar.bz2]] | [[1.0.9|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.0.9.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXt-1.1.3.tar.bz2]] +[[libXtst|http://cgit.freedesktop.org/xorg/lib/libXtst/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/lib/libXtst-1.2.1.tar.bz2]] +[[libXv|http://cgit.freedesktop.org/xorg/lib/libXv/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libXv-1.0.7.tar.bz2]] +[[libXvMC|http://cgit.freedesktop.org/xorg/lib/libXvMC/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libXvMC-1.0.7.tar.bz2]] +[[libXxf86dga|http://cgit.freedesktop.org/xorg/lib/libXxf86dga/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.0.2.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.1.2.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/lib/libXxf86dga-1.1.3.tar.bz2]] +[[libXxf86misc|http://cgit.freedesktop.org/xorg/lib/libXxf86misc/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXxf86misc-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86misc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86misc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86misc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86misc-1.0.1.tar.bz2]] | _none_||| +[[libXxf86vm|http://cgit.freedesktop.org/xorg/lib/libXxf86vm/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libXxf86vm-1.1.2.tar.bz2]] +[[libdmx|http://cgit.freedesktop.org/xorg/lib/libdmx/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/lib/libdmx-1.1.2.tar.bz2]] +[[libfontenc|http://cgit.freedesktop.org/xorg/lib/libfontenc/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/lib/libfontenc-1.1.1.tar.bz2]] +[[liblbxutil|http://cgit.freedesktop.org/xorg/lib/liblbxutil/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/liblbxutil-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/liblbxutil-1.0.1.tar.bz2]] | _none_|||||| +[[liboldX|http://cgit.freedesktop.org/xorg/lib/liboldX/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/liboldX-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/liboldX-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/liboldX-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/liboldX-1.0.1.tar.bz2]] | _none_|||| +[[libpciaccess|http://cgit.freedesktop.org/xorg/lib/libpciaccess/]] | lib | _none_|||| | [[0.10.3|http://xorg.freedesktop.org/releases/individual/lib/libpciaccess-0.10.3.tar.bz2]] | [[0.10.9|http://xorg.freedesktop.org/releases/individual/lib/libpciaccess-0.10.9.tar.bz2]] | [[0.12.0|http://xorg.freedesktop.org/releases/individual/lib/libpciaccess-0.12.0.tar.bz2]] | [[0.13.1|http://xorg.freedesktop.org/releases/individual/lib/libpciaccess-0.13.1.tar.bz2]] +[[libpthread-stubs|http://cgit.freedesktop.org/xorg/lib/libpthread-stubs/]] | lib | _none_|| | [[0.1|http://xorg.freedesktop.org/releases/individual/lib/libpthread-stubs-0.1.tar.bz2]] | [[0.1|http://xorg.freedesktop.org/releases/individual/lib/libpthread-stubs-0.1.tar.bz2]] | _none_|| | [[0.3|http://xorg.freedesktop.org/releases/individual/lib/libpthread-stubs-0.3.tar.bz2]] | [[0.3|http://xorg.freedesktop.org/releases/individual/lib/libpthread-stubs-0.3.tar.bz2]] +[[libxcb|http://cgit.freedesktop.org/xcb/libxcb/]] | xcb | _none_|||||| | [[1.7|http://xorg.freedesktop.org/releases/individual/xcb/libxcb-1.7.tar.bz2]] | [[1.8.1|http://xorg.freedesktop.org/releases/individual/xcb/libxcb-1.8.1.tar.bz2]] +[[libxkbfile|http://cgit.freedesktop.org/xorg/lib/libxkbfile/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.7.tar.bz2]] | [[1.0.8|http://xorg.freedesktop.org/releases/individual/lib/libxkbfile-1.0.8.tar.bz2]] +[[libxkbui|http://cgit.freedesktop.org/xorg/lib/libxkbui/]] | lib | [[1.0.1|http://xorg.freedesktop.org/releases/individual/lib/libxkbui-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libxkbui-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libxkbui-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/lib/libxkbui-1.0.2.tar.bz2]] | _none_|||| +[[listres|http://cgit.freedesktop.org/xorg/app/listres/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/listres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/listres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/listres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/listres-1.0.1.tar.bz2]] | _none_|||| +[[lndir|http://cgit.freedesktop.org/xorg/util/lndir/]] | util | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/lndir-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/lndir-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/lndir-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/lndir-1.0.1.tar.bz2]] | _none_|||| +[[luit|http://cgit.freedesktop.org/xorg/app/luit/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/luit-1.0.4.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/luit-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/luit-1.1.1.tar.bz2]] +[[makedepend|http://cgit.freedesktop.org/xorg/util/makedepend/]] | util | [[1.0.0|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/util/makedepend-1.0.4.tar.bz2]] +[[mkcfm|http://cgit.freedesktop.org/xorg/app/mkcfm/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/mkcfm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/mkcfm-1.0.1.tar.bz2]] | _none_|||||| +[[mkcomposecache|http://cgit.freedesktop.org/xorg/app/mkcomposecache/]] | app | _none_|| | [[1.2|http://xorg.freedesktop.org/releases/individual/app/mkcomposecache-1.2.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/app/mkcomposecache-1.2.tar.bz2]] | _none_|||| +[[mkfontdir|http://cgit.freedesktop.org/xorg/app/mkfontdir/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/mkfontdir-1.0.7.tar.bz2]] +[[mkfontscale|http://cgit.freedesktop.org/xorg/app/mkfontscale/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.3.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.5.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.7.tar.bz2]] | [[1.0.8|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.0.8.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/mkfontscale-1.1.0.tar.bz2]] +[[oclock|http://cgit.freedesktop.org/xorg/app/oclock/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/oclock-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/oclock-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/oclock-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/oclock-1.0.1.tar.bz2]] | _none_|||| +[[printproto|http://cgit.freedesktop.org/xorg/proto/printproto/]] | proto | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/printproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/printproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/printproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/printproto-1.0.3.tar.bz2]] | _none_|||| +[[proxymngr|http://cgit.freedesktop.org/xorg/app/proxymngr/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/proxymngr-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/proxymngr-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/proxymngr-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/proxymngr-1.0.1.tar.bz2]] | _none_|||| +[[randrproto|http://cgit.freedesktop.org/xorg/proto/randrproto/]] | proto | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.1.2.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.2.1.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.3.1.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.3.2.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/proto/randrproto-1.3.2.tar.bz2]] +[[recordproto|http://cgit.freedesktop.org/xorg/proto/recordproto/]] | proto | [[1.13.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.13.2.tar.bz2]] | [[1.13.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.13.2.tar.bz2]] | [[1.13.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.13.2.tar.bz2]] | [[1.13.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.13.2.tar.bz2]] | [[1.13.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.13.2.tar.bz2]] | [[1.14|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.14.tar.bz2]] | [[1.14.1|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.14.1.tar.bz2]] | [[1.14.2|http://xorg.freedesktop.org/releases/individual/proto/recordproto-1.14.2.tar.bz2]] +[[renderproto|http://cgit.freedesktop.org/xorg/proto/renderproto/]] | proto | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.9.2.tar.bz2]] | [[0.9.3|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.9.3.tar.bz2]] | [[0.9.3|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.9.3.tar.bz2]] | [[0.11|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.11.tar.bz2]] | [[0.11.1|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.11.1.tar.bz2]] | [[0.11.1|http://xorg.freedesktop.org/releases/individual/proto/renderproto-0.11.1.tar.bz2]] +[[resourceproto|http://cgit.freedesktop.org/xorg/proto/resourceproto/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/resourceproto-1.2.0.tar.bz2]] +[[rgb|http://cgit.freedesktop.org/xorg/app/rgb/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/rgb-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/rgb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/rgb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/rgb-1.0.1.tar.bz2]] | _none_|||| +[[rstart|http://cgit.freedesktop.org/xorg/app/rstart/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/rstart-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/rstart-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/rstart-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/rstart-1.0.2.tar.bz2]] | _none_|||| +[[scripts|http://cgit.freedesktop.org/xorg/app/scripts/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/scripts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/scripts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/scripts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/scripts-1.0.1.tar.bz2]] | _none_|||| +[[scrnsaverproto|http://cgit.freedesktop.org/xorg/proto/scrnsaverproto/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.2.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/proto/scrnsaverproto-1.2.2.tar.bz2]] +[[sessreg|http://cgit.freedesktop.org/xorg/app/sessreg/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.0.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/sessreg-1.0.7.tar.bz2]] +[[setxkbmap|http://cgit.freedesktop.org/xorg/app/setxkbmap/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.0.4.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.2.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/app/setxkbmap-1.3.0.tar.bz2]] +[[showfont|http://cgit.freedesktop.org/xorg/app/showfont/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/showfont-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/showfont-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/showfont-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/showfont-1.0.1.tar.bz2]] | _none_|||| +[[smproxy|http://cgit.freedesktop.org/xorg/app/smproxy/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/smproxy-1.0.5.tar.bz2]] +[[trapproto|http://cgit.freedesktop.org/xorg/proto/trapproto/]] | proto | [[3.4.3|http://xorg.freedesktop.org/releases/individual/proto/trapproto-3.4.3.tar.bz2]] | [[3.4.3|http://xorg.freedesktop.org/releases/individual/proto/trapproto-3.4.3.tar.bz2]] | [[3.4.3|http://xorg.freedesktop.org/releases/individual/proto/trapproto-3.4.3.tar.bz2]] | [[3.4.3|http://xorg.freedesktop.org/releases/individual/proto/trapproto-3.4.3.tar.bz2]] | [[3.4.3|http://xorg.freedesktop.org/releases/individual/proto/trapproto-3.4.3.tar.bz2]] | _none_||| +[[twm|http://cgit.freedesktop.org/xorg/app/twm/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/twm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/twm-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/twm-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/twm-1.0.3.tar.bz2]] | _none_|||| +[[util-macros|http://cgit.freedesktop.org/xorg/util/macros/]] | util | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.0.2.tar.bz2]] | [[1.1.5|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.1.5.tar.bz2]] | [[1.1.5|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.1.5.tar.bz2]] | [[1.1.6|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.1.6.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.3.0.tar.bz2]] | [[1.11.0|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.11.0.tar.bz2]] | [[1.17|http://xorg.freedesktop.org/releases/individual/util/util-macros-1.17.tar.bz2]] +[[videoproto|http://cgit.freedesktop.org/xorg/proto/videoproto/]] | proto | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.2.2.tar.bz2]] | [[2.3.0|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.3.0.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.3.1.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/proto/videoproto-2.3.1.tar.bz2]] +[[viewres|http://cgit.freedesktop.org/xorg/app/viewres/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/viewres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/viewres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/viewres-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/viewres-1.0.1.tar.bz2]] | _none_|||| +[[windowswmproto|http://cgit.freedesktop.org/xorg/proto/windowswmproto/]] | proto | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/proto/windowswmproto-1.0.4.tar.bz2]] +[[x11perf|http://cgit.freedesktop.org/xorg/app/x11perf/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.0.1.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.4.1.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.4.1.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.4.1.tar.bz2]] | [[1.5|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.5.tar.bz2]] | [[1.5.1|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.5.1.tar.bz2]] | [[1.5.2|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.5.2.tar.bz2]] | [[1.5.4|http://xorg.freedesktop.org/releases/individual/app/x11perf-1.5.4.tar.bz2]] +[[xauth|http://cgit.freedesktop.org/xorg/app/xauth/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.5.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/xauth-1.0.7.tar.bz2]] +[[xbacklight|http://cgit.freedesktop.org/xorg/data/xbacklight/]] | data | _none_||| | [[1.1|http://xorg.freedesktop.org/releases/individual/data/xbacklight-1.1.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/data/xbacklight-1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/data/xbacklight-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/data/xbacklight-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/data/xbacklight-1.1.2.tar.bz2]] +[[xbiff|http://cgit.freedesktop.org/xorg/app/xbiff/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xbiff-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xbiff-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xbiff-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xbiff-1.0.1.tar.bz2]] | _none_|||| +[[xbitmaps|http://cgit.freedesktop.org/xorg/data/xbitmaps/]] | data | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.0.1.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/data/xbitmaps-1.1.1.tar.bz2]] +[[xcalc|http://cgit.freedesktop.org/xorg/app/xcalc/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcalc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcalc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcalc-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xcalc-1.0.2.tar.bz2]] | _none_|||| +[[xcb-proto|http://cgit.freedesktop.org/xcb/proto/]] | xcb | _none_|||||| | [[1.6|http://xorg.freedesktop.org/releases/individual/xcb/xcb-proto-1.6.tar.bz2]] | [[1.7.1|http://xorg.freedesktop.org/releases/individual/xcb/xcb-proto-1.7.1.tar.bz2]] +[[xclipboard|http://cgit.freedesktop.org/xorg/app/xclipboard/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xclipboard-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xclipboard-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xclipboard-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xclipboard-1.0.1.tar.bz2]] | _none_|||| +[[xclock|http://cgit.freedesktop.org/xorg/app/xclock/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xclock-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xclock-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xclock-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xclock-1.0.3.tar.bz2]] | _none_|||| +[[xcmiscproto|http://cgit.freedesktop.org/xorg/proto/xcmiscproto/]] | proto | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.1.2.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.2.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/proto/xcmiscproto-1.2.2.tar.bz2]] +[[xcmsdb|http://cgit.freedesktop.org/xorg/app/xcmsdb/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xcmsdb-1.0.4.tar.bz2]] +[[xconsole|http://cgit.freedesktop.org/xorg/app/xconsole/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xconsole-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xconsole-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xconsole-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xconsole-1.0.3.tar.bz2]] | _none_|||| +[[xcursor-themes|http://cgit.freedesktop.org/xorg/data/xcursor-themes/]] | data | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/data/xcursor-themes-1.0.3.tar.bz2]] +[[xcursorgen|http://cgit.freedesktop.org/xorg/app/xcursorgen/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xcursorgen-1.0.5.tar.bz2]] +[[xdbedizzy|http://cgit.freedesktop.org/xorg/app/xdbedizzy/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdbedizzy-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdbedizzy-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xdbedizzy-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xdbedizzy-1.0.2.tar.bz2]] | _none_|||| +[[xditview|http://cgit.freedesktop.org/xorg/app/xditview/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xditview-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xditview-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xditview-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xditview-1.0.1.tar.bz2]] | _none_|||| +[[xdm|http://cgit.freedesktop.org/xorg/app/xdm/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdm-1.0.1.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xdm-1.0.4.tar.bz2]] | [[1.1.4|http://xorg.freedesktop.org/releases/individual/app/xdm-1.1.4.tar.bz2]] | [[1.1.6|http://xorg.freedesktop.org/releases/individual/app/xdm-1.1.6.tar.bz2]] | _none_|||| +[[xdpyinfo|http://cgit.freedesktop.org/xorg/app/xdpyinfo/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.2.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/app/xdpyinfo-1.3.0.tar.bz2]] +[[xdriinfo|http://cgit.freedesktop.org/xorg/app/xdriinfo/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xdriinfo-1.0.4.tar.bz2]] +[[xedit|http://cgit.freedesktop.org/xorg/app/xedit/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xedit-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xedit-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xedit-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xedit-1.0.2.tar.bz2]] | _none_|||| +[[xev|http://cgit.freedesktop.org/xorg/app/xev/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xev-1.0.4.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xev-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/app/xev-1.2.0.tar.bz2]] +[[xextproto|http://cgit.freedesktop.org/xorg/proto/xextproto/]] | proto | [[7.0.2|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2]] | [[7.0.2|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2]] | [[7.0.2|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2]] | [[7.0.2|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.2.tar.bz2]] | [[7.0.3|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.0.3.tar.bz2]] | [[7.1.1|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.1.1.tar.bz2]] | [[7.1.2|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.1.2.tar.bz2]] | [[7.2.1|http://xorg.freedesktop.org/releases/individual/proto/xextproto-7.2.1.tar.bz2]] +[[xeyes|http://cgit.freedesktop.org/xorg/app/xeyes/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xeyes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xeyes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xeyes-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xeyes-1.0.1.tar.bz2]] | _none_|||| +[[xf86-input-acecad|http://cgit.freedesktop.org/xorg/driver/xf86-input-acecad/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.2.0.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.2.2.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.4.0.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-acecad-1.4.0.tar.bz2]] | _none_ +[[xf86-input-aiptek|http://cgit.freedesktop.org/xorg/driver/xf86-input-aiptek/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.0.0.5.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.0.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.1.1.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.3.0.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-aiptek-1.3.1.tar.bz2]] | _none_ +[[xf86-input-calcomp|http://cgit.freedesktop.org/xorg/driver/xf86-input-calcomp/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-calcomp-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-calcomp-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-calcomp-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-calcomp-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-citron|http://cgit.freedesktop.org/xorg/driver/xf86-input-citron/]] | driver | [[2.1.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-citron-2.1.1.5.tar.bz2]] | [[2.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-citron-2.2.0.tar.bz2]] | [[2.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-citron-2.2.0.tar.bz2]] | [[2.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-citron-2.2.0.tar.bz2]] | _none_|||| +[[xf86-input-digitaledge|http://cgit.freedesktop.org/xorg/driver/xf86-input-digitaledge/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-digitaledge-1.0.1.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-digitaledge-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-digitaledge-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-digitaledge-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-dmc|http://cgit.freedesktop.org/xorg/driver/xf86-input-dmc/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dmc-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dmc-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dmc-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dmc-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-dynapro|http://cgit.freedesktop.org/xorg/driver/xf86-input-dynapro/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dynapro-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dynapro-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dynapro-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-dynapro-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-elo2300|http://cgit.freedesktop.org/xorg/driver/xf86-input-elo2300/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elo2300-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elo2300-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elo2300-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elo2300-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-elographics|http://cgit.freedesktop.org/xorg/driver/xf86-input-elographics/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elographics-1.0.0.5.tar.bz2]] | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elographics-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elographics-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-elographics-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-evdev|http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-1.0.0.5.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-1.1.2.tar.bz2]] | [[1.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-1.1.5.tar.bz2]] | [[1.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-1.1.5.tar.bz2]] | [[2.0.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-2.0.4.tar.bz2]] | [[2.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-2.3.0.tar.bz2]] | [[2.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-2.5.0.tar.bz2]] | [[2.7.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-evdev-2.7.0.tar.bz2]] +[[xf86-input-fpit|http://cgit.freedesktop.org/xorg/driver/xf86-input-fpit/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-fpit-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-fpit-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-fpit-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-fpit-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-hyperpen|http://cgit.freedesktop.org/xorg/driver/xf86-input-hyperpen/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-hyperpen-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-hyperpen-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-hyperpen-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-hyperpen-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-jamstudio|http://cgit.freedesktop.org/xorg/driver/xf86-input-jamstudio/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-jamstudio-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-jamstudio-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-jamstudio-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-jamstudio-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-joystick|http://cgit.freedesktop.org/xorg/driver/xf86-input-joystick/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.1.0.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.2.3.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.3.2.tar.bz2]] | [[1.4.99.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.4.99.2.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.5.0.tar.bz2]] | [[1.6.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-joystick-1.6.1.tar.bz2]] +[[xf86-input-keyboard|http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.0.1.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.1.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.2.2.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.3.1.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.4.0.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.5.0.tar.bz2]] | [[1.6.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-keyboard-1.6.1.tar.bz2]] +[[xf86-input-magellan|http://cgit.freedesktop.org/xorg/driver/xf86-input-magellan/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magellan-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magellan-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magellan-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magellan-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-magictouch|http://cgit.freedesktop.org/xorg/driver/xf86-input-magictouch/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magictouch-1.0.0.5.tar.bz2]] | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magictouch-1.0.0.5.tar.bz2]] | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magictouch-1.0.0.5.tar.bz2]] | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-magictouch-1.0.0.5.tar.bz2]] | _none_|||| +[[xf86-input-microtouch|http://cgit.freedesktop.org/xorg/driver/xf86-input-microtouch/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-microtouch-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-microtouch-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-microtouch-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-microtouch-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-mouse|http://cgit.freedesktop.org/xorg/driver/xf86-input-mouse/]] | driver | [[1.0.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.0.3.1.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.1.0.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.1.2.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.2.2.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.3.0.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.5.0.tar.bz2]] | [[1.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.6.0.tar.bz2]] | [[1.7.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mouse-1.7.2.tar.bz2]] +[[xf86-input-mutouch|http://cgit.freedesktop.org/xorg/driver/xf86-input-mutouch/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mutouch-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mutouch-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mutouch-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-mutouch-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-palmax|http://cgit.freedesktop.org/xorg/driver/xf86-input-palmax/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-palmax-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-palmax-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-palmax-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-palmax-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-penmount|http://cgit.freedesktop.org/xorg/driver/xf86-input-penmount/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-penmount-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-penmount-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-penmount-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-penmount-1.2.0.tar.bz2]] | _none_|||| +[[xf86-input-spaceorb|http://cgit.freedesktop.org/xorg/driver/xf86-input-spaceorb/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-spaceorb-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-spaceorb-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-spaceorb-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-spaceorb-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-summa|http://cgit.freedesktop.org/xorg/driver/xf86-input-summa/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-summa-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-summa-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-summa-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-summa-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-synaptics|http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/]] | driver | _none_|||| | [[0.15.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-synaptics-0.15.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-synaptics-1.2.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-synaptics-1.3.0.tar.bz2]] | [[1.6.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-synaptics-1.6.1.tar.bz2]] +[[xf86-input-tek4957|http://cgit.freedesktop.org/xorg/driver/xf86-input-tek4957/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-tek4957-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-tek4957-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-tek4957-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-tek4957-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-ur98|http://cgit.freedesktop.org/xorg/driver/xf86-input-ur98/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-ur98-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-ur98-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-ur98-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-ur98-1.1.0.tar.bz2]] | _none_|||| +[[xf86-input-vmmouse|http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/]] | driver | _none_ | [[12.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.4.0.tar.bz2]] | [[12.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.4.0.tar.bz2]] | [[12.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.4.1.tar.bz2]] | [[12.5.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.5.1.tar.bz2]] | [[12.6.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.5.tar.bz2]] | [[12.6.10|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.6.10.tar.bz2]] | [[12.8.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.8.0.tar.bz2]] +[[xf86-input-void|http://cgit.freedesktop.org/xorg/driver/xf86-input-void/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.1.1.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.3.0.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.3.1.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-input-void-1.4.0.tar.bz2]] +[[xf86-video-apm|http://cgit.freedesktop.org/xorg/driver/xf86-video-apm/]] | driver | [[1.0.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.0.1.5.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.2.0.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.2.2.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-apm-1.2.3.tar.bz2]] | _none_ +[[xf86-video-ark|http://cgit.freedesktop.org/xorg/driver/xf86-video-ark/]] | driver | [[0.5.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.5.0.5.tar.bz2]] | [[0.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.6.0.tar.bz2]] | [[0.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.6.0.tar.bz2]] | [[0.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.6.0.tar.bz2]] | [[0.7.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.7.0.tar.bz2]] | [[0.7.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.7.2.tar.bz2]] | [[0.7.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.7.3.tar.bz2]] | [[0.7.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ark-0.7.4.tar.bz2]] +[[xf86-video-ast|http://cgit.freedesktop.org/xorg/driver/xf86-video-ast/]] | driver | _none_ | [[0.81.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.81.0.tar.bz2]] | [[0.81.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.81.0.tar.bz2]] | [[0.81.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.81.0.tar.bz2]] | [[0.85.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.85.0.tar.bz2]] | [[0.89.9|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.89.9.tar.bz2]] | [[0.91.10|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.91.10.tar.bz2]] | [[0.93.10|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ast-0.93.10.tar.bz2]] +[[xf86-video-ati|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]] | driver | [[6.5.7.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.5.7.3.tar.bz2]] | [[6.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.6.0.tar.bz2]] | [[6.6.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.6.3.tar.bz2]] | [[6.6.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.6.3.tar.bz2]] | [[6.9.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.9.0.tar.bz2]] | [[6.12.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.12.4.tar.bz2]] | [[6.13.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.13.2.tar.bz2]] | [[6.14.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.14.4.tar.bz2]] +[[xf86-video-chips|http://cgit.freedesktop.org/xorg/driver/xf86-video-chips/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.0.1.3.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.2.0.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.2.2.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-chips-1.2.3.tar.bz2]] | _none_ +[[xf86-video-cirrus|http://cgit.freedesktop.org/xorg/driver/xf86-video-cirrus/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.1.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.2.1.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.3.2.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.3.2.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cirrus-1.4.0.tar.bz2]] +[[xf86-video-cyrix|http://cgit.freedesktop.org/xorg/driver/xf86-video-cyrix/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cyrix-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cyrix-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cyrix-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-cyrix-1.1.0.tar.bz2]] | _none_|||| +[[xf86-video-dummy|http://cgit.freedesktop.org/xorg/driver/xf86-video-dummy/]] | driver | [[0.1.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.1.0.5.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.2.0.tar.bz2]] | [[0.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.3.0.tar.bz2]] | [[0.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.3.2.tar.bz2]] | [[0.3.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.3.4.tar.bz2]] | [[0.3.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-dummy-0.3.5.tar.bz2]] +[[xf86-video-fbdev|http://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/]] | driver | [[0.1.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.1.0.5.tar.bz2]] | [[0.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.3.0.tar.bz2]] | [[0.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.3.1.tar.bz2]] | [[0.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.3.1.tar.bz2]] | [[0.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.4.0.tar.bz2]] | [[0.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.4.1.tar.bz2]] | [[0.4.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.4.2.tar.bz2]] | [[0.4.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-fbdev-0.4.2.tar.bz2]] +[[xf86-video-geode|http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/]] | driver | _none_|||| | [[2.10.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-geode-2.10.1.tar.bz2]] | [[2.11.6|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-geode-2.11.6.tar.bz2]] | [[2.11.10|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-geode-2.11.10.tar.bz2]] | [[2.11.13|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-geode-2.11.13.tar.bz2]] +[[xf86-video-glide|http://cgit.freedesktop.org/xorg/driver/xf86-video-glide/]] | driver | _none_||| | [[1.0.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glide-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glide-1.0.1.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glide-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glide-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glide-1.2.0.tar.bz2]] +[[xf86-video-glint|http://cgit.freedesktop.org/xorg/driver/xf86-video-glint/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.0.1.3.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.1.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.2.1.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.2.4.tar.bz2]] | [[1.2.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.2.5.tar.bz2]] | [[1.2.7|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-glint-1.2.7.tar.bz2]] +[[xf86-video-i128|http://cgit.freedesktop.org/xorg/driver/xf86-video-i128/]] | driver | [[1.1.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.1.0.5.tar.bz2]] | [[1.1.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.1.0.5.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.2.1.tar.bz2]] | [[1.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.3.1.tar.bz2]] | [[1.3.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.3.3.tar.bz2]] | [[1.3.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.3.4.tar.bz2]] | [[1.3.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i128-1.3.5.tar.bz2]] +[[xf86-video-i740|http://cgit.freedesktop.org/xorg/driver/xf86-video-i740/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.2.0.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.3.2.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i740-1.3.2.tar.bz2]] | _none_ +[[xf86-video-i810|http://cgit.freedesktop.org/xorg/driver/xf86-video-i810/]] | driver | [[1.4.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i810-1.4.1.3.tar.bz2]] | [[1.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i810-1.6.0.tar.bz2]] | [[1.7.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i810-1.7.4.tar.bz2]] | [[1.7.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-i810-1.7.4.tar.bz2]] | _none_|||| +[[xf86-video-impact|http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/]] | driver | _none_|| | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-impact-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-impact-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-impact-0.2.0.tar.bz2]] | _none_||| +[[xf86-video-imstt|http://cgit.freedesktop.org/xorg/driver/xf86-video-imstt/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-imstt-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-imstt-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-imstt-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-imstt-1.1.0.tar.bz2]] | _none_|||| +[[xf86-video-intel|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/]] | driver | _none_||| | [[2.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-intel-2.1.1.tar.bz2]] | [[2.4.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-intel-2.4.2.tar.bz2]] | [[2.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-intel-2.9.1.tar.bz2]] | [[2.13.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-intel-2.13.0.tar.bz2]] | [[2.19.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-intel-2.19.0.tar.bz2]] +[[xf86-video-mach64|http://cgit.freedesktop.org/xorg/driver/xf86-video-mach64/]] | driver | _none_|||| | [[6.8.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mach64-6.8.0.tar.bz2]] | [[6.8.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mach64-6.8.2.tar.bz2]] | [[6.8.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mach64-6.8.2.tar.bz2]] | [[6.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mach64-6.9.1.tar.bz2]] +[[xf86-video-mga|http://cgit.freedesktop.org/xorg/driver/xf86-video-mga/]] | driver | [[1.2.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.2.1.3.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.1.tar.bz2]] | [[1.4.6|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.6.tar.bz2]] | [[1.4.6|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.6.tar.bz2]] | [[1.4.9|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.9.tar.bz2]] | [[1.4.11|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.11.tar.bz2]] | [[1.4.13|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.4.13.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-mga-1.5.0.tar.bz2]] +[[xf86-video-neomagic|http://cgit.freedesktop.org/xorg/driver/xf86-video-neomagic/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.0.0.5.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.1.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.2.1.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.2.4.tar.bz2]] | [[1.2.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.2.5.tar.bz2]] | [[1.2.6|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-neomagic-1.2.6.tar.bz2]] +[[xf86-video-newport|http://cgit.freedesktop.org/xorg/driver/xf86-video-newport/]] | driver | [[0.1.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.1.4.1.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.0.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.1.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.1.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.1.tar.bz2]] | [[0.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.3.tar.bz2]] | [[0.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.3.tar.bz2]] | [[0.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-newport-0.2.4.tar.bz2]] +[[xf86-video-nsc|http://cgit.freedesktop.org/xorg/driver/xf86-video-nsc/]] | driver | [[2.7.6.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nsc-2.7.6.5.tar.bz2]] | [[2.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nsc-2.8.1.tar.bz2]] | [[2.8.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nsc-2.8.2.tar.bz2]] | [[2.8.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nsc-2.8.3.tar.bz2]] | _none_|||| +[[xf86-video-nv|http://cgit.freedesktop.org/xorg/driver/xf86-video-nv/]] | driver | [[1.0.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-1.0.1.5.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-1.1.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-1.2.2.tar.bz2]] | [[2.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-2.1.3.tar.bz2]] | [[2.1.12|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-2.1.12.tar.bz2]] | [[2.1.15|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-2.1.15.tar.bz2]] | [[2.1.18|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-2.1.18.tar.bz2]] | [[2.1.18|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-nv-2.1.18.tar.bz2]] +[[xf86-video-openchrome|http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/]] | driver | _none_|||| | [[0.2.903|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-openchrome-0.2.903.tar.bz2]] | [[0.2.904|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-openchrome-0.2.904.tar.bz2]] | [[0.2.904|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-openchrome-0.2.904.tar.bz2]] | [[0.2.906|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-openchrome-0.2.906.tar.bz2]] +[[xf86-video-r128|http://cgit.freedesktop.org/xorg/driver/xf86-video-r128/]] | driver | _none_|||| | [[6.8.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-r128-6.8.0.tar.bz2]] | [[6.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-r128-6.8.1.tar.bz2]] | [[6.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-r128-6.8.1.tar.bz2]] | [[6.8.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-r128-6.8.2.tar.bz2]] +[[xf86-video-rendition|http://cgit.freedesktop.org/xorg/driver/xf86-video-rendition/]] | driver | [[4.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.0.1.3.tar.bz2]] | [[4.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.1.0.tar.bz2]] | [[4.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.1.3.tar.bz2]] | [[4.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.1.3.tar.bz2]] | [[4.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.2.0.tar.bz2]] | [[4.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.2.3.tar.bz2]] | [[4.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-rendition-4.2.4.tar.bz2]] | _none_ +[[xf86-video-s3|http://cgit.freedesktop.org/xorg/driver/xf86-video-s3/]] | driver | [[0.3.5.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.3.5.5.tar.bz2]] | [[0.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.4.1.tar.bz2]] | [[0.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.5.0.tar.bz2]] | [[0.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.5.0.tar.bz2]] | [[0.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.6.0.tar.bz2]] | [[0.6.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.6.3.tar.bz2]] | [[0.6.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3-0.6.3.tar.bz2]] | _none_ +[[xf86-video-s3virge|http://cgit.freedesktop.org/xorg/driver/xf86-video-s3virge/]] | driver | [[1.8.6.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.8.6.5.tar.bz2]] | [[1.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.9.1.tar.bz2]] | [[1.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.9.1.tar.bz2]] | [[1.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.9.1.tar.bz2]] | [[1.10.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.10.1.tar.bz2]] | [[1.10.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.10.4.tar.bz2]] | [[1.10.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-s3virge-1.10.4.tar.bz2]] | _none_ +[[xf86-video-savage|http://cgit.freedesktop.org/xorg/driver/xf86-video-savage/]] | driver | [[2.0.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.0.2.3.tar.bz2]] | [[2.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.1.1.tar.bz2]] | [[2.1.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.1.2.tar.bz2]] | [[2.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.1.3.tar.bz2]] | [[2.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.2.1.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.3.1.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.3.1.tar.bz2]] | [[2.3.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-savage-2.3.4.tar.bz2]] +[[xf86-video-siliconmotion|http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/]] | driver | [[1.3.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.3.1.5.tar.bz2]] | [[1.4.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.4.1.tar.bz2]] | [[1.4.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.4.2.tar.bz2]] | [[1.4.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.4.2.tar.bz2]] | [[1.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.6.0.tar.bz2]] | [[1.7.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.7.3.tar.bz2]] | [[1.7.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.7.4.tar.bz2]] | [[1.7.6|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-siliconmotion-1.7.6.tar.bz2]] +[[xf86-video-sis|http://cgit.freedesktop.org/xorg/driver/xf86-video-sis/]] | driver | [[0.8.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.8.1.3.tar.bz2]] | [[0.9.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.9.1.tar.bz2]] | [[0.9.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.9.3.tar.bz2]] | [[0.9.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.9.3.tar.bz2]] | [[0.10.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.10.0.tar.bz2]] | [[0.10.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.10.2.tar.bz2]] | [[0.10.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.10.3.tar.bz2]] | [[0.10.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sis-0.10.4.tar.bz2]] +[[xf86-video-sisusb|http://cgit.freedesktop.org/xorg/driver/xf86-video-sisusb/]] | driver | [[0.7.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.7.1.3.tar.bz2]] | [[0.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.8.1.tar.bz2]] | [[0.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.8.1.tar.bz2]] | [[0.8.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.8.1.tar.bz2]] | [[0.9.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.9.0.tar.bz2]] | [[0.9.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.9.3.tar.bz2]] | [[0.9.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sisusb-0.9.4.tar.bz2]] | _none_ +[[xf86-video-sunbw2|http://cgit.freedesktop.org/xorg/driver/xf86-video-sunbw2/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunbw2-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunbw2-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunbw2-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunbw2-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunbw2-1.1.0.tar.bz2]] | _none_||| +[[xf86-video-suncg14|http://cgit.freedesktop.org/xorg/driver/xf86-video-suncg14/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg14-1.1.1.tar.bz2]] | _none_ +[[xf86-video-suncg3|http://cgit.freedesktop.org/xorg/driver/xf86-video-suncg3/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg3-1.1.1.tar.bz2]] | _none_ +[[xf86-video-suncg6|http://cgit.freedesktop.org/xorg/driver/xf86-video-suncg6/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suncg6-1.1.1.tar.bz2]] +[[xf86-video-sunffb|http://cgit.freedesktop.org/xorg/driver/xf86-video-sunffb/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.0.1.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunffb-1.2.1.tar.bz2]] +[[xf86-video-sunleo|http://cgit.freedesktop.org/xorg/driver/xf86-video-sunleo/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-sunleo-1.2.0.tar.bz2]] | _none_ +[[xf86-video-suntcx|http://cgit.freedesktop.org/xorg/driver/xf86-video-suntcx/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-suntcx-1.1.1.tar.bz2]] | _none_ +[[xf86-video-tdfx|http://cgit.freedesktop.org/xorg/driver/xf86-video-tdfx/]] | driver | [[1.1.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.1.1.3.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.2.1.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.3.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.3.0.tar.bz2]] | [[1.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.4.0.tar.bz2]] | [[1.4.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.4.3.tar.bz2]] | [[1.4.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.4.3.tar.bz2]] | [[1.4.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tdfx-1.4.4.tar.bz2]] +[[xf86-video-tga|http://cgit.freedesktop.org/xorg/driver/xf86-video-tga/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.2.1.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tga-1.2.1.tar.bz2]] +[[xf86-video-trident|http://cgit.freedesktop.org/xorg/driver/xf86-video-trident/]] | driver | [[1.0.1.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.0.1.2.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.2.1.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.2.3.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.2.3.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.3.0.tar.bz2]] | [[1.3.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.3.3.tar.bz2]] | [[1.3.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.3.4.tar.bz2]] | [[1.3.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-trident-1.3.5.tar.bz2]] +[[xf86-video-tseng|http://cgit.freedesktop.org/xorg/driver/xf86-video-tseng/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.2.0.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.2.3.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-tseng-1.2.4.tar.bz2]] | _none_ +[[xf86-video-v4l|http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/]] | driver | [[0.0.1.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.0.1.5.tar.bz2]] | [[0.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.1.1.tar.bz2]] | [[0.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.1.1.tar.bz2]] | [[0.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.1.1.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.2.0.tar.bz2]] | [[0.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-v4l-0.2.0.tar.bz2]] +[[xf86-video-vermilion|http://cgit.freedesktop.org/xorg/driver/xf86-video-vermilion/]] | driver | _none_||| | [[1.0.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vermilion-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vermilion-1.0.1.tar.bz2]] | _none_||| +[[xf86-video-vesa|http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/]] | driver | [[1.0.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-1.0.1.3.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-1.2.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-1.3.0.tar.bz2]] | [[1.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-1.3.0.tar.bz2]] | [[2.0.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-2.0.0.tar.bz2]] | [[2.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-2.2.1.tar.bz2]] | [[2.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-2.3.0.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vesa-2.3.1.tar.bz2]] +[[xf86-video-vga|http://cgit.freedesktop.org/xorg/driver/xf86-video-vga/]] | driver | [[4.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vga-4.0.0.5.tar.bz2]] | [[4.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vga-4.1.0.tar.bz2]] | [[4.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vga-4.1.0.tar.bz2]] | [[4.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vga-4.1.0.tar.bz2]] | _none_|||| +[[xf86-video-via|http://cgit.freedesktop.org/xorg/driver/xf86-video-via/]] | driver | [[0.1.33.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-via-0.1.33.2.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-via-0.2.1.tar.bz2]] | [[0.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-via-0.2.2.tar.bz2]] | [[0.2.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-via-0.2.2.tar.bz2]] | _none_|||| +[[xf86-video-vmware|http://cgit.freedesktop.org/xorg/driver/xf86-video-vmware/]] | driver | [[10.11.1.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.11.1.3.tar.bz2]] | [[10.13.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.13.0.tar.bz2]] | [[10.14.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.14.1.tar.bz2]] | [[10.14.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.14.1.tar.bz2]] | [[10.16.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.16.5.tar.bz2]] | [[10.16.8|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-10.16.8.tar.bz2]] | [[11.0.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-11.0.3.tar.bz2]] | [[12.0.2|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-vmware-12.0.2.tar.bz2]] +[[xf86-video-voodoo|http://cgit.freedesktop.org/xorg/driver/xf86-video-voodoo/]] | driver | [[1.0.0.5|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.0.0.5.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.2.0.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.2.3.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.2.4.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-voodoo-1.2.4.tar.bz2]] +[[xf86-video-wsfb|http://cgit.freedesktop.org/xorg/driver/xf86-video-wsfb/]] | driver | _none_|| | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.2.1.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.2.1.tar.bz2]] | [[0.2.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.2.1.tar.bz2]] | [[0.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.3.0.tar.bz2]] | [[0.3.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.3.0.tar.bz2]] | [[0.4.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-wsfb-0.4.0.tar.bz2]] +[[xf86-video-xgi|http://cgit.freedesktop.org/xorg/driver/xf86-video-xgi/]] | driver | _none_|||| | [[1.5.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgi-1.5.0.tar.bz2]] | [[1.5.1|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgi-1.5.1.tar.bz2]] | [[1.6.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgi-1.6.0.tar.bz2]] | _none_ +[[xf86-video-xgixp|http://cgit.freedesktop.org/xorg/driver/xf86-video-xgixp/]] | driver | _none_|||| | [[1.7.99.3|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgixp-1.7.99.3.tar.bz2]] | [[1.7.99.4|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgixp-1.7.99.4.tar.bz2]] | [[1.8.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-xgixp-1.8.0.tar.bz2]] | _none_ +[[xf86bigfontproto|http://cgit.freedesktop.org/xorg/proto/xf86bigfontproto/]] | proto | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.1.2.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/proto/xf86bigfontproto-1.2.0.tar.bz2]] +[[xf86dga|http://cgit.freedesktop.org/xorg/app/xf86dga/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xf86dga-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xf86dga-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xf86dga-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xf86dga-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xf86dga-1.0.2.tar.bz2]] | _none_||| +[[xf86dgaproto|http://cgit.freedesktop.org/xorg/proto/xf86dgaproto/]] | proto | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.0.2.tar.bz2]] | [[2.0.2|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.0.2.tar.bz2]] | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.0.3.tar.bz2]] | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.0.3.tar.bz2]] | [[2.1|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.1.tar.bz2]] | [[2.1|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.1.tar.bz2]] | [[2.1|http://xorg.freedesktop.org/releases/individual/proto/xf86dgaproto-2.1.tar.bz2]] +[[xf86driproto|http://cgit.freedesktop.org/xorg/proto/xf86driproto/]] | proto | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.0.3.tar.bz2]] | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.0.3.tar.bz2]] | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.0.3.tar.bz2]] | [[2.0.3|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.0.3.tar.bz2]] | [[2.0.4|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.0.4.tar.bz2]] | [[2.1.0|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.1.0.tar.bz2]] | [[2.1.0|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.1.0.tar.bz2]] | [[2.1.1|http://xorg.freedesktop.org/releases/individual/proto/xf86driproto-2.1.1.tar.bz2]] +[[xf86miscproto|http://cgit.freedesktop.org/xorg/proto/xf86miscproto/]] | proto | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/xf86miscproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/xf86miscproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/xf86miscproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/xf86miscproto-0.9.2.tar.bz2]] | [[0.9.2|http://xorg.freedesktop.org/releases/individual/proto/xf86miscproto-0.9.2.tar.bz2]] | _none_||| +[[xf86rushproto|http://cgit.freedesktop.org/xorg/proto/xf86rushproto/]] | proto | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86rushproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86rushproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86rushproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xf86rushproto-1.1.2.tar.bz2]] | _none_|||| +[[xf86vidmodeproto|http://cgit.freedesktop.org/xorg/proto/xf86vidmodeproto/]] | proto | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.2.2.tar.bz2]] | [[2.2.2|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.2.2.tar.bz2]] | [[2.3|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.3.tar.bz2]] | [[2.3|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.3.tar.bz2]] | [[2.3.1|http://xorg.freedesktop.org/releases/individual/proto/xf86vidmodeproto-2.3.1.tar.bz2]] +[[xfd|http://cgit.freedesktop.org/xorg/app/xfd/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfd-1.0.1.tar.bz2]] | _none_|||| +[[xfindproxy|http://cgit.freedesktop.org/xorg/app/xfindproxy/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfindproxy-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfindproxy-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfindproxy-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfindproxy-1.0.1.tar.bz2]] | _none_|||| +[[xfontsel|http://cgit.freedesktop.org/xorg/app/xfontsel/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfontsel-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfontsel-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xfontsel-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xfontsel-1.0.2.tar.bz2]] | _none_|||| +[[xfs|http://cgit.freedesktop.org/xorg/app/xfs/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfs-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xfs-1.0.2.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xfs-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xfs-1.0.4.tar.bz2]] | _none_|||| +[[xfsinfo|http://cgit.freedesktop.org/xorg/app/xfsinfo/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfsinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfsinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfsinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfsinfo-1.0.1.tar.bz2]] | _none_|||| +[[xfwp|http://cgit.freedesktop.org/xorg/app/xfwp/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfwp-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfwp-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfwp-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xfwp-1.0.1.tar.bz2]] | _none_|||| +[[xgamma|http://cgit.freedesktop.org/xorg/app/xgamma/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xgamma-1.0.5.tar.bz2]] +[[xgc|http://cgit.freedesktop.org/xorg/app/xgc/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgc-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xgc-1.0.1.tar.bz2]] | _none_|||| +[[xhost|http://cgit.freedesktop.org/xorg/app/xhost/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xhost-1.0.5.tar.bz2]] +[[xineramaproto|http://cgit.freedesktop.org/xorg/proto/xineramaproto/]] | proto | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.1.2.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.1.2.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.2.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.2.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/proto/xineramaproto-1.2.1.tar.bz2]] +[[xinit|http://cgit.freedesktop.org/xorg/app/xinit/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xinit-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xinit-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xinit-1.0.3.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xinit-1.0.5.tar.bz2]] | _none_|||| +[[xinput|http://cgit.freedesktop.org/xorg/app/xinput/]] | app | _none_|||| | [[1.3.0|http://xorg.freedesktop.org/releases/individual/app/xinput-1.3.0.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/app/xinput-1.5.0.tar.bz2]] | [[1.5.3|http://xorg.freedesktop.org/releases/individual/app/xinput-1.5.3.tar.bz2]] | [[1.6.0|http://xorg.freedesktop.org/releases/individual/app/xinput-1.6.0.tar.bz2]] +[[xkbcomp|http://cgit.freedesktop.org/xorg/app/xkbcomp/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.0.3.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.0.5.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.1.1.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.2.0.tar.bz2]] | [[1.2.4|http://xorg.freedesktop.org/releases/individual/app/xkbcomp-1.2.4.tar.bz2]] +[[xkbdata|http://cgit.freedesktop.org/xorg/data/xkbdata/]] | data | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xkbdata-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xkbdata-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xkbdata-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/data/xkbdata-1.0.1.tar.bz2]] | _none_|||| +[[xkbevd|http://cgit.freedesktop.org/xorg/app/xkbevd/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.1.0.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.1.2.tar.bz2]] | [[1.1.3|http://xorg.freedesktop.org/releases/individual/app/xkbevd-1.1.3.tar.bz2]] +[[xkbprint|http://cgit.freedesktop.org/xorg/app/xkbprint/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbprint-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbprint-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbprint-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbprint-1.0.1.tar.bz2]] | _none_|||| +[[xkbutils|http://cgit.freedesktop.org/xorg/app/xkbutils/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkbutils-1.0.3.tar.bz2]] +[[xkeyboard-config|http://cgit.freedesktop.org/xkeyboard-config/]] | data | _none_||||||| | [[2.6|http://xorg.freedesktop.org/releases/individual/data/xkeyboard-config//xkeyboard-config-2.6.tar.bz2]] +[[xkill|http://cgit.freedesktop.org/xorg/app/xkill/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xkill-1.0.3.tar.bz2]] +[[xload|http://cgit.freedesktop.org/xorg/app/xload/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xload-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xload-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xload-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xload-1.0.2.tar.bz2]] | _none_|||| +[[xlogo|http://cgit.freedesktop.org/xorg/app/xlogo/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlogo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlogo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlogo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlogo-1.0.1.tar.bz2]] | _none_|||| +[[xlsatoms|http://cgit.freedesktop.org/xorg/app/xlsatoms/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xlsatoms-1.1.1.tar.bz2]] +[[xlsclients|http://cgit.freedesktop.org/xorg/app/xlsclients/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.0.2.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/app/xlsclients-1.1.2.tar.bz2]] +[[xlsfonts|http://cgit.freedesktop.org/xorg/app/xlsfonts/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsfonts-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xlsfonts-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xlsfonts-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xlsfonts-1.0.2.tar.bz2]] | _none_|||| +[[xmag|http://cgit.freedesktop.org/xorg/app/xmag/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmag-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmag-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmag-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xmag-1.0.2.tar.bz2]] | _none_|||| +[[xman|http://cgit.freedesktop.org/xorg/app/xman/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xman-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xman-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xman-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xman-1.0.3.tar.bz2]] | _none_|||| +[[xmessage|http://cgit.freedesktop.org/xorg/app/xmessage/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmessage-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmessage-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmessage-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xmessage-1.0.2.tar.bz2]] | _none_|||| +[[xmh|http://cgit.freedesktop.org/xorg/app/xmh/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmh-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmh-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmh-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmh-1.0.1.tar.bz2]] | _none_|||| +[[xmodmap|http://cgit.freedesktop.org/xorg/app/xmodmap/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.5.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/xmodmap-1.0.7.tar.bz2]] +[[xmore|http://cgit.freedesktop.org/xorg/app/xmore/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmore-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmore-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmore-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xmore-1.0.1.tar.bz2]] | _none_|||| +[[xorg-cf-files|http://cgit.freedesktop.org/xorg/util/xorg-cf-files/]] | util | [[1.0.1|http://xorg.freedesktop.org/releases/individual/util/xorg-cf-files-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/xorg-cf-files-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/xorg-cf-files-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/util/xorg-cf-files-1.0.2.tar.bz2]] | _none_|||| +[[xorg-docs|http://cgit.freedesktop.org/xorg/doc/xorg-docs/]] | doc | [[1.0.1|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.0.1.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.2.tar.bz2]] | [[1.3|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.3.tar.bz2]] | [[1.4|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.4.tar.bz2]] | [[1.4|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.4.tar.bz2]] | [[1.5|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.5.tar.bz2]] | [[1.6|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.6.tar.bz2]] | [[1.7|http://xorg.freedesktop.org/releases/individual/doc/xorg-docs-1.7.tar.bz2]] +[[xorg-server|http://cgit.freedesktop.org/xorg/xserver/]] | xserver | [[1.0.1|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.0.1.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.2.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.2.0.tar.bz2]] | [[1.5.0|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.5.0.tar.bz2]] | [[1.7.1|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.7.1.tar.bz2]] | [[1.9.3|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.9.3.tar.bz2]] | [[1.12.2|http://xorg.freedesktop.org/releases/individual/xserver/xorg-server-1.12.2.tar.bz2]] +[[xorg-sgml-doctools|http://cgit.freedesktop.org/xorg/doc/xorg-sgml-doctools/]] | doc | [[1.0.1|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.0.1.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.1.tar.bz2]] | [[1.1|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.1.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.2.tar.bz2]] | [[1.2|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.2.tar.bz2]] | [[1.3|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.3.tar.bz2]] | [[1.6|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.6.tar.bz2]] | [[1.11|http://xorg.freedesktop.org/releases/individual/doc/xorg-sgml-doctools-1.11.tar.bz2]] +[[xphelloworld|http://cgit.freedesktop.org/xorg/app/xphelloworld/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xphelloworld-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xphelloworld-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xphelloworld-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xphelloworld-1.0.1.tar.bz2]] | _none_|||| +[[xplsprinters|http://cgit.freedesktop.org/xorg/app/xplsprinters/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xplsprinters-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xplsprinters-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xplsprinters-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xplsprinters-1.0.1.tar.bz2]] | _none_|||| +[[xpr|http://cgit.freedesktop.org/xorg/app/xpr/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.3.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xpr-1.0.4.tar.bz2]] +[[xprehashprinterlist|http://cgit.freedesktop.org/xorg/app/xprehashprinterlist/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprehashprinterlist-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprehashprinterlist-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprehashprinterlist-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprehashprinterlist-1.0.1.tar.bz2]] | _none_|||| +[[xprop|http://cgit.freedesktop.org/xorg/app/xprop/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprop-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xprop-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xprop-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xprop-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xprop-1.0.4.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xprop-1.1.0.tar.bz2]] | [[1.2.0|http://xorg.freedesktop.org/releases/individual/app/xprop-1.2.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/app/xprop-1.2.1.tar.bz2]] +[[xproto|http://cgit.freedesktop.org/xorg/proto/x11proto/]] | proto | [[7.0.4|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.4.tar.bz2]] | [[7.0.5|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.5.tar.bz2]] | [[7.0.10|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.10.tar.bz2]] | [[7.0.10|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.10.tar.bz2]] | [[7.0.13|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.13.tar.bz2]] | [[7.0.16|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.16.tar.bz2]] | [[7.0.20|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.20.tar.bz2]] | [[7.0.23|http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.23.tar.bz2]] +[[xproxymanagementprotocol|http://cgit.freedesktop.org/xorg/proto/pmproto/]] | proto | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/xproxymanagementprotocol-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/xproxymanagementprotocol-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/xproxymanagementprotocol-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/proto/xproxymanagementprotocol-1.0.2.tar.bz2]] | _none_|||| +[[xrandr|http://cgit.freedesktop.org/xorg/app/xrandr/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.0.2.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.2.2.tar.bz2]] | [[1.2.3|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.2.3.tar.bz2]] | [[1.3.2|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.3.2.tar.bz2]] | [[1.3.4|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.3.4.tar.bz2]] | [[1.3.5|http://xorg.freedesktop.org/releases/individual/app/xrandr-1.3.5.tar.bz2]] +[[xrdb|http://cgit.freedesktop.org/xorg/app/xrdb/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.5.tar.bz2]] | [[1.0.6|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.6.tar.bz2]] | [[1.0.7|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.7.tar.bz2]] | [[1.0.9|http://xorg.freedesktop.org/releases/individual/app/xrdb-1.0.9.tar.bz2]] +[[xrefresh|http://cgit.freedesktop.org/xorg/app/xrefresh/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.4.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xrefresh-1.0.4.tar.bz2]] +[[xrx|http://cgit.freedesktop.org/xorg/app/xrx/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrx-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrx-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrx-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xrx-1.0.1.tar.bz2]] | _none_|||| +[[xset|http://cgit.freedesktop.org/xorg/app/xset/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xset-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xset-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xset-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xset-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xset-1.0.4.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xset-1.1.0.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/app/xset-1.2.1.tar.bz2]] | [[1.2.2|http://xorg.freedesktop.org/releases/individual/app/xset-1.2.2.tar.bz2]] +[[xsetmode|http://cgit.freedesktop.org/xorg/app/xsetmode/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetmode-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetmode-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetmode-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetmode-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetmode-1.0.0.tar.bz2]] | _none_||| +[[xsetpointer|http://cgit.freedesktop.org/xorg/app/xsetpointer/]] | app | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetpointer-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/app/xsetpointer-1.0.0.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsetpointer-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsetpointer-1.0.1.tar.bz2]] | _none_|||| +[[xsetroot|http://cgit.freedesktop.org/xorg/app/xsetroot/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.0.3.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.1.0.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xsetroot-1.1.0.tar.bz2]] +[[xsm|http://cgit.freedesktop.org/xorg/app/xsm/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsm-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xsm-1.0.1.tar.bz2]] | _none_|||| +[[xstdcmap|http://cgit.freedesktop.org/xorg/app/xstdcmap/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xstdcmap-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xstdcmap-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xstdcmap-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xstdcmap-1.0.1.tar.bz2]] | _none_|||| +[[xtrans|http://cgit.freedesktop.org/xorg/lib/xtrans/]] | lib | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.0.tar.bz2]] | [[1.0.0|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.0.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.0.4.tar.bz2]] | [[1.2.1|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.2.1.tar.bz2]] | [[1.2.5|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.2.5.tar.bz2]] | [[1.2.6|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.2.6.tar.bz2]] | [[1.2.7|http://xorg.freedesktop.org/releases/individual/lib/xtrans-1.2.7.tar.bz2]] +[[xtrap|http://cgit.freedesktop.org/xorg/app/xtrap/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xtrap-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xtrap-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xtrap-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xtrap-1.0.2.tar.bz2]] | _none_|||| +[[xvidtune|http://cgit.freedesktop.org/xorg/app/xvidtune/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvidtune-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvidtune-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvidtune-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvidtune-1.0.1.tar.bz2]] | _none_|||| +[[xvinfo|http://cgit.freedesktop.org/xorg/app/xvinfo/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.0.2.tar.bz2]] | [[1.1.0|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.1.0.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.1.1.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xvinfo-1.1.1.tar.bz2]] +[[xwd|http://cgit.freedesktop.org/xorg/app/xwd/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xwd-1.0.5.tar.bz2]] +[[xwininfo|http://cgit.freedesktop.org/xorg/app/xwininfo/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.2.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.4.tar.bz2]] | [[1.0.5|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.0.5.tar.bz2]] | [[1.1.1|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.1.1.tar.bz2]] | [[1.1.2|http://xorg.freedesktop.org/releases/individual/app/xwininfo-1.1.2.tar.bz2]] +[[xwud|http://cgit.freedesktop.org/xorg/app/xwud/]] | app | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.1.tar.bz2]] | [[1.0.1|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.1.tar.bz2]] | [[1.0.2|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.2.tar.bz2]] | [[1.0.3|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.3.tar.bz2]] | [[1.0.4|http://xorg.freedesktop.org/releases/individual/app/xwud-1.0.4.tar.bz2]] +"""]] diff --git a/RepoPolicy.mdwn b/RepoPolicy.mdwn new file mode 100644 index 00000000..18442b66 --- /dev/null +++ b/RepoPolicy.mdwn @@ -0,0 +1,39 @@ + +X.Org currently keeps the source for its stuff in a [[GIT|http://www.freedesktop.org/wiki/Infrastructure/git]] repository. This page is one of several documents describing that repository. **Note: The xserver module follows a slightly different development model than outlined below. Some information below may not apply. Please read the [[XServer|XServer]] page for more detail.** + + +## Who can access the repository? + +* Anyone. See the users' GIT [[page|http://www.freedesktop.org/wiki/Infrastructure/git/Users]] for instructions about how to access the repository anonymously. + +## Who can get repository commit privileges? + +* Anyone can apply for commit privileges to the master repository. You should give a description of what you plan to do, or even better provide an initial set of patches you plan to apply. A sponsor from the current X.Org team is required before commit privileges can be granted. This sponsor needs to have some idea of your background and experience. You may be asked for a sample of code to judge the quality of your coding. Only people with serious projects and long term commitment get commit privileges. One-time-fix submissions should be done to the [[xorg-devel mailing list|http://lists.x.org/mailman/listinfo/xorg-devel]], or to the freedesktop.org [[Bugzilla|https://bugs.freedesktop.org/]], against the xorg product. + +## Is there something in between? + +* Thanks to GIT, yes, there is. GIT makes it quite straightforward for you to maintain your own repository of changes that tracks our master repository. You might host this repository on your own website, on a hosting site such as gitorious, or you might request an account at people.freedesktop.org. This makes it easy for folks with commit access to the master repository to incorporate your changes, and gives you a chance to establish a track record as a developer in a "safe" environment. We highly recommend that you initially do development this way. + +## ChangeLog + +* X.Org no longer uses manually maintained Change``Log files, but instead uses dist-hook entries in the top-level Makefile to generate Change``Log from git log output when tarballs are being generated. + +## Master Repository Commit Rules + +* Before being given commit priviliges on the master repository, you need to read and agree to the commit rules described in this section. + +### Who may commit what? + +* Committers are allowed to commit to master (where ongoing development takes place) only after review. Exceptions are obvious bug and typo fixes. Write access to other branches is controlled by the branch owner. The release manager is the owner of the release branch. + +### Use proper discretion + +* The general rule is (especially when committing to HEAD): only commit stuff you are certain about. If you don't understand a particular area and you think you need to commit a patch: *ASK*! There may be someone who can help you. In general, it's nice to post to the appropriate list describing the changes you've just made or would like to make. That increases the visibility of the change (potentially saving others lots of time) and gives others a chance to comment on and/or improve upon your modifications. Don't worry if you don't get any comments: it may be that your patch is perfect, so go ahead and check it in. If there's something wrong with it, you'll find out soon enough. Again, please note the different rules for [[the X server|XServer]]. + +### What should you do after the commit? + +* Committers are responsible for their own commits. They should be prepared to fix without delay problems their commit may create, or revert their changes. Ideally a committer would watch the [[tinderbox|http://tinderbox.freedesktop.org/]] to see if their changes caused any build breakages afterwards, though we currently need more machines in the tinderbox for it to be useful. + +### What if you screw up the repo? + +* Please email [[sitewranglers@freedesktop.org|mailto:sitewranglers@freedesktop.org]] *promptly* if you feel you may have corrupted the master GIT repository. This is not something you are likely to be able to fix yourself, and we'll need to tackle it *as soon as possible*. (The good news is that with GIT this is very difficult to do.) If you are unhappy with a patch sequence, and think the repo needs a rollback or rebase, please contact someone as soon as possible. These things are much easier the sooner they're tackled. In general, we will not disturb commits to the repository without a *very* good reason, so please be careful out there. People's commit privileges shall be revoked if they repeatedly violate these rules.
\ No newline at end of file diff --git a/RequiredPackages.mdwn b/RequiredPackages.mdwn new file mode 100644 index 00000000..66385a2e --- /dev/null +++ b/RequiredPackages.mdwn @@ -0,0 +1,199 @@ + +List of required packages to build the X server from git. [[!toc ]] + +(Please add your distribution if it is missing) + + +## Ubuntu + + +### Natty Narwhal 11.04 + +Swipe the following command to install all required packages. About 900MB of additional storage is required. +[[!format txt """ +sudo apt-get install asciidoc autoconf automake autotools-dev bison docbook-utils doxygen flex fop git-core gperf intltool jadetex libfontconfig1-dev libfreetype6-dev libglib2.0-dev libncurses5-dev libpng12-dev libssl-dev libtool llvm m4 netpbm psutils w3m xmlto zlib1g-dev +"""]] + +[[!format txt """ +asciidoc 8.6.3 +autoconf 2.67 +automake 1.11 +autotools-dev 20100122 +bison 2.4.1 +docbook-utils 0.6.14 +doxygen 1.7.3 +flex 2.5.35 +fontconfig 2.8.0 pre-installed +fop 0.95 +gcc 4.5.2 pre-installed +gettext 0.18.1 pre-installed +gettext-base 0.18.1 pre-installed +ghostscript 9.01 pre-installed +git-core 1.7.4 +gperf 3.0.3 +intltool 0.41.1 +jadetex 3.13 +libfontconfig1-dev 2.8.0 +libfreetype6 2.4.4 pre-installed +libfreetype6-dev 2.4.4 +libglib2.0-dev 2.28.6 +libncurses5-dev 5.7 +libpng12-0 1.2.44 pre-installed +libpng12-dev 1.2.44 +libssl-dev 0.9.8o +libtool 2.2.6b +llvm 2.8 +m4 1.4.14 +netpbm 10.0 +openssl 0.9.8o pre-installed +perl 5.10.1 pre-installed +pkg-config 0.25 pre-installed +psutils 1.17 +w3m 0.5.3 +xmlto 0.0.23 +zlib1g 1.2.3.4 pre-installed +zlib1g-dev 1.2.3.3 +"""]] + +### Oneiric Ocelot 11.10 + +Swipe the following command to install all required packages. About 900MB of additional storage is required. +[[!format txt """ +sudo apt-get install asciidoc autoconf automake autotools-dev bison docbook-utils doxygen flex fop git-core gperf intltool jadetex libdrm-dev libfontconfig1-dev libfreetype6-dev libglib2.0-dev libncurses5-dev libpng12-dev libssl-dev libtool libudev-dev llvm m4 netpbm psutils systemtap-sdt-dev w3m xmlto zlib1g-dev +"""]] + +[[!format txt """ +asciidoc 8.6.4 +autoconf 2.68 +automake 1.11.1 +autotools-dev 20110511 +bison 2.4.1 +docbook-utils 0.6.14 +doxygen 1.7.4 +flex 2.5.35 +fontconfig 2.8.0 pre-installed +fop 0.95 +gcc 4.6.1 pre-installed +gettext 0.18.1 pre-installed +gettext-base 0.18.1 pre-installed +ghostscript 9.04 pre-installed +git-core 1.7.5.4 +gperf 3.0.3 +intltool 0.41.1 +jadetex 3.13 +libfontconfig1-dev 2.8.0 +libfreetype6 2.4.4 pre-installed +libfreetype6-dev 2.4.4 +libglib2.0-dev 2.30.0 +libncurses5-dev 5.9 +libpng12-0 1.2.46 pre-installed +libpng12-dev 1.2.46 +libssl-dev 1.0.0e +libtool 2.4 +libudev-dev +llvm 2.8 +m4 1.4.16 +netpbm 10.0 +openssl 1.0.0e pre-installed +perl 5.12.4 pre-installed +pkg-config 0.26 pre-installed +psutils 1.17 +systemtap-sdt-dev 1.4 +w3m 0.5.3 +xmlto 0.0.23 +zlib1g 1.2.3.4 pre-installed +zlib1g-dev 1.2.3.4 +"""]] + +## Gentoo + + +### stage3-amd64-20100514.tar.bz2 + +Had to install: +[[!format txt """ +docbook-xml-dtd 4.1.2 +docbook-xml-dtd 4.3 +docbook-xml-dtd 4.4 +doxygen +gd (USE: jpeg png) +git +gperf +freetype +intltool +libxlst +lynx (or w3m) +pkgconfig +xmlto +"""]] + +## OpenSolaris + + +### 2009.06 + + +[[!format txt """ +There are multiple versions for aclocal, automake, and python. You need to create links to the latest version in $prefix/bin. +SUNWaconf 2.61 +SUNWgnu-automake-110 1.10 +SUNWbison 2.3 +SUNWgnome-xml 0.6.3 +SUNWdoxygen 1.5.7.1 +SUNWflexlex 2.5.33 +SUNWfontconfig 2.5.0 pre-installed +SUNWgcc 3.4.3 +gcc-dev 3.4.3 +SUNWgmake 3.81 +SUNWgnome-common-devel 0.5.11 +SUNWgnu-gettext 0.16.1 +SUNWgit 1.5.6.5 +SUNWgperf 3.0.3 +SUNWgroff 1.19.2 +SUNWncurses 0.5.11 +SUNWpng 0.5.11 +SUNWopenssl 0.9.8 pre-installed +SUNWlibtool 1.5.22 +SUNWgm4 1.4.2 +SUNWperl* 5.8.4 +SUNWPython26 2.6.1 +SUNWpython-lxml 2.1.2 +SUNWzlib 1.2.3 +"""]] + +## OpenBSD + +pkg_add the following packages +[[!format txt """ +automake-1.9 +autoconf-2.62 +libtool +metaauto +"""]] +_Packages needed to reformat docs need to be sorted out_... + +Set environment variables to point to the autotools version you're using + + +[[!format txt """ +PKG_CONFIG_LIBDIR=/usr/X11R6/lib/pkgconfig +AUTOMAKE_VERSION=1.9 +AUTOCONF_VERSION=2.62 +ACLOCAL="aclocal -I /usr/X11R6/share/aclocal" +"""]] + +## openSUSE + + +### 11.3 + +The `libtalloc-devel` package for openSUSE 11.3 is missing the required `talloc.pc` file to allow the _mesa_ build to complete successfully. There are two ways this can be fixed: + +1. defining environment variables which work with `pkg-config`: [[!format txt """ + $> export TALLOC_LIBS=-ltalloc + $> export TALLOC_CFLAGS="-I/usr/include" + $> build.sh -o mesa/mesa $PREFIX + +"""]] +1. installing a fixed, updated `libtalloc-devel` package. See [[https://bugzilla.novell.com/show_bug.cgi?id=632770|https://bugzilla.novell.com/show_bug.cgi?id=632770]] for details. +NOTE: openSUSE 11.2 also seems to have this problem diff --git a/RobClark.mdwn b/RobClark.mdwn new file mode 100644 index 00000000..28031c20 --- /dev/null +++ b/RobClark.mdwn @@ -0,0 +1,13 @@ + + +## Rob Clark + +Email: robclark AT SPAMFREE freedesktop DOT org + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/RomanKennke.mdwn b/RomanKennke.mdwn new file mode 100644 index 00000000..f4b3fc0a --- /dev/null +++ b/RomanKennke.mdwn @@ -0,0 +1,13 @@ + + +## Roman Kennke + +Email: roman AT SPAMFREE kennke DOT org + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/SDVOADD2Cards.mdwn b/SDVOADD2Cards.mdwn new file mode 100644 index 00000000..2576993c --- /dev/null +++ b/SDVOADD2Cards.mdwn @@ -0,0 +1,99 @@ + + +# sDVO ADD2 DVI Cards + +The [[Intel Driver Documentation|http://intellinuxgraphics.org/documentation.html]] says: + + * You can purchase (for around $20) an 'sDVO' card which plugs into the PCI-E slot and offers DVI support in various flavors. This is just an adapter board which connects the onboard graphics chip with a DVI connector using the sDVO portion of the PCI-E standard; it's not an external graphics adapter. +There doesn't seem to be a lot of information about these cards, so I thought I would consolidate some of it here in the hopes that it helps other people looking for a solution. + +At [[http://lwn.net/Articles/194821/|http://lwn.net/Articles/194821/]] Keith Packard from Intel said: + + * We've bought a huge pile of sDVO cards to work on the modesetting branch. One thing we discovered is that there are two flavors of sDVO cards, the ADD2-N and ADD2-R cards. The suffix indicates whether the card is set up in 'N'ormal or 'R'everse orientation; Normal cards use the first channels on the PCI-E connector while Reverse cards use the last channels. + + + + * All of the motherboards we have support only Normal cards, I guess the theory for Reverse cards is that you could plug in a PCI-E x4 card into the same PCI-E bus as one of the Reverse cards and have both things working at the same time. + + + + * And, all of the ADD2-N cards we've got work just fine with everything from 915 through 965. + + + + * I can see where the AGP-based ADD (not ADD2) cards would cause problems; they don't use a standard interface so the driver has to have support for each specific card. We're facing that with the modesetting branch and we're collecting information on as many of those as we can. + + + + * In summary - ADD2-N cards 'just work' everywhere we've tried them. ADD cards require card-specific driver changes. +According to [[one manufacturer|http://www.asisupport.com/newsletter_04_2005.htm#%22ADD2%22%20Cards%20-%20What%20exactly%20are%20they?]], ADD2-N cards are intended for ATX form factor boards while ADD2-R cards are intended for BTX form factor boards. That would be in line with Keith's comments above as I believe that all the Intel boards are ATX. + + +## Cards + +Eric Anholt has a [[List of ADD2 Cards|http://web.archive.org/web/20071215081658/http://people.freedesktop.org/~anholt/intel-add-list.html]]. Please fill in any additional information about these cards, or their specifications, features, and compatibility here. + + +### ADD2 (SDVO) Cards + +* ASUS DVI-ADD2 (DVI-D, Same as HP?) + * [[Manufacturer Specs|http://support.asus.com/download/download.aspx?modelname=DVI-ADD2&SLanguage=en-us]] +* HP DY674A (DVI-D, Normal pinout) + * [[Manufacturer Specs|http://h18000.www1.hp.com/products/quickspecs/12008_na/12008_na.HTML]] + * [[Manufacturer Specs|http://h18000.www1.hp.com/products/quickspecs/11968_div/11968_div.HTML]] (shows pinout, search for model number) +* HP DY673A (DVI-D, Reverse pinout) + * [[Manufacturer Specs|http://h18000.www1.hp.com/products/quickspecs/12008_na/12008_na.HTML]] + * [[Manufacturer Specs|http://h18000.www1.hp.com/products/quickspecs/11968_div/11968_div.HTML]] (shows pinout, search for model number) +* MOLEX 79530-5004 (DVI, ADD2-R, 16x, UPC:8-41531-06000-8) + * [[Manufacturer Specs|http://www.channel.molex.com/files/chnnl_usrgd_add2_Rev1.pdf]] +* MOLEX 79530-5005 (DVI, ADD2-N, 4x, UPC:8-41531-06001-5) + * [[Manufacturer Specs|http://www.channel.molex.com/files/chnnl_usrgd_add2_Rev1.pdf]] +* MOLEX 79530-5006 (DVI, ADD2-R, 16x, UPC:8-41531-06002-2) + * [[Manufacturer Specs|http://www.channel.molex.com/files/chnnl_usrgd_add2_Rev1.pdf]] +* MOLEX 79530-5007 (DVI, ADD2-N, 4x, UPC:8-41531-06003-9) + * [[Manufacturer Specs|http://www.channel.molex.com/files/chnnl_usrgd_add2_Rev1.pdf]] +* Prolink ADD-7021-DVI-T (DVI, S-Video, ADD2-R/N?, CH7021 chipset) + * [[Manufacturer Specs|http://www.prolink-usa.com/item_disp.php?upc=4711845391135]] +* Prolink ADD-7307-DVI-N (DVI, ADD2-N?, CH7307B chipset) + * [[Manufacturer Specs|http://www.prolink-usa.com/item_disp.php?upc=4711845391173]] +* Prolink ADD-7307-DVI-R (DVI, ADD2-R?, CH7307B chipset) + * [[Manufacturer Specs|http://www.prolink-usa.com/item_disp.php?upc=782515006004]] +* Prolink PV-CH7312 (DVI?, CH7312 chipset?) + * [[Manufacturer Specs|http://www.prolink.com.tw/english/products/vga/PCX/ADD2%20Card.htm]] +* Prolink PV-CH7315 (DVI, HDMI?, CH7315 chipset?) + * [[Manufacturer Specs|http://www.prolink.com.tw/english/products/vga/PCX/ADD2%20Card.htm]] +* DELL J4571 (DVI?, ADD2-N) +* Wintec 35111141 (DVI-I) + * [[Manufacturer Specs|http://www.wintecind.com/pegasus.htm]] +* Wintec 35111142 (DVI-I, HDCP) + * [[Manufacturer Specs|http://www.wintecind.com/pegasus.htm]] +* Wintec 35111140 (Dual DVI-I, standard cable) + * [[Manufacturer Specs|http://www.wintecind.com/pegasus.htm]] +* Wintec 35111147 (DMS59, DVI, Y-cable) + * [[Manufacturer Specs|http://www.wintecind.com/pegasus.htm]] +* Wintec 35111149 (HDMI) + * [[Manufacturer Specs|http://www.wintecind.com/pegasus.htm]] +* Lenovo 73P2516 (DVI-I) + * [[Manufacturer Specs|http://www5.pc.ibm.com/europe/products.nsf/$wwwPartNumLookup/_73P2516?OpenDocument]] +* Silicon Image Orion ADD2-N DUAL PAD x16 Card (Sil 1364 chipset, Same as ASUS?) + * [[i965G (Asus P5B-V): Diagnosing ADD2/SDVO issues|http://lists.freedesktop.org/archives/xorg/2007-February/022184.html]] + +### ADD (DVO) Cards + +* Kontron ADD-LVDS 820935 (LVDS, CH7017 chipset) + * [[Manufacturer Specs|http://www.kontron-emea.com/index.php?id=226&cat=188&productid=491]] +* Kontron ADD-DVI 720930 (DVI, TV, s-video/composite) + * [[Manufacturer Specs|http://www.kontron-emea.com/index.php?id=226&cat=188&productid=490]] +* Kontron ADD-DVI-I/CRT 820942 (DVI-I, internal CRT, internal LVDS) + * [[Manufacturer Specs|http://www.kontron-emea.com/index.php?id=226&cat=188&productid=1221]] +* HP DD505A (DVI-D, Sil164 chipset) + * [[Manufacturer Specs|http://h18000.www1.hp.com/products/quickspecs/11443_na/11443_na.HTML]] +* AOpen 91.88V10.001 (DVI, TV, cvbs, s-video) + * [[Manufacturer Specs|http://global.aopen.com.tw/products/mb/add.htm]] + +## Other Mailing List Threads/Info + +* [[Intel 965G - working&supported Add2 card with TV-out/S-video?|http://lists.freedesktop.org/archives/xorg/2007-February/021695.html]] +* [[Intel graphics driver -- thanks!|http://lists.freedesktop.org/archives/xorg/2007-February/021735.html]] +* [[Intel GMA graphics - any good for hi-def?|http://lists.freedesktop.org/archives/xorg/2007-February/022004.html]] +* [[Wikipedia sDVO page|http://en.wikipedia.org/wiki/SDVO]]
\ No newline at end of file diff --git a/SecurityPage.mdwn b/SecurityPage.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/SecurityPage.mdwn diff --git a/SecurityTalkAgenda.mdwn b/SecurityTalkAgenda.mdwn new file mode 100644 index 00000000..d740990c --- /dev/null +++ b/SecurityTalkAgenda.mdwn @@ -0,0 +1,35 @@ + + +# Xorg Developer's Conference - Security Talk + +Rough outline of talk/discussion follows: + + +## Security Advisories/Response + +* Not covered + +## X Authentication/Transport + +* Loadable module support for authentication methods. Could be done: provide registration function, call callback list passing connection setup information plus file descriptor; callback performs authentication entirely before returning decision to server. +* Xtrans improvements. XCB doesn't use it. Could make it an actual library. Is a filehandle a sufficient abstraction? +* XC-QUERY-SECURITY rework. + +## Fine-Grained Access Control + +* Have a research paper; will post link. +* Improved resource lookup functions: still thinking about the prototype for dixLookupResource. Not sure if the Dix``Read``Access/Dix``Write``Access flags are useful or necessary. +* Use the resource system to store your module's objects. +* Don't multiplex different operations through the same protocol request. + +## Other Security Work of Note + +* Security error handling. Right now, the Security extension "hides" denials from the user by returning false information. I would like to see the server begin returning actual errors, preferably Bad``Access. +* devPrivates rework. Currently have separate functions for each supported structure. Could standardize this into one set of functions. +* Need to add devPrivates to additional structures: Property``Rec. +* Window labeling: currently exporting properties to window manager. Feature request: need secure area for showing labels. +* Secure handling of input events. Secure attention key support. + +## Applications + +* Shared Display Wall
\ No newline at end of file diff --git a/Server110Branch.mdwn b/Server110Branch.mdwn new file mode 100644 index 00000000..2277e4d6 --- /dev/null +++ b/Server110Branch.mdwn @@ -0,0 +1,58 @@ + +Release manager: [[KeithPackard|KeithPackard]] + +Stable branch maintainer: [[JeremyHuddleston|JeremyHuddleston]] + +**The 1.10 branch is no longer actively maintained** + + +## Schedule + +See the [[X.Org Calendar|http://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80%40group.calendar.google.com&ctz=Australia/Brisbane]]. + + +## Merge Windows + +The stable release cycle will typically be 6 weeks between dot releases. This is subject to change as needed if big issues arise forcing earlier releases or regressions arise pushing back a release. + + +#### 3 weeks before RC1 + +During the first three weeks of the release cycle, the branch is open for general nominations. As a rule of thumb, if a change does not alter ABI, change dependencies, or introduce new features, it can probably be considered for the stable branch. The focus of patches merged into the stable branch during this period should be + + * Crash fixes + * General bug fixes + * New architecture support + +#### 2 weeks before RC2 + +During the next two weeks of the cycle, the branch gets slightly tighter. The branch is still open for general nominations, but the criteria for acceptance is a bit stricter. Larger change sets which do not fix crashes or regressions will likely be deferred to the next release cycle (and picked up prior to RC1). The focus of patches merged into stable during this period should be + + * Crash fixes + * Regressions (from any previous release) + * Fixes for bugs listed in the [[1.10 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.10]] + +#### 1 week before final release + +During the last week before the release, the branch gets much tighter. Any other changes should be held for nomination in the next cycle. The focus of patches merged into stable during this period should be + + * Crash fixes with minimal code churn + * Regressions from the previous stable release + +## Proposing patches for 1.10.x + +Server 1.10.0 has been [[released|http://lists.freedesktop.org/archives/xorg-announce/2011-February/001612.html]]. Patches may be nominated for future 1.10.x releases using the process outlined below. + + * **Do not push to server-1.10-branch.** + * Patches for 1.10 must be in master first. Please follow the guidelines outlined on the [[XServer|XServer]] page to get a patch into master. Exceptions are patches where the master code has changed in a way that git master is not affected by a particular bug. + * For single patches: Once a patch is in master, let the stable branch maintainer know that this patch is to be cherry-picked to 1.10. Reply to the original patch email, placing the branch maintainer in TO and CC-ing the list. Make sure that the subject line contains `[PATCH 1.10]`. + * For multiple patches: Create a local branch and cherry-pick the patches required (Always use cherry-pick -x). Push this branch to your people.freedesktop.org repository and send a pull request to the stable branch maintainer, CC-ing the list. Make sure the subject line contains `[PULL 1.10]`. + * Only fixes for regressions introduced since the previous stable release will be accepted between the final rc and the release. + +### Critical Bugs / Halting Release + +If you have found a bug that you believe should delay the release of the next stable release, make sure you do each of the following to get attention: + + * Create a bug, and make sure the branch maintainer is CC'd. Include a link to the commit that caused the issue if you were able to determine that. + * Email the branch maintainer and xorg-devel about the issue. Make sure the subject line contains either `[1.10 REGRESSION]` or `[1.10 DNR]` or similar. +Make sure you get confirmation, and follow up. If the branch maintainer agrees, the bug will be added to the [[1.10 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.10]]. diff --git a/Server112Branch.mdwn b/Server112Branch.mdwn new file mode 100644 index 00000000..f16a33d4 --- /dev/null +++ b/Server112Branch.mdwn @@ -0,0 +1,54 @@ + +Stable branch release manager: [[JeremyHuddleston|JeremyHuddleston]] + + +## Schedule + +See the [[X.Org Calendar|http://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80%40group.calendar.google.com&ctz=Australia/Brisbane]]. + + +## Merge Windows + +The stable release cycle will typically be 6 weeks between dot releases. This is subject to change as needed if big issues arise forcing earlier releases or regressions arise pushing back a release. + + +#### 3 weeks before RC1 + +During the first three weeks of the release cycle, the branch is open for general nominations. As a rule of thumb, if a change does not alter ABI, change dependencies, or introduce new features, it can probably be considered for the stable branch. The focus of patches merged into the stable branch during this period should be + + * Crash fixes + * General bug fixes + * New architecture support + +#### 2 weeks before RC2 + +During the next two weeks of the cycle, the branch gets slightly tighter. The branch is still open for general nominations, but the criteria for acceptance is a bit stricter. Larger change sets which do not fix crashes or regressions will likely be deferred to the next release cycle (and picked up prior to RC1). The focus of patches merged into stable during this period should be + + * Crash fixes + * Regressions (from any previous release) + * Fixes for bugs listed in the [[1.12 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12]] + +#### 1 week before final release + +During the last week before the release, the branch gets much tighter. Any other changes should be held for nomination in the next cycle. The focus of patches merged into stable during this period should be + + * Crash fixes with minimal code churn + * Regressions from the previous stable release + +## Proposing patches + +Server 1.12.0 has been [[released|http://lists.freedesktop.org/archives/xorg-announce/2012-March/001846.html]]. Patches may be nominated for future 1.12.x releases using the process outlined below. + + * **Do not push to server-1.12-branch.** + * Patches for 1.12 must be in master first. Please follow the guidelines outlined on the [[XServer|XServer]] page to get a patch into master. Exceptions are patches where the master code has changed in a way that git master is not affected by a particular bug. + * For single patches: Once a patch is in master, let the stable branch maintainer know that this patch is to be cherry-picked to 1.12. Reply to the original patch email, placing the branch maintainer in TO and CC-ing the list. Make sure that the subject line contains `[PATCH 1.11]`. + * For multiple patches: Create a local branch and cherry-pick the patches required (Always use cherry-pick -x). Push this branch to your people.freedesktop.org repository and send a pull request to the stable branch maintainer, CC-ing the list. Make sure the subject line contains `[PULL 1.12]`. + * Only fixes for regressions introduced since the previous stable release will be accepted between the final rc and the release. + +### Critical Bugs / Halting Release + +If you have found a bug that you believe should delay the release of the next stable release, make sure you do each of the following to get attention: + + * Create a bug, and make sure the branch maintainer is CC'd. Include a link to the commit that caused the issue if you were able to determine that. + * Email the branch maintainer and xorg-devel about the issue. Make sure the subject line contains either `[1.12 REGRESSION]` or `[1.12 DNR]` or similar. +Make sure you get confirmation, and follow up. If the branch maintainer agrees, the bug will be added to the [[1.11 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.11]]. diff --git a/Server113Branch.mdwn b/Server113Branch.mdwn new file mode 100644 index 00000000..b29c1de9 --- /dev/null +++ b/Server113Branch.mdwn @@ -0,0 +1,56 @@ + +Release manager: [[KeithPackard|KeithPackard]] + +Stable branch maintainer: [[MattDew|MattDew]] + + +## Schedule + +See the [[X.Org Calendar|http://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80%40group.calendar.google.com&ctz=Australia/Brisbane]]. + + +## Merge Windows + +The stable release cycle will typically be 6 weeks between dot releases. This is subject to change as needed if big issues arise forcing earlier releases or regressions arise pushing back a release. + + +#### 3 weeks before RC1 + +During the first three weeks of the release cycle, the branch is open for general nominations. As a rule of thumb, if a change does not alter ABI, change dependencies, or introduce new features, it can probably be considered for the stable branch. The focus of patches merged into the stable branch during this period should be + + * Crash fixes + * General bug fixes + * New architecture support + +#### 2 weeks before RC2 + +During the next two weeks of the cycle, the branch gets slightly tighter. The branch is still open for general nominations, but the criteria for acceptance is a bit stricter. Larger change sets which do not fix crashes or regressions will likely be deferred to the next release cycle (and picked up prior to RC1). The focus of patches merged into stable during this period should be + + * Crash fixes + * Regressions (from any previous release) + * Fixes for bugs listed in the [[1.13 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.13]] + +#### 1 week before final release + +During the last week before the release, the branch gets much tighter. Any other changes should be held for nomination in the next cycle. The focus of patches merged into stable during this period should be + + * Crash fixes with minimal code churn + * Regressions from the previous stable release + +## Proposing patches for 1.13.x + +Server 1.13.0 has been [[released|http://lists.x.org/archives/xorg-announce/2012-September/002068.html]]. Patches may be nominated for future 1.13.x releases using the process outlined below. + + * **Do not push to server-1.13-branch.** + * Patches for 1.13 must be in master first. Please follow the guidelines outlined on the [[XServer|XServer]] page to get a patch into master. Exceptions are patches where the master code has changed in a way that git master is not affected by a particular bug. + * For single patches: Once a patch is in master, let the stable branch maintainer know that this patch is to be cherry-picked to 1.13. Reply to the original patch email, placing the branch maintainer in TO and CC-ing the list. Make sure that the subject line contains `[PATCH 1.13]`. + * For multiple patches: Create a local branch and cherry-pick the patches required (Always use cherry-pick -x). Push this branch to your people.freedesktop.org repository and send a pull request to the stable branch maintainer, CC-ing the list. Make sure the subject line contains `[PULL 1.13]`. + * Only fixes for regressions introduced since the previous stable release will be accepted between the final rc and the release. + +### Critical Bugs / Halting Release + +If you have found a bug that you believe should delay the release of the next stable release, make sure you do each of the following to get attention: + + * Create a bug, and make sure the branch maintainer is CC'd. Include a link to the commit that caused the issue if you were able to determine that. + * Email the branch maintainer and xorg-devel about the issue. Make sure the subject line contains either `[1.13 REGRESSION]` or `[1.13 DNR]` or similar. +Make sure you get confirmation, and follow up. If the branch maintainer agrees, the bug will be added to the [[1.13 tracker|https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.13]]. diff --git a/Server12Branch.mdwn b/Server12Branch.mdwn new file mode 100644 index 00000000..6752cf04 --- /dev/null +++ b/Server12Branch.mdwn @@ -0,0 +1,4 @@ + +This page lists revisions nominated for the server-1.2-branch, after sufficient testing. + +(None!) diff --git a/Server13Branch.mdwn b/Server13Branch.mdwn new file mode 100644 index 00000000..1f9de013 --- /dev/null +++ b/Server13Branch.mdwn @@ -0,0 +1,98 @@ + + +## X server version 1.3 release plans + +X server version 1.3 is API/ABI compatible with X server version 1.2. It includes the following new features: + +* RandR 1.2 +* EXA Damage track +Below here, please list patches nominated for merging into the 1.3.x branch from master, after sufficient testing has been done (no insta-merges, please). + +* f8482967ae8080f49dd1bbb0b79cc65020df679f: Add exa driver callback for pixmapIsOffscreen. +* c10df5b967d4da4e11786520317e2917de5541fa: Swap RRScreenChangeNotifyEvent dimensions when the screen has one crtc and it's rotated. +* 649e7f82d8d4333443493056b81eb20d6cf022bc: Consolidate portPriv->pDraw assignments into xf86XVEnlistPortInWindow. (Fixes crashes introduced by commit a232693c8c2a206aac47c07b133c071938204e0b below, see e.g. [[https://bugs.freedesktop.org/show_bug.cgi?id=11264|https://bugs.freedesktop.org/show_bug.cgi?id=11264]]) + + +--- + + + +Once those patches are merged, please move them below this line: + + + +--- + + RC1 contains these fixes: + +* 811675733e97416c990e6dc9c19271b43d96248d: os: fix client privates leak + * We accidentally leaked the os layer's private structures for every client. +* 0f6dd4aea6176507dbe1c90c950d332fecbcaacb: xephyr: fix screen private leak + * We accidentally leaked the screen private structure every regeneration. +* 5dcad9e9d7d9993d65f989219bee94a060bbf476: Fix bus error on startup in 64-bit Xephyr + * We were passing pointers to CARD32's to a function expecting pointers to unsigned longs. +* c4b7e9d1c16797c3e4b1200b40aceab5696a7fb8: Add an RDTSC implementation to the x86 emulator. + * Not a very good implementation, but it's better than nothing. +* edd5f1745461f995670969cb736d1569ca94643f: Add ast driver/device info to Xorg server & config utilities + * No reason not to let the server give this driver a try. +* 40f84793bca40dcc6883d51aefa1bda44bd1ac61: Propogate $LIBS for xtrans, clock_gettime, libm, etc for each server + * Make sure OS'es that need additional libraries get them added to the library list for all the servers +* f9f7d7f3be53c808abb5eaceb7a1abc55744a210: Make sparc #ifdefs compatible with Sun cc +* 5680efc0d2baf0a9451e82e490e3690fc23dda0f: Xorg should not be including <sys/immu.h> on Solaris + * Fixes builds on current Solaris development branch releases +RC2 contains these fixes: + +* d5aba03feff41722c72b4c6193f09d141cbf1678: Xprint: shorten font filename to fit in tar length limit + * Follow-up for commit aeabf2a1f873f884b8a8c33b1517c3f3cab4c7f5, bring filenames within tar limits. Revert 73904d953f2f9cbe941a215ba240b46bc7a61357 before applying. + + +--- + + RC3 contains these fixes: + +fbdevhw fixes: + +* f6815cb68b0f6698497348fc6e4214dacef33b95: fbdevhw: Consolidate modeset ioctl calling, report failure if it modifies mode. +* c385bcf0bde38dd869f7065f859dd4b4126f5690: fbdevhw: Fix some issues with the previous commit. +* d077c0da470ab7291e8d838eaace57b066477d6f: fbdevhw: Use displayWidth for fbdev virtual width when appropriate. +* dc5eb4523298f966bd5fd9ae6672160034b5e82c: fbdevhw: Override RGB offsets and masks after setting initial mode. +* 27a01e100bff21ac0b70c6d72071d7226fc91264: fbdevhw: Consider mode set equal to mode requested if virtual width is larger. +* 14d6a9b327381a6bb2dac59c62728e5fd0f0bcfb: fbdevhw: Only deal with RGB weight if default visual is True- or [[DirectColor|DirectColor]]. +Allow colour-keyed Xv overlay adaptors to work a little better with compositing managers (only implemented in radeon driver on master branch so far): + +* a232693c8c2a206aac47c07b133c071938204e0b: Add per-drawable Xv colour key helper function. +* 788cfce911793a26aed16f38f30678ecee82c873: Bump video driver ABI version to 1.2. + + +--- + + + +RC4 didn't contain these fixes, so they're in RC5 instead. + +* 8c7f56d92d8471ee059c14d322af5f7f555dd5c6: Fix timer reschedule. +* 645d87cf8ef724d4591614f9994cdc4d7549a7a8: CVE-2007-1003 + + +--- + + Patches which cause chaos when cherry-picked. These have been rejected for 1.3; suitable 1.3-specific patches are welcome as substitutes; please publish as a branch from a 1.3 tag or attach a patch to this message. + +* 68d39d8571d8717d26cedc84015d537549520a14: kdrive/ephyr: fix keysym type confusion once and for all + * Keysyms were getting mangled in the keymap load, because of 32-bit vs. 64-bit type confusion. +* 68c64ad7b1eea79c786b5a7f3459076780163a47: Xext: Update device's lastx/lasty when sending a motion event with XTest. + + +--- + + Patches which appear to change the ABI/API compatibility with server version 1.2. + +DRI enhancements: + +Allow page flipping with unredirected fullscreen windows while running compiz: + +* eedf148e5a1273ebbf4dc8dcac9c435712fc00ea: Track number of visible DRI windows separately for transitions. +Allow independent page flipping on each CRTC and excluding the DRI window contents when synchronizing 2D rendering between pages (only implemented in the intel driver so far): + +* 3c7a27dc77595ad018bb7c4f7cef6bc178268cb6: DRI: New [[ClipNotify|ClipNotify]] driver hook. +* 3344a4eda704edc7dc30037f095de277a60a70bb: DRI: Make sure number of DRI windows is accurate in driver [[ClipNotify|ClipNotify]] hook.
\ No newline at end of file diff --git a/Server14Branch.mdwn b/Server14Branch.mdwn new file mode 100644 index 00000000..3393b888 --- /dev/null +++ b/Server14Branch.mdwn @@ -0,0 +1,92 @@ + + +## X server version 1.4 release plans + + +### 1.4.1 + +1.4.1 will be released on November 11th, 2007. It is scheduled to contain some random minor fixups, as well as a load of input fixes for extended events. Please nominate your patches on this page, as usual. + +[[DanielStone|DanielStone]] is responsible for this release. The blocker bug for this release is [[xorg-server-1.4.1|https://bugs.freedesktop.org/show_bug.cgi?id=xorg-server-1.4.1]]. + + +### 1.4.0 + +X server version 1.4.0 includes the following new features: + +* [[Input hotplug|Projects/Input]]: Input hotplug allows hotplugging of input devices, and also adds enhanced support for touchscreens and tablets, through either HAL or D-Bus. +* KDrive: Numerous enhancements have been made to the KDrive codebase, including better support for multiple input devices. +* [[DTrace|http://people.freedesktop.org/~alanc/dtrace/]]: When running on [[OpenSolaris|OpenSolaris]], DTrace support is available in the X server, allowing detailed accounting of operations inside the server. +* EXA: A great deal of work has been done on the EXA framework to make it more usable. + +## ABI + +The input & video driver API/ABI's are **not** compatible with X server version 1.3. All other module type API/ABI's are compatible with X server version 1.3. +[[!table header="no" class="mointable" data=""" + | **1.4** | **1.3 ** + ABI_ANSIC_VERSION | 0.3 | 0.3 + ABI_VIDEODRV_VERSION | 2.0 | 1.2 + ABI_XINPUT_VERSION | 2.0 | 0.7 + ABI_EXTENSION_VERSION | 0.3 | 0.3 + ABI_FONT_VERSION | 0.5 | 0.5 +"""]] + + +## Proposed patches + +Below here, please list patches nominated for merging into the [[server-1.4-branch|http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.4-branch]] from [[master|http://cgit.freedesktop.org/xorg/xserver/log/]], after sufficient testing has been done (no insta-merges, please). + +* [[095850596114178119a8cc854716ce0cc6e05121|http://cgit.freedesktop.org/xorg/xserver/commit/?id=095850596114178119a8cc854716ce0cc6e05121]] ``_``_glXDRIbindTexImage: Fail if no texture bound to pixmap's texture target. +* [[d502521c3669f3f22b94c39a64ab63bfd92c6a97|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d502521c3669f3f22b94c39a64ab63bfd92c6a97]] - EXA: Fix off-by-one in polyline drawing. +* [[feac0759522cbdc3e61ccfa373df735903c5cb27|http://cgit.freedesktop.org/xorg/xserver/commit/?id=feac0759522cbdc3e61ccfa373df735903c5cb27]] - Make config file preferred mode override monitor preferred mode. +* [[29e0e180729a4f0cc020985a4de4c8bc4b9c7f5f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=29e0e180729a4f0cc020985a4de4c8bc4b9c7f5f]] - Leave hardware-specified preferred modes alone when user preference exists. +* [[ce50bfd3369686cfecee5a138bd84ef1107a249d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ce50bfd3369686cfecee5a138bd84ef1107a249d]] - EXA: Skip empty glyphs. ([[bug 13407|https://bugs.freedesktop.org/show_bug.cgi?id=13407]]) +* [[12e532403210c15a25200ef448bfe9701735ab20|http://cgit.freedesktop.org/xorg/xserver/commit/?id=12e532403210c15a25200ef448bfe9701735ab20]] - dix: Always add valuator information if present [[discussion here|http://lists.freedesktop.org/archives/xorg/2007-December/031195.html]] + + +--- + + + +* Once those patches are merged, please move them below this line: + + +--- + + + +* [[70c0592a97c7dc9db0576d32b3bdbe4766520509|http://cgit.freedesktop.org/xorg/xserver/commit/?id=70c0592a97c7dc9db0576d32b3bdbe4766520509]] - Resize composite overlay window when the root window changes. +* [[a48cc88ea2674c28b69b8d738b168cbafcf4001f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a48cc88ea2674c28b69b8d738b168cbafcf4001f]] - Fix rotation for multi-monitor situation. +* [[c7d6d1f589d729fa689d22d82fe30afbc6e1cacb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c7d6d1f589d729fa689d22d82fe30afbc6e1cacb]] - EXA: Punt on fallback case not handled correctly in exaFillRegionTiled. (Backport to 1.4 branch attached to [[bug 12520|https://bugs.freedesktop.org/show_bug.cgi?id=12520]]) +* [[006f6525057970a74382132237b2131286ad147c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=006f6525057970a74382132237b2131286ad147c]] - EXA: Make sure tile offsets passed to drivers are never negative. (Backport to 1.4 branch attached to [[bug 12606|https://bugs.freedesktop.org/show_bug.cgi?id=12606]]) +* [[5d74416740de883b7ef0994afea4bbd4d3901be0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5d74416740de883b7ef0994afea4bbd4d3901be0]] - EXA: Don't attempt to move in pixmaps that can't be accelerated. (Backport to 1.4 branch attached to [[bug 12815|https://bugs.freedesktop.org/show_bug.cgi?id=12815]]) +* [[23fbd5292d356067e85e1eec4eb4f743532b0503|http://cgit.freedesktop.org/xorg/xserver/commit/?id=23fbd5292d356067e85e1eec4eb4f743532b0503]] Actually build Secure RPC authentication support +* [[265a633cf1fcbf497d6916d9e22403dffdde2e07|http://cgit.freedesktop.org/xorg/xserver/commit/?id=265a633cf1fcbf497d6916d9e22403dffdde2e07]] Screen size changing should leave FB alone when X is inactive. +* [[48ca5961caee62f2980017a6bdc96a1b4c747727|http://cgit.freedesktop.org/xorg/xserver/commit/?id=48ca5961caee62f2980017a6bdc96a1b4c747727]] - Prefer configured [[DisplaySize|DisplaySize]] to probed DDC data, if available. +* [[3a965fdadccea7beff09a28c9c0ef4b4975eae38|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3a965fdadccea7beff09a28c9c0ef4b4975eae38]] - Don't segfault on shutdown if we never managed to connect to dbus. +* [[50fa8722d35c12e5f0322cebe25faf99c39d4f50|http://cgit.freedesktop.org/xorg/xserver/commit/?id=50fa8722d35c12e5f0322cebe25faf99c39d4f50]] - Set noCompositeExtension to TRUE when failing to initialize the extension (e.g. when Xinerama is enabled). +* 0fcde83d94507eadd9f99d4e6a63584b221c989c and 3f42af8c0ef1e5379bc836f589e0cbee43c02ac5. Tested with add & remove command, both valid and invalid forms, on a compile of the server-1.4. branch. +* d0dc9698ae4324d44ed4c0482d6858d0b73bff33 Add _X_EXPORT to exported functions in hw/xfree86/modes/* +* 32666d77227fcd2c066de16bf3c07366f92b0457 Bug #12015: Use the right offsets in the dst arguments of pixman_blt. +* 6a32a96d8df184c3ace4847beb48fdcb846d2286 stride is in [[FbBits|FbBits]]-sized chunks, but xoff is not. +* 53c04351c462d2ae307684e50d5960debe1ee557 move intel crtc xv clipping helper to the xserver +* 1f6ddae003ec65d6bc567831bf32bf75dfefdd6c add xf86_crtc_clip_video_helper to xf86sym.c +* 7dc8531548cc9573e28bb04363dcbb3af5864c9a Ref count cursors used in hw/xfree86/modes code. +* 12d27cf33c6d963eae77795c0d247175907162a5 fix for bug [[#3113|https://bugs.freedesktop.org/show_bug.cgi?id=3113]] (also get a66c0f1dca2958835ff65a5b50579e3304ed316a please.) +* 0dc2bb6101704d0fd25f36e2c3df79687f119f5b [RANDR] Compare only milliseconds of config time. (Bug #6502) +* 1afdf8b0a92437dffe84fa98b6083b3d8fd55e27 [RANDR] Don't mark Xinerama as active if no crtcs are enabled. (bug #11504). +* f98dfec79dadb70fa7bba84e7335f92b3a73dc02 [COMPOSITE] Composite used for pixmap population on redirect. (Bug #7447) + + +--- + + + +* Patches not approved for 1.4.0: + + +--- + + + +* [[c839859d1bc35451923a2cbd5dfac4f3ca5eb3f9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c839859d1bc35451923a2cbd5dfac4f3ca5eb3f9]] Move module defaults from the header to the source file.
\ No newline at end of file diff --git a/Server15Branch.mdwn b/Server15Branch.mdwn new file mode 100644 index 00000000..76a4c9ed --- /dev/null +++ b/Server15Branch.mdwn @@ -0,0 +1,139 @@ + + +## Proposed patches + +Below here, please list patches nominated for merging into the [[server-1.5-branch|http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.5-branch]] from [[master|http://cgit.freedesktop.org/xorg/xserver/log/?h=master]], after sufficient testing has been done (no insta-merges, please). + +Since xserver 1.5.3 has been released, nominations here will be considered for future 1.5.x bugfix releases, if we do any. + +[[08cd361234ed0410f67342f46ae01120c4fe3331|http://cgit.freedesktop.org/xorg/xserver/commit/?id=08cd361234ed0410f67342f46ae01120c4fe3331]] exa: avoid doing prepare/done without intervening copies in exaFillRegionTiled + +[[0b56b44addc323a00eb7cd86240cb0dd4275bcf8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b56b44addc323a00eb7cd86240cb0dd4275bcf8]] xfree86: [[AllowEmptyInput|AllowEmptyInput]] is true by default - update the xf86Info defaults. + +[[ace38fafb062372dcd3d56378b5b8f86525c6241|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ace38fafb062372dcd3d56378b5b8f86525c6241]] xfree86: without CONFIG_HAL, Auto{Add|Enable}Devices and AEI is false. + +[[a54153e669fd293a47f0077bf25505dd545ddce2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a54153e669fd293a47f0077bf25505dd545ddce2]] xfree86: don't reset Auto(Add|Enable)Devices, use defaults from xf86Globals + +[[8d4d0b47a07a298a20ffae9fefe96c8c7ca9dccc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8d4d0b47a07a298a20ffae9fefe96c8c7ca9dccc]] gl: include assert.h if we're compiling with DEBUG + +[[60bcdd687040db76490851d4b459284ce37020e0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=60bcdd687040db76490851d4b459284ce37020e0]] x11-input.fdi: Add options needed to handle adding USB devices on Solaris + +[[d2cf562bbad553d7f09b70202134f5b6ada0114e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d2cf562bbad553d7f09b70202134f5b6ada0114e]] Make [[RgbPath|RgbPath]] keyword in xorg.conf a non-fatal error + +[[ca56d764d2be28c64fe15c9e37d534ef00117ad2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ca56d764d2be28c64fe15c9e37d534ef00117ad2]] xsync: Fix wakeup storm in idletime counter. + +[[Bug 21459|https://bugs.freedesktop.org/show_bug.cgi?id=21459]] bogus events sent out whe XKB is disables + +* Patch at [[Xi: don't send XKB mapping notifications when XKB is disabled|https://bugs.freedesktop.org/attachment.cgi?id=25226]] +[[Bug 21455|http://bugs.freedesktop.org/show_bug.cgi?id=21455]] Bad event list generated when adding fake [[KeyRelease|KeyRelease]] + +* Patch at [[dix: fix calculation of number of fake KeyRelease events|http://bugs.freedesktop.org/attachment.cgi?id=25218]] +[[Bug 20098|http://bugs.freedesktop.org/show_bug.cgi?id=20098]] Xserver 1.5: seg fault when initializing DMX screens + +* Patch at [[add dmx*PrivateKeyIndex static ints / dixRequestPrivate|http://bugs.freedesktop.org/attachment.cgi?id=22897]] + + +--- + + + +Once these have been merged, move them below this line: + + + +--- + + + +[[a9e20306fbe3262602f21b876a52a1ef38cdf20a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a9e20306fbe3262602f21b876a52a1ef38cdf20a]] int10: Do an mprotect(..,PROT_EXEC) on shmat()ed memory ranges. + +[[d3d6be4948fa19947fd3b03e6694247109cc0ffb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d3d6be4948fa19947fd3b03e6694247109cc0ffb]] mi: Fix infinite loop on regen when swrast_dri.so is missing + +[[991c88b7542164194be73573e7644164416ea90c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=991c88b7542164194be73573e7644164416ea90c]] xfree86: xf86SetDepthBpp needs to respect the driver's depth24flags + +[[59f9fb4b8c031df69b3592a26b77e744ff4a556e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=59f9fb4b8c031df69b3592a26b77e744ff4a556e]] XAA [[PixmapOps|PixmapOps]]: Sync before accessing unwrapped callbacks. + +[[c9051b684b524549eab6d5b88ee3e195a6f6fbe8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c9051b684b524549eab6d5b88ee3e195a6f6fbe8]] Use [[OsSignal|OsSignal]] in Popen/Pclose to avoid SysV signal() stupidity + +[[d63ea510138c8b6de66184c78cda39ed9981fc1f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d63ea510138c8b6de66184c78cda39ed9981fc1f]] Non-Linux OS'es should default to kbd driver, not now-dead keyboard driver + +[[8f8a9c19ad58768b07461a3f4bccea98f7c4f958|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8f8a9c19ad58768b07461a3f4bccea98f7c4f958]] EXA: avoid copy operations if no boxes in use + +[[c9c1c8ca18d57b65889ec69a93e249f549562732|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c9c1c8ca18d57b65889ec69a93e249f549562732]] dix: extra sanity-checks against potential NULL-dereferences. + + +### Xserver 1.5.3 + +[[8e368cf5b964f1d29fda0a463f9510457619b14d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e368cf5b964f1d29fda0a463f9510457619b14d]] Xorg: add -modalias option + +[[ffaaa1a198a77eb6800c08d4613ee1cc0b068ba0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ffaaa1a198a77eb6800c08d4613ee1cc0b068ba0]] xfree86: fix compiler warnings in [[DoModalias|DoModalias]]() + +[[5b336585a4cdf11d20831a9536ad581e959ea7f1|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5b336585a4cdf11d20831a9536ad581e959ea7f1]] dri: don't set the dixPrivate key to NULL, as this is a staticly set variable + + +### Xserver 1.5.2 + +[[8c46505d7d91e0644b19cccc4b342fceb6f86cab|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8c46505d7d91e0644b19cccc4b342fceb6f86cab]] xkb: fix use of uninitialized variable. + +[[ae986d1c73d2f720bd0309d8c33328d14e8eed25|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ae986d1c73d2f720bd0309d8c33328d14e8eed25]] xkb: fix core keyboard map generation. #14373 + +[[30c3c13f1030268aaa6a3598d538fafd0592d77a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=30c3c13f1030268aaa6a3598d538fafd0592d77a]] xkb: squash canonical types into explicit ones on core reconstruction + +[[94919480d8bb66e1807b4fe87b8f326ef6e012c6|http://cgit.freedesktop.org/xorg/xserver/commit/?id=94919480d8bb66e1807b4fe87b8f326ef6e012c6]] int10: Fix a nasty memory leak. (depends on int10 warning commits [[a65e36a873cd1ba9896cd0f9a3e94dd933666005|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a65e36a873cd1ba9896cd0f9a3e94dd933666005]] & [[a57b2f172c1291f22f7ba2780c1b2f55e353c3e9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a57b2f172c1291f22f7ba2780c1b2f55e353c3e9]] ) + +[[56c615368c5a8e7acb0398434c2c68578626aa38|http://cgit.freedesktop.org/xorg/xserver/commit/?id=56c615368c5a8e7acb0398434c2c68578626aa38]] Check nextEnabledOutput()'s return in bestModeForAspect() + +[[1feb69eb63e6739ff5db255ad529e84adf941a10|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1feb69eb63e6739ff5db255ad529e84adf941a10]] DGA: Fix ProcXF86DGASetViewPort for missing support in driver. + + +### Xserver 1.5.1 + +[[2b266eda6e23d16116f8a8e258192df353970279|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2b266eda6e23d16116f8a8e258192df353970279]] Fix panoramiX request and reply swapping + +[[b4762c0245ed2966606171cf27f40aa745fdc76e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b4762c0245ed2966606171cf27f40aa745fdc76e]] exa: disable shared pixmaps + + +### Xserver 1.5 + +[[d01c5ca7935a8340a3cd68c325da6dfec005c952|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d01c5ca7935a8340a3cd68c325da6dfec005c952]] Xserver.man: Typo (the the). + +[[229e60db8f95232afc8cdcb7cd0572d117c84b90|http://cgit.freedesktop.org/xorg/xserver/commit/?id=229e60db8f95232afc8cdcb7cd0572d117c84b90]] Xorg.man: Typo (the the). + +[[01264f17925005969c3b71ca945fc1014bcd8c8e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=01264f17925005969c3b71ca945fc1014bcd8c8e]] Add swapped dispatch for randr 1.2 requests. (alternatively, return 1.1 from RRQueryVersion if (client->swapped)) + +[[d3ae193f4ac87530f2745f8cb5e7b70dd516881e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d3ae193f4ac87530f2745f8cb5e7b70dd516881e]] Xevie: always initialize rep.length (bug#17394) + +[[b5cdcfa55c399e83d51242e93d4f25d8bc4fec1f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b5cdcfa55c399e83d51242e93d4f25d8bc4fec1f]] Xevie: swap replies as necessary + +[[eff25430b4a391409e39337962ff7697165d23c7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=eff25430b4a391409e39337962ff7697165d23c7]] Don't abort if swrast library is not present + +[[244a635fcdc9e0a7212d51b26d74f49d8e1b071f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=244a635fcdc9e0a7212d51b26d74f49d8e1b071f]] Fix the tile offset in miPaintWindow for [[ParentRelative|ParentRelative]] windows. + +[[49751fee3b82ebc4917bfb168ec78aad7874f1f1|http://cgit.freedesktop.org/xorg/xserver/commit/?id=49751fee3b82ebc4917bfb168ec78aad7874f1f1]] glx: copy msaa visual capabilities + +[[2d7ba09dc4b5eff5dba8d7867f285111574b1737|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2d7ba09dc4b5eff5dba8d7867f285111574b1737]] Make devPrivates lookup functions ABI instead of static inlines. + +[[95d4ede538fbb68049ba3efa0acb0e9712e5cb01|http://cgit.freedesktop.org/xorg/xserver/commit/?id=95d4ede538fbb68049ba3efa0acb0e9712e5cb01]] Fix types of modeIsPresent + +[[d5ae85b5b722821499d5796cf0973ecb6ec125f1|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d5ae85b5b722821499d5796cf0973ecb6ec125f1]] Fix embarrasing GLXPixmap leak. + +[[facb255fa9267e343cbc91f841f1b64e5dc99e98|http://cgit.freedesktop.org/xorg/xserver/commit/?id=facb255fa9267e343cbc91f841f1b64e5dc99e98]] Need to unref pixmaps backing pbuffers too. + +[[0b9ef835a0fe900c121b84e43989591e58ab1126|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b9ef835a0fe900c121b84e43989591e58ab1126]] modes: fix initial xorg.conf mode selection. + +[[2eaed4a10fe5bf727579bca4ab8d4a47c8763a7d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2eaed4a10fe5bf727579bca4ab8d4a47c8763a7d]] xfree86: use xorg.conf input devices if there is no [[ServerLayout|ServerLayout]] (or revert c30f36c8c1dfd85deaf1c109823a1f15dd218ac7) + +[[b8dd07f855c555af56cbf0f69df799f424da2cca|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b8dd07f855c555af56cbf0f69df799f424da2cca]] HAL: Remove grotesque open-coded strcasestr + +[[35b14519b4a3158592a089170ec039bbc219603e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=35b14519b4a3158592a089170ec039bbc219603e]] config: add parsing for input.x11_options.[[XkbOptions|XkbOptions]]. #16874 + +[[92c51b183c2ff06361dad7f918daed6577ba4935|http://cgit.freedesktop.org/xorg/xserver/commit/?id=92c51b183c2ff06361dad7f918daed6577ba4935]] config: support type strlist for [[XkbOptions|XkbOptions]] property. + +[[3c6a9c531f673b7a0cb9ca01860b4dbe79686363|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3c6a9c531f673b7a0cb9ca01860b4dbe79686363]] config: protect against potential out-of-bounds indexing. + + +## Rejected + +These changes were nominated, but found not suitable for a 1.5.x release, though they will be in 1.6.0 and later: + +[[b6ab114212c0e4c3346ceb5b207f14c526ab81e7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b6ab114212c0e4c3346ceb5b207f14c526ab81e7]] Array-index based devPrivates implementation. (depends on [[ebea78cdba0ff14a397239ee1936bd254c181e1b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ebea78cdba0ff14a397239ee1936bd254c181e1b]]) -- **breaks ABI** diff --git a/Server16Branch.mdwn b/Server16Branch.mdwn new file mode 100644 index 00000000..7630ef3b --- /dev/null +++ b/Server16Branch.mdwn @@ -0,0 +1,351 @@ + + +## Features + +* RANDR 1.3 +* DRI2 +* Xinput 1.5 (including [[Input device properties|http://who-t.blogspot.com/2008/07/input-device-properties.html]]) ([[PeterHutterer|PeterHutterer]]) +* [[predictable pointer acceleration|Development/Documentation/PointerAcceleration]] ([[SimonThum|SimonThum]]) + +## Proposed patches + +Since xserver 1.6.0 has been released, nominations here will be considered for future 1.6.x bugfix releases, if we do any. + +Below here, please list patches nominated for merging into the [[server-1.6-branch|http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.6-branch]] from [[master|http://cgit.freedesktop.org/xorg/xserver/log/]], after sufficient testing has been done (no insta-merges, please). + +* [[3a690598cf18c4cdc6aadd10a1ecf0772cacd34b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3a690598cf18c4cdc6aadd10a1ecf0772cacd34b]] Remove unused [[HandleSpecialKeys|HandleSpecialKeys]] config option + * best to just merge the man page sections, the xf86Info might be ABI? + * +--- + + + +Once these have been merged, move them below this line: + + * +--- + + + +* [[2180174034ae007023f248964be315fccc3c32ee|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=2180174034ae007023f248964be315fccc3c32ee]] xace: Fake return values on denials in input polling requests. +* [[4a8cc895ccdb64945661747c75a118deea96b53a|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=4a8cc895ccdb64945661747c75a118deea96b53a]] xselinux: Stop special-casing [[QueryPointer|QueryPointer]] access checks. +* [[e81a665ef210845911d2b03bcca4f6a05cb367d0|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=e81a665ef210845911d2b03bcca4f6a05cb367d0]] xace: Relax permissions on [[XkbGetState|XkbGetState]] from Read to Getattr. +* [[e26957d0cd937a6433f980c7384f0290c0c579b3|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=e26957d0cd937a6433f980c7384f0290c0c579b3]] xselinux: switch from x_device to separate x_pointer and x_keyboard classes. +* [[b14bbce6b420a3891cab886d759175c6a16d54e5|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=b14bbce6b420a3891cab886d759175c6a16d54e5]] xselinux: Note something in the log if disabled by boolean. +* [[cfc09c3618ca194bca0b7ca0bf8334afe9327a36|http://cgit.freedesktop.org/~ewalsh/xserver/commit/?h=server-1.6-branch&id=cfc09c3618ca194bca0b7ca0bf8334afe9327a36]] xselinux: Allow [[SetWindowCreateContext|SetWindowCreateContext]] to be used for pixmaps as well. +* [[9625f6d328d6f516520930227b218979309938bc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9625f6d328d6f516520930227b218979309938bc]] Fix breakage on alpha caused by c7680befe5ae + +## xserver 1.6.5 + +* [[19be992d9dc542b61fa3f4fd32a09071c9e64880|http://cgit.freedesktop.org/xorg/xserver/commit/?id=19be992d9dc542b61fa3f4fd32a09071c9e64880]] ephyr: if -parent is given, check for a trailing -screen. (#24144) + +### xserver 1.6.4.901 (1.6.5 RC1) + +* [[db98b26ee145f70e732e2cf4a6ac3de77fdf4adc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=db98b26ee145f70e732e2cf4a6ac3de77fdf4adc]] Re-fix DGA removal. + +## xserver 1.6.4 + +* [[c1d901d723c3bee523736eacc15b44a7dff484fe|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c1d901d723c3bee523736eacc15b44a7dff484fe]] Don't reset the lastDeviceEventTime when doing DPMS actions +* [[df597709d71f47b8516e27c6fb1bfffd59de5e48|http://cgit.freedesktop.org/xorg/xserver/commit/?id=df597709d71f47b8516e27c6fb1bfffd59de5e48]] dri2: Don't crash if pPriv is NULL. +* [[render: return the supported version rather than just passing the proto's version|http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/render-return-the-supported-version.patch;h=cdd84851c7f9b3243d39e7bf533ccd1743717c60;hb=0c5ab464dd5bee5644ac05164d1154006e338d04]] (1.6 doesn't support render 0.11, this patch makes it advertise 0.10 even when built against newer renderproto) +* [[f4350c66b493d63fa06be87caa958d7033232ea4|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4350c66b493d63fa06be87caa958d7033232ea4]] fbdevhw: Test for graphics:fb%d as well as graphics/fb%d +* [[f56cbe1ef24415d0142b9a7d0ab0a031069ccb52|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f56cbe1ef24415d0142b9a7d0ab0a031069ccb52]] dix: append "built-ins" to the font path in [[SetDefaultFontPath|SetDefaultFontPath]] +* [[0b7c6c728c2e2d8433a188315cc591308a89cd85|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b7c6c728c2e2d8433a188315cc591308a89cd85]] xfree86/modes: Remove all framebuffer support from DGA +* [[Bug 24100 (Attachment 29788)|https://bugs.freedesktop.org/attachment.cgi?id=29788]] Don't send core events for devices that have [[SendCoreEvents|SendCoreEvents]] off + +### xserver 1.6.3.901 (1.6.4 RC1) + +* [[db568f9eabf3450d8a023597ff007df355b13ea8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=db568f9eabf3450d8a023597ff007df355b13ea8]] Xext: fix up wrong conditions for negative sync transitions. +* [[49046088f10cceaea7da97401d742d3fb59371f5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=49046088f10cceaea7da97401d742d3fb59371f5]] config: don't shutdown the libhal ctx if it failed to initialize (#23213). +* [[c73cd3b265c301b8a54ffe484d6c696f2abefb46|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c73cd3b265c301b8a54ffe484d6c696f2abefb46]] xfree86: Link libselinux with Xorg system libraries. +* [[6c292d17053eb2a7e7054e51210f423dbc0cb7e8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6c292d17053eb2a7e7054e51210f423dbc0cb7e8]] dix: update the sprite trace for all masters && floating slaves (#23257) (does not apply cleanly) +* [[6b5978dcf1f7ac3ecc2f22df06f7000f360e2066|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6b5978dcf1f7ac3ecc2f22df06f7000f360e2066]] Do not reset lastDeviceEventTime when we do dixSaveScreens +* [[2075d4bf9e53b8baef0b919da6c44771220cd4a5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2075d4bf9e53b8baef0b919da6c44771220cd4a5]] glx: If a destroyed window is bound to the current context, make it not current +* [[3020b1d43e34fca08cd51f7c7c8ed51497d49ef3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3020b1d43e34fca08cd51f7c7c8ed51497d49ef3]] glx: Clean up more thoroughly if the drawable of a current context goes away +* [[4aab05e3b3231f1ec9795a66a075d17a722634a7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=4aab05e3b3231f1ec9795a66a075d17a722634a7]] xf86_reload_cursors: fix cursor position to eliminate jumping after mode set +* [[1740cda7a37abc7d0a169ab4555b446adaa62211|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1740cda7a37abc7d0a169ab4555b446adaa62211]] Perform rotation redisplay before calling driver block handler (which may flush rendering) +* [[e7dd1efef408effe52d0bd3d3aa0b5d4ee10ed90|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e7dd1efef408effe52d0bd3d3aa0b5d4ee10ed90]] Ensure that rotation updates happen frequently + +## xserver 1.6.3 + +* [[b1c3dc6ae226db178420e3b5f297b94afc87c94c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b1c3dc6ae226db178420e3b5f297b94afc87c94c]] config: add HAL error checks +* [[1e816065e5ec3b9394dc1fa5815457a664e15fd9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1e816065e5ec3b9394dc1fa5815457a664e15fd9]] Don't printf NULL pointers on HAL connection error +* [[048697ccfa31cf7f7a29afa90a2f702d43efb7d4|http://cgit.freedesktop.org/xorg/xserver/commit/?id=048697ccfa31cf7f7a29afa90a2f702d43efb7d4]] quirk: use first detailed timing as preferred for PEA prod 9003 (rh#492359) +* [[283a081572d8db787c77d09e5ba6bcadebf4f7fe|http://cgit.freedesktop.org/xorg/xserver/commit/?id=283a081572d8db787c77d09e5ba6bcadebf4f7fe]] selinux: Only activate if policy says to be an object manager +* [[442967c90dd9d8483a56bdc9237c49e33d619126|http://cgit.freedesktop.org/xorg/xserver/commit/?id=442967c90dd9d8483a56bdc9237c49e33d619126]] Remove hardcoded gcc -Wall option from configure.ac + +### xserver 1.6.2.901 + +* [[http://lists.freedesktop.org/archives/xorg-devel/2009-July/001338.html|http://lists.freedesktop.org/archives/xorg-devel/2009-July/001338.html]] Fix build of drivers with 1.6.2 when not using --install-libxf86config +* [[0eb19f9437b7d8c19592e49eedb028771d300d80|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0eb19f9437b7d8c19592e49eedb028771d300d80]] xdmcp: Don't crash on X -query with more than 255 IP addresses. (#20675) +* [[Bug 22885|https://bugs.freedesktop.org/show_bug.cgi?id=22885]] Fix key repeat problem. + * Patch at [[https://bugs.freedesktop.org/attachment.cgi?id=27898|https://bugs.freedesktop.org/attachment.cgi?id=27898]] +* [[35758544813f156eaac28844e693b2a28f6de316|http://cgit.freedesktop.org/xorg/xserver/commit/?id=35758544813f156eaac28844e693b2a28f6de316]] EXA: Only pass CT_YXBANDED to RECTS_TO_REGION() if that is really true. +* [[2c69deb92e11542f615df0f24fdc03e3b4415475|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2c69deb92e11542f615df0f24fdc03e3b4415475]] configure: libXinerama isn't needed anymore (reduce deps for embedded setups -- [[RemiCardona|RemiCardona]]) +* [[b3e3154cce47add97f5561088036ce3b9e7dc937|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b3e3154cce47add97f5561088036ce3b9e7dc937]] One = is more than adequate here. Make is sh safe. +* [[f8dd80d13bb5313a11b38b280f8ad3e22f0a6300|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f8dd80d13bb5313a11b38b280f8ad3e22f0a6300]] Replace dixLookupResource by dixLookupResourceBy{Type,Class} (Fixes xfs -- [[RemiCardona|RemiCardona]]) +* [[12e725d08b4cf7dbb7f09b9ec09fa1b621156ea9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=12e725d08b4cf7dbb7f09b9ec09fa1b621156ea9]] randr: fix server crash in RRGetScreenInfo +* [[cadf65a6e190a8952ad3cc216dc9ea55241de91a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cadf65a6e190a8952ad3cc216dc9ea55241de91a]] randr: Nuke broken set_origin shortcut +* [[6f59a8160042ea145514fdcb410f17f33fd437c2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6f59a8160042ea145514fdcb410f17f33fd437c2]] hw/xf86/modes: Set crtc mode/rotation/transform before calling set_mode_major +* [[b2bf67b61c564a4b92a429ca9ad455403161f33a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b2bf67b61c564a4b92a429ca9ad455403161f33a]] randr: fix operation order so that rotation+transform works +* [[0de58c88aba7ddd69b04f24ab5b2967c359aa69e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0de58c88aba7ddd69b04f24ab5b2967c359aa69e]] xfree86: move didLock assignment down to where the function pointer is valid. + +## xserver 1.6.2 + +* [[b349a764e98f0d8f221190157ffa0904b91beca5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b349a764e98f0d8f221190157ffa0904b91beca5]] xinerama: Put the proto version in the code instead using proto headers. +* [[2a8b8077d8f6001eb57deba60e1009fc99c28668|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2a8b8077d8f6001eb57deba60e1009fc99c28668]] dri2: support glXWaitGL & glXWaitX by copying fake front to front and vice-versa. +* [[https://bugs.freedesktop.org/attachment.cgi?id=27363|https://bugs.freedesktop.org/attachment.cgi?id=27363]] build system: fix make install +* [[2e2c5b216cc1c7a9bc26bd2c68226aaed5fc52ca|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2e2c5b216cc1c7a9bc26bd2c68226aaed5fc52ca]] dri2: Preserve compatibility with 1.6 DRI2 API/ABI + +### xserver 1.6.1.902 + +* The following 10 patches that fix front-buffer rendering with DRI2: + * Have these been tested to work with clients without the corresponding fixes? Obviously front-buffer rendering would remain broken in that case. -[[MichelDaenzer|MichelDaenzer]] + * In theory, yes. In practice, no. Commit ff6c7764c2909e4126403b7211faa6c58556b341 changes the DRI2 interface between the driver and the extension. When xf86-driver-intel was updated to the new interface, we changed the way that clients request stencils buffers (using DRI2BufferDepthStencil vs. DRI2BufferDepth and DRI2BufferStencil). This affects one driver (intel), and it will be resolved by Intel's 2009Q2 in a couple weeks. In the mean time, users upgrading their xserver can use DRI1. I don't think this should block pulling these patches to 1.6. If anything, not having them in 1.6 soon potentiates the same sort of compatibility for other drivers that will be releasing DRI2 support soon. - [[IanRomanick|IanRomanick]] + * For the record, those patches require a new release of dri2proto - [[RemiCardona|RemiCardona]] + * Yes. [[KristianHoegsberg|KristianHoegsberg]] released dri2proto 2.1 on June 12th, 2009. - [[IanRomanick|IanRomanick]] + * [[03aebed519986c4dd03e02b3b3d4af1f64595ca7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=03aebed519986c4dd03e02b3b3d4af1f64595ca7]] Use a #define instead of a magic number + * [[f250eea2e90fc50bec5214c2f41132b95edc2c46|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f250eea2e90fc50bec5214c2f41132b95edc2c46]] DRI2: update DRI2 private drawable width & height according to X drawable + * [[0d9d3f3e361f769822caedccf4c2a58cc9930ecc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0d9d3f3e361f769822caedccf4c2a58cc9930ecc]] DRI2: Force allocation of real-front buffer for non-windows as well + * [[ff6c7764c2909e4126403b7211faa6c58556b341|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ff6c7764c2909e4126403b7211faa6c58556b341]] DRI2: Implement protocol for DRI2GetBuffersWithFormat + * [[28ddfc88d8d547941c7f4713db527a3c2f9ec35a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=28ddfc88d8d547941c7f4713db527a3c2f9ec35a]] DRI2: Add interface for drivers to query DRI2 extension version + * [[d1e916d29be8b470cbc8cadcf6e83991fdbc5a9f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d1e916d29be8b470cbc8cadcf6e83991fdbc5a9f]] DRI2: Add missing front-buffer flush callback. + * [[de1e43181bd670877b994db221ad8a04b5d63324|http://cgit.freedesktop.org/xorg/xserver/commit/?id=de1e43181bd670877b994db221ad8a04b5d63324]] DRI2: Don't leave empty entries in private->buffers + * [[567cf67959b30432ae30f4851ec17b3a375ab838|http://cgit.freedesktop.org/xorg/xserver/commit/?id=567cf67959b30432ae30f4851ec17b3a375ab838]] DRI2: Synchronize the contents of the real and fake front-buffers + * [[f1a995d1496d73741731e32f475097c44a8da972|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f1a995d1496d73741731e32f475097c44a8da972]] DRI2: Do not send the real front buffer of a window to the client + * [[aa2928325fe51d94a636dde9c090e8f54a311a12|http://cgit.freedesktop.org/xorg/xserver/commit/?id=aa2928325fe51d94a636dde9c090e8f54a311a12]] DRI2: Add fake front-buffer to request list for windows +* [[557dbadf3be273255e8fdb12d9321f4e88bf2b65|http://cgit.freedesktop.org/xorg/xserver/commit/?id=557dbadf3be273255e8fdb12d9321f4e88bf2b65]] [[XkbSetNamedIndicator|XkbSetNamedIndicator]] should ignore SD's without LED's +* [[b0ad9e1ced9619f37acf77764c395c57b86cf463|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b0ad9e1ced9619f37acf77764c395c57b86cf463]] Remove long-gone '-co' option from Xserver man page +* [[d0dd649035fc3698c5b436f9d9d248116aa106a3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d0dd649035fc3698c5b436f9d9d248116aa106a3]] Remove references to rgb.txt from files section of Xserver and Xorg man page +* [[7d0f7518c2235a9dc783029971259ddaada2db20|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7d0f7518c2235a9dc783029971259ddaada2db20]] Fix byte swapping of XF86VidMode{Get,Set}[[GammaRamp|GammaRamp]] +* [[faf7dfa099f5b42a703313fbd1bf8afdad07a179|http://cgit.freedesktop.org/xorg/xserver/commit/?id=faf7dfa099f5b42a703313fbd1bf8afdad07a179]] randr12: looking up these bits if randr isn't initialised is bad. +* [[0e0642ee9466d3268476d0084a83a9d93a4aa555|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0e0642ee9466d3268476d0084a83a9d93a4aa555]] os: don't malloc memory in LogVMessageVerb. +* [[8b583ca2b21155359c6255f406c96599b277c762|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8b583ca2b21155359c6255f406c96599b277c762]] Xi: fix copy/paste error causing sizeof against wrong struct. +* [[50cc8adafca4ba3838d468278d6eb8a4692d2488|http://cgit.freedesktop.org/xorg/xserver/commit/?id=50cc8adafca4ba3838d468278d6eb8a4692d2488]] Xi: don't double-swap the XListDeviceProperties reply. +* [[1c101d75d4855b2698e3fc8d2dd662f20585812f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c101d75d4855b2698e3fc8d2dd662f20585812f]] Don't leak canonical module name and patterns if module is built-in +* [[66539cc05d0b017b9feb4a038499907810140623|http://cgit.freedesktop.org/xorg/xserver/commit/?id=66539cc05d0b017b9feb4a038499907810140623]] Don't leak default font path when appending built-ins +* [[91b697efdefba125348dbcaf584ee51a7f8c9bf6|http://cgit.freedesktop.org/xorg/xserver/commit/?id=91b697efdefba125348dbcaf584ee51a7f8c9bf6]] Support setTexBuffer2 in AIGLX. (Needs mesa 7.5 or #ifdef protection code to work with mesa 7.4 -- [[RemiCardona|RemiCardona]]) +* [[525aa17f804d37d1cfcbbf6b8e6cddb45e999b20|http://cgit.freedesktop.org/xorg/xserver/commit/?id=525aa17f804d37d1cfcbbf6b8e6cddb45e999b20]] Bug #6428, #16458, #21464: Fix crash due to uninitialized VModMap fields. +* [[850675d4de4373e5df95507dbf2cd9affaaf54bc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=850675d4de4373e5df95507dbf2cd9affaaf54bc]] EXA: Take GC client clip type into account for migration. +* [[7c8327f0a75087a85864256a9cea80dd4b86def5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7c8327f0a75087a85864256a9cea80dd4b86def5]] EXA: Always damage glyph cache pixmap manually after uploading a glyph. +* [[737b49199a05299486064e6e762cf2a2f6f95be6|http://cgit.freedesktop.org/xorg/xserver/commit/?id=737b49199a05299486064e6e762cf2a2f6f95be6]] xfree86: restore default off for [[DontZap|DontZap]] +* [[04c9e80f083659e63cffec8969fb3a0cfc551a97|http://cgit.freedesktop.org/xorg/xserver/commit/?id=04c9e80f083659e63cffec8969fb3a0cfc551a97]] off by one fixes from alanc, rebased for the 1.6 branch +* [[b746a00cffca5c553b607a8e9c1074294a23b443|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b746a00cffca5c553b607a8e9c1074294a23b443]] Resync COPYING file with notices in code base as of xorg-server-1.6.1 +* [[Turn off ExaOptimizeMigration by default|http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob_plain;f=debian/patches/Change-default-for-ExaOptimizeMigration-to-false.diff;h=41930f9a255225ccf2fec6085975a6c4bb26b79c;hb=e026fa4df402a207f01b3bf99f70b355ca8719da]] as suggested by [[MichelDaenzer|MichelDaenzer]] in [[http://lists.x.org/pipermail/xorg-devel/2009-February/000187.html|http://lists.x.org/pipermail/xorg-devel/2009-February/000187.html]] +* [[6f9e22049862ee9ac7f604411d005d8bb1b2dd1c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6f9e22049862ee9ac7f604411d005d8bb1b2dd1c]] dix: ensure Activate/DeactivateGrab has a valid value. +* [[b1b5ec45c1cb650ccb8c659218f9481379c777d9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b1b5ec45c1cb650ccb8c659218f9481379c777d9]] kdrive: set Activate/Deactivate grab for input devices (#21591) +* [[e244a5991e2cc55f5aa2f6e5255f1dabf56f0235|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e244a5991e2cc55f5aa2f6e5255f1dabf56f0235]] dix/randr: Add missing fields to SRR*[[NotifyEvent|NotifyEvent]]() (#21987) +* [[69a9545d1f8110841538410818df19fd960412c5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=69a9545d1f8110841538410818df19fd960412c5]] Make RANDR 'set' timestamps follow client specified time. Bug 21987. +* [[Fedora:xserver-1.6.0-xinerama-cursors.patch|http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/F-11/xserver-1.6.0-xinerama-cursors.patch?revision=1.1]] - backport to 1.6 of [[66089e9129a821cfb1983d3d35f41b975a52de5e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=66089e9129a821cfb1983d3d35f41b975a52de5e]] xfree86: fix SWCursor check in xf86CursorSetCursor. + +### xserver 1.6.1.901 + +* [[44227ef1b77467c76147b9bf79bdd0e6305a522a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=44227ef1b77467c76147b9bf79bdd0e6305a522a]] DRI2: Send the version the code actually supports +* [[4cfb36f6ad2df01215028fec48d99239a0e4496b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=4cfb36f6ad2df01215028fec48d99239a0e4496b]] EXA: Handle separate alpha maps properly in Composite fallback, take two. +* [[3948b523893d3d44b6a088340c4252e969613769|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3948b523893d3d44b6a088340c4252e969613769]] EXA: Guard empty pending region warning by DEBUG_MIGRATE. +* [[Bug 20557|http://bugs.freedesktop.org/show_bug.cgi?id=20557]] Xinerama causes segfault on keypress on xserver-1.6.0 + * Patch at [[dix: ignore non-pointer events in XineramaCheckMotion (#20557)|http://bugs.freedesktop.org/attachment.cgi?id=24224]] +* [[efa31092d6703397121a0ada4f7205a8ecad3d3d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=efa31092d6703397121a0ada4f7205a8ecad3d3d]] xfree86: Remove device from inputInfo.devices if [[ActivateDevice|ActivateDevice]] failed. +* [[063833f3a6d9f8f657e3de309c8d6d5c3d606513|http://cgit.freedesktop.org/xorg/xserver/commit/?id=063833f3a6d9f8f657e3de309c8d6d5c3d606513]] Add XI 1.5 event and requests to protocol.txt +* [[4f86ee61a4abf7a29e565d095aa08abd0ca9dc66|http://cgit.freedesktop.org/xorg/xserver/commit/?id=4f86ee61a4abf7a29e565d095aa08abd0ca9dc66]] Add RandR 1.3 requests to protocol.txt +* [[b1dab580bdfb4acfe3feddeda6e760098ec4922a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b1dab580bdfb4acfe3feddeda6e760098ec4922a]] xfree86: edid quirk for Philips LCD LP154W01-TLAJ +* [[0dfb97f15f591f85e079f5829c77d0c328d00464|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0dfb97f15f591f85e079f5829c77d0c328d00464]] Bug#21324: Add quirk for Iiyama Vision Master 450 +* [[94648bb797d94b025746c60679c584e5be2fae28|http://cgit.freedesktop.org/xorg/xserver/commit/?id=94648bb797d94b025746c60679c584e5be2fae28]] Bug #21077: flicker when setting modes with KMS +* [[Bug 21459|https://bugs.freedesktop.org/show_bug.cgi?id=21459]] bogus events sent out whe XKB is disables + * Patch at [[Xi: don't send XKB mapping notifications when XKB is disabled|https://bugs.freedesktop.org/attachment.cgi?id=25226]] +* [[Bug 21455|http://bugs.freedesktop.org/show_bug.cgi?id=21455]] Bad event list generated when adding fake [[KeyRelease|KeyRelease]] + * Patch at [[dix: fix calculation of number of fake KeyRelease events|http://bugs.freedesktop.org/attachment.cgi?id=25218]] + +## xserver 1.6.1 + +* [[7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a]] glx: Fix drawable private leak on destroy +* [[603db34337a61754e0c5f71525011d10eab78411|http://cgit.freedesktop.org/xorg/xserver/commit/?id=603db34337a61754e0c5f71525011d10eab78411]] Xext: set POINTER_SCREEN flag in XTestFakeInput if necessary. (RH #490984) +* [[8a6ed44a8b2fc5f14729dc54fec17607ced03859|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8a6ed44a8b2fc5f14729dc54fec17607ced03859]] randr: Fix thinko in xf86TargetPreferred + * patch for bug causing only one mode available in randr +* [[669f6810af9a89187d6149841925fe765f3988ff|http://cgit.freedesktop.org/xorg/xserver/commit/?id=669f6810af9a89187d6149841925fe765f3988ff]] Xi: add XIPropToInt() auxiliary function. + * this patch is required for simple merging of the XATOM_FLOAT one. +* [[a48c81dcdf569a3f634ac23e08d2491354de6a36|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a48c81dcdf569a3f634ac23e08d2491354de6a36]] Xi: add XATOM_FLOAT to server-defined properties. +* [[0d9a42dc0380d1583889b6b6521bd5a2451735d4|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0d9a42dc0380d1583889b6b6521bd5a2451735d4]] Xi: don't crash on a NULL property name, just return None. +* [[f5bf1fdaf36163d5c2f1b9b51df96326ebbb0e9c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f5bf1fdaf36163d5c2f1b9b51df96326ebbb0e9c]] xkb: Fix wrong colour reference in XKB geometry copying. #20081 + +## xserver 1.6.0 + +* [[ab61033700b5383a7a15370dd054eaa80e72e811|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ab61033700b5383a7a15370dd054eaa80e72e811]] Add Extensions section to xorg.conf man page +* [[4901b8147e593d26d7a31a9b73a201254b948916|http://cgit.freedesktop.org/xorg/xserver/commit/?id=4901b8147e593d26d7a31a9b73a201254b948916]] XQuartz: Fix caps-lock +* [[ef320bdd5ec3419abba77041d3a4d96a3ff87563|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ef320bdd5ec3419abba77041d3a4d96a3ff87563]] DRI1: Make DRICreateDrawable return TRUE for pixmaps. (Fixes regression from a26c77ff432d2e85a2665fc36fca25143460c476 below) +* [[24c562f04b41d219c34f5fa3f963564accf329f2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=24c562f04b41d219c34f5fa3f963564accf329f2]] Update See Also lists in Xorg & xorg.conf man pages +* [[5f3f14179edf48aad518f6f707bfdc37c27267c6|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5f3f14179edf48aad518f6f707bfdc37c27267c6]] Xorg server core dump in xf86RandRModeRefresh(NULL) +* [[6a1850b8c677e2a2993f6f6b731ee3d35aa55d09|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6a1850b8c677e2a2993f6f6b731ee3d35aa55d09]] Correct warning for unknown [[GlxVisuals|GlxVisuals]] option in conf file +* [[8c560422b44e012053612754430d2b87dc44ed59|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8c560422b44e012053612754430d2b87dc44ed59]] More man page updates for 1.6 release for Xorg, xorg.conf & exa man pages +* [[b0d371ab0a6efd4956c3677faa20b2ac15c33765|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b0d371ab0a6efd4956c3677faa20b2ac15c33765]] randr: Don't send output property events on server exit +* [[c1db925d10fd37077bed90612ed95c3fd20cd2e2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c1db925d10fd37077bed90612ed95c3fd20cd2e2]] Add atKeynames.h to libdmxinput_a_SOURCES so it's included in tarballs +* [[15bb6abd59fdefe7037237faaea1a39711a972ed|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=15bb6abd59fdefe7037237faaea1a39711a972ed]] XQuartz 39: XQuartz GLX Updates for 1.6 +* [[a665ed16f736cf1901b89448dc5d37f4d16dfaf4|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=a665ed16f736cf1901b89448dc5d37f4d16dfaf4]] XQuartz 40: XQuartz GLX Updates for 1.6 +* [[d514152195452ae11ec7769c76489651620ad380|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=d514152195452ae11ec7769c76489651620ad380]] XQuartz 41: XQuartz GLX Updates for 1.6 +* [[6461729647ff4441d80811e73f0c0d2f108f2700|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=6461729647ff4441d80811e73f0c0d2f108f2700]] XQuartz 42: Only call [[DarwinUpdateModKeys|DarwinUpdateModKeys]] when needed +* [[9cf264e67744262b9f45079e6cd752eb3e3b0e08|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=9cf264e67744262b9f45079e6cd752eb3e3b0e08]] XQuartz 43: XQuartz xpr DRI Updates for GLX +* [[f020900641b44a1142e5c2198e9678de2744454e|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=f020900641b44a1142e5c2198e9678de2744454e]] XQuartz 44: Fix builddir != srcdir issues and undef _XSERVER64 where appropriate on fat binary compilation +* [[94e417ac87a98cd5c6bf2d7c495d702748398931|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=94e417ac87a98cd5c6bf2d7c495d702748398931]] XQuartz 45: mieq: Wait for the server to finish initializing before letting other threads mieqEnqueue +* [[b57cb05c69acbedb00a97234099ea104309aa2cb|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=b57cb05c69acbedb00a97234099ea104309aa2cb]] XQuartz 46: [[SnowLeopard|SnowLeopard]] Help Book Name +* [[143224405ba74929c702a95de52b56df140b0d1b|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=143224405ba74929c702a95de52b56df140b0d1b]] XQuartz 47: [[SnowLeopard|SnowLeopard]] OpenGL.framework compat fix +* [[639f289dcdbe00a516820f573c01a8339e120ed4|http://cgit.freedesktop.org/xorg/xserver/commit/?id=639f289dcdbe00a516820f573c01a8339e120ed4]] EXA: Declare glyph cache picture as component-alpha when necessary. (#19233) +* [[5f3188228eb988bd8f08b62c84f98a8ff66ee283|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5f3188228eb988bd8f08b62c84f98a8ff66ee283]] Avoid a potential endless loop. (#19343) +* [[77c7a64e8885696665556c9fbcb3cffb552e367a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=77c7a64e8885696665556c9fbcb3cffb552e367a]] RandR rotations and reflections offset by one pixel + +#### 2008-12-9 + +* [[1dfed222e93f4684c2a450944a9a0ea9e085c43f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1dfed222e93f4684c2a450944a9a0ea9e085c43f]] Xext: fix [[MultiBuffer|MultiBuffer]] compilation error with [[TryClientEvents|TryClientEvents]]. (#18835) +* Revert [[8da8a0fec4b1b9d9208635dedb2f449dc99e0004|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8da8a0fec4b1b9d9208635dedb2f449dc99e0004]] dmx: claim we support XI 2. +* [[fd2d40b7ec5d685dac55453eb1f2da672dc83126|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fd2d40b7ec5d685dac55453eb1f2da672dc83126]] Xi: change XIUnRegisterPropertyHandler to XIUnregisterPropertyHandler +* [[110a71d11ab7a1a55a6a24d792457fdef0b0746d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=110a71d11ab7a1a55a6a24d792457fdef0b0746d]] Test for DRI2 extension in dri_internal.h and only enable AIGLX DRI2 if found. +* [[0b5ecabfb803cd820338fb0364521fe39b05578b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b5ecabfb803cd820338fb0364521fe39b05578b]] randr: add swapped dispatch for RR[GS]etCrtcTransform +* [[dd128ddcdcbe254a9cdd973590f6a979a7f0427e|http://cgit.freedesktop.org/xorg/xserver/patch/?id=dd128ddcdcbe254a9cdd973590f6a979a7f0427e]] If AEI is on, disable 'vmmouse' in addition to 'kbd' and 'mouse'. +* [[ffb484f7ef84099019b196ef97bfb2355eb6d52a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ffb484f7ef84099019b196ef97bfb2355eb6d52a]] randr: Avoid needlessly creating a shadow framebuffer. +* [[39db182b637041255ed6dac739ff77c8e4e07c30|http://cgit.freedesktop.org/xorg/xserver/commit/?id=39db182b637041255ed6dac739ff77c8e4e07c30]] xfree86: init EQ before trying to initialise the devices (#18890) +* [[78a62d7713c708d067d8824ec41b0a0225c1997f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=78a62d7713c708d067d8824ec41b0a0225c1997f]] Xi: XIGetDevice needs to ignore the MORE_EVENTS flag. +* [[ee1a6c28418a6dad6c89f79a994f27bfbaa77368|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ee1a6c28418a6dad6c89f79a994f27bfbaa77368]] dix: fix calculation of valuator events. +* [[d507f60689f4e14383b0d24e63afc8cf836360d5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d507f60689f4e14383b0d24e63afc8cf836360d5]] xfree86: don't [[FatalError|FatalError]] on "too many input devices". +* [[bbf811514d3cdf84790bad5b852942a4e636902b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=bbf811514d3cdf84790bad5b852942a4e636902b]] ddxCtrls.c: XkbDDXUsesSoftRepeat always returns 1 now +* [[58a27d2932164e43c0db42b1286ec2f95250b420|http://cgit.freedesktop.org/xorg/xserver/commit/?id=58a27d2932164e43c0db42b1286ec2f95250b420]] Default to x86emu even on i386 linux + +#### 2008-12-16 + +* [[0bdfdaa7df8105c7ffc3248a4fdd5f64da67103c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0bdfdaa7df8105c7ffc3248a4fdd5f64da67103c]] randr: Add [GS]etOutputPrimary +* [[2ef02833d614c42693e019a444560e84f501b5dc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2ef02833d614c42693e019a444560e84f501b5dc]] randr: Mangle compat Xinerama reply based on primary output +* [[f0234a9eb88ed103bca7db73a833c472ab95b48f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f0234a9eb88ed103bca7db73a833c472ab95b48f]] randr: Mangle [[GetScreenResources|GetScreenResources]] sort order based on primary output +* [[2bc53ce66828b6c177e3298fa2f326c77c93e136|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2bc53ce66828b6c177e3298fa2f326c77c93e136]] randr: use primary output for RRFirstOutput() +* [[a82f10c5dd9fa74ff18759ab288bbd9c8b7ac4de|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a82f10c5dd9fa74ff18759ab288bbd9c8b7ac4de]] randr: clear primaryOutput when the output is deleted +* [[ca56d764d2be28c64fe15c9e37d534ef00117ad2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ca56d764d2be28c64fe15c9e37d534ef00117ad2]] xsync: Fix wakeup storm in idletime counter. +* [[7be6520d94df874c6bbd46d06a1830a12d0967f2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7be6520d94df874c6bbd46d06a1830a12d0967f2]] dolt: allow older versions of bash to compile the xserver (#19031). +* [[Xi: don't update VCP's valuators from DeviceValuator events #18882|http://lists.freedesktop.org/archives/xorg/2008-December/041231.html]] +* [[463e02e7de5da3e582a3a049110a476713c7210e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=463e02e7de5da3e582a3a049110a476713c7210e]] xkb: Allow NULL as rulesFile in [[XkbSetRulesDflts|XkbSetRulesDflts]]. +* [[bb072019fa8dd292a50ef433d05caeefd1304a73|http://cgit.freedesktop.org/xorg/xserver/commit/?id=bb072019fa8dd292a50ef433d05caeefd1304a73]] xfree86: don't render SW cursors for devices attached to VCP (#16805) +* [[8e3279134987a45f2a89c963ef2d33bc3d3c8179|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8e3279134987a45f2a89c963ef2d33bc3d3c8179]] xfree86: fix compiler warning (use of uninitialized variable) +* [[fb2a8d0e59a3d187255538f6add22ec67551507a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fb2a8d0e59a3d187255538f6add22ec67551507a]] Xi: silence compiler warning +* [[cbb9ee57f8f29d2a1c39946381471fcd3b8e495e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cbb9ee57f8f29d2a1c39946381471fcd3b8e495e]] XQuartz 01: pbproxy: Simplify linking +* [[451050b1e2dc0f2f6356d74ddb6f52183a794e8f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=451050b1e2dc0f2f6356d74ddb6f52183a794e8f]] XQuartz 02: Removed unused option from configure.ac for launchd +* [[9ac2e68d86ed1eb6e3f6c900c60908813eca140e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9ac2e68d86ed1eb6e3f6c900c60908813eca140e]] XQuartz 03: Corrected name/command labels in the customization widget +* [[70930f6d31cc2ca16b40c17e101b106506a8337a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=70930f6d31cc2ca16b40c17e101b106506a8337a]] XQuartz 04: darwinPointer reports the actual pixel position now rather than a relative position +* [[8065953ea8c3b7d10c775f6b7fec629bb5a2c83c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8065953ea8c3b7d10c775f6b7fec629bb5a2c83c]] XQuartz 05: Removed some debug spew +* [[99b2cbf061a9d074e66e6220dc08f8b4624ea6bb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=99b2cbf061a9d074e66e6220dc08f8b4624ea6bb]] XQuartz 06: unsetenv(DISPLAY) if we're not org.x.X11 +* [[9cbed0a325175e7ddb751db54fe6c0f5a5cedd16|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9cbed0a325175e7ddb751db54fe6c0f5a5cedd16]] XQuartz 07: unset DISPLAY if we didn't get a launchd socket handoff +* [[fdf64256127b2661bd6aa81ac694350028d36c43|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fdf64256127b2661bd6aa81ac694350028d36c43]] XQuartz 08: Avoid using login /bin/sh blech. Just use a bash script to start the app, so it will inherit the right environment +* [[13eff12902be1b25d0ccc2089e08305f88949f32|http://cgit.freedesktop.org/xorg/xserver/commit/?id=13eff12902be1b25d0ccc2089e08305f88949f32]] XQuartz 09: fixed make dist +* [[5926b213b39a90601c73f026dc0699723f5ed10d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5926b213b39a90601c73f026dc0699723f5ed10d]] XQuartz 10: Fix path to executable +* [[fd31984e0c0f9a37087cd1cffaa3ba116b12c2e5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fd31984e0c0f9a37087cd1cffaa3ba116b12c2e5]] XQuartz 11: Tiger fix, don't call Xplugin code in the Appkit thread if Xplugin isn't threadsafe +* [[73987010b2ef9c67b6614e226c6fae65d834d8f3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=73987010b2ef9c67b6614e226c6fae65d834d8f3]] XQuartz 12: Updated menu item ordering for better HIG compliance +* [[2a61397d17339113b9e37995b06ca543589814ce|http://cgit.freedesktop.org/xorg/xserver/commit/?id=2a61397d17339113b9e37995b06ca543589814ce]] Fix typo in xf86PickCrtcs() +* [[f1c9b5ab230cbb4124d8d476ae4886d05022adcb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f1c9b5ab230cbb4124d8d476ae4886d05022adcb]] GLX: Changes resulting from changes to Mesa generator scripts / data +* [[7aa29b9d66c3cd0f8af4fafbe92efd0c0556d225|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7aa29b9d66c3cd0f8af4fafbe92efd0c0556d225]] Support -sharevts on FreeBSD. + +#### 2009-1-12 + +* [[0c6987df3b9b3a37d201d740d8248c326449835e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0c6987df3b9b3a37d201d740d8248c326449835e]] XAA: Disable offscreen pixmaps by default. +* [[6d8ea5104cf97dbf64612f58fc06f94f869ed5ec|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6d8ea5104cf97dbf64612f58fc06f94f869ed5ec]] Fix compilation with -Werror=format-security (and a small memleak) +* [[d61e902aab92c262e6c8ee9cd70aec4493cf6cae|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d61e902aab92c262e6c8ee9cd70aec4493cf6cae]] Don't log audit messages when -audit 0 specified +* [[d281866b74f7067f2704c278fe9720eafc0ee5ef|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d281866b74f7067f2704c278fe9720eafc0ee5ef]] mi 1: Clean up [[CopyGetMasterEvent|CopyGetMasterEvent]], re-use the memory. (NB: it seems [[0b4fef6337d88ae8ef05b8b73941350a9007565c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0b4fef6337d88ae8ef05b8b73941350a9007565c]] is needed for this to work - coling) +* [[a939368ab8140d48c1da4ba0bb229d13b221189c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a939368ab8140d48c1da4ba0bb229d13b221189c]] mi 2: Reuse memory in mieqProcessInputEvents rather than making excessive calls to calloc() +* [[aedd2f566df585db7a1614f302cc8d3feda54275|http://cgit.freedesktop.org/xorg/xserver/commit/?id=aedd2f566df585db7a1614f302cc8d3feda54275]] randr/xfree86: Fix a one off error in the panning calculations. +* [[102abeda37d6b62971a9952efa0453e38504ae0b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=102abeda37d6b62971a9952efa0453e38504ae0b]] XQuartz 13: Name the startup shell script X11 for better compatability +* [[fd6fb6a2771df152b57f9dfb159fa42a3b1d37cd|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=fd6fb6a2771df152b57f9dfb159fa42a3b1d37cd]] XQuartz 14: Get rid of white rectangle bug +* [[c3812aec973b7341a600e5d2d07d5a7f15abd609|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=c3812aec973b7341a600e5d2d07d5a7f15abd609]] XQuartz 15: Changed X11.sh to allow use of a ~/.x11run as requested by users of alternate shells +* [[ecc3a7b6090552c309fe8e264d527ddd666a5761|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=ecc3a7b6090552c309fe8e264d527ddd666a5761]] XQuartz 16: update quoting in case X11.app is moved to a directory with a space. +* [[4c256c0e9c4fe61990343c8bcf2e352c83d76e69|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=4c256c0e9c4fe61990343c8bcf2e352c83d76e69]] XQuartz 17: pbproxy: Release display notification lock when not needed to avoid a deadlock +* [[7dc0dafef1d241d396f215c506ec2d4f7d8e3a24|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=7dc0dafef1d241d396f215c506ec2d4f7d8e3a24]] XQuartz 18: Run applications via '/bin/sh -c ...' to support users who expect shell parsing +* [[7e7758e1780326ad867be74dbd583a154bad017b|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=7e7758e1780326ad867be74dbd583a154bad017b]] XQuartz 19: Update our "screens" when we toggle rootless rather than when we toggle fullscreen (makes our root window consistent and avoids a crash due to our root window being smaller than our screen) +* [[84f0c03418bf74188596635dcac128fc05f204ad|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=84f0c03418bf74188596635dcac128fc05f204ad]] XQuartz 20: Don't use keycode 0 to determine !swallow since our most common key to swallow is actually keycode=0 +* [[85347902d97f2d4937f63ae1fac62ee46a61c82f|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=85347902d97f2d4937f63ae1fac62ee46a61c82f]] XQuartz 22: Re-enable rlAccel +* [[61ae56f97326c57dda05632ca9f4873238ee18e1|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=61ae56f97326c57dda05632ca9f4873238ee18e1]] XQuartz 23: Reposition windows when we enter fullscreen to ensure our root window +* [[338f096861136fb6c4f604e93ff21277252676b7|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=338f096861136fb6c4f604e93ff21277252676b7]] XQuartz 24: Try harder to get the user's login environment +* [[8c6e8fa811c782c85e7fefbe75fe5480098739ae|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=8c6e8fa811c782c85e7fefbe75fe5480098739ae]] XQuartz 25: pbproxy: We explicitly need libX11 for pbproxy +* [[d790c9dd041a2c8e3513d14a556333219d0f8d5e|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=d790c9dd041a2c8e3513d14a556333219d0f8d5e]] XQuartz 26: Updated man page fullscreen_hotkeys fullscreen_menu +* [[c67a3e2972c75c02f1aeed94bc0a3c5272422267|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=c67a3e2972c75c02f1aeed94bc0a3c5272422267]] XQuartz 27: Workaround OSX VNC server bug for modifier key state +* [[4be8d7346b9fdc014b72dd6c404ceecc0ef0d245|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=4be8d7346b9fdc014b72dd6c404ceecc0ef0d245]] XQuartz 28: Better avoid stuck keys on context switches +* [[9faf3de7e5610af340b92acb1b86bf03b6f2241a|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=9faf3de7e5610af340b92acb1b86bf03b6f2241a]] XQuartz 29: Honor system key repeat rate +* [[0d2621b6d4684ec62e67156a5a9dbdd3297f9cb0|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=0d2621b6d4684ec62e67156a5a9dbdd3297f9cb0]] XQuartz 30: Make sure to reset the saved key state when deactivating X11.app +* [[0676a580fcc05d54049269028a34358935a4101c|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=0676a580fcc05d54049269028a34358935a4101c]] XQuartz 31: Don't use NX_SECONDARYFNMASK, NX_NUMERICPADMASK, NX_HELPMASK +* [[adbfd49da2453b58a9e13b09c62e0611ea1c3f77|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=adbfd49da2453b58a9e13b09c62e0611ea1c3f77]] XQuartz 32: pbproxy: Push dpy init and CFRunLoop hook setup into the pbproxy thread to avoid possible deadlock +* [[df6ca888b0c04fdf4ff2d7fb4a414275b983ed34|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=df6ca888b0c04fdf4ff2d7fb4a414275b983ed34]] XQuartz 33: copyright date updated for 2009 +* [[65ab2f44ea7fc4d87e021bed548eda81fc3cbae7|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=65ab2f44ea7fc4d87e021bed548eda81fc3cbae7]] XQuartz 34: use a more compatible header for availability macros +* [[cc677cb4f458f371a4012ce0dc1121a52a2cb699|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=cc677cb4f458f371a4012ce0dc1121a52a2cb699]] XQuartz 35: cpp magic for 32/64 fat binary builds on OSX +* [[3534a5e5d9c5af85149c799f324257f89507fa23|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3534a5e5d9c5af85149c799f324257f89507fa23]] exa: Allow drivers to set non-NULL devPrivate.ptr for !offscreen pixmaps. +* [[027b440d4f9f0cdd46addff46fd2d5c44cd5c847|http://cgit.freedesktop.org/xorg/xserver/commit/?id=027b440d4f9f0cdd46addff46fd2d5c44cd5c847]] exa: preparing as source and finishing access as mask is a bad idea +* [[e1a3a1a0d85c9971aea65c2228b5fd4dbf3bf57a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e1a3a1a0d85c9971aea65c2228b5fd4dbf3bf57a]] xfree86: don't call [[CheckMotion|CheckMotion]] if a device hasn't been enabled. #19176 +* [[27011254c4de4e573a0851bf46892fb488db6522|http://cgit.freedesktop.org/xorg/xserver/commit/?id=27011254c4de4e573a0851bf46892fb488db6522]] xfree86: If an input device failed to activate, return immediately. +* [[aea6f19f25e13768b1d09fac4991d6a5e6c2cdac|http://cgit.freedesktop.org/xorg/xserver/commit/?id=aea6f19f25e13768b1d09fac4991d6a5e6c2cdac]] xfree86: don't restore the TTY mode if we didn't initialize it ourselves +* [[9c5dd7337fa93fb1650cc017e523b939dcbf482a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9c5dd7337fa93fb1650cc017e523b939dcbf482a]] Let the DDX decide on the [[XkbRulesDefaults|XkbRulesDefaults]]. +* [[13de7511b17b57a28668e1a60b196ccfe61dbcbe|http://cgit.freedesktop.org/xorg/xserver/commit/?id=13de7511b17b57a28668e1a60b196ccfe61dbcbe]] xfree86: Only use the evdev ruleset on linux +* [[1962af7ee3bdf54cfa674187dea67b9ad36cd5a1|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=1962af7ee3bdf54cfa674187dea67b9ad36cd5a1]] XQuartz 20.5: Added some debugging code that causes this next patch to fail if not merged first +* [[932ed6e949757926a17f7efe6b0255e38efa1152|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=932ed6e949757926a17f7efe6b0255e38efa1152]] XQuartz 21: Use depth=24 instead of [[FatalError|FatalError]] if we can't figure out our depth +* [[a1d35cee5907a76977ee43c49cb55c8f411c9794|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=a1d35cee5907a76977ee43c49cb55c8f411c9794]] XQuartz 36: Force DRI2 off on OSX +* [[c137f681680e1d04b1513a8be68aeda4d1c56fd5|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=c137f681680e1d04b1513a8be68aeda4d1c56fd5]] XQuartz 37: Misc 1.5->1.6 DDX changes for XQuartz +* [[7a8d2266861e74176b5310b83652a9c10a170494|http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.6-apple&id=7a8d2266861e74176b5310b83652a9c10a170494]] XQuartz 38: mieq locking for thread safety in XQuartz +* [[56efbc0986e782da45addb05ece9f456d41d7a90|http://cgit.freedesktop.org/xorg/xserver/commit/?id=56efbc0986e782da45addb05ece9f456d41d7a90]] dix: drop x/y back into last.valuators before updating the history (#19285) +* [[488d45295105daf10ccd17ca93ae6a6f4d0104f1|http://cgit.freedesktop.org/xorg/xserver/commit/?id=488d45295105daf10ccd17ca93ae6a6f4d0104f1]] dix: [[EnqueueEvent|EnqueueEvent]] and [[PlayReleasedEvent|PlayReleasedEvent]] need to handle [[DeviceMotionNotifies|DeviceMotionNotifies]] +* [[d36adf52a2b2711d22b11105f7bd907d4493fb9b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d36adf52a2b2711d22b11105f7bd907d4493fb9b]] dix: fix [[WarpPointer|WarpPointer]] calls for devices with custom valuator ranges (#19297) +* [[a85f0d6b98237d8a196de624207acf1983a1859a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a85f0d6b98237d8a196de624207acf1983a1859a]] Xi: fix use of button->down - bitflags instead of int arrays. +* [[515ce3e4ba42605a1ee9979e8bb5acd3cf6470a3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=515ce3e4ba42605a1ee9979e8bb5acd3cf6470a3]] xkb: fix typo - missing negation when checking button state. +* [[b2756a71a432f7cf7c870a48676c98625512558d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b2756a71a432f7cf7c870a48676c98625512558d]] Xext: Send out correct events in ProcXTestFakeInput +* [[3d549438c29004d78032ecc50ab45ca0e3f49623|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3d549438c29004d78032ecc50ab45ca0e3f49623]] Don't alter device button maps in [[DoSetPointerMapping|DoSetPointerMapping]] +* [[d645721170b1196e5064b397cfbffd1da8c79bb1|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d645721170b1196e5064b397cfbffd1da8c79bb1]] mi: ensure chained button mappings from SD -> MD (#19282) +* [[f7f85f696570541e2dd43462675de9e6ee46f545|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f7f85f696570541e2dd43462675de9e6ee46f545]] Count the number of logically down buttons in buttonsDown +* [[717a961528ec69a6e630d536e15568670e0b398a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=717a961528ec69a6e630d536e15568670e0b398a]] Don't release grabs unless all buttons are up +* [[332d65ec7a6e94d75efe95d53742f137835274de|http://cgit.freedesktop.org/xorg/xserver/commit?id=332d65ec7a6e94d75efe95d53742f137835274de]] randr: Consider panned crtc's when calculating xinerama screen sizes. Question -- what about RRGetCrtcInfo? Resolved -- same as Xinerama + +#### 2009-2-17 + +* [[123093996507c4d3b6dc457240ce00f8ac42f410|http://cgit.freedesktop.org/xorg/xserver/commit/?id=76f18b94bd2719a8199334742d021c4d0806187d]] Add [[XkbDir|XkbDir]] to Files config file section +* [[123093996507c4d3b6dc457240ce00f8ac42f410|http://cgit.freedesktop.org/xorg/xserver/commit/?id=123093996507c4d3b6dc457240ce00f8ac42f410]] RANDR: Fail softly on [[GetPanning|GetPanning]] if the screen can't do it. +* [[49b93df8a3002db7196aa3fc1fd8dca1c12a55d6|http://cgit.freedesktop.org/xorg/xserver/commit/?id=49b93df8a3002db7196aa3fc1fd8dca1c12a55d6]] Default to use standard bitmap fonts, with builtins as fallback + * See [[http://lists.freedesktop.org/archives/xorg/2009-January/042632.html|http://lists.freedesktop.org/archives/xorg/2009-January/042632.html]] + * I've tested it in Xquartz, but I can't vouch for the hw/xfree86/* changes ... either way, something needs to be done to handle this - JH + * Tested with Xorg - DN +* [[a26c77ff432d2e85a2665fc36fca25143460c476|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a26c77ff432d2e85a2665fc36fca25143460c476]] glx: fix retval checks when failures occur for drawable creation. +* [[ea309e47457156b60aadbf113f04e5b6851029c8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ea309e47457156b60aadbf113f04e5b6851029c8]] Make crtc_notify wrap/unwrap code do nothing unless mode code is inuse +* [[b1d29784410b3b93037e5636f336ba608d8ad6e3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b1d29784410b3b93037e5636f336ba608d8ad6e3]] XQuartz 48: Remove extrenuous Activate/EnableDevice +* [[fd08be749e0b3c5de02a6ae8b3d21f92c5986157|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fd08be749e0b3c5de02a6ae8b3d21f92c5986157]] XQuartz 49: Conditionalize indirect.c for Tiger's OpenGL.framework +* [[0dbc356795bbab3889b5f1684f55bd193757d0c9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0dbc356795bbab3889b5f1684f55bd193757d0c9]] XQuartz 50: Fixes the condition in the previous patch to not exclude Leopard +* [[60bcdd687040db76490851d4b459284ce37020e0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=60bcdd687040db76490851d4b459284ce37020e0]] x11-input.fdi: Add options needed to handle adding USB devices on Solaris +* [[5100d829a4d71ce4a9fbc2b81694a1fb90066ccf|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5100d829a4d71ce4a9fbc2b81694a1fb90066ccf]] glx: Don't match fbconfigs to visuals with mismatched channel masks. +* [[Bug 19754|http://bugs.freedesktop.org/show_bug.cgi?id=19574]] Pressing a multimedia key will cause the X Server to crash +* [[9fe9b6e4ef669b192ee349e3290db5d2aeea273c|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9fe9b6e4ef669b192ee349e3290db5d2aeea273c]] mi: don't call [[UpdateSpriteForScreen|UpdateSpriteForScreen]] if we have Xinerama enabled. #18668 +* [[panning-for-server-1.6|http://cgit.freedesktop.org/xorg/xserver/log/?h=panning-for-server-1.6]] branch (5 commits) +* [[16b11cd03d8c5def07f0e598f237f71a37883a46|http://cgit.freedesktop.org/xorg/xserver/commit/?id=16b11cd03d8c5def07f0e598f237f71a37883a46]] Correct the display of resouce length in pci probe line. +* [[b33905234025f005819c7e2acd653a3a0ecfeb82|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b33905234025f005819c7e2acd653a3a0ecfeb82]] xfree86: always force RAW mode under linux. +* [[ac470dfb4fadaa0b28b6f8b57f4f13a20842b897|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ac470dfb4fadaa0b28b6f8b57f4f13a20842b897]] Check for and report errors writing xorg.conf.new from Xorg -configure +* [[bd713794ceaa1b2890522554562103c0a2d50f04|http://cgit.freedesktop.org/xorg/xserver/commit/?id=bd713794ceaa1b2890522554562103c0a2d50f04]] Correct error message if specified config file is not found + +### Xserver 1.6 + +* [[066b17028a35956a089815716e38571f305469c5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=066b17028a35956a089815716e38571f305469c5]] XQuartz: [[BuildFailure|BuildFailure]] fix from 516f8e2cad1311a09764e2633644188d1e3c31bb +* [[43967514cd57ad836d7fb85c8c9e58ada07e0232|http://cgit.freedesktop.org/xorg/xserver/commit/?id=43967514cd57ad836d7fb85c8c9e58ada07e0232]] XQuartz: Support version strings like W.X.Y.Z-XXXXX +* [[4039603413f9f46d7f725463a70b4a51838e0049|http://cgit.freedesktop.org/xorg/xserver/commit/?id=4039603413f9f46d7f725463a70b4a51838e0049]] glx: Inialize best_score before calculating visual scores +* [[d2cf562bbad553d7f09b70202134f5b6ada0114e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d2cf562bbad553d7f09b70202134f5b6ada0114e]] Make [[RgbPath|RgbPath]] keyword in xorg.conf a non-fatal error +* [[5cc67ae94c066dcac78072ad8a819c3b602d8bab|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5cc67ae94c066dcac78072ad8a819c3b602d8bab]] exa: kill of exaImageGlyphBlt + +### Rejected + +These changes were nominated, but found not suitable for a 1.6.x release, though they will be in 1.7.0 and later: + +* [[09df7cc5ad7b72d8a23c3e22fc718aad8c16f4d3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=09df7cc5ad7b72d8a23c3e22fc718aad8c16f4d3]] Avoid dereferencing NULL pScreen in xf86CrtcSetModeTransform(). +* [[58c4116c47543b5e30c2232e7bee8efc0b9be176|http://cgit.freedesktop.org/xorg/xserver/commit/?id=58c4116c47543b5e30c2232e7bee8efc0b9be176]] XQuartz 51: DRI - Fix code for pixmaps +* [[630518766b01022c49fe3a9e7d501808f71b06e2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=630518766b01022c49fe3a9e7d501808f71b06e2]] XQuartz 52: More GLXPixmap work for OSX +* [[e46f02fa2de79261221b42ab73f9daa2ce8ac650|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e46f02fa2de79261221b42ab73f9daa2ce8ac650]] Xext: allocate a separate event list for XTest events (#23100) (does not apply as-is cleanly) (unnecessary as 1.6 doesn't use the DIX event queue from SIGIO) +* [[bfb219f532f3c78ba905424365ee7c5f7b5f21a2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=bfb219f532f3c78ba905424365ee7c5f7b5f21a2]] input: allow for detectable autorepeat. (#22515) + * too invasive, imo. this patch has indentation stuff + XI2-dependent stuff that doesn't work on 1.6, so it requires extra time and testing to apply. [whot] +* [[34eddbbb73bb16395dba0818247909c1b4bee4c2|http://cgit.freedesktop.org/xorg/xserver/commit/?id=34eddbbb73bb16395dba0818247909c1b4bee4c2]] Fix undefined symbols on alpha + * Not needed on 1.6 as these symbols were already _X_EXPORT'd + + +--- + + + + +## Features Removed + +* X server libraries: [[cfb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0dab6fa3582b70ccd0f01459902415c28dbc81ff]], [[afb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=20ea99c655140e101f2d20cfab78fb22765fec62]], [[mfb/xf1bpp|http://cgit.freedesktop.org/xorg/xserver/commit/?id=eabcfce0a68d504d11be9479f09e66f574dd2f21]] +* X server support for obsolete/unused/broken/unmaintained extensions: [[AppGroup|http://cgit.freedesktop.org/xorg/xserver/commit/?id=eafaf40fb3368ca7e4cf48336fdb7a6c9f536bfa]], [[EVI|http://cgit.freedesktop.org/xorg/xserver/commit/?id=13adef8a17d8815f4db2aaac30ae04438e125343]], [[MIT-SUNDRY-NONSTANDARD|http://cgit.freedesktop.org/xorg/xserver/commit/?id=25827fde68d3bb02a2b7e05fae53a1d97edf1f76]], [[TOG-CUP|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a7503615a6893749d512f75d37646273f31b9dbf]], [[XTrap|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cbc20d92de92aad5ca240310a9156ccf97c24a01]], [[XFree86-Misc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=22e64108ec63ba77779891f8df237913ef9ca731]], [[XEvIE|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a]] +* X server command line flags: [[-co|http://cgit.freedesktop.org/xorg/xserver/commit/?id=41b68e0dea9305d66bca2fc4ad96db01f5342c6d]], [[-bestrefresh|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1f416fba994ed7a7e072a9f0a86b515855ea3bac]], [[-showunresolved|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5a72c45d42abc7227c6cf3d14fd7043ea7527c54]] +* X server bundled utilties: [[xorgconfig|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d34430414ac0e77eec61ab0ac9ef427b236eb639]], [[xorgcfg|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5c1e254cc85e9ad409b0217780545c29f62d5feb]], [[ioport|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b74927c3844bc2650d95f604fe782d95ade067f1]], [[kbd_mode|http://cgit.freedesktop.org/xorg/xserver/commit/?id=8c0518379089d230060e9ff672ba5eba34198325]] +* Unmaintained X server variants: [[Xgl|http://cgit.freedesktop.org/xorg/xserver/commit/?id=d15b3790307053587df8daed1936ff6923881b63]], [[Xprt|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1c8bd318fbaf65890ef16fe26c76dd5e6f14dfde]] (moved to [[separate xprint git repo|http://cgit.freedesktop.org/xorg/xprint/]])
\ No newline at end of file diff --git a/Server17Branch.mdwn b/Server17Branch.mdwn new file mode 100644 index 00000000..aea08045 --- /dev/null +++ b/Server17Branch.mdwn @@ -0,0 +1,92 @@ + + +## Schedule + +* 1.7.0: Released 2009-10-01 +* 1.7.1: Released 2009-10-22 +* 1.7.2: Scheduled 2009-11-26 + +## Features + +* X Input 2.0 +* Mandatory XKB +* Support for symbol visibility +* EXA mixed pixmaps +* VGA arbitration + +## Proposing patches for 1.7.x + +The 1.7 branch has reached the [[end|http://lists.x.org/archives/xorg-devel/2010-June/009460.html]] of its active development lifecycle. Patches may be committed directly to the [[server-1.7-branch|http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.7-branch]]. If you feel the need to make an additional maintenance release from this branch, please discuss it on the [[xorg-devel|http://lists.x.org/mailman/listinfo/xorg-devel]] mailing list after making sure it [[doesn't perform worse|http://lists.x.org/archives/xorg-devel/2010-June/009484.html]] than the previous release. + + +## Patches merged between RC2 and 1.7.0 + + +#### 2009-09-25 + +* [[824a09d856a5f750694e11d2fd2faaa3de705eaa|http://cgit.freedesktop.org/xorg/xserver/commit/?id=824a09d856a5f750694e11d2fd2faaa3de705eaa]] dix: move bounds check before access +* [[096f21bb7a1217443d8a03529b1a2938518eb24f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=096f21bb7a1217443d8a03529b1a2938518eb24f]] EXA: Fix some issues pointed out by clang. +* [[ce1fe8ddb4a4dbe6cfd909e5b1b73b459d742bec|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ce1fe8ddb4a4dbe6cfd909e5b1b73b459d742bec]] render: Don't add b8g8r8x8 format for depth 24. +* [[5402f18d9c3f7ba19cc05b3a814e3a9e94c8d551|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5402f18d9c3f7ba19cc05b3a814e3a9e94c8d551]] dix: report XI1 axis values correctly if first_valuator != 0 +* [[3b5bbb149d4c932d9624336f5cbe9fe71c87bea3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3b5bbb149d4c932d9624336f5cbe9fe71c87bea3]] configure: fix up tslib check once again + +#### 2009-09-26 + +* [[9fa73be9fa543a686ea35c861084f5af37d44caa|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9fa73be9fa543a686ea35c861084f5af37d44caa]] Require libXext >= 1.0.99.4 +* [[a9c274df5c37cb4ece6449e934342d8ff8e61705|http://cgit.freedesktop.org/xorg/xserver/commit/?id=a9c274df5c37cb4ece6449e934342d8ff8e61705]] kdrive: plug two memory leaks when freeing the KdKeyboard/Pointer. +* [[fd913136732ff14a0484ca28f60ac1fbf49be81d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fd913136732ff14a0484ca28f60ac1fbf49be81d]] dix: plug memory leak in [[DeviceEnterLeaveEvents|DeviceEnterLeaveEvents]]. +* [[e23bffc41b007f1bc2b8f5cd4ac54213062c95cc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e23bffc41b007f1bc2b8f5cd4ac54213062c95cc]] Fix build of unit tests when dtrace probes are enabled +* [[1818cbd70fc1f2e1487b4c678e67e28f1265c0ef|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1818cbd70fc1f2e1487b4c678e67e28f1265c0ef]] EXA: Extend mixed pixmaps scheme to allow driver [[PrepareAccess|PrepareAccess]] hook to fail. + +#### 2009-09-27 + +* [[e7c2598f565e8252dd66ee3e6212b310856476cb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e7c2598f565e8252dd66ee3e6212b310856476cb]] dmx: core events are always in screen coordinates when passed to GPE. +* [[43a2eb794f19a2ba56d653f465fc5f6b2ff0d3d3|http://cgit.freedesktop.org/xorg/xserver/commit/?id=43a2eb794f19a2ba56d653f465fc5f6b2ff0d3d3]] configure: Unify all library defines that require a specific version. +* [[9bd08c690fc687c4d69bb70536f3079a9184476d|http://cgit.freedesktop.org/xorg/xserver/commit/?id=9bd08c690fc687c4d69bb70536f3079a9184476d]] Xi: update axisVals with the right subpixel data. +* [[c9ec2bab2f258798fd6e6676698c732f09571a60|http://cgit.freedesktop.org/xorg/xserver/commit/?id=c9ec2bab2f258798fd6e6676698c732f09571a60]] dmx: undefine MITSHM, move undefs to miinitext.c. +* [[fc9d733bab3ff0e4e51b19c73b66196dca563a70|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fc9d733bab3ff0e4e51b19c73b66196dca563a70]] dmx: reshuffle linker order to avoid errors when MITSHM is undefined. +* [[73ae547d5e687ef10dea45801fc627e10ac4b659|http://cgit.freedesktop.org/xorg/xserver/commit/?id=73ae547d5e687ef10dea45801fc627e10ac4b659]] EXA: Fix mixed pixmaps crash with missing / failing [[UploadToScreen|UploadToScreen]] hook. ([[http://bugs.freedesktop.org/show_bug.cgi?id=24167|http://bugs.freedesktop.org/show_bug.cgi?id=24167]]) + +#### 2009-09-28 + +* merge [[xorg-server-1.7-apple (77099b933a0362d40a28f9afea46c5cc97c29e13)|http://cgit.freedesktop.org/xorg/xserver/log/?h=77099b933a0362d40a28f9afea46c5cc97c29e13]]: + * [[1a0dfde2d102d845f1ceda66ad7a078aa1b42ef9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=1a0dfde2d102d845f1ceda66ad7a078aa1b42ef9]] XQuartz: GLX capabilities: Allow 16bit accumulation buffers + * [[e0e2eaf1f30ebce4c0ff28416259d8e976fdf0d7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=e0e2eaf1f30ebce4c0ff28416259d8e976fdf0d7]] XQuartz: Use internal xshm header for new xextproto + * [[6e4fc5d066d9c1ea4fca444cfee1e73147c5fefb|http://cgit.freedesktop.org/xorg/xserver/commit/?id=6e4fc5d066d9c1ea4fca444cfee1e73147c5fefb]] Xi: [[CopyKeyClass|CopyKeyClass]] is not static for XQuartz + * [[fd1adc21a931e2dd1ff2e52b60a77c2153a30fe0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=fd1adc21a931e2dd1ff2e52b60a77c2153a30fe0]] XQuartz: Nuke duplicate locks that make painful headaches + * [[29b2d9cdf5095399b79d9ff2a2f12f5a9c49cf1f|http://cgit.freedesktop.org/xorg/xserver/commit/?id=29b2d9cdf5095399b79d9ff2a2f12f5a9c49cf1f]] XQuartz: Fix a brain-o array indexing problem + * [[7958f6b75b3c6b8a827188af2e684f181bdd7688|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7958f6b75b3c6b8a827188af2e684f181bdd7688]] XQuartz: Add pressure/tilt property labels + * [[77099b933a0362d40a28f9afea46c5cc97c29e13|http://cgit.freedesktop.org/xorg/xserver/commit/?id=77099b933a0362d40a28f9afea46c5cc97c29e13]] XQuartz: Stop checking version numbers of the bundle because CFBundleGetVersionNumber is gimpish +* [[78ad6ca9a97440b74019c00a28144ea7d1e03431|http://cgit.freedesktop.org/xorg/xserver/commit/?id=78ad6ca9a97440b74019c00a28144ea7d1e03431]] xfree86: Hurd fix +* [[3db28f92b0c810b452506abbed299a204c90ba0b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3db28f92b0c810b452506abbed299a204c90ba0b]] configure: make XNEST default to auto. +* merge [[xorg-server-1.7-apple (b49dba33f94b51ba9a14803f0d81ccde2cb778f8)|http://cgit.freedesktop.org/xorg/xserver/log/?h=b49dba33f94b51ba9a14803f0d81ccde2cb778f8]]: + * [[a3dbde2de87ee4f577748a8c447501a3ea462559|http://cgit.freedesktop.org/xorg/xserver/commit/?id= a3dbde2de87ee4f577748a8c447501a3ea462559]] XQuartz: Transition from xEvent based mieq to [[InternalEvent|InternalEvent]] + * [[ceaa5c779ceed3de5ea53727649613be3133b24e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=ceaa5c779ceed3de5ea53727649613be3133b24e]] XQuartz: Force a keymap resync on the first keypress to workaround XKB mucking with our keymap + * [[de6cee11e1c335a0e5f708e7641e81d3cfe52529|http://cgit.freedesktop.org/xorg/xserver/commit/?id=de6cee11e1c335a0e5f708e7641e81d3cfe52529]] XQuartz: Fix inverse map from mode_switch to alt + * [[29cb904e4de2411a9b6dbe68694954788f0525f7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=29cb904e4de2411a9b6dbe68694954788f0525f7]] XQuartz: Nuke TSM + * [[54000bdcbca52a2de31f7c1a1147de6d8e9dbbb8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=54000bdcbca52a2de31f7c1a1147de6d8e9dbbb8]] XQuartz: Fix a bunch of compilation warnings about style + * [[dadab5a2279a19dcf709402d7f22f0cd48670db0|http://cgit.freedesktop.org/xorg/xserver/commit/?id=dadab5a2279a19dcf709402d7f22f0cd48670db0]] XQuartz: Fix [[QuartzSetCursor|QuartzSetCursor]] to match the expected prototype. + * [[cf2e3312cff3f341e9edba8c321a4ca7ffd8748e|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cf2e3312cff3f341e9edba8c321a4ca7ffd8748e]] Rootless: Correct border rendering on parent-relative windows + * This one I'm not so sure about... it fixes the problem, but it's ugly. I'm hoping there's a better way. -JH + * [[b49dba33f94b51ba9a14803f0d81ccde2cb778f8|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b49dba33f94b51ba9a14803f0d81ccde2cb778f8]] Add (ok, fix) support for DTrace under OS X + +#### 2009-09-30 + +* [[f772014c435f56db56520ca13ffa39431684f122|http://cgit.freedesktop.org/xorg/xserver/commit/?id=f772014c435f56db56520ca13ffa39431684f122]] render: Plug a memory leak in [[AddGlyph|AddGlyph]]. (#23286) +* [[83023ffd09a84ff48e6b99f57ebad101a00478db|http://cgit.freedesktop.org/xorg/xserver/commit/?id=83023ffd09a84ff48e6b99f57ebad101a00478db]] xfree86: use the DDC size if either width or height of [[DisplaySize|DisplaySize]] is bogus. +* [[0c2731596f27f2cdf5000ba41de37e7eb86ad6f9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=0c2731596f27f2cdf5000ba41de37e7eb86ad6f9]] Put tests for zero-sized strings in quotes (#24060) +* [[19be992d9dc542b61fa3f4fd32a09071c9e64880|http://cgit.freedesktop.org/xorg/xserver/commit/?id=19be992d9dc542b61fa3f4fd32a09071c9e64880]] ephyr: if -parent is given, check for a trailing -screen. (#24144) + +#### 2009-10-01 + +* [[db98b26ee145f70e732e2cf4a6ac3de77fdf4adc|http://cgit.freedesktop.org/xorg/xserver/commit/?id=db98b26ee145f70e732e2cf4a6ac3de77fdf4adc]] Re-fix DGA removal. +* [[b5fcc5553eb784c9f4826936e839079c0cdee55a|http://cgit.freedesktop.org/xorg/xserver/commit/?id=b5fcc5553eb784c9f4826936e839079c0cdee55a]] exa: avoid infinite loops if UTS sw fallbacks. +* [[758ab55d2defc78d0169fd61a7036eb9f889e9e7|http://cgit.freedesktop.org/xorg/xserver/commit/?id=758ab55d2defc78d0169fd61a7036eb9f889e9e7]] render: set the glyph picture to NULL by default. + * needed for 622fc98fd08aba98369e6933c3ab8c9ff85385d5 +* [[622fc98fd08aba98369e6933c3ab8c9ff85385d5|http://cgit.freedesktop.org/xorg/xserver/commit/?id=622fc98fd08aba98369e6933c3ab8c9ff85385d5]] render: Fix crash in [[RenderAddGlyphs|RenderAddGlyphs]] (#23645) + +#### 2009-10-02 + +* [[3ebb82d61c2b56e8f7145443a552a4e913bbfc80|http://cgit.freedesktop.org/xorg/xserver/commit/?id=3ebb82d61c2b56e8f7145443a552a4e913bbfc80]] rotate: drop unwrapping inside block handler. +* [[64fe5784b49347e1fd27b0c463be5c16557594c9|http://cgit.freedesktop.org/xorg/xserver/commit/?id=64fe5784b49347e1fd27b0c463be5c16557594c9]] configure: if xnest was requested but modules weren't found, fail. +* [[45f447dafded5adfe11b7df3325c2d8f6ae0639b|http://cgit.freedesktop.org/xorg/xserver/commit/?id=45f447dafded5adfe11b7df3325c2d8f6ae0639b]] dix: force a minimum of 0 for screen coordinates.
\ No newline at end of file diff --git a/Server18Branch.mdwn b/Server18Branch.mdwn new file mode 100644 index 00000000..30c9fcb1 --- /dev/null +++ b/Server18Branch.mdwn @@ -0,0 +1,21 @@ + +Release manager: [[KeithPackard|KeithPackard]] + +Stable branch maintainer: [[PeterHutterer|PeterHutterer]] + + +## Schedule + +* End of feature merge window: 2009-12-31 +* End of bugfix window: 2010-2-28 +* Release of 1.8.0: 2010-3-31 + +## Features + +* [[New input hotplug and configuration system|http://who-t.blogspot.com/2010/01/new-configuration-world-order.html]], including: + * [[HAL Replacement|XorgHAL]] - udev support for Linux integrated, other OS'es TBD + * [[xorg.conf.d|http://lists.freedesktop.org/archives/xorg-devel/2009-November/003710.html]] + +## Proposing patches for 1.8.x + +The 1.8 branch has reached the [[end|http://lists.x.org/archives/xorg-devel/2010-June/009460.html]] of its active development lifecycle. Patches may be committed directly to the [[server-1.8-branch|http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.8-branch]]. If you feel the need to make an additional maintenance release from this branch, please discuss it on the [[xorg-devel|http://lists.x.org/mailman/listinfo/xorg-devel]] mailing list after making sure it [[doesn't perform worse|http://lists.x.org/archives/xorg-devel/2010-June/009484.html]] than the previous release. diff --git a/Server19Branch.mdwn b/Server19Branch.mdwn new file mode 100644 index 00000000..3afa7abc --- /dev/null +++ b/Server19Branch.mdwn @@ -0,0 +1,44 @@ + +Release manager: [[KeithPackard|KeithPackard]] + +Stable branch maintainer: [[JeremyHuddleston|JeremyHuddleston]] + + +## Schedule + +* End of feature merge window: 2010-06-01 +* End of bugfix window: 2010-08-01 +* Release of 1.9.0: 2010-08-20 +See also the [[X.Org Calendar|http://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80%40group.calendar.google.com&ctz=Australia/Brisbane]]. + + +## Features + +* dix devPrivates rework (changed by a memory-wise version) +* DRI2: + * [[new authentication mechanism|http://cgit.freedesktop.org/xorg/xserver/commit/?id=cdcb575664d3d60b662c542e782de83a047165c9]] allowing build the server without libdrm + * [[buffers invalidation|http://cgit.freedesktop.org/xorg/xserver/commit/?id=421606a8ef447d10c2ee0986f20e752056a47675]] to reduce unnecessary round trips to the X server + * lot of fixes. +* configuration: smart set up using xorg.conf.d (FIXME [[DanNicholson|DanNicholson]], [[PeterHutterer|PeterHutterer]]), start up of the server [[without output devices connected|http://cgit.freedesktop.org/xorg/xserver/commit/?id=5939e39a641773a36c22104e1184143678dca7a2]] +* xinput: [[invisible cursor sprite not damaging screen anymore|http://cgit.freedesktop.org/xorg/xserver/commit/?id=7c085aebfedeb621a6fbeb3f09f4fcc640452044]] (performance improvements) +* code clean-up: + * MAXSCREENS (almost) removal + * allocation function wrapping removal + * bus PCI related + * replacement of all X allocation functions (*alloc) with their C89 counterparts (performance improvement) + * removal of bzero + * region implementation from mi to dix + * mandatory RENDER +* documentation: conversion of [[LinuxDoc|LinuxDoc]] documents to DocBook/XML +* deprecation: mibank support, Multibuffer extension (MBE). +* besides lot of bug fixing as usual ([[sw cursor on multiple screens|http://cgit.freedesktop.org/xorg/xserver/commit/?id=518f3b189b6c8aa28b62837d14309fd06163ccbb]]) and big number of changes (339 commits since X server 1.8.0 - 9th Jun) + +## Proposing patches for 1.9.x + +Server 1.9.0 has been [[released|http://lists.freedesktop.org/archives/xorg-announce/2010-August/001390.html]]. Patches may be nominated for future 1.9.x releases using the process outlined below. + + * **Do not push to server-1.9-branch.** + * Patches for 1.9 must be in master first. Please follow the guidelines outlined on the [[XServer|XServer]] page to get a patch into master. Exceptions are patches where the master code has changed in a way that git master is not affected by a particular bug. + * For single patches: Once a patch is in master, let the stable branch maintainer know that this patch is to be cherry-picked to 1.9. Reply to the original patch email, placing the branch maintainer in TO and CC-ing the list. Make sure that the subject line contains `[PATCH 1.9]`. + * For multiple patches: Create a local branch and cherry-pick the patches required (Always use cherry-pick -x). Push this branch to your people.freedesktop.org repository and send a pull request to the stable branch maintainer, CC-ing the list. Make sure the subject line contains `[PULL 1.9]`. + * Only regressions over the previous stable will be accepted between the final rc and the release.
\ No newline at end of file diff --git a/SimonFarnsworth.mdwn b/SimonFarnsworth.mdwn new file mode 100644 index 00000000..55f05480 --- /dev/null +++ b/SimonFarnsworth.mdwn @@ -0,0 +1,11 @@ + + +## Simon Farnsworth + +Work email: [[simon.farnsworth@onelan.co.uk]] Or personal e-mail: [[simon@farnz.org.uk]] + +Found on IRC as farnz anywhere I lurk. + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/SimosXenitellis.mdwn b/SimosXenitellis.mdwn new file mode 100644 index 00000000..82118b8c --- /dev/null +++ b/SimosXenitellis.mdwn @@ -0,0 +1,13 @@ + + +## Simos Xenitellis + +Email: simos.lists AT SPAMFREE googlemail DOT com + +Blogs: [[http://simos.info/blog/|http://simos.info/blog/]] and [[http://blogs.gnome.org/simos/|http://blogs.gnome.org/simos/]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/SiteNavigation.mdwn b/SiteNavigation.mdwn new file mode 100644 index 00000000..d64c0419 --- /dev/null +++ b/SiteNavigation.mdwn @@ -0,0 +1,16 @@ + +SiteNavigation is the central place to explore this wiki. [[MoinMoin|MoinMoin]] supports these [[!MeatBall IndexingScheme desc="IndexingScheme"]]****s: + +* [[RecentChanges|RecentChanges]] +* [[TitleIndex|TitleIndex]] +* [[WordIndex|WordIndex]] +* [[FindPage|FindPage]] +* [[WantedPages|WantedPages]] +* [[OrphanedPages|OrphanedPages]] +* [[RandomPage|RandomPage]] +* [[PageSize|PageSize]] +At the bottom of each page, there are actions that allow to navigate to other pages related to the current page: + +* Like****Pages +* Local****Site****Map +Additionally, there are the `[[PageList]]`, `[[FullSearch('text')]]` and `[[TableOfContents]]` macros, which allow you to automatically generate indices for cohesive parts of a wiki. diff --git a/SooChanLim.mdwn b/SooChanLim.mdwn new file mode 100644 index 00000000..0be9c2ff --- /dev/null +++ b/SooChanLim.mdwn @@ -0,0 +1,15 @@ + + +## SooChan Lim + +Email: [[sc1.lim@samsung.com)|sc1.lim@samsung.com)]] + +X man~! + +... + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/SponsorshipPage.mdwn b/SponsorshipPage.mdwn new file mode 100644 index 00000000..e0b82889 --- /dev/null +++ b/SponsorshipPage.mdwn @@ -0,0 +1,10 @@ + +# Information for Sponsors + +X.Org is trying to do an extremely big, important job with limited resources. Sponsorship and contributions of money, equipment, etc are extremely valuable to us in promoting and supporting X development. + +X.Org Foundation is a non-profit Delaware corporation and has applied for tax-exempt 501(c)(3) status, but has not yet received a tax exemption ruling from the IRS. Donations will not be tax deductible until this status is obtained from the IRS. However, upon recognition of tax exemption, all donations will be tax-deductible retroactive to the date of donation. + +Please contact our Treasurer, currently Stuart Kreitman <[[Stuart.Kreitman@oracle.com|mailto:Stuart.Kreitman@oracle.com]]>, for Tax ID information and any other financial information you need to facilitate your sponsorship. Please contact our Secretary, currently Bart Massey <[[bart@cs.pdx.edu|mailto:bart@cs.pdx.edu]]>, if you have general questions about sponsorship or contribution. + +Thank you for your support. diff --git a/StephaneMarchesin.mdwn b/StephaneMarchesin.mdwn new file mode 100644 index 00000000..9122df28 --- /dev/null +++ b/StephaneMarchesin.mdwn @@ -0,0 +1,13 @@ + + +## Stephane Marchesin + +Email: stephane DOT marchesin AT gmail DOT com + +Yup, that's my X.Org wiki page. But there's more at [[http://people.freedesktop.org/~marcheu/|http://people.freedesktop.org/~marcheu/]] + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/StructuredText.mdwn b/StructuredText.mdwn new file mode 100644 index 00000000..5847234b --- /dev/null +++ b/StructuredText.mdwn @@ -0,0 +1,48 @@ + +Structured text is text that uses indentation and simple symbology to indicate the structure of a document. For the next generation of structured text, see [[!MoinMoin ReStructuredText desc="ReStructuredText"]] and [[here|http://dev.zope.org/Members/jim/StructuredTextWiki/StructuredTextNG]]. + +A structured string consists of a sequence of paragraphs separated by one or more blank lines. Each paragraph has a level which is defined as the minimum indentation of the paragraph. A paragraph is a sub-paragraph of another paragraph if the other paragraph is the last preceding paragraph that has a lower level. + +Special symbology is used to indicate special constructs: + +* A single-line paragraph whose immediately succeeding paragraphs are lower level is treated as a header. +* A paragraph that begins with a '-', '*', or 'o' is treated as an unordered list (bullet) element. +* A paragraph that begins with a sequence of digits followed by a white-space character is treated as an ordered list element. +* A paragraph that begins with a sequence of sequences, where each sequence is a sequence of digits or a sequence of letters followed by a period, is treated as an ordered list element. +* A paragraph with a first line that contains some text, followed by some white-space and '--' is treated as a descriptive list element. The leading text is treated as the element title. +* Sub-paragraphs of a paragraph that ends in the word 'example' or the word 'examples', or '::' is treated as example code and is output as is. +* Text enclosed single quotes (with white-space to the left of the first quote and whitespace or puctuation to the right of the second quote) is treated as example code. +* Text surrounded by '*' characters (with white-space to the left of the first '*' and whitespace or puctuation to the right of the second '*') is emphasized. +* Text surrounded by '**' characters (with white-space to the left of the first '**' and whitespace or puctuation to the right of the second '**') is made strong. +* Text surrounded by '_' underscore characters (with whitespace to the left and whitespace or punctuation to the right) is made underlined. +* Text encloded by double quotes followed by a colon, a URL, and concluded by punctuation plus white space, *or* just white space, is treated as a hyper link. For example: + * "Zope":[[http://www.zope.org/|http://www.zope.org/]] is ... +Is interpreted as '<a href="[[http://www.zope.org/">Zope</a>|http://www.zope.org/">Zope</a>]] is ....' + +**Note:** This works for relative as well as absolute URLs. + +* Text enclosed by double quotes followed by a comma, one or more spaces, an absolute URL and concluded by punctuation plus white space, or just white space, is treated as a hyper link. For example: + * "mail me", [[mailto:amos@digicool.com|mailto:amos@digicool.com]]. +Is interpreted as '<a href="[[mailto:amos@digicool.com">mail|mailto:amos@digicool.com">mail]] me</a>.' + +* Text enclosed in brackets which consists only of letters, digits, underscores and dashes is treated as hyper links within the document. For example: + * As demonstrated by Smith [12] this technique is quite effective. +Is interpreted as '... by Smith <a href="#12">[12]</a> this ...'. Together with the next rule this allows easy coding of references or end notes. + +* Text enclosed in brackets which is preceded by the start of a line, two periods and a space is treated as a named link. For example: + * . [12] "Effective Techniques" Smith, Joe ... +Is interpreted as '<a name="12">[12]</a> "Effective Techniques" ...'. Together with the previous rule this allows easy coding of references or end notes. + +* A paragraph that has blocks of text enclosed in '||' is treated as a table. The text blocks correspond to table cells and table rows are denoted by newlines. By default the cells are center aligned. A cell can span more than one column by preceding a block of text with an equivalent number of cell separators '||'. Newlines and '|' cannot be a part of the cell text. For example: + * [[!format txt """ +|||| **Ingredients** || +|| *Name* || *Amount* || +||Spam||10|| +||Eggs||3|| +"""]]renders like this: + * [[!table header="no" class="mointable" data=""" + **Ingredients** || + *Name* | *Amount* +Spam | 10 +Eggs | 3 +"""]] diff --git a/StuartKreitman.mdwn b/StuartKreitman.mdwn new file mode 100644 index 00000000..ec71426f --- /dev/null +++ b/StuartKreitman.mdwn @@ -0,0 +1,13 @@ + + +## Stuart Kreitman + +Email: stuart.kreitman AT SPAMFREE sun DOT com + +Helping move Solaris from Xsun to Xorg for Sparc and Sunray, configuration, multihead, laptop issues. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/SummerOfCodeIdeas.mdwn b/SummerOfCodeIdeas.mdwn new file mode 100644 index 00000000..1c241568 --- /dev/null +++ b/SummerOfCodeIdeas.mdwn @@ -0,0 +1,178 @@ + + +# Project Ideas for Google Summer of Code / X.Org Endless Vacation of Code programs + + +## Goal + +The X.org board treats GSoC as an opportunity to teach new developers rather than a chance to get a pile of free code. With this perspective, if, in two months, the student actually has learned how to contribute to X Window System, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part. + +When writing a proposal, please remember to make it detailed. Include at least the information called for in "[[What should a student application look like?|http://code.google.com/support/bin/answer.py?answer=60306&topic=10727]]", but including milestones and a project schedule is even better. See [[GSoCApplication|GSoCApplication]] for guidelines. + +X.Org is a large and comprehensive project with a huge number of possible opportunities for interesting Google / X.Org Summer of Code projects. This list contains a few of those opportunities that are particularly interesting to X.Org developers and potential mentors. Please note that these are just suggestions; if you have an idea for something else please ask. + +If you have questions, feel free to contact us on the [[X.Org mailing list|http://lists.freedesktop.org/mailman/listinfo/xorg]] or the [[X.Org IRC channel|irc://irc.freenode.net/#xorg-devel]]. + + +## 2013 Ideas + + +### Glamor + + +##### Glamor Performance Tuning + +* _Difficulty:_ Medium +* _Skills Required:_C, OpenGL +* _Helpful, but optional skills:_ GLSL, GPU driver development +* _Where to ask questions:_ [[glamor@lists.freedesktop.org|mailto:glamor@lists.freedesktop.org]], #dri-devel on irc.freenode.org +* _Description:_ +* Glamor is a helper library that uses OpenGL to accelerate X rendering. The goal of this task would be to improve the the performance of Glamor by profiling problematic areas and improving the. Some possible ideas: + 1. Implement a delayed flushing mechanism to avoid tiny drawing operation for each [[DrawElements/DrawArrays|DrawElements/DrawArrays]] call. + 1. Implement an atlas for small pixmap. + 1. Optimize trapezoid shader to reduce the overhead for those non-edge pixels. + 1. Optimize trapezoid/gradient shader to merge the mask/source creation and compositing into one shader. + +##### Glamor Xv support + +* _Difficulty:_ Easy +* _Skills Required:_C, OpenGL +* _Helpful, but optional skills:_ GLSL, GPU driver development +* _Where to ask questions:_ [[glamor@lists.freedesktop.org|mailto:glamor@lists.freedesktop.org]], #dri-devel on irc.freenode.org +* _Description:_ +* Glamor is a helper library that uses OpenGL to accelerate X rendering. The goal of this task would be to implement support for Xv (Xvideo) in glamor. Basic support would involve using OpenGL to implement colorspace conversion for various YUV formats. More advanced goals include: + 1. Improved scaling algorithms + 1. Support for brightness/contrast/saturation/hue adjustments + 1. Support for gamma adjustment + 1. Support for colorspace selection (ITU-R BT.601 vs. BT.709) + +### Mesa + + +#### GLSL Compiler + + +##### Find common patterns in real GLSL shaders + +* _Difficulty:_ Medium +* _Skills Required:_ C, C++ +* _Helpful, but optional skills:_ GLSL, compilers +* _Possible Mentor:_ [[IanRomanick|IanRomanick]] (idr on IRC) +* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #dri-devel on irc.freenode.org +* _Description:_ +* Using Mesa's stand-along GLSL compiler as a basis, generate a database of IR from a large number of existing shaders (e.g., from shaderdb). Write a piece of software that will mine this database for "large" patterns that commonly occur in shaders. This information will be used by people working on the GLSL compiler to improve code generation for these sequences. + +##### Improved application of GLSL complier optimizations + +* _Difficulty:_ Easy +* _Skills Required:_ C, C++ +* _Helpful, but optional skills:_ GLSL, compilers +* _Possible Mentor:_ [[IanRomanick|IanRomanick]] (idr on IRC) +* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #dri-devel on irc.freenode.org +* _Description:_ +* Mesa's GLSL compiler contains a large number of optimization passes. Each pass may change the code of a shader, and this may result in opportunities for other passes to make more changes. As a result, we run all of our optimization passes in a loop until the shader code stabilizes. This is expensive, and, though we have never observed this in the wild, it is possible that a shader may never stabilize. +* Find a static ordering, with possible repeats, of optimization passes that does not compromise the quality of the generated code. Measure the before and after speed of compiling a large set of real-world shaders. + +#### r600g + + +##### Add support for OpenCL local and private memory spaces + + * _Difficulty:_ Medium + * _Skills Required:_ C, C++ + * _Helpful, but optional skills:_ OpenCL, compilers, GPU driver development, LLVM + * _Possible Mentor:_ [[TomStellard|TomStellard]] (tstellar on IRC) + * _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #radeon or #dri-devel on irc.freenode.org + * _Description:_ + * This project would involve modifying the r600g driver and LLVM compiler backend to support reading and writing from local and private memory spaces as defined by the OpenCL specification. + +##### Improve VLIW5 scheduling in the LLVM backend + + * _Difficulty:_ Easy + * _Skills Required:_ C, C++ + * _Helpful, but optional skills:_ compilers, GPU driver development, LLVM + * _Possible Mentor:_ [[VincentLejeune|VincentLejeune]] (vlj on IRC) + * _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #radeon or #dri-devel on irc.freenode.org + * _Description:_ + * The idea is to improve hw utilization by improving instruction scheduling on VLIW5 hardware (r6xx-evergreen). This would require a way to represent trans slot compatibility for instructions and handle the additional constant read and literals limitations on this slot and updating the scheduler to take advantage of it. + +#### clover + + +##### Pick a popular OpenCL application and get it running with clover and at least one of the compute capable drivers (r600g or radeonsi) + +* _Difficulty:_ Depends on the application +* _Skills Required_ C, C++, OpenCL +* _Helpful, but optional skills:_ Compilers, LLVM +* _Possible Mentor:_ [[TomStellard|TomStellard]] (tstellar on IRC) +* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #radeon or #dri-devel on irc.freenode.org +* _Description:_ +* This project is pretty straightforward: Pick an application and fix bugs or implement missing features in clover and/or the gallium drivers until it works. In order to come up with a good proposal for this project a student will need to first investigate their chosen application to determine what needs to be done to get it working. Some possible applications: + * Any bitcoin client (r600g = Medium / radeonsi = Hard) + * GEGL filters in GIMP (r600g = Easy / radeonsi = Hard) + * Luxmark (r600g = Hard / radeonsi = Very Hard) + +#### Intel + + +##### Implement GLSL 1.30 for older chipsets than SandyBridge + +* _Difficulty:_ Medium +* _Skills Required:_ C, C++ +* _Helpful, but optional skills:_ GLSL, compilers +* _Possible Mentor:_ [[PaulBerry|PaulBerry]] (stereotype441 on IRC) +* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #dri-devel on irc.freenode.org +* _Description:_ +* Implement GLSL 1.30 support for pre-Sandybridge asics that support it. For additional details see: [[https://bugs.freedesktop.org/show_bug.cgi?id=59187|https://bugs.freedesktop.org/show_bug.cgi?id=59187]] + +### Piglit + + +#### GL/GLSL tests for GL 3.2, 3.3 + +* _Difficulty:_ Easy-Medium +* _Skills Required:_ C +* _Useful skills:_ OpenGL, GLSL programming +* _Hardware/Software required:_ driver supporting >= OpenGL 3.2 +* _Possible Mentor:_ [[JordanJusten|JordanJusten]] (jljusten on IRC) +* _Where to ask questions:_ [[mesa-dev@lists.freedesktop.org|mailto:mesa-dev@lists.freedesktop.org]], #dri-devel on irc.freedesktop.org +* _Description:_ +* Write tests for OpenGL 3.2 / GLSL 1.50 and newer. Proposal should identify: + * GL/GLSL version/features you plan to focus on + * Number of tests you estimate completing + * Hardware/driver you have access to + +### X Server + + +#### Shatter support for the X Server (Xinerama replacement) + + * _Difficulty:_ Hard + * _Skills Required:_ C + * _Helpful, but optional skills:_ GPU driver development + * _Possible Mentor:_ [[DaveAirlie|DaveAirlie]] (airlied on IRC) + * _Where to ask questions:_ [[xorg-devel@lists.x.org|mailto:xorg-devel@lists.x.org]] or #xorg-devel on irc.freenode.org + * _Description:_ + * This project would involve adding an impedance layer to the X Server to divide rendering between multiple GPUs each covering different areas of a larger desktop. For more details: [[http://mirror.linux.org.au/linux.conf.au/2013/ogv/Teaching_the_X_server_new_tricks.ogv|http://mirror.linux.org.au/linux.conf.au/2013/ogv/Teaching_the_X_server_new_tricks.ogv]] (shatter discussion starts at ~24:00). + +### Kernel + + +#### Implement working rendernode support + + * _Difficulty:_ Medium + * _Skills Required:_ C + * _Helpful, but optional skills:_ GPU driver development + * _Possible Mentors:_ [[DaveAirlie|DaveAirlie]] (airlied on IRC), [[DanielVetter|DanielVetter]] (danvet on IRC) + * _Where to ask questions:_ [[dri-devel@lists.freedesktop.org|mailto:dri-devel@lists.freedesktop.org]] or #dri-devel on irc.freenode.org + * _Description:_ + * This project would involve adding a new interface to the drm to allow rendering on drm nodes without being master. This could also be expanded to cover display resource allocation for things like multiseat. Further information: + 1. [[http://airlied.livejournal.com/72187.html|http://airlied.livejournal.com/72187.html]] + 1. [[http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html|http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html]] + 1. [[http://lists.freedesktop.org/archives/dri-devel/2012-September/028338.html|http://lists.freedesktop.org/archives/dri-devel/2012-September/028338.html]] + +### Xpra + +See this page for ideas: [[https://www.xpra.org/trac/wiki/ProjectIdeas|https://www.xpra.org/trac/wiki/ProjectIdeas]] + +See also: [[ToDo|ToDo]] diff --git a/SummerOfCodeIdeas2008.mdwn b/SummerOfCodeIdeas2008.mdwn new file mode 100644 index 00000000..26cee0c7 --- /dev/null +++ b/SummerOfCodeIdeas2008.mdwn @@ -0,0 +1,97 @@ + + +## Goal + +The X.org board treats GSoC as an opportunity to teach new developers rather than a chance to get a pile of free code. With this perspective, if, in two months, the student actually has learned how to contribute to X Window System, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part. + + +## Ideas + +Ideas for projects for students looking to participate in Google's Summer of Code. Please note that these are just suggestions; if you have an idea for something else please ask. + +When writing a proposal, please remember to make it detailed. Include at least the information called for in "[[What should a student application look like?|http://code.google.com/support/bin/answer.py?answer=60306&topic=10727]]", but including milestones and a project schedule is even better. See [[X.Org-GSoC2008-Application|X.Org-GSoC2008-Application]] for guidelines. + + +### Xserver core + +* Move the dmx muxing code into the server to replace the existing xinerama mux code +* EXA support for surfaces larger than the hardware limits +* Infrastructure for direct-rendering GL windows larger than the hardware supports +* Investigate redoing miarc/miwideline/etc. for smaller size and better performance + +### Xinerama + +* Composite/Xinerama integration +* Hotplugging additional local and remote displays +* Auto enabling and disabling Xinerama screens. +* Make Xinerama handle more than just X screens + +### Xdmx + + * Integrate with the rootless code a la Xdarwin and Cygwin/X, for floating window migration + * Add support for Fixes/Damage/Composite + * Fix input + +### XCB + + * Auto-generate server-side protocol stubs from XCB's protocol descriptions + * Implement a new language binding for XCB + * Finishing the Haskell language binding would be really cool. + * Implement a more complete test suite for XCB + * Port Gdk and/or Qt to XCB + * Port the important X utilities (xdpyinfo, xhost, etc.) to XCB + * The [[XCB demos|http://gitweb.freedesktop.org/?p=xcb;a=tree;f=xcb-demo]] include partial ports of xdpyinfo and xrandr. + * You'd have to port a lot of applications to make this an interesting Summer of Code project. + * See [[XCBToDo|http://xcb.freedesktop.org/XCBToDo]] and Bugzilla(XCB) for more ideas, or contact [[jamey@minilop.net|mailto:jamey@minilop.net]] or [[xcb@lists.freedesktop.org|mailto:xcb@lists.freedesktop.org]]. + +### Xau/Xdmcp + + * Implement the XDM-AUTHORIZATION-2 authentification protocol for better IPv6/XDM support. (See [[Bug 277|https://bugs.freedesktop.org/show_bug.cgi?id=277]] and the never-adopted draft of the XDM-AUTHORIZATION-2 changes to the XDMCP protocol spec.) + * Replace the old/uncompiliable KERBEROS-5 authentication with GSS-API authentication. + +### Drivers + + * Add more support for EXA in the drivers; see [[ExaStatus|ExaStatus]] for a list. + * Add dualhead support to an unsupported chip (trident, mach64, s3virge, [[nv|https://bugs.freedesktop.org/show_bug.cgi?id=5190]], etc.) + * Add basic DRI support to an unsupported chip (trident, s3virge, glint, siliconmotion, etc.) + * Do some work on [[nouveau|http://nouveau.freedesktop.org/]] ; ideas include adding 3D support for more cards, better Xv/XvMC support through gallium, suspend/resume support, (see our [[TODO page|http://nouveau.freedesktop.org/wiki/ToDo]] for more ideas) + * More DRI-related ideas are visible on [[http://dri.freedesktop.org/wiki/GSoC_2008|http://dri.freedesktop.org/wiki/GSoC_2008]] + +### XQuartz (OSX) + +Some of these might require changes to libXplugin (proprietary Apple code), but Apple is more than willing to provide the needed hooks. Just join the [[xquartz-dev mailing list|http://trac.macosforge.org/projects/xquartz/wiki/MailingLists]] + + * New extension support + * RandR + * Composite + * Fix OpenGL support + * Switch to XF86DRI instead of AppleDRI + * Write a Mesa DRI driver that uses OpenGL.framework + * Top-Of-Tree syncing + * input model, keymapping needs to be reworked + * Copy/Paste proxying between OS-X and X11 + * Eliminate the need for AppleWM extension to allow other WMs to work better + * Handle exposé / spaces events inside the X server rather than quartz-wm (so other WMs can be used) + * Compositing window manager to replace quartz-wm (once Composite is enabled) + +### Misc + +* Add test cases for more extensions, especially newer ones like Render, Composite, etc. (possibly to XTS5; see [[TestGroup|TestGroup]] wiki) +* Introspection extension to support tools like xscope + * Would allow querying for request names and structures in generic fashion + * Look at xcb-proto descriptions +* Integrate NX in XCB or X protocol +* Create GUI or textual tool for assisted editing of XKB configuration database. +* Formally documenting XKB configuration syntax and configuration database structure. + +### DRI + + * GLX_EXT_texture_from_pixmap + * Update to latest spec + * More efficient implementation, ideally texturing directly from offscreen pixmaps + * Integrate properly with Composite, in particular, render to redirected windows correctly + * Port new memory manager changes to drivers other than i915 + * make the X server's Xsync extension use DRM vblank waits or signals (really a DRI/X cross project) + * rough patch is already available + * developer would get good exposure to server and DRM internals +See also: [[ToDo|ToDo]], [[Releases/7.4|Releases/7.4]], [[DRI ideas list|http://dri.freedesktop.org/wiki/SummerOfCode]]. diff --git a/SummerOfCodeResults2008.mdwn b/SummerOfCodeResults2008.mdwn new file mode 100644 index 00000000..5492804e --- /dev/null +++ b/SummerOfCodeResults2008.mdwn @@ -0,0 +1,12 @@ + +This page is a brief and highly belated report on the highly successful Google / X.Org Summer of Code 2008. Details, of course, are welcome. + +In 2008, Google / X.Org Summer of Code was able to accept five student applicants. As in previous years, each accepted student received a $4500 stipend (in two contingent payments at the midway point and at the end) to execute a proposed coding project useful to X.Org. + +Of the five students accepted, one dropped out early on. The remaining four completed their projects successfully. + + * Younes Manton, under the mentorship of Stephane Marchesin, completed the bulk of work on a full implementation of GPU-accelerated video decoding for X. + * Kristof Ralovich, under the mentorship of Bart Massey, worked on adding support for XCB-GLX to Mesa. In the end, this proved to be a debugging and architecture project that resulted in improvements to both codebases. + * Symeon Xenitellis, under the mentorship of Sergey Udaltsov, built a GUI tool for assisted editing of the XKB configuration database. + * Tiago Vignatti returned for a second year with Google / X.Org Summer of Code. Under the mentorship of Daniel Stone, he extended his 2008 Summer of Code project that moved X server pointer handling into a separate thread by moving remaining input code into this thread. +X.Org would like to thank the students for their great contributions to X, and also the mentors who volunteered their time to make these students a success. diff --git a/SupportMailingList.mdwn b/SupportMailingList.mdwn new file mode 100644 index 00000000..f147231a --- /dev/null +++ b/SupportMailingList.mdwn @@ -0,0 +1,66 @@ + + +## X.Org Mailing Lists + +So you have a question and you can't find the answer on the wiki or [[Google|http://www.google.com]]. + +Feel free to subscribe to the X.Org support mailing list. **Please** subscribe, don't just post your questions there. You will not receive all of the answers to your question unless you subscribe to the list. + + +### Please Hear Our Cry! + +**You can help us to help you!** + +**Before** you post your problem you should take a look at our **[[FAQ|FAQ]]** if you haven't done so already. Maybe somebody has had the same problem before and it is already answered. + +When you post a report please: + + * Please post in **English**. Even though people subscribed to the list may be able to speak some other languages English is the 'least common denominator' on this list. + * _Post your questions to the **X.Org** mailing list only. Do **NOT** crosspost!_ + * Also please post your Xorg log file. It can typically be found here: `/var/log/Xorg.0.log` + * A description of your problem would also be helpful, along with the steps you've taken in your attempts to solve it. **You have tried to fix it yourself haven't you?** At the very least you should **READ** your log file. There is a key which explains some of the symbols used in it at the top (of the log file.) + * Please **don't** use HTML in your email! You are much less likely to receive an answer. Some supporters filter out email containing HTML as SPAM. + * Please consider this outcry of an anonymous supporter: + +[[!format txt """ +May I ask all posters to refrain from using the subject lines: +(no subject) +Need help +Help +please help +Can someone help me +Problem +Big problem +X crash +Fatal server error +X server crash +crash +X windows problem +Fatal server error +Server crash +what is this +Error log + +and all other permutations on this theme. + +Some creative possibilities for subject lines are: +The error message you are receiving. +The manufacturer and name of your graphic card. +The Distro and version of X you are running. +Area where the problem is occurring. + i.e. if your mouse isn't working, "Mouse Troubles" + +Thanks for your support, + anonymous poster on a support mailing list. +"""]] + +## How to Subscribe + +Have you read our requests above? ;) + +OK, please go ahead and **[[subscribe|http://freedesktop.org/mailman/listinfo/xorg]]** to the support mailing list. + + +## Other lists + +* [[ati/radeon driver|http://lists.freedesktop.org/mailman/listinfo/xorg-driver-ati]] specific list
\ No newline at end of file diff --git a/TestGroup.mdwn b/TestGroup.mdwn new file mode 100644 index 00000000..90d09cee --- /dev/null +++ b/TestGroup.mdwn @@ -0,0 +1,69 @@ + + +# X.Org Foundation(XOF) Testing WorkGroup + + +## Purpose + +The Testing Group's purpose is to maintain and extend the test suites associated with the X Window System technology and to develop and maintain an infrastructure for regression testing releases. The following goals have been established for the Testing Group: + +* Support and Maintain the existing X Test Suite +* Extend the existing X Test Suite to cover additional interfaces which have become X.Org standards +* Support the XOF Release process, and the XOF Release Manager by providing test suites, scripts and tool that can be used for regression and verification testing of each new release +* Provide input on the testability of new features during the design and development process of those features +* define and maintain procedures for testing portions of the product not covered by the X Test Suite. + +## Organization + +The Test Group will communicate primarily via IRC and email. Occasional conference calls may be held as needed. IRC meetings shall default to being held weekly at a time that is suitable to the majority of the active participants of the group. + +* IRC on #xorg-test on [[FreeNode|http://freenode.net/]] with channel logging archive available via the web. +* email list [[xorg-test@lists.x.org|mailto:xorg-test@lists.x.org]] ([[http://lists.x.org/mailman/listinfo/xorg-test/|http://lists.x.org/mailman/listinfo/xorg-test/]]) +* CVS is at [[http://cvs.freedesktop.org/xtest/|http://cvs.freedesktop.org/xtest/]] +Participation is open to everyone. Membership in X.Org is not required, but is encouraged. + + +## Deliverables + +We need to take a look at the exisiting APIs to create a list of tests which are missing (results documented here). Examples include the RENDER extension, RandR, DAMAGE and COMPOSITE. + +Unless there is good reason, new tests shall be in the [[TET|http://tetworks.opengroup.org]] framework to facilitate integration into the existing test suite. An additional task to investigate is to provide additional documentation that helps people to understand the TET framework more easily. + +Other frameworks could also be investigated, but we should be cautious to not get bogged down in endless religious debate over testing frameworks. + + +## Policies + +* [[TestGroup/CodeManagement|TestGroup/CodeManagement]] +* [[TestGroup/HowTo|TestGroup/HowTo]] + +## Build the X Test Suite + +Building the X Test Suite requires a few steps, but none of them are terribly difficult. Instructions can be found at [[BuildingXtest|BuildingXtest]]. + +Prebuilt tests can be found [[http://xorg.freedesktop.org/tests/|http://xorg.freedesktop.org/tests/]] + + +## CurrentWork + +* [[TestGroup/EviExt|TestGroup/EviExt]] - 3 interfaces +* [[TestGroup/DpmsExt|TestGroup/DpmsExt]] - 9 interfaces +* Xau +* Xmu(u) +* Xdbe +* XShm +* XSync +* XShape +* XMITMisc +* XSecurity +* Xcomposite +* Xcursor +* Xdamage +* Xevie +* Xft +* Xi +* Xinerama +* Xpm +* Xrender +* Xss +* Xv
\ No newline at end of file diff --git a/TestGroup/CodeManagement.mdwn b/TestGroup/CodeManagement.mdwn new file mode 100644 index 00000000..42ec235d --- /dev/null +++ b/TestGroup/CodeManagement.mdwn @@ -0,0 +1,26 @@ + + +# Test Suite Code Management + +More formal rules should be used for managing the source code of formal tests. This document defined the rules that should be followed. + + +## Change Reviews + +Code changes should be sent to the [[mailing list|http://lists.freedesktop.org/mailman/listinfo/xorg-test]] for approval. 2 days should be allowed for comments, after which time, the change may be committed if there were not issues raised. Code changes that alter the method used to implement a test should be given heavier consideration and evaluated against the definition of the assertion and test cases involved. + + +## Functional Changes + +Functional changes to existing code should be considered carefully. Functional changes should not change the intended result of a test. + + +## New Features + +New features should be developed following the formal process of test suite development as summarized here + +* The specification of the feature being tested shall be identified. The specification should be largely complete, with some maturity, but need not be formally approved as a Standard yet. +* For each entity (ie function) in the Specification, a list of assertions shall be created and reviewed. +* For each assertion, a list of test cases shall be created and reviewed. +* For each test case, write code to implement the test. +New features shall be clearly marked as "in-progress" until they are complete, and approved by the Testing Group for use as a part of the formal test suite. diff --git a/TestGroup/DpmsExt.mdwn b/TestGroup/DpmsExt.mdwn new file mode 100644 index 00000000..3b7227de --- /dev/null +++ b/TestGroup/DpmsExt.mdwn @@ -0,0 +1,25 @@ + + +# Display Power Managment Signaling Test Suite + +This is an addition to the test suite for the DPMS extension. + + +## The Specification + +The specification for this extension can be found [[here|http://xorg.freedesktop.org/docs/Xext/DPMSLib.pdf]]. + + +## The Test Code + +Until we get our own CVS repository organized, this work is being done in the Linux Standard Base (LSB) project repository, [[http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-vsw4/xtest/tset/DPMS/?cvsroot=lsb|http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-vsw4/xtest/tset/DPMS/?cvsroot=lsb]] + + +## Owner + +Gordon [[McFadden|McFadden]] + + +## Current Status + +Assertions ready for Review diff --git a/TestGroup/EviExt.mdwn b/TestGroup/EviExt.mdwn new file mode 100644 index 00000000..c72adc92 --- /dev/null +++ b/TestGroup/EviExt.mdwn @@ -0,0 +1,27 @@ + + +# Extended Visual Information Test Suite + +This is an addition to the test suite for the EVI extension. This extension has only 3 APIs so it a good small example of how to add tests for an extension. + + +## The Specification + +The specification for this extension can be found [[here|http://xorg.freedesktop.org/docs/Xext/evi.pdf]]. + + +## The Test Code + +Until we get our own CVS repository organized, this work is being done in the Linux Standard Base (LSB) project repository, [[http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-vsw4/xtest/tset/EVI/?cvsroot=lsb#dirlist|http://cvs.gforge.freestandards.org/cgi-bin/cvsweb.cgi/tests/lsb-vsw4/xtest/tset/EVI/?cvsroot=lsb#dirlist]] + + +## Owner + +Gordon [[McFadden|McFadden]] [[gordon.mcfadde@intel.com|mailto:gordon.mcfadde@intel.com]] + + +## Current Status + +Assertions ready for Review + +Strategy sections have been added diff --git a/TestGroup/HowTo.mdwn b/TestGroup/HowTo.mdwn new file mode 100644 index 00000000..2d9250d5 --- /dev/null +++ b/TestGroup/HowTo.mdwn @@ -0,0 +1,11 @@ + +The existing X Test Suite was developed using a methodology that will be described here. + + +## Create Assertion List + + +## Develop Test Strategy + + +## Implement Test Cases diff --git a/TiagoVignatti.mdwn b/TiagoVignatti.mdwn new file mode 100644 index 00000000..d3be06ca --- /dev/null +++ b/TiagoVignatti.mdwn @@ -0,0 +1,13 @@ + + +## Tiago Vignatti + +[[http://web.inf.ufpr.br/vignatti|http://web.inf.ufpr.br/vignatti]] + +Email: vignatti AT c3sl DOT ufpr DOT br + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/Tinderbox.mdwn b/Tinderbox.mdwn new file mode 100644 index 00000000..bbbfed33 --- /dev/null +++ b/Tinderbox.mdwn @@ -0,0 +1,54 @@ +## Tinderbox status + +[[tinderbox|http://tinderbox.x.org/]] + +## Adding a new machine + +The steps for setting up a new machine are: + +* Read [[http://tinderbox.x.org/participate|http://tinderbox.x.org/participate]], get a username/pass +* Set up jhbuild; see [[http://wiki.x.org/wiki/JhBuildInstructions|http://wiki.x.org/wiki/JhBuildInstructions]] +* "jhbuild build"; check that the build completes and you have the appropriate dependencies +* Once you're ready to add the machine to the tinderbox front page, set up a crontab entry such as: + +`0 */2 * * * bin/jhbuild autobuild -a -c --report-url="http://USER:PASS@tinderbox.x.org/builds/rpc"` + +(instructions from [[this email|http://lists.freedesktop.org/archives/xorg/2008-December/041211.html]]) + +## Using ccache and an autoconf cache file + +Since many of these clean/configure/build runs will be identical, it's a big win to use [[ccache|http://ccache.samba.org/]] and an [[autoconf cache file|http://www.gnu.org/software/hello/manual/autoconf/Cache-Files.html]], e.g. add to jhbuildrc + + os.environ['CC'] = 'ccache gcc' + os.environ['CXX'] = 'ccache g++' + autogenargs='--cache-file=os.path.join(os.environ['HOME'], 'configure-cache') + +## Changing the moduleset + +Locally modifying the jhbuild moduleset to add or remove modules isn't a good idea as this means that you don't automatically pick up changes to it. + +To avoid building modules (e.g. which aren't appropriate to your target), you can use the skip configuration variable in the jhbuildrc file, e.g. + + skip = [ 'xdriinfo', 'libdrm', 'libpciaccess' ] + +To add additional modules, you can use the technique of creating of local moduleset which includes the standard moduleset and your additions, e.g. + + moduleset = os.path.join(os.environ['HOME'], 'myxorg.modules') + +where the contents of myxorg.modules is something like + + <?xml version="1.0" standalone="no"?> <!--*- mode: nxml -*--> + <!DOCTYPE moduleset SYSTEM "moduleset.dtd"> + <?xml-stylesheet type="text/xsl" href="moduleset.xsl"?> + + <moduleset> + <include href="http://cgit.freedesktop.org/xorg/util/modular/plain/xorg.modules" /> + + <metamodule id="xquartz"> + <dependencies> + <dep package="libAppleWM"/> + <dep package="xorg"/> + </dependencies> + </metamodule> + + </moduleset> diff --git a/ToDo.mdwn b/ToDo.mdwn new file mode 100644 index 00000000..50c40bae --- /dev/null +++ b/ToDo.mdwn @@ -0,0 +1,77 @@ + +[[!toc ]] + +Xorg always needs more work and more contributors. Several tasks anyone can help with are listed below. Don't feel limited to these suggestions, and feel free to add your own suggestions to the list. + + +## Server + + +### Janitorial things + +These are largely mechanical things, suitable for someone who's just getting started and needs a way to get familiar with the server. + +* The diagnostic messages printed in the log file are confusing. They range from uninformative, to misleading, to flat out wrong. The message severity levels are frequently wrong as well. [[Bug 3116|https://bugs.freedesktop.org/show_bug.cgi?id=3116]] +* Driver option names are inconsistent. +* Many drivers are underdocumented. +* The X codebase is quite crufty and could use a lot of cleaning up. +* Still far too much K&R C that should be ANSI. +* Triage [[open bugs in bugzilla|https://bugs.freedesktop.org/buglist.cgi?bug_status=__open__&product=xorg]]. +* Review and test [[patches in bugzilla|https://bugs.freedesktop.org/buglist.cgi?bug_status=__open__&product=xorg&keywords=patch]] and from [[the xorg mailing list|http://lists.freedesktop.org/archives/xorg/]]. +* Remove CVS tags inside of files. +See more possible work in the [[Janitor|Development/Janitor]] page. + + +### Minor development + +These are relatively self-contained problems, suitable for someone who knows how to program but doesn't necessarily understand the whole server. + +* X server backtraces could potentially be more useful. glibc's backtrace() isn't great. Maybe fork() gdb? Maybe link against libelf and walk the the symbols ourselves? +* XAA is lacking. See [[ExaStatus|ExaStatus]] for status on the replacement. +* Input properties are a lovely hammer, but they need some standardization for things like pointer acceleration. +* X server protocol dispatch is still handwritten. We should generate it from xcb-proto instead. +* Extend shadow to be something you can have per-drawable instead of per-screen. +* Loader: Remove the abstraction from the loader (hw/xfree86/loader) so it's just a simple libdl wrapper with the same API, and punt it up to the DIX, so all DDXes can use it. +* Remove statics: Make [[MAXSCREENS|https://bugs.freedesktop.org/show_bug.cgi?id=3876]] and [[MAXFORMATS|https://bugs.freedesktop.org/show_bug.cgi?id=3876]] run-time configurable, ditto MAXCLIENTS. ajax started a patch for MAXFORMATS, bother him about it. +* Code removal: Remove anything that's unused and/or bad. +* Port the int10 code to libx86. mjg59 and vignatti had started on this (from opposite ends). +* Build the "X server awesome scheduler": + * What we want is simple: a preemptive scheduler with priorities (real-time scheduler) to deal with multiple clients and with a special care for input events. One interesting thing to considerer is that the issue of long-lived requests is mostly a thing of the past. [[PolyLines|PolyLines]] are not that common, fonts are mostly client side, and OpenGL is usually client-side as well due to DRI. Moreover, clients can block each other. Just try to execute a `x11perf -getimagexy500` plus play a video to see. x11perf eats all the X process. Isn't wiser to give a tiny quantum here for each client? The funny thing is that -dumbSched gives a better result than with the _smart_ scheduler :) So simultaneous client requests aren't dealt by smart scheduler at all. This is quite interesting for those who is trying to start in the X world because it doesn't touch much of the graphics oddities :) + +### Major development + +These are big cross-cutting things. Much of this is just ajax's wishlist. + +* Rewrite the bottom of the rendering layer. The old Get/Set/Fill``Spans API was appropriate when your memory aperture was all of 16 bytes, but this is really not the case anymore. Should move to Get``Image/Put``Image/Poly``Fill``Rect/Copy``Area. +* Redo Pictures. Right now they're like a GC and a Drawable in one, which makes things really awkward. +* More generally, detach rendering from the ScreenRec. Wrapping is a useful technique, but most useful if the thing with the wrap chain is something you can create temporaries of, which ScreenRec is not. +* Extend Xdmx to act as a drop-in replacement for Xnest, and delete the latter. +* Extend Xdmx to use the XI2 model of input devices. +* Port to any new platforms we need support for. +* Make one set of Xinerama protocol routines for use by Xinerama and Xinerama-emulating code such as randr-1.2 and driver MergedFB code. +* Make one set of logical screen to graphics device splitting code out of the Xinerama & Xdmx code bases. +* Enable more input devices, in particular speech recognition, by allowing events to specify keysyms. It can be very difficult to convert dictation to keystrokes; it is much easier to transmit unicode directly to the application. + +### Driver projects + +* evdev: the evdev driver currently ignores joysticks altogether. It could be extended to work against such devices and auto-setup itself accordingly. +* evdev: evdev touchscreen support is still subpar to evtouch. One missing feature is a right-click emulation on long presses. This would be a quite trivial project. +* synaptics: coasting is a on/off state toggle. should be momentum-based instead + +## Utilities + +* xrandr is still a bit touchy. The failure modes are not obvious, CRTCs are magical, etc. +* Input device utilities (xmodmap, setxkbmap, xkbutils etc.) need to deal with multiple devices (MPX/Xi2). +* xev needs to learn how to display events added in recent extensions, such as Xi2, RandR +* Should xprop work with input device (Xi2) and output device (randr) properties too? +* xdpyinfo could probably use some updates to the -ext support for newer extensions. +* Port utilities (one at a time) from libX11 to [[xcb|http://xcb.freedesktop.org/]] + +## Testing + +* For general information on helping with Xorg testing, see the [[TestGroup|TestGroup]] page. +* Specific information about release testing can be found on the [[XorgTesting|XorgTesting]] page. + +## Related Projects + +* xcb: See [[XCBToDo|http://xcb.freedesktop.org/XCBToDo/]]
\ No newline at end of file diff --git a/UrosNedic.mdwn b/UrosNedic.mdwn new file mode 100644 index 00000000..b2da5855 --- /dev/null +++ b/UrosNedic.mdwn @@ -0,0 +1,29 @@ + + +## Uros Nedic + +_Date of birth_: June 25th, 1980 + +_Place of birth_: Belgrade, Serbia + +_Spoken languages_: Serbian, English, Russian + +_Primary education_: Primary School Saint Sava, Velika Plana, GPA 5.0/5.0_ + +_Secondary education: Mathematical high school, Belgrade, GPA 5.0/5.0_ + +_Faculty education: School of Electrical Eng., Dep. of Telecommunications, Univ. of Belgrade_ + +_Areas of interest: Digital networks, Software design, Theory of Computer Sci., Antennas, Radio Comm._ + +_Areas of interest in [[OpenSolaris|OpenSolaris]] Comm.: Writing kernel modules, X Window System_ + +**Rest to be written very soon** + +Email: urosn AT SPAMFREE acm DOT org + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/UserDocumentation.mdwn b/UserDocumentation.mdwn new file mode 100644 index 00000000..a1eb5fc5 --- /dev/null +++ b/UserDocumentation.mdwn @@ -0,0 +1,17 @@ + +The user documentation for the different versions can be found here: + +* [[6.9.0|http://ftp.x.org/pub/X11R6.9.0/doc/html]] +* [[7.0|http://ftp.x.org/pub/X11R7.0/doc/html]] +* [[7.5|http://www.x.org/releases/X11R7.5/doc/]] +* [[7.6|http://www.x.org/releases/X11R7.6/doc/]] +* [[7.7|http://www.x.org/releases/X11R7.7/doc/]] +A brief getting started guide and tutorial for end-users and non-programmers is [[here|UserDocumentation/GettingStarted]]. + +O'Reilly & Associates have also made freely available online some of their classic X Window System manuals. These are a bit older, dating from the [[X11R3|X11R3]], R4, or R5 eras, and applying to the commercial Unix versions of the time, but may still have some useful information in: + +* [[X Series Volume 3: X Window System User's Guide, 3rd Edition (1990, covers X11R3 & R4)|http://www.archive.org/details/xwindowsystem03quermiss]] +* [[X Series Volume 3: X Window System User's Guide, OSF/Motif Edition (1990, covers X11R4 & Motif 1.1)|http://www.archive.org/details/xwindowsytemosf03querarch]] +* [[X Series Volume 3: X Window System User's Guide, OpenLook Edition (never published)|http://www.oreilly.com/openbook/openlook/]] +* [[X Series Volume 8: X Window System Administrator's Guide, 1st edition (1993, covers X11R5)|http://www.archive.org/details/xwindowsystemadm08muimiss]] +O'Reilly has published a much more recent and up-to-date user guide [[X Power Tools|http://books.google.com/books?id=V1ZBeNJIx7UC]], but only a small preview of it is available for free online at this point. diff --git a/UserDocumentation/GettingStarted.mdwn b/UserDocumentation/GettingStarted.mdwn new file mode 100644 index 00000000..cf0a3c66 --- /dev/null +++ b/UserDocumentation/GettingStarted.mdwn @@ -0,0 +1,217 @@ + +This wiki page will be used to briefly document getting started with X.org tools and technologies. This wiki page is a quick tutorial for end-users and non-programmers. (Please add wiki content to quickly introduce and get up to speed with tools and technologies, but keep it brief -- link to manual page or other wiki pages for full details. See copyright license note at bottom.) + + +# Tools and applications + +The following are some of the commonly installed applications and tools included with X.org. This is not a complete list. This just briefly introduces, shares examples of common usage, and links to further details. + +TODO: maybe better organize this by just most common applications first or just remove rarely used applications. + + +### appres + +List "application resources". For example, "appres XTerm" will list the xterm resources. These X resources are a type of configuration syntax. Default X resource configuration files can be seen under /etc/X11/app-defaults/, /usr/local/lib/X11/app-defaults/, or other location. + + +### beforelight + +Simple screensaver using MIT-SCREEN-SAVER. TODO link to details about MIT-SCREEN-SAVER. TODO: And show example usage. + + +### bitmap + + +### atobm + + +### bmtoa + + +### editres + + +### iceauth + + +### ico + + +### listres + + +### luit + + +### setxkbmap + + +### twm + +"twm (Tom's Window Manager or Tab Window Manager) is the standard window manager for the X Window System, version [[X11R4|X11R4]] onwards. twm was created by Tom [[LaStrange|LaStrange]]. It is a re-parenting window manager that provides title bars, shaped windows and icon management, and is extensively configurable. + +twm was a breakthrough achievement in its time, but has been largely superseded by other window managers and is no longer maintained. " [[http//en.wikipedia.org/wiki/Tom's_Window_Manager|http//en.wikipedia.org/wiki/Tom's_Window_Manager]] +### x11perf + + +### x11perfcomp + + +### xauth + + +### xbacklight + + +### xbiff + + +### xcalc + +xcalc is a scientific calculator desktop accessory that can emulate a TI-30 or an HP-10C. (from the xcalc man page) +### xclock + +The xclock program displays the time in analog or digital form. The time is continuously updated at a frequency which may be specified by the user. (from the xclock man page) +### xconsole + + +### xdm + + +### xdmshell + + +### xdpyinfo + +Xdpyinfo is a utility for displaying information about an X server. It is used to examine the capabilities of a server, the predefined values for various parameters used in communicating between clients and the server, and the different types of screens and visuals that are available. [...] (from the xdpyinfo man page) +### xev + +This opens a small "Event Tester" window. This is normally used for studying X events, such as pointer motion, entering windows, etc. + +For a normal user it may be useful to identify special keys. For example, running xev and pressing the "right Windows menu" key on a system may show "keycode 117 (keysym 0xff67, Menu)" (and other details). + + +### xeyes + +"xeyes is a graphical computer program showing two googly eyes which follow the cursor movements on the screen as if they were watching it." [[http://en.wikipedia.org/wiki/Xeyes|http://en.wikipedia.org/wiki/Xeyes]] + + +### xfontsel + + +### xgamma + + +### xhost + + +### xinit + + +### startx + + +### xkill + + +### xload + + +### xlogo + + +### xlsclients + +Xlsclients is a utility for listing information about the client applications running on a display. It may be used to generate scripts representing a snapshot of the user's current session. (from the xlsclients man page) +### xmag + + +### xman + + +### xmessage + + +### xmodmap + + +### xmore + + +### xplsprinters + + +### xprehashprinterlist + + +### xprop + + +### xrandr + + +### xrdb + + +### xrefresh + + +### xset + + +### xsetmode + + +### xsetpointer + + +### xsetroot + + +### xsm + + +### koi8rxterm + + +### resize + + +### uxterm + + +### xterm + +"xterm is the standard terminal emulator for the X Window System. A user can have many different invocations of xterm running at once on the same display, each of which provides independent input/output for the process running in it (normally the process is a Unix shell)." [[http://en.wikipedia.org/wiki/Xterm|http://en.wikipedia.org/wiki/Xterm]] + + +### xvinfo + + +### xwd + +Useful and easy way to take screenshots. Saves in the XWD X Window Dump image data format. The image can be displayed with xwud or The GIMP, [[ImageMagick|ImageMagick]] display or other popular image viewers. + +Here's an example of taking screenshot of entire display: + + * xwd -root -out screenshot.xwd +Here's an example of taking a screenshot of just a selected window after three seconds: + + * sleep 3 && xwd -out window.xwd +(It will show a special mouse pointer for you to click in the window to capture.) + + +### xwininfo + + +### xwud + +Can be used to display images in the XWD X Window Dump image format (see xwd above). Note that common utilities like The GIMP and [[ImageMagick|ImageMagick]] display(1) can also work with these images. + + + +--- + + + +Copyright / License. I have no idea what the copyright and licensing is for this entire wiki website. For this webpage, let's just consider this content is under the standard X.org license. (I'd link to it but don't see official statement on the license to be used for new code.) diff --git a/VgaArbiter.mdwn b/VgaArbiter.mdwn new file mode 100644 index 00000000..2223f7a2 --- /dev/null +++ b/VgaArbiter.mdwn @@ -0,0 +1,117 @@ + + +# VGA arbiter + + +## Background + +When multiple video cards are uncoordinatedly using the legacy VGA interface, one card might decode messages that were not sent to it. To solve this problem, it is needed an entity that controls all the accesses made using the legacy VGA interface. In Xorg this happens when multiple instances are running. It is important to note that some GPUs can skip completely if they are able to disable their VGA decoding resources (unfortunately this seems not so usual). + +A good explanation of this problem is presented here: [[http://people.freedesktop.org/~dodji/arbitration-log.txt|http://people.freedesktop.org/~dodji/arbitration-log.txt]] + + +## Required Functionality + +Devices that decode legacy VGA IO and/or MEM need to be identified. In addition, their IO/MEM enable/disable bits need to be toggled (along with the VGA forwarding enables on any bridges on the path to the devices). This is needed to prevent multiple devices from decoding legacy access. Drivers need to disable legacy decoding completely on their hardware, which most modern cards can do. The driver must be able to inform the arbiter of that fact to take out the card from the picture. This must be done carefully since bad things will happen if the card generates an interrupt when the arbiter has disabled MEM decoding on the card. The arbiter needs to either forbid cards to use interrupts if they are set to decode legacy space (and thus can be disabled at any time) or have a driver callback for disabling IRQ emission on a given card when it's being disabled by the arbiter. IO and MEM can't be treated separately since there is only one VGA forward bit on PCI-to-PCI bridges. + + +## Project Status + +The implementation provided is just a proof-of-concept, and it shows that the VGA Arbiter **works**. Now we need to decide the definitive interfaces and start writing the definitive code. There is an interesting [[blog post|http://vignatti.wordpress.com/2008/02/21/benchmarking-it-all/]] regarding the performance of this proof-of-concept. + +The current implementation is split into 3 pieces. + + +### Kernel Module + +The VGA Arbiter, a Linux Kernel module, provides a device node that has to be used by applications that decode the legacy VGA interface. This can be easily ported to others platforms. + +Currently, it is just a Kernel module because modules are way much easier to compile and test than built-in Kernel code. Ideally, this module will be integrated into the Kernel so that Kernel code will also be able to use the module without using its device node interface. + +Also, the device node interface could also be changed to something else, to improve performance. + + +### User Space Library + +There is a little user space library that communicates with the arbiter using the device node interface. It was made so that the code inside the applications would be much easier to write. Also, when something on the device node interface changes, we wouldn't need to change all the applications, only the library (considering that its interface doesn't change). + + +### X Server Code + +There is a modified version of the X server that uses the VGA Arbiter instead of RAC when it can. The current implementation works exactly like the RAC implementation: it's a wrapper on the video drivers. Ideally, only the code that accesses the VGA Arbiter should be moved to inside the video drivers, because this would allow a much better performance. So, the video driver wrapper could be just removed. + + +## Current Implementation + +[[http://people.freedesktop.org/~vignatti/VGA.Notes|http://people.freedesktop.org/~vignatti/VGA.Notes]] + + +## Source code + +The current repository address is just **temporary**, so when it stops working, be sure to visit this page again to get the updated link. + +* Kernel module: git-clone [[http://git.c3sl.ufpr.br/pub/scm/multiseat/vga-module.git|http://git.c3sl.ufpr.br/pub/scm/multiseat/vga-module.git]] +* User space library: git-clone [[http://git.c3sl.ufpr.br/pub/scm/multiseat/libvgaaccess.git|http://git.c3sl.ufpr.br/pub/scm/multiseat/libvgaaccess.git]] +* X implementation: git-clone [[http://git.c3sl.ufpr.br/pub/scm/multiseat/xserver.git|http://git.c3sl.ufpr.br/pub/scm/multiseat/xserver.git]] (Note that the code is under server-1.4-branch branch) +You can also use [[gitweb|http://git.c3sl.ufpr.br/gitweb]] to navigate through the code. + + +## Building and installing + +Beyond these repositories above, to bring up an Xorg server with the VGA arbiter, we'll need to clone the input devices and the video driver repository from fd.o. After cloned all these repositories, the first step is building the kernel module. We'll need this environment variable set: +[[!format txt """ + export PKG_CONFIG_PATH=/opt/master/lib/pkgconfig +"""]] +then, + + +[[!format txt """ + cd vga-module + make +"""]] +After we need to build the vgaaccess library: +[[!format txt """ + cd libvgaaccess + ./autogen.sh --prefix=/opt/master + make + sudo make install +"""]] +Now we can build the X server: +[[!format txt """ + cd xserver + git-checkout -b server-1.4-branch origin/server-1.4-branch # to checkout the server-1.4-branch where the arbiter implementation resides + ./autogen.sh --prefix=/opt/master -disable-xnest -disable-kdrive -disable-xprint -disable-xvfb + make + sudo make install +"""]] +So now it's time to run it all. Lets do it using two servers: +[[!format txt """ + cd vga-module + insmod vgaarb.ko + cd .. + cd xserver + ./hw/xfree86/Xorg -ac -fp /usr/share/fonts/X11/misc -noreset -sharevts -VGAarbiter vt7 :1 & + ./hw/xfree86/Xorg -ac -fp /usr/share/fonts/X11/misc -noreset -sharevts -VGAarbiter vt7 :2 & +"""]] + +## TODO + +Kernel Module: + +* make it a built-in Kernel Code. +* decide if the device node interface will be the definitive interface. +* make other parts Kernel code that use the VGA Interface use the module functions +* need to be DRI (interruptions) aware. +X server code: + +* call the arbiter functions inside the video drivers, not using the current video driver wrapper (like in RAC). (this sentence means: start the X server code all over again, but now doing it the right way). + +## FAQ + +Q: Why? + +A: To start several instances of Xorg at same time using different graphical devices (e.g. to deploy a [[multiseat|http://wiki.c3sl.ufpr.br/multiseat/]]) + +Q: Who is working here? + +A: [[TiagoVignatti|TiagoVignatti]], [[PauloZanoni|PauloZanoni]] and Benjamin Herrenschmidt diff --git a/VideoDriverFAQ.mdwn b/VideoDriverFAQ.mdwn new file mode 100644 index 00000000..04027e1a --- /dev/null +++ b/VideoDriverFAQ.mdwn @@ -0,0 +1,43 @@ + + +# Video driver FAQ + +[[!toc ]] + +Information about the individual video drivers can be found on the [[VideoDrivers|VideoDrivers]] page. This page is there to provide information that doesn't quite fit into a single driver. + + +## I have an S3 graphics card, which driver should I use ? + +There are three drivers for S3 graphics chipsets: + + * The _S3_ driver, which supports some of the _Trio64_ and older chipsets (use: `Driver "s3"`, for details check [[s3|s3]]), + * the _S3 Virge_ driver which supports the _S3 Virge_ and _S3 Trio3D_ chipsets (use: `Driver "s3virge"`, for details check [[s3virge|s3virge]]), + * the _Savage_ driver which supports most of the _S3 Savage_ chipsets (use: `Driver "savage"`, for details check [[savage|savage]]). +Please *NOTE*. The S3 driver in XFree86 3.x supports a lot more of the old S3 chips. Only support for a few of them has been ported to X.Org R6.7. Currently noone is working on porting further chipsets. We are still looking for someone to help porting more S3 chips. + + +## I have a CirrusLogic chipset, which driver should I use ? + +There is one 'wrapper' module which will automatically detect the type of hardware and load the correct sub module. We support both flavors of Cirrus Logic chipsets, the _ 'Laguna' _ and the _ 'Alpine' _ chipsets. (use: `Driver "cirrus"`, for details check [[cirrus|cirrus]]) + +Please *NOTE*: X.Org 6.7 doesn't support some of the old ISA Cirrus chips XFree86 3.x used to support. + + +## I have an ATI graphics card, which driver should I use ? + +The [[GATOS|http://sourceforge.net/projects/gatos]] project create enhanced (fast) drivers for the ATI chipsets, which also include TV in/out support for most ATI cards that have this feature. While the main target of these drivers is still XFree86, they are still compatible with the X.org server. The GATOS project does not yet redistribute X.org compatible binaries, but compiling against the X.org source tree will work. The GATOS TV-in code has been incorporated into XOrg, but its TV-out code is still only available in the GATOS drivers. + +For r200 cards on down, the open source ati drivers will provide excellent 3d acceleration. for r300 and up, the only fully functioning option is ATI's proprietary fglrx drivers in [[X11R6|X11R6]].8 and below. In [[X11R6|X11R6]].9 and [[X11R7|X11R7]].0, DRI will work on r300 and up. + + +## I have an XGI card, which driver should I use? + +The XGI XP5 laptop chip and Volari V3 card are based on a Trident core. However, they are not yet supported in the [[trident|trident]] driver, so you will have to use [[vesa|vesa]] for now. + +All other XGI chips (Volari V3XT, V5, and V8) are supported by the [[sis|sis]] driver in Xorg 6.9 and later. + + +## I have a Matrox card, which driver should I use? + +X.Org ships with the [[mga|mga]] driver which supports the Matrox G-series cards (G550 and below). Alternatively, Matrox offers X.org-compatible Linux drivers on their [[driver download page|http://www.matrox.com/mga/support/drivers/latest/home.cfm]], for both the G-series and P-series cards. diff --git a/VideoDrivers.mdwn b/VideoDrivers.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/VideoDrivers.mdwn diff --git a/WikiHomePage.mdwn b/WikiHomePage.mdwn new file mode 100644 index 00000000..adec7b77 --- /dev/null +++ b/WikiHomePage.mdwn @@ -0,0 +1,10 @@ + +A WikiHomePage is your personal page on a [[WikiWikiWeb|WikiWikiWeb]], where you could put information how to contact you, your interests and skills, etc. It is regarded as to be owned by the person that created it, so be careful when editing it. + +When you create one, put the the word [[CategoryHomepage|CategoryHomepage]] on it, like can be seen on this page. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/WikiName.mdwn b/WikiName.mdwn new file mode 100644 index 00000000..0b6481e3 --- /dev/null +++ b/WikiName.mdwn @@ -0,0 +1,2 @@ + +A WikiName is a word that uses capitalized words. WikiName****s automagically become hyperlinks to the WikiName's page. See also [[HelpForBeginners|HelpForBeginners]], "Arbitrary Page Names". diff --git a/WikiSandBox/.._.._.._plugin_action_moinexec.py b/WikiSandBox/.._.._.._plugin_action_moinexec.py Binary files differnew file mode 100644 index 00000000..b8befca1 --- /dev/null +++ b/WikiSandBox/.._.._.._plugin_action_moinexec.py diff --git a/WikiSandBox/mytest.png b/WikiSandBox/mytest.png Binary files differnew file mode 100644 index 00000000..5e7c09c7 --- /dev/null +++ b/WikiSandBox/mytest.png diff --git a/WikiWikiWeb.mdwn b/WikiWikiWeb.mdwn new file mode 100644 index 00000000..15f5ecd3 --- /dev/null +++ b/WikiWikiWeb.mdwn @@ -0,0 +1,11 @@ + +The [[!c2 FrontPage desc="first ever wiki site"]] was founded in 1994 as an automated supplement to the [[!c2 PortlandPatternRepository desc="PortlandPatternRepository"]]. The site was immediately popular within the pattern community, largely due to the newness of the internet and a good slate of [[!c2 InvitedAuthors desc="InvitedAuthors"]]. The site was, and remains, dedicated to [[!c2 PeopleProjectsAndPatterns desc="PeopleProjectsAndPatterns"]]. + +[[!c2 WardCunningham desc="WardCunningham"]] created the site and the WikiWikiWeb machinery that operates it. He chose wiki-wiki as an alliterative substitute for quick and thereby avoided naming this stuff quick-web. An early page, [[!c2 WikiWikiHyperCard desc="WikiWikiHyperCard"]], traces wiki ideas back to a [[!c2 HyperCard desc="HyperCard"]] stack he wrote in the late 80's. + +See also one of these links: + +* [[http://www.c2.com/cgi/wiki|http://www.c2.com/cgi/wiki]] or [[!c2 FrontPage desc="FrontPage"]] +* get some answers on the [[!c2 WikiWikiWebFaq desc="WikiWikiWebFaq"]] +* get to know more about the [[!c2 WikiHistory desc="WikiHistory"]] +* [[Ward Cunningham Radio Interview|http://news.mpr.org/programs/futuretense/daily_rafiles/20011220.ram]]
\ No newline at end of file diff --git a/X.Org-GSoC2008-Application.mdwn b/X.Org-GSoC2008-Application.mdwn new file mode 100644 index 00000000..dc8531bb --- /dev/null +++ b/X.Org-GSoC2008-Application.mdwn @@ -0,0 +1,41 @@ + + +## Project Proposal Guidelines + +We expect more project proposals than Google will be able to fund. Here is our list of suggestions about how to write a Summer of Code proposal that will stand a chance of rising to the top of the heap. + + +## Requirements + + * Applicants meet Google's requirements for participation in Summer of Code. + * Applicants are in regular and close contact with their X.Org mentors. + * Applicants know their target programming language. + +## Proposal Outline + + * Name and Contact Information + * Title + * Synopsis. A short summary. + * Benefits to the Community. What novel technologies or approaches will be demonstrated? + * Deliverables. Give a brief, clear work breakdown structure with milestones and deadlines. Make sure to label deliverables as optional or required. You may want plan to start by producing some kind of whitepaper, or planning the project in traditional software engineering style. Work should include + * investigation + * programming + * documentation + * dissemination + * Description. A list of project details (rough architecture, etc). + * Related Work. A list of other people's work. Could be as simple as a URL with one sentence description. Be sure to explain how the proposed work is different from similar related work. + * Biographical Information. + * Summarize your education, work, and open source experience. + * List your skills and give evidence of your qualifications. + * List published papers, successful open source projects, etc. + * Please list any non-Summer-of-Code plans you have for the Summer, especially employment and class-taking. Be specific about schedules and time commitments. + +## General Notes + +Your proposal should be around 1500-4000 words in plain text. There is a limit on the number of submitted proposals, if you have several ideas, please submit several proposals. Do include URLs pointing to information that would help convince us of your chances of success: preliminary project plans or progress, other projects you've been involved with that were successful, code samples, etc. + +It is better if your project is under-scoped and sure to complete; as opposed to a largeish project which may not get done. + +One of the features of Google/X.Org Summer of Code is that it is a organization to help with projects involving integrating free software and hardware from different sources. + +See [[SummerOfCodeIdeas|SummerOfCodeIdeas]] for project ideas. diff --git a/X11R68PostPartumNotes.mdwn b/X11R68PostPartumNotes.mdwn new file mode 100644 index 00000000..a6bdc9e8 --- /dev/null +++ b/X11R68PostPartumNotes.mdwn @@ -0,0 +1,215 @@ + + +# X.Org Foundation 6.8 release postpartum discussion notes + +[[!toc ]] + + +## Introduction + +These notes serve to document the tasks and issues that arose during the 6.8 release cycle and are intended to be a starting point for further discussion. They are arranged into the following general categories: scheduling, testing, and finalizing the release. + +While the discussion below mainly focuses on tasks that did not work well or need to be improved, it should be noted that the goal of the release team was not to perfect the release process but rather to improve it as much as possible. I (and, from the comment I received, many others) feel that the team was very successful and achieved its goal given the constraints of the release. + + +## Scheduling + +Discussion of this release started in late May 2004; however, due to the travel schedules of most X.Org Foundation BOD members, the schedule was not finalized until mid July 2004. The release was determined to be a time based release since it was driven by several companies (most notably Red Hat and SUSE) that needed to have a newer X Window System release for their upcoming products. Those companies needed to have the release ready at the beginning of September 2004, so the date for the release was initially set to 25 August 2004 in order to give a buffer for problems that might occur during the release cycle. + +The initial deadline for the release left us with a very tight schedule, which had several consequences. + + * The deadlines for the feature freeze and code freeze were severely compressed, which limited the features that could be added and limited the amount of testing that was possible. + * A few bugs that would have otherwise have held up the release had to be postponed until after the release. + * The number of new features added in this release was significant; however, most (if not all) had significant testing outside of the X.Org CVS tree before they were merged in. The majority of the remaining testing and bug fixing for these features were due to interactions they had with other new components. + * It was challenging to keep people working on the features and bugs in order to meet the deadlines. Gentle pressure was applied in most cases to help motivate people on the critical paths. This will likely always be an issue for the release manager. + * Because the release cycle was compressed, it was not difficult to keep people focused on the release. However, if the release cycle was longer, this will likely become a problem. +The schedule was broken down into three phases: adding new features, fixing bugs and updating documentation. The deadlines were set approximately two weeks apart for each phase in order for the release to be completed by the initial target date. + +During the first phase, the tree was open to adding new features, fixing bugs and updating documentation. The primary responsibility was setting up the initial wiki pages to describe the release plan and status, making sure that the community members were aware of the release schedule and coordinating with the authors of the new code to make sure that everything was checked in before the feature freeze deadline. This phase went smoothly with only a small amount of additional work being required to encourage a few of the committers to have their code checked in before the deadline. + +After the feature freeze, the work was limited to fixing bugs and updating documentation. The source tree remained open to all committers to allow for the most people to find and fix bugs. For the release manager, the amount of time and effort required was significantly higher in this phase. The main tasks included: + + * Managing the blocker bug list + * Holding regular release wranglers meetings (3 days/week) + * Keeping people focused on fixing bugs + * Reviewing and checking in fixes + * Resolving conflicts + * Encouraging testing (see testing section below) +Several suggestions were made by the release wranglers to help with fixing bugs. The most important of which was the release bug, which is a commonly practiced method of managing a release. Bugs that were considered serious enough to hold up (i.e., block) the release should be marked as blocking the release bug. Bugzilla allows the release manager to list the dependency tree of all bugs that block the release. While there were several attempts to explain how this worked, there was still some confusion. For future releases, it should probably be explicitly explained on the release and status pages. + +The release wranglers met several times per week -- usually Monday, Wednesday and Friday mornings -- to focus on the blocker bugs and any issues that had come up during the previous few days. During these meetings, the release manager asked for (and usually got) volunteers to work on certain bugs. The remaining bugs were left to the release manager to investigate and resolve. These meetings were invaluable to the release manager. + +Since multiple people were working on fixing bugs at this time, the source tree remained open, which not only allowed the release wranglers to check-in fixes, but also allowed other members of the community to work on and fix issues. The release manager monitored all of the check-ins to make sure that new features were not being added to the release. + +Other important contributions during this stage came from those testing the release. There were quite a few people who were just staring to compile the tree and do testing. They reported bugs and marked them as blockers where appropriate. Some pre-packaged binaries were also made to help those who didn't have the experience of building the source tree, but could help with testing. These packages should be encouraged and made more formal in future releases. The general idea behind the testing for this release was loosely defined, but the details had not yet been worked out at this point, so the majority of the testing during this phase was devoted to build and daily usage testing. + +Two other bugs were added during this phase: the "hold open but not block the release" bug and the release notes bug. The "hold open" bug turned out to be the less useful of the two since there was too much other work to do that these did not get attention. It is possible that this bug might be more useful in future releases if the schedule is not so compressed. The release notes bug was very useful and over the course of the release cycle it became the place where all documentation issues were placed. + +This bug fixing phase was extended by three days to allow several major bug fixes to be completed and checked in. It could have been extended further, but the general feeling what that if we were going to keep on track for a late August release, then we should go ahead and freeze the code. + +After the code freeze, the work was limited to fixing all major blocker bugs and updating the documentation. As noted above, the transition between the previous phase and this one was rather arbitrary to keep the release on schedule; however, it turned out that the main difference was that instead of everyone else checking in bug fixes, the release manager was the only person allowed to check in changes. Bug fixes were being proposed and attached to the release blocker bugs, and the release manager and/or the release wranglers would evaluate the change (where possible) and apply the patch if it was accepted. + +Looking back, having all bug fixes funneled through a single person slowed down the bug fixing too much. For future releases, we should consider having a small team of people with write permission to continue to check in bugs during the critical bug fixing phase. Also, this transition phase should probably happen before the code freeze goes into effect, which would allow the code freeze phase to concentrate solely on documentation changes and last minute critical bug fixes. + +It was during this code freeze phase that the testing was finally formalized. Once the formal testing procedures were documented, many more people started testing the release. The test matrix was updated as time permitted and as new test reports came in. Ideally, the testing should have been happening much earlier, but due to the compressed time schedule the test procedures were not formalized until late in the process. See the next section on testing for more details of the formal testing requirements for this release. + +One action helped initiate the testing: tagging the tree with the first release candidate. This action along with the formalizing of the test procedure appeared to catalyze the community around the release. There were four release candidates tagged during this phase. Perhaps making snapshot tags in the previous release process and defining the test procedure earlier would have helped focus attention on testing before the code freeze. + +As active formal testing began, more bugs were found and fixed in a relatively short period of time, but it soon became clear that the release would not be able to happen on the original schedule. The number of bugs were remaining relatively constant during this time. At this time, a list of the current blocker bugs was sent out each night to the mailing list to let people know the state of each blocker bug. + +Over time the number of blocker bugs slowly shrank, and the focus shifted from bug fixing to updating the release documentation. Initially, the source tree was open to others making documentation only changes, but as the release neared, the source tree was closed to all but the release manager. At that time, the release notes bug became even more valuable to keep track of the features and bugs that needed to be documented. + +The documentation needed to be updated in several places. First, the release number is currently present in the following files in the xc/docs directory: + + * xc/doc/man/general/Standards.man + * xc/doc/man/general/X.man + * xc/doc/man/general/XOrg``Foundation.man + * xc/doc/specs/BDF/bdf.ms + * xc/doc/specs/CTEXT/ctext.tbl.ms + * xc/doc/specs/FSProtocol/protocol.ms + * xc/doc/specs/ICCCM/icccm.ms + * xc/doc/specs/ICCCM/indexmacros.t + * xc/doc/specs/ICE/ICElib.ms + * xc/doc/specs/ICE/ice.ms + * xc/doc/specs/SM/SMlib.ms + * xc/doc/specs/SM/xsmp.ms + * xc/doc/specs/X11/CH01 + * xc/doc/specs/X11/abstract.t + * xc/doc/specs/X11/indexmacros.t + * xc/doc/specs/XDMCP/xdmcp.ms + * xc/doc/specs/XIM/xim.ms + * xc/doc/specs/XLFD/xlfd.tbl.ms + * xc/doc/specs/XProtocol/X11.protocol + * xc/doc/specs/XProtocol/indexmacros.t + * xc/doc/specs/Xaw/CH1 + * xc/doc/specs/Xaw/TPage_Credits + * xc/doc/specs/Xaw/widg.idxmac.t + * xc/doc/specs/Xext/DPMS.ms + * xc/doc/specs/Xext/DPMSLib.ms + * xc/doc/specs/Xext/bigreq.ms + * xc/doc/specs/Xext/evi.ms + * xc/doc/specs/Xext/record.ms + * xc/doc/specs/Xext/recordlib.ms + * xc/doc/specs/Xext/security.tex + * xc/doc/specs/Xext/shape.ms + * xc/doc/specs/Xext/shapelib.ms + * xc/doc/specs/Xext/sync.tex + * xc/doc/specs/Xext/synclib.tex + * xc/doc/specs/Xext/tog-cup.ms + * xc/doc/specs/Xext/xc-misc.ms + * xc/doc/specs/Xi/library.ms + * xc/doc/specs/Xi/porting.ms + * xc/doc/specs/Xi/protocol.ms + * xc/doc/specs/Xmu/Xmu.ms + * xc/doc/specs/Xt/strings.mit + * xc/doc/specs/i18n/Framework.ms + * xc/doc/specs/i18n/LocaleDB.ms + * xc/doc/specs/i18n/Trans.ms +Note that the documentation listed above is current as of the 6.8 release, and might change in the future. + +The documentation in the xc/programs/Xserver/hw/xfree86/doc directory also needed to be updated. This documentation was built from the sgml files in the sgml subdir. The README, BUILD and RELNOTES sgml files will probably need to be updated with every release. The other files should be updated by their respective maintainers as needed. One special file, defs.ent, contains the macro definitions for the current and previous releases, and it was updated. Next, the old XFree86 doctools were required to build the sgml documentation. A few patches were required to build the tools (thanks to Soeren). Egbert added a README.build-docs file that describes what is needed to build and update the docs in the source tree. + +Once the documentation was complete, the last steps to finish the development phase of the release were: + + * Set the final version number and release date in the config/cf/xorg.cf and config/cf/cygwin.cf files + * Tag the tree with the release tag, XORG-6_8_0 + * Create the release branch, XORG-6_8-branch +It was noted in an earlier release wranglers call that the branch could have been created much earlier in the release. Due to the compressed time schedule, it was decided to hold off creating the branch until very late to keep people focused on the release, instead of on new development. This should be reevaluated for future releases. + +Additional discussion points: + + * How should new releases be scheduled (i.e., if someone has a need for a new release, what should they do to get it scheduled)? + * Who/what determines the feature set for a new release? + * When should the stable release branch be created? What are the consequences of creating it earlier or later in the release cycle? + * Who should have write access to the source tree during the various stages of the release cycle? + * When should the tree be tagged for snapshots and release candidates? + * Should the documentation be updated to a more modern format? If so, should all docs be updated? + +## Testing + +For the release to be successful and accepted by the community, it was determined very early in the release cycle that testing the release would need to be a priority. The testing was broken down into two parts: what platforms were to be tested and what tests were to be run on those platforms. During OLS, Stuart Anderson and I discussed both of these issues and then presented it to the BOD. + +First, we determined that, given the scheduling constraints, it would not be possible to test all possible OS vendor, release, architecture, video card combinations, so a subset was proposed as sufficient. These included the operating system, the architecture, the distribution and release version number. Each combination would define a platform to be tested. + +Next, we proposed a set of tests to be run on those platforms. The list included build, install, conformance and run test categories, and we outlined what was required to pass each test category. The tests as well as the platforms were organized into a matrix and was added to the freedesktop wiki: + + * [[http://wiki.x.org/wiki/X11R68ReleaseStatus|http://wiki.x.org/wiki/X11R68ReleaseStatus]] +On that page, the test matrix was included and instructions were given for running each of the tests. Initially the instructions were quite sparse, but as more people ran the tests, they were expanded and improved. + +In the test matrix, the first three columns of each row defined one platform to be tested, and the last four columns displayed the state of the testing on that platform. Entries were labeled with the release candidate version that was tested and were given a green background if the test passed or a red background if the test failed (or had not yet been tested). + +Names responsible for testing (or gathering the test information) were put into the fourth column in an attempt to give people some ownership and responsibility for testing a particular platform. This was moderately successful; however, there were a few problems with this system: + + * The release schedule was incredibly tight and it was not possible to fully test all of the platforms listed. + * The amount of time to run through all of the tests was on the order or 8+ hours (on a 1GHz PC running Linux). Other platforms were significantly slower and some took days to complete the tests. + * Finding volunteers for testing (i.e., adding their name to the table) was not difficult as this was done early in the process, but it was not managed well enough. Clear responsibilities should have been outlined so that this process could have been self-starting and self-regulating. + * Updating the test matrix was cumbersome. Either giving this responsibility to those that volunteered to test a particular platform or automating it so that anyone can update the table would be better. The process for this release required that the release manager monitor the mailing list and update the release matrix as new reports came in. + * By the time the testing had begun, it quickly became clear that there were problems with the tests, which had to be addressed before any testing could truly begin. These problems were worked out within a few days, but the delay caused confusion and slowed down the testing process, and ultimately led to the release being delayed. + * There was also confusion about exactly which tests could be run on each platform. Certain tests could only be run on Linux systems, and comparable tests were not investigated for other platforms. + * The X test suite used was chosen for expediency and ease of use. It was not necessarily the best one available. +The initial goal for testing was to fill in the entire test matrix before the final release. However, it became clear to the release wranglers during the release cycle that the test matrix would not be completely filled, so the goal was changed to fill in as much of the matrix as possible before the release. + +As noted above, testing is a very time consuming process and certain tests lend themselves to automation. Many people do not have the extra test machines required to do run tests; however, for those that do, automating the test process would certainly make it more likely that testing would be done. One key tool that automated part of the testing procedure was tinderbox. It allowed us to quickly notice when recent check-ins broke the build process. During many of the release wranglers calls, tinderbox and related tools were discussed, and it was generally agreed that these tools should be explored further to help automate as many of the tests as possible. + +Additional discussion points: + + * What else should be done to improve the test instructions? + * How can the test matrix be better managed? + +## Finalizing the release + +Once the main development tasks were complete (as outlined above in the schedule section), the release was ready to be packaged and distributed to the community. This finalization stage included building the tarballs and documentation, uploading everything to the appropriate websites and handling the announcement/press release. + +Historically, the source code for each public release is made available through a set of tarballs. Egbert created a script to automate creating the set of tarballs from a checked out source tree. Here is an outline of the steps involved (to be run as root): + + 1. Create a new directory that will hold the release + * `mkdir /tmp/release` + 1. Export the tagged tree to this new dir + * `cd /tmp/release` + * `cvs export -r XORG-6_8_0 xc` + 1. Untar Egbert's build scripts and cd to that directory + 1. Create a directory to hold the tarballs and run the source script + * `mkdir final` + * `cd final` + * `../source /tmp/release` + 1. Rename the tarballs to the appropriate names for the current release + * `cd source/bindist` + * `mv Xsrc1.tgz X11R6.8.0-src1.tar.gz` + * _Repeat for each of the other src files_ +Currently, there are seven tarballs created. Their contents are described in the README file that is shipped with the release (and can be found in the documentation on the website -- see below). + +In addition to the multiple tarballs, it was later determined during the 6.8.1 update release that creating one large tarball containing all source code was desirable. From the web logs, more people downloaded the one large tarball than the set of smaller ones. + +The website on freedesktop includes not only the tarballs (above) but also the documentation for the release. The website is arranged as follows: +[[!format txt """ + X11R6.8.0/ + binaries/ + doc/ + patches/ + PDF/ + src/ + src-single/ +"""]] +The binaries directory contains the pre-compiled binaries for various operating system releases. At this time, no pre-compiled binaries are being made available. We should consider doing this for future releases. + +The doc directory contains the html formatted documentation for the full release. This documentation is taken from `ProjectRoot/lib/X11/doc/html` after doing both a "make install" and a "make install.man" from a full build of the release. These html files also reference the PDF docs, so the PDF sibling directory should contain the documentation from `ProjectRoot/lib/X11/doc/PDF`. + +The src directory contains the set of seven tarballs (described above) along with the md5sums file. The md5sums file can be created with the following command: "md5sum *.tar.* > md5sums". The src-single dir contains the single source tarballs and their own md5sums. For the 6.8.1 release, two single source tarballs were created: one in gzipped tar format and one in bzip2'd tar format. The bzip2 compressed tarball was added since it has become very popular and is smaller than the gzip compressed tarball. + +The patches directory is normally empty for full releases (i.e., releases that have a patch number of 0). For patch releases, this directory would contain the patches necessary to bring the release from the previous full or patch release up-to-date with the current patch release. See the 6.8.1 release for an example. + +The next task of the finalization process is creating the press release. This task took quite a while to get appropriate quotes from members of the community, companies, etc. so it is suggested for future releases that it be started well in advance of the preparation of the website documentation and tarballs. There are other steps required here, but since I was not involved with this task, I will leave it to others to describe the process. + +The goal was to complete the tasks described above and make the release available to the community on 9 September 2004. Unfortunately, several problems occurred and important lessons were learned about how to handle the release announcements: + +Many people were very excited about this release, and we hope that the excitement and enthusiasm carries over to future releases. However, there were some who snooped around the website and found the source tarballs before the official announcement had been made, and this got reported to slashdot. Since the X.Org website had not been updated and the press releases had not been finalized, this pre-announcement by slashdot caused confusion and "stole the thunder" from the official announcement. The lesson here is that the documentation and tarballs should be embargoed in a completely private place that no one other than those involved in the finalization stage have access to. + +The X.Org website and freedesktop website need to be made public at very nearly the same time. The official website should be X.Org with freedesktop as a mirror. However, since few people have access to the X.Org website, the freedesktop site was set up first and the X.Org site files were copied from there. This could have been handled better by embargoing the release. + +The press release needs to be prepared well ahead of time so that the official announcement sent to the press/mailing lists and the unveiling of the websites can be done simultaneously. + +Discussion points: + + * How much ahead of time does the press release need to be sent to the appropriate press outlets in order for it to be released at a specific time (i.e., the time that the embargo is lifted)? + * What other mirror sites are available? What should be done to coordinate with them to make the release available on their sites as soon as possible after the announcement? +-- [[KevinMartin|http://wiki.freedesktop.org/wiki/KevinMartin]] - 29 Sep 2004 (updated for [[MoinMoin|MoinMoin]] 02 Mar 2005) diff --git a/X11R7and69TODO.mdwn b/X11R7and69TODO.mdwn new file mode 100644 index 00000000..58b09090 --- /dev/null +++ b/X11R7and69TODO.mdwn @@ -0,0 +1,36 @@ + + +# X11R7 and X11R6.9 TODO Task List + +[[!toc ]] + +The plan is to use this page as a list of tasks and changes that need to be completed before the combined X11``R6.9/7.0 release. So, please feel free to add tasks that you are currently working on or will be eventually. People who are looking for ways that they can help can go through this list to pick out tasks to work on. + + +## General items + +The blocker bug for the combined release is here: [[https://bugs.freedesktop.org/show_bug.cgi?id=1690|https://bugs.freedesktop.org/show_bug.cgi?id=1690]] + +* Test the code in the tree and file bugs for problems found +* Go through all of the bugs listed in bugzilla and fix those that we can before the release +* Set up tinder clients for your system (see [[http://freedesktop.org/Software/TinderboxWiki|http://freedesktop.org/Software/TinderboxWiki]] for info on how to do this) + +## X11R6.9 + +Tasks for the 6.9 release: + +* Update to latest Mesa release -- note this is still being worked on by the Mesa developers. + +## X11R7.0 + +Tasks for the 7.0 release: + +* Many of the supporting files either have not been created or are currently empty. These include the protocol (for the proto module components), AUTHORS, Change``Log, COPYING, INSTALL, NEWS, README, and DEPEDENCIES files. +* Configure options corresponding to various monolithic tree cf options need to be supported. +* Server: create style guide for Makefile.ams, rewrite to fit. It's a mess right now. [[[DanielStone|DanielStone]]] +* Server: audit files currently being installed and determine if they match the exported SDK from 6.9, and if/how we need to update it. +* Server: port to more platforms (non-trivially difficult). +* Server: quartz, cygwin support +* Server: dmx, Xprint DDXes +* Server: add optional Exa support, expose selected AA via pkg-config. [[[DanielStone|DanielStone]]] +* lib/drivers: add XvMC client side libraries for via and i810
\ No newline at end of file diff --git a/XConsortium.mdwn b/XConsortium.mdwn new file mode 100644 index 00000000..d273a509 --- /dev/null +++ b/XConsortium.mdwn @@ -0,0 +1,170 @@ + + +## Name + +XConsortium - X Consortium information + + +## Synopsis + +Release 6.3 of X Version 11 was brought to you by X Consortium, Inc. + + +## Description + +The X Consortium was an independent, not-for-profit Delaware membership corporation. It was formed in 1993 as the successor to the MIT X Consortium. The purpose of the X Consortium was to foster the development, evolution, and maintenance of the X Window System, a comprehensive set of vendor-neutral, system-architecture neutral, network-transparent windowing and user interface standards. + +The X Window System was created in the mid-1980s at the Massachusetts Institute of Technology. In 1988, MIT formed a member-funded consortium to provide the technical and administrative leadership necessary to support further development of the X Window System. In 1992, MIT and the membership decided it was in their best interests to move the consortium out of MIT and create an independent, stand-alone organization. All rights to the X Window System were assigned by MIT to X Consortium, Inc. on January 1, 1994. X Consortium, Inc. closed its doors on December 31, 1996. All rights to the X Window System have been assigned to the Open Software Foundation. + +The X Consortium was financially self-supporting through membership fees. There are no license fees associated with the use of X Window System standards and code developed by the X Consortium. Membership in the X Consortium was open to any organization willing to execute a membership agreement. + +The X Consortium was a highly participative body. Members were encouraged to actively cooperate with the staff and other members in the design and review of proposed specifications, and in the design, coding and testing of sample implementations of those specifications. + +The X Consortium accomplished most of its work using electronic mail over the Internet, with individual mailing lists for working groups. Internet electronic mail connectivity was viewed as a requirement for useful participation in X Consortium activities. Meetings were held as necessary, often in conjunction with industry conferences and trade shows. + + +## Address + +To reach the X Consortium public Wide World Web server, use the URL: [[http://www.x.org|http://www.x.org]] + +To reach the X Consortium public ftp machine, use anonymous ftp to: [[ftp://ftp.x.org|ftp://ftp.x.org]] + + +## Roles + + +### Staff + +* President: + * Bob Scheifler +* Office Manager: + * Janet O'Halloran +* Director of Marketing: + * Paul Lavallee +* Director of Engineering: + * Jim Fournier +* Manager, X Window System: + * Matt Landau, emeritus +* Technical Director, X Window System: + * Ralph Swick +* Technical Staff, X Window System: + * Donna Converse, emeritus + * Stephen Gildea, emeritus + * Kaleb Keithley + * Arnaud Le Hors + * Ralph Mor, emeritus + * Ray Tice + * Dave Wiggins, emeritus +* Managers, CDE Development: + * Giora Guth + * Peter Bohnert, emeritus +* Manager, CDE Quality Engineering: + * David Brooks +* CDE Architects: + * Kevin Samborn + * Daniel Dardailler, emeritus +* Technical Staff, CDE Development: + * Art Barstow + * Pascale Dardailler + * David Kaelbling + * Mitch Greess + * Robert Seacord +* Technical Staff, CDE Quality Engineering: + * Chris Burleson + * Tom Cavin + * Sami Mohammed + * Mark Schuldenfrei +* Manager, Systems Administration: + * Kevin Ethier +* Technical Staff, Systems Administration: + * Mike Donati + * Amy Rich, emeritus + * Anne Salemme + +### Board of Directors + +The X Consortium's activities and affairs were managed under the direction and oversight of a Board of Directors, elected annually by the Members. The Board was responsible for reviewing the achievements of the Consortium, approving planned work, appointing a President and other officers of the Consortium, and setting membership dues. The last Directors were: + +* Robert W. Scheifler, President, X Consortium +* Dr. Forest Baskett, Senior VP of R&D, Silicon Graphics Computer Systems +* Harold D. Blair, Apogee International Corp. +* Roger S. Gourd, Gourd & Associates +* Dr. Robin Hillyard, Chairman and Chief Technical Officer, Novasoft Systems +* Don McGovern, General Operations Manager and Executive Dir., Hewlett Packard +* Peter J. Shaw, Senior VP, NetManage +* Michael Tobias, President, Tech-Source, Inc. + +### Full Members + +* Adobe Systems Inc. +* Cray Research, Inc. +* Digital Equipment Corp. +* Fujitsu Limited +* Hewlett-Packard Company +* Hitachi Ltd. +* IBM Corporation +* Megatek Corp. +* Motorola, Inc. +* NEC Corporation +* Novell, Inc. +* Oki Electric Industry Co., Ltd. +* OMRON Corporation +* SCO, Inc. +* Siemens Nixdorf Informationssysteme AG +* Silicon Graphics, Inc. +* Sony Corporation +* Sun Microsystems, Inc. +* Tektronix, Inc. + +### Associate Members + +* Boundless Technologies +* Hummingbird Communications Ltd. +* Insignia Solutions, Ltd. +* Mercury Interactive Corp. +* NetManage, Inc. +* Network Computing Devices +* VisiCom Laboratories, Inc. +* Walker Richer & Quinn, Inc. + +### End Users + +* Hughes Aircraft Company + +### Affiliate Members + +* ASTEC, Inc. +* BARCO Chromatics, Inc. +* CenterLine Software, Inc. +* CliniComp, Intl. +* Component Integration Laboratories, Inc. +* Draper Laboratory. +* Electronic Book Technologies, Inc. +* Gallium Software, Inc. +* Georgia Institiute of Technology +* Human Designed Systems, Inc. +* INRIA - Institut National de Recherche en Informatique et en Automatique +* Integrated Computer Solutions, Inc. +* Investment Management Services, Inc. +* Jupiter Systems +* KL Group Inc. +* Massachusetts Institute of Technology +* Metheus Corporation +* Metro Link, Inc. +* Object Management Group, Inc. +* Open Software Foundation +* Performance Awareness Corp. +* Peritek Corp. +* Petrotechnical Open Software Corp. +* Point Technologies, Inc. +* Shiman Associates, Inc. +* Smithsonian Astrophysical Observatory. +* Software Development Corp. +* SOUM Corporation +* Spectragraphics Corp. +* Tech-Source, Inc. +* TriTeal Corp. +* White Pine Software, Inc. +* World Wide Web Consortium. +* The XFree86 Project, Inc. +* X Inside, Inc.
\ No newline at end of file diff --git a/XDC2007Notes.mdwn b/XDC2007Notes.mdwn new file mode 100644 index 00000000..4af91ef3 --- /dev/null +++ b/XDC2007Notes.mdwn @@ -0,0 +1,300 @@ + +[[!toc ]] + +These are running notes from the X Developer's Conference in San Jose, February 7 through 9, 2007. Please add more content, and reformat to look prettier. + + +## Wednesday, February 7 + + +### (intro speech) + +What are we doing this year? By the end of the week, we should know and communicate this. + + +### Peter Hutterer: MPX + +Slides: [[PDF slides|XDC07_mpx_slides.pdf]] + +Basic problem: Only one focus for keyboard and mouse input + +All the existing multi-user toolkits don't work. You have to write to them, doesn't work for arbitrary apps. So, hey, let's give X multiple pointers! + +Basically all functionality works. Each pointer acts like a core pointer, like an XI pointer, can have different shapes, can be queried, can be warped, each keyboard can have different focus, and pointers and keyboards can be dynamically associated. + +So what changed? + +Event delivery is modified so that every device has its own sprite structure, instead of just one like we have now. Therefore, on event dequeue, we know _which_ device generated the event. + +Cursor rendering goes entirely through software now, since basically no hardware has more than one cursor in hardware. This had to be extended to handle the cases where the backing tiles for each cursor overlap. + +In standard X, you get one shape per window, and shapes can be inherited. In MPX, each device can have one shape per window, and the inheritance works the way you expect. + +[[QueryDevicePointer|QueryDevicePointer]] [[WarpDevicePointer|WarpDevicePointer]] [[DefineDeviceCursor|DefineDeviceCursor]] [[ChangePointerKeyboardPairing|ChangePointerKeyboardPairing]] Device{Enter,Leave}Notify [[PairingChangedNotify|PairingChangedNotify]] + +~30 calls in the core protocol no longer have a defined state. Possible solution: "[[SetPointerBehaviour|SetPointerBehaviour]]" for [[FollowSingle|FollowSingle]], [[DevicePointer|DevicePointer]], etc., which the window manager would enforce for naive apps. Lots of race conditions until this happens when multiple users are interacting with the same window or widget. + +Really need window manager support for this to work. There is a demo wm that works, blackbox kinda works, metacity completely doesn't. + +Also, applications need to become aware of this too. Pointers can pop in and out of existance now. + +Things to think of: + +* Floor control +* Relative device events +* Multi-user cut-and-paste +* Mouse cursor restacking +* Gesture events +It's not ready yet. + +Questions: + +* Composite and DMX integration? "Not yet, would be cool" +* Use cases? "Lots, needs more research" +* How to handle hotplug? "That's Daniel's problem." + +### (Intermission for lunch orders) + + +### Philip Langdale: Virtual Multihead in VMware + +Host support + +Single head: plain fullscreen + +Multihead: Old school manual window resizing + +Guest support, since this was pre-RANDR 1.2: yet another pseudo-xinerama. Additional call to the vmware extension to send a new xinerama config. + +Needs RANDR 1.2 integration. EWMH needs extending to cover maximization across multiple screens. + +(shiny demo) + + +### (another intermission) + + +### Keith Packard: RANDR 1.2 + +Things we had tried before: Xinerama, xf86vidmode, RandR Classic + +Core X does not support multiple screens well. Number of screens is fixed, size of each screen is fixed, monitors probed at startup. This info is passed over to Xlib at app startup, and is really hard to fix. The server also makes this fragile internally, but that's fixable. But many resources are per-screen, so it just doesn't work the way you want. + +Xinerama. Merges many monitors into one screen. Allows apps to move across screens, which is cool! Screen config was fixed at startup, so suitable for fixed multi-head environment. (Initial implementation also happened to be wildly inefficient.) + +Changing modes was xf86vidmode. Changes monitor mode on the fly, but not the screen size. Whee, pan and scan. Also exposes gamma correction. But screen size is still fixed at startup, and set of modes fixed at startup. + +Changing screen size was RandR. Runtime changes to screen size, but still fixed set of sizes and monitor modes, and mode expressed as size and refresh only. + +Randr 1.0 done for kdrive for rotation. When added to xfree86, was done without changing drivers, so no mode reprobing, no rotation... + +RandR 1.2 fully expresses hardware capabilities. All configuration can be changed. Unified config file structure, reduced driver-specific code, unifies the semantics of the above extensions. + +The three objects: Screen, CRTC, Output. (Pretty picture). One screen, N CRTCs, connected to M outputs. (Shiny demo) + +What else can it do? LUT for gamma adjustment. Arbitrary output properties. User defined modes. New driver-independent API. + +Minor driver problems. XAA is kind of gross, DRI is fixed. + +Protocol is finished, DIX implementation is finished, intel driver working, radeon and nouveau nearly working, gtk-based UI demo. Need to fix remaining drivers and finish rotation/reflection work. + + +### ajax: Xorg releases and future planning + +The current release is almost done, and is blocked on the documentation release. That's mostly a build system issue, and we should work on making the docs build something that is less of a disaster for future releases. + +However, the release process is far too heavyweight, and we have pieces of our process which are not adding value and burning out release managers. Prevailing opinion has been that this is probably a job for more than one person, but we might be able to get it down to something manageable by a single person sustainably. We've also been doing a better job of documenting our processes ([[MakingReleases|MakingReleases]]), so that the release process is transferable between people. + +Currently, the release manager is rolling releases for everything that has been touched but not released as part of releasing the katamari. This was not the initial plan for modularization, which involved getting individual maintainers per module. There are several solutions to this burden on the release wrangler + +* ajax: remove more modules from the katamari. We have a lot of dead weight that shouldn't be bothered with any more. +* get more individual maintainers to take care of modules +* remove the burden of doing new releases not critical to the katamari from the release manager's responsibility. +If we remove the responsibility of catching minor changes to unloved modules for release, then we should automate reminder messages to get those released after they've been sitting stable for some amount of time. + +The badged tarball idea needs to be abandoned. The badged tarballs don't match the unbadged versions, and don't even distcheck. Instead, our only badging process that's recorded outside of the release announcement would be a git tag for the katamari in each module (which is somewhat failure-prone, but can be remedied if mistakes are found). + +As far as abandoning modules, abandoning apps katamari entirely was discussed but thrown out. + +The X Server release should be decoupled from the katamari release. So the upcoming server release planned (~2 week timeframe) will be 1.3 instead of 1.2.1. + +We should do a better job of maintaining stable branches. This is the responsibility of OSVs and others maintaining stable releases. However, if we accomplish our goal of faster releases, it may be less interesting. + +The planned features for 1.3: + +* exa updates from master +* damage protocol update (already merged) +* randr 1.2 with xfree86 layer (randr 1.2 base already merged) +The planned features for 7.3 katamari (1.4+ xserver, ~May 2007) + +* XACE merged (almost done) +* Apple's OSX support (pended for 7.2 release to not disturb it) +* lobotomized generic DGA (will be done, straightforward) +* input hotplug (ready) +* GPU -> CRTC mapping property for randr. +* input transformation +* active module deprecation +* PCI rework +Desired goals for 7.4 katamari (1.5+ xserver, ~Nov 2007) + +* XAA death (large change, but mostly mechanical) +* DRI memory manager +* kernel modesetting support +* GLX 1.3 +* GL acceleration architecture +* MPX +* XCB server-side +* ABI rework +* FB rework +* DMX/Xinerama integration +ABI/API compatibility was discussed. One proposal was the kernel model, of just releasing the server when server people want to, and if that breaks things then people get to recover. keithp's proposal is maintaining API compatibility between last stable releases and master, but not ABI. This is being experimented with in the intel driver, and appears to be promising, allow more change, but still maintain what OSVs really want (recompiling lets you take new driver and run on old X Server, or take new X Server and run with old driver code) + +Eric Anholt is signed up for the 7.3 release management. Badged tarballs will not be done. Rolling releases for minor fixes will be up to people interested in seeing those fixes go out -- only the X Server and other criticial releases will be rolled by Eric. + + +### (keith doing nerdcore about randr1.2 api) + + +## Thursday, February 8 + + +### Board Q/A session + +Observations: lack of structured talk scheduling doesn't seem to reduce the amount of quality technical discussion. Flipside is that the small sessions need to be responsible for reporting their results. + +Do we need to go as far as professional facilitators? Maybe not. But hey, look, office supplies! (Pass stuff out.) Let's try to write stuff down. + +Do we want to try changing the format to a hothouse / retreat? Yeah, maybe. One thing lacking this year was that, last year, almost everyone was at the same hotel, which encouraged after-hours discussion and work. Suggestion for next year is to either reserve hotel earlier so we can get block allocation, or try the retreat format. + +It's been suggested that the board should facilitate small group meetings. So, yeah, if you have a proposal for this kind of thing, please send it to the board so they can get that started. All reasonable proposals will be entertained. Local groups, small interest stuff, etc. + +Question from a non-member: I'm not one, should I be? It lets you vote on the board, host events, represent the organization at conferences and trade shows, etc. It's free, there's really no downside, and it announces your participation in the X development community. Do it! + +Suggestion: Is it possible to do something like Summer of Code directly from X? Sure. Board hasn't finalized anything yet, but could be doable. The important thing about SoC is that it's not about producing code, it's about teaching students. + + +### Joe Miseli: Display technology, VESA, and EDID + +[[PDF slides|Xorg_2007-EDID-JMiseli.pdf]] + +EDID is the mechanism by which monitors describe themselves. It's now technically called E-EDID since it's been extended, but it's still the same thing. EDID is now at version 1.4. + +Review of various display technologies in use today: CRT, LCD, plasma, projector, etc. Most fixed-pixel array displays have scalers. Newer and higher resolution displays have no pure scalers, so EDID becomes critical for driving them correctly. + +Review of display interfaces: VGA, DVI-{D,I}, HDMI, [[DisplayPort|DisplayPort]], UDI... + +A display may have many timings, CRTs for example are basically infinitely adaptable within their sync range. Some may have a few timings, or even only one. All cases are handled by EDID. The purpose of EDID is to make sure that _something_ comes up at power on. + +Signalling: Video content, blanking, sync, I2C digital signals for communication. Connector may carry other pins too (USB, audio, etc). (Timing math.) Timing specs include DMT, GTF, CVT. DMT was pages of explicit timings, GTF and CVT are formulas. + +Sync. Three main times: separate, where H and V can be positive or negative on independent pins; composite, where they're combined into one phase- coherent signal (unsupported but sometimes works for DVI); and sync-on-green, which is a DC-bias added to the green signal. + +Version table: 1.1 in 1996, 1.2 in 1997, 1.3 in 2000, 1.4 in 2006. 1.3 was the first that could handle extension blocks. + +Timing priority order: Preferred timing, other detailed timings in the base block, other detailed timings in the VTB-EXT, 3-byte CVT codes in base or extended blocks, standard timings, established timings, base video mode. + +Related vesa standards: CVT, DMT, DPM, DDC/CI, DPVL, MCCS, MDDI. DDC is the carrier channel for EDID. Coordinated Video Timings and Detailed Monitor Timings are various timing specs. DPM (successor to DPMS) is for Display Power Management. Basically, missing pulses on either or both sync pins plus inactive video means low power mode. DPMS was more complicated where there were standby and suspend modes between On and Off, depending on sync pin wiggling. + +Extensions: CEA, VTB, DI, LS, DPVL. (consumer electronics conformance, video timing block, display information, localised strings, and digital packet video link.) CEA is the DTV profile for uncompressed high speed digital video. DDC/CI allows for control of displays, basically anything you could do from the front panel and more. MCCS is the standard command set for DDC/CI. DPVL allows for only updating the regions of the screen that have changed. + +Lots of changes in EDID 1.4. (Will acquire slides for the list.) + + +### Eamon Walsh: Security in X + +(See [[SecurityTalkAgenda|SecurityTalkAgenda]]) + +"The trick is to have a consistent set of lies." + + +### Bart Massey: Cut and Paste + +Something about elephants. + +Cut and paste suffers from weak guidelines, data type hell, and indifference. The problems really exist, are easy to find and demo. Need to figure out requirements, then the fixes, draft the spec, write the library to make it work, and fix the visible important apps. + +Amusingly enough, DND works more reliably than copy and paste. The problem space here is cut/copy/paste versus select/insert. Should work for text, pictures, and "other". + +How it works: highlighting a region makes it the PRIMARY selection. You can either middle-click to paste the PRIMARY, or hit ^C to copy it to the CLIPBOARD. ^V pastes from CLIPBOARD. That would be a nice theory, but it's not consistently implemented. + +Non-text selection is also completely broken. + +Anyway it's all busted and it needs to be fixed. Will be starting the CCP Strike Force to make this work. Join! Do stuff! + + +## Friday, February 9 + + +### David Reveman: Compiz + +What is compiz? Compositing window manager with flexible plugin architecture. + +Latest additions include multihead support and pluggable fragment shading. (shiny demo of stacked fragment plugins) + +Wants to switch to software cursors. Doing this properly requires modifying the Fixes extension's reporting of cursor changes to include the sprite dimensions and hotspot. + +Also wants to change the Xv interface to allow the compositing manager to do the colorspace conversion and scaling, which would be slightly more efficient in terms of copies, gets frame sync (potentially) right, etc. + +Drawing synchronization. Could be done entirely client-side, but could also have server-support. Most of the server support options are fairly brutal; needs more thought. Do client side first. + +Input transformation. Need it so you can interact (correctly) with transformed windows. Match the triangle primitives of the windows to an input mesh, and do the straightforward pick. Implementation is started, where Composite clients provide pairs of triangles that specify the mapping lfrom the composite window to the redirected subwindow. Minimal DIX changes to XYToWindow, [[WriteEventsToClient|WriteEventsToClient]], and [[TranslateCoords|TranslateCoords]]. + +Retained drawing interface. Currently have interfaces for decorations, video, thumbnails, blur-behind-window, etc. Want one common interface instead, with tree hierarchy of inheritance, extensible by current plugin architecture. + + +### Quinn Storm: Beryl + +Beryl is another GL-based compositing manager. Started as a fork of compiz, has many more visual effects, bit more experimental of a plugin interface, etc. + +(mostly demo) + + +### Brian Paul: Mesa + +Memory management update. Initial development done for unified memory architectures like i915, currently working on VRAM architectures. Accelerated readback for glReadPixels and glCopyPixels not quite sorted, but soon. Also working on sub-allocator for more efficient management. White paper coming soon! + +VBO changes. Will enable storing vertex data in GPU memory, avoids per-draw host-to-GPU memory transfer. All vertex-related drawing code done in one place now; glBegin/glEnd converted into VBOs, as are display lists. Simplifies life for driver writers too, including helper code for buffers larger than the hardware can handle. Todo: implement compiled vertex arrays in the same way, update the DRI drivers to use the new path. + +OpenGL shading language. Mesa has kind of had this support for a while, but had no hardware support, very slow, etc. Previously had support for the ATI and nVidia extensions, but GLSL wasn't integrated with this. Shaders are clearly the way forward, so we need to get Mesa fixed to handle this. + +(example shader program walkthrough.) + +(shader compiler diagram. ATI_fp and friends had one front-end, one middle-end for representation, and N backends for execution. GLSL had own front-end, but different middle- and backends. New model unifies this, and adds a stage for optimization and hinting. + +Kept the GLSL tokenizer/parser, but replaced the rest. Pretty much a straightforward compiler design. Need to extend the IR to handle new instructions (jump, branch) and addressing modes. Other changes needed to handle the different between ARB shader extensions and the GL 2.0 version. + +GL 2.0 API interface is complete, supports most of the language except: arrays, structs, multishader linking, and integer ops. Need to implement indirect addressing for arrays. Register allocation is fair but not great. No subroutining, everything is inlined. No hardware backends updated for this yet, but not a huge job to add. Backends need to be extneded to say what instructions are supported. Error detection is kinda poor. Possible extras: profiler, histogram, debugger, peephole optimizations, etc. + + +### Andy Ritger: Multi-GPU X Screens + +Why would you want to use multiple GPUs? Solve larger problems, throw more power at large problems. SLI is one technique for splitting the scene among multiple GPUs. Xinerama is another technique for big desktop. The two are not mutually exclusive. + +SLI allows multiple GPUs to render one X screen. Multiple modes: alternate frame rendering, scan line interleaving, and SLI + antialiasing. + +Xinerama means two things. One is the protocol, which defines the "screen" layout. The internal implementation is the code that splits the protocol requests among multiple hardware drivers. + +Unofficial terminology: the "physical" X screen is a video memory buffer in a single GPU, the "logical" X screen is the object as visible through the protocol to clients. + +Use cases: Powerwalls. Caves. Large desktop. Multiple logical X screens. + +What do we have today? TwinView/MergedFB, where two display devices are connected to one physical X screen (vram buffer). Multiple X screens per GPU, sort of the classic X "Zaphod" mode; allows you to advertise different capabilities per screen. Xinerama, where you have multiple physical X screens glued together into one logical X screen. RANDR 1.2 operates on a logical X screen, basically allows dynamic reconfig of MergedFB/TwinView. + +What's nice about the existing Xinerama? Transparent to X drivers, and mostly works today. What's bad? Lots of resource duplication, which causes performance issues. What does it mean to redirect windows with multi-GPU X screens? RANDR and Xinerama (implementation) are mutually exclusive. + +Ideas: Post RANDR 1.2, expose physical X screen in the RANDR protocol, which would allow the combination of the two. Apply DMX lessons and work to the Xinerama implementation for optimization. Expose ways for compmgrs to control what GPU receives the allocation for a redirected pixmap. + +Nothing solid yet. Think about how to address these issues. + + +### Bart Massey: XCB mini-status + +It lives! 1.0 released, included in [[X11R7|X11R7]].2. Supports most of the X protocol. Team of about 6 active contributors with occasional casuals. Used for the client-side protocol libraries, but not the server (yet). + +XCB is XML descriptions of the protocol, with XSLT to produce the C "top half". The C bottom-half contains the transport and multiplexing code. Xlib now built on the XCB bottom-half. Conceptualised in ~2000, originally done in m4 instead of XSLT. + +There is minimal magic here, it's just protocol. Latency hiding is free, threading just works, error handling fixed, protocol docs are handy for other tools like wireshark or language bindings. + +Lets you mix and match Xlib and XCB code, which allows the transition. Make the transition short, of course. It's slightly volatile and sometimes awkward to work with, the team bandwidth is slightly low, etc. But it's a good start. Still need client libraries, XSLT cleanups, get XCB into the toolkits, to use it on the server side, and to grow the team. + +Question: can I handle disconnect politely with XCB? Yes, but maybe not if you're using the Xlib frontend. diff --git a/XDC2007Notes/XDC07_mpx_slides.pdf b/XDC2007Notes/XDC07_mpx_slides.pdf Binary files differnew file mode 100644 index 00000000..62b05102 --- /dev/null +++ b/XDC2007Notes/XDC07_mpx_slides.pdf diff --git a/XDC2007Notes/Xorg_2007-EDID-JMiseli.pdf b/XDC2007Notes/Xorg_2007-EDID-JMiseli.pdf Binary files differnew file mode 100644 index 00000000..98907675 --- /dev/null +++ b/XDC2007Notes/Xorg_2007-EDID-JMiseli.pdf diff --git a/XDevConf.mdwn b/XDevConf.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/XDevConf.mdwn diff --git a/XHotplugProposal.mdwn b/XHotplugProposal.mdwn new file mode 100644 index 00000000..588f3e2d --- /dev/null +++ b/XHotplugProposal.mdwn @@ -0,0 +1,82 @@ + + +# X Hotplug Proposal + + +## Table of Contents + +[[!toc ]] + + +## Overview + +This is a proposal for converting the entire X server over to a hotplug-capable configuration mechanism. This effort expects to occur on similiar time scales as the modular code effort and the X on GL effort. The proposal is designed around a non-root X server not being possible in the near future. + + +## Phases + + +### Phase 1: Design + +[[EgbertEich|EgbertEich]] suggested using a different IPC method than the X protocol. This immediately solves the security problems. Possibilities include dbus or another named socket (/tmp/.X11-unix/X0.conf ?). + +The currently evolving plan is to have an external device daemon that informs the server of available devices. This external daemon can help with system level access control and negotiation among multiple servers. This daemon would handle all direct communications to the OS-dependent hotplug system. + +The list of input devices on the server is not simply be a list of all local devices. It should be possible to keep devices 'installed' in the X device list, even if that device gets unplugged. Newly discovered local devices should generally not be automatically installed into the X Device List. One approach is to have a Device Manager, somewhat like the Window Manager, which handles every addition or removal to the X device list. + + +#### Questions + +* Would the named socket cause problems with cygwin? (or other archs?) +* Is dbus an acceptable dependency? +* The configuration client would probably expose itself on dbus if we want DEs to be able to fiddle with policy. (This would be instead of the DEs writing their own configuration client, since with a root X server that's a security problem), so a dbus dependancy wouldn't be necessary in Xorg even if we want to control Xorg from across dbus. + +### Phase 2: XINPUT + +The protocol will expose only the device_presence_notify event. The AddDevice and RemoveDevice commands will be exposed on the new configuration IPC mechanism (chosen above). + +Backwards compatibility with newly broken code can be solved by exposing a single mouse and single keyboard to any client that doesn't request a new enough version of the XINPUT extension. These devices should be horrendously generic and barely reflect the hardware. + +Essentially, if we go the "virtual device" route, only these devices would be exposed to old clients (since they are never added or removed). + + +#### Questions + +* Compatibility will be lost for clients that want to use special features of input devices. (Are there any common cases other than drawing pads under the gimp? What else specifically uses extension devices?) I don't see an alternative: either we break code or we break features. I prefer to broken features to crashing code. (Are the problems with gtk crashing bugs?) +* [[XInputHotplug|XInputHotplug]] suggests remote input devices may be a problem. Is there any reason to natively support these rather than implement them as a driver? +* Should the core pointer and keyboard continue to exist? Should they be converted into "dummy" devices instead and have all new input devices SendCoreEvents by default? ([[XOrgInputDriverSpec|XOrgInputDriverSpec]] suggest the dummy pointer (or virtual pointer) method) +* Should multiple cursor support be native, or should things like the MERL projector table expose numerous devices and have the client monitor each one individually? Perhaps clients could request that multiple, specific devices become pointers (locked into that client's window, so as not to confuse other clients)? + +#### Further work + +There are a number of issues raised on the [[XInputHotplug|XInputHotplug]] page under the "XInput Protocol" and "Other Stuff" sections about driver ugliness and protocol problems. Also [[XOrgInputDriverSpec|XOrgInputDriverSpec]] and [[XInputSpec|XInputSpec]]. These changes to the protocol would probably go in along with the device event, so phase 2 depends on this work as well. + + +### Phase 3: General + +Move all configuration into the configuration client. The parser for /etc/X11/X![[OrgConfig|OrgConfig]] would be moved into its own client and out of the X server. The client can now control everything about the X server, including displays. + + +#### Questions + +* Presumably, opening sockets for regular clients to connect would be a command issued by the configuration client. Should we just error if the command is issued before the X server has a full configuration, or should we begin supporting a partial configuration? +* Are all the event notifications we need in order to support display-hotplug present? Would adding another head be any different than a "mode change" from 800x600 to 1600x600 to the client? Would any client even care if we suddenly start rendering to a projector as well as an lcd? (other than the configuration client) + +### Phase 4: Completion + +Presumably at the same time XOrg begins using OpenGL, mode changing will be freed up. This responsibility could be moved out of the X server and into the configuration client, and only framebuffer configuration would be sent to the X server. See questions belows. + +At this point, X![[OrgConfig|OrgConfig]] is just another configuration client. Any internal assumptions about configuration format can be changed without external compatibility problems (just change the client to send information in the new format). (except for binary drivers? If X on GL happens, would nvidia or ati even have a binary driver for xorg anymore?) + +After this phase, external configuration clients could be encouraged. Prior to this, maintaining backwards compatibility for external clients would mean we wouldn't gain anything by making the client do something because the server would still have to be able to do it, just in case. Therefore, we don't care about compatibility until this point. + + +#### Questions + +* The mode selection part is debatable. I think it would be better for it to seem to the configuration client that the X server still does mode selection, even if that is moved into a shared library outside of the X server (mesa?). -- [[TedKaminski|TedKaminski]] - 22 Jan 2005 + +## See Also + +* [[XInputHotplug|XInputHotplug]] +* [[XOrgInputDriverSpec|XOrgInputDriverSpec]] +* [[XInputSpec|XInputSpec]]
\ No newline at end of file diff --git a/XInputHotplug.mdwn b/XInputHotplug.mdwn new file mode 100644 index 00000000..060d303a --- /dev/null +++ b/XInputHotplug.mdwn @@ -0,0 +1,94 @@ + + +# XInput Hotplug +[[!table header="no" class="mointable" data=""" + /!\ The following description is quite out of date and left for historical reference only - the DBus API described below was later rev'ed to version 2, then deprecated in favor of [[HAL|XorgHAL]], which itself was deprecated in favor of udev on Linux. +"""]] + + +## Table of Contents + +[[!toc ]] + + +## Overview + +The X.org server supports hotplugging input devices since November 2006 [[http://lists.freedesktop.org/archives/xorg/2006-October/019007.html|http://lists.freedesktop.org/archives/xorg/2006-October/019007.html]] ([[X11R7|X11R7]].2 will NOT have hotplug support yet). + + +## Design + +The X.server uses DBus to get information about devices that are to be added or removed. From [[http://cgit.freedesktop.org/xorg/xserver/commit/config/dbus-api?id=ec35e7198debf938f1115f584e675ce5995743e3|http://cgit.freedesktop.org/xorg/xserver/commit/config/dbus-api?id=ec35e7198debf938f1115f584e675ce5995743e3]] + + +[[!format txt """ +D-BUS Configuration API v0.1 +---------------------------- + +The X server will register the bus name org.x.config.displayN, and the +object /org/x/config/N, where N is the display number. + + +Currently only hotplugging of input devices is supported. + +org.x.config.input: + org.x.config.input.add: + Takes an argument of key/value option pairs in arrays, e.g.: + [ss][ss][ss][ss] + is the signature for four options. These options will be passed + to the input driver as with any others. + Option names beginning with _ are not allowed; they are reserved + for internal use. + + Returns one int32, which is an X Status, as defined in X.h. If + everything is successful, Success will be returned. BadMatch will + be returned if the options given do not match any device. BadValue + is returned for a malformed message. + + Notably, BadAlloc is never returned: the server internally signals + to D-BUS that the attempt failed for lack of memory. + + The return does not notify the client of which devices were created + or modified as a result of this request: clients are encouraged to + listen for the XInput DevicePresenceNotify event to monitor changes + in the device list. + + org.x.config.input.remove: + Takes one int32 argument, which is the device ID to remove, i.e.: + i + is the signature. + Same return values as org.x.config.input.add. + +"""]] +The main idea behind keeping the discovery mechanism out of the server was that different systems can use different mechanisms. On GNOME or KDE desktops it would make good sense to use [[HAL|http://freedesktop.org/wiki/Software/hal]] for detection (which is a cross-platform device detection and enummeration system), but an embedded system may well want to use something more lean. + +Also, by moving the mechanism to an X client daemon, you can implement desktop specific policy in the daemon. For example, in the GNOME environment you could have a daemon that reads per user settings for input devices from GConf. + + +## XInput Protocol + +A event was added _devicePresenceNotify_ to notify a client about new devices. XI has been bumped to version 1.5 + + +## Code + + * Simple, experimental device manager in C: git://anongit.freedesktop.org/users/daniels/respeclaration + +## Other Stuff + + * The design of XOrg XINPUT drivers is undocumented, and inconsistent. The main driver Control() functions are not being used correctly, with PreInit() doing much of the work for DEVICE_INIT and DEVICE_ON. + * Main.[[JoeKrahn|JoeKrahn]] suggests: combining the various other driver export functions into additional deviceControl() operations to create as a single driver access point, rather than Probe(), PreInit(). This function could also be used to replace the numerous standard driver-name symbols like _DriverName_Options. This would require a change to the module ABI, but would be, IMHO, much simpler and cleaner, and allow for things like returning an altered option list, based on the hardware. + +## Issues + + * Security: allowing any client to ask the server to open a file as an input device is problematic. E.g. adding a mouse and specifying /etc/passwd as the device file. + * Backwards compatibility: GTK+ doesn't handle disappearing XInput devices well. One option is to keep a shadow list that doesn't change, and export that to clients that haven't asked for a recent enough version of XInput. + * Remote devices: how well does this integrate with remote input devices? + * DBus' behaviour to abort the process (using assert()) if an error in the library occurs. This behaviour was considered inappropriate by Daniel Stone, with announcements that it may cause DBus to be removed again [[http://lists.freedesktop.org/archives/dbus/2006-November/006390.html|http://lists.freedesktop.org/archives/dbus/2006-November/006390.html]]. + +# See Also + + * [[XInputSpec|XInputSpec]] - Related updates for the XInput extension. + * [[XOrgInputDriverSpec|XOrgInputDriverSpec]] - Input Driver module design. + * [[XHotplugProposal|XHotplugProposal]] - Initial proposal for the hotplug design. +-- Created by Main.[[KristianHogsberg|KristianHogsberg]] - 02 Jul 2004 diff --git a/XInputSpec.mdwn b/XInputSpec.mdwn new file mode 100644 index 00000000..bbb94c38 --- /dev/null +++ b/XInputSpec.mdwn @@ -0,0 +1,196 @@ + + +# XInput Extension Specifications (Developmental Proposal) + +**This page is out of date and its content is provided for historic reasons only. Some of the features below is superfluous, others have been implemented already. This is not a guide to the future of input development.** + + +## Table of Contents + +[[!toc ]] + + +## Overview + +This page is intended as a place to evolve the design specifications for the next version of the XINPUT for the X.org server. This includes a long needed update to the XINPUT specification to improve support for better device controls, hotplugging, and multiple core devices. This page focuses on the XInput protocol. The implementation in the XOrg server should be documented in [[XOrgInputDriverSpec|XOrgInputDriverSpec]]. + + +## Introduction + +First, an important question: Should the XInput improvements all be part of XInput 2.0? XInput includes several commands that resemble a general purpose interface to extension events. Furthermore, many of the needed improvements for managing and configuring input devices are applicable to output devices, including something as substantial as a hot-pluggable PCMCIA video card. + +So, in addition to the much-needed update to the XInput protocol, should there also be another extension called (perhaps) XDevice, that defines all of the runtime device configuration and management issues that are not part of the existing XInput? + +Or, should we just extend XInput, and not worry that it is really applicable to more than just input devices, despite the name? This is already true for XInput because Feedback events are a form of output. (In a way, a graphical display is just a very elaborate central Feedback device.) Besides, HID is similarly misnamed. + + +## HID Protocol Features + +The HID design is a verbose and inflexible, rather than a simple but extensible design. This does not really fit the overall X design concept very well, so it does not make sense to incorporate the actual HID spec into X. However, most modern input devices are designed around HID, so XInput should attempt to be HID compatible. In otherwords, XInput should be able to include device and control attributes that correspond to HID names, but these should all conveyed by name rather than using all of the HID enum values. + +One useful aspect of HID is Device and Control Usages. XInput has some support for Device Usage by including a type Atom in the X![[DeviceInfo|DeviceInfo]] structure, although it has not been adequately implemented. It is reasonable to define the standard type Atoms with the corresponding HID Usage names, which already include several common type names typically used in X, such as Pointer, Keyboard, Joystick. + +Individual controls do not have a similar type identifier, but one should be incorporated into the various control Info structures. Each info structure includes a length value. That means it is possible to extend these structures and keep backwards compatibility. The extended structures should also include additional details about each control. For example, buttons can be described as momentary or toggle switches. + +Rather than trying to define a few additional specific properties, it is probably best to support a variable number of parameter+value pairs for each device and each control. This allows for extensibility, and can work similar to Window properties. + + +## Security Considerations + +Device event handling has important security implications. Currently, security is handled with global Display access, and temporary Device Grabs. With the possibility of multiple input devices, multiple servers, and even [[multiple users on the same Display|http://www.freedesktop.org/wiki/MultiplePointers]], event access control needs to be more explicit. So, devices need security attributes, which probably need to be implemented in a similar way for explicit access to/from individual windows. + + +## Proposed Additional XInput Functions + + +### X[Get|Change|Delete]DeviceProperty(), X[List|Rotate]DeviceProperties() + +A straightforward method of implementing extensible and diverse device properties is to provide each device with a set of properties that is accessible in a manner similar to Window properties. This allows for a variety of data formats and sizes, and would use the existing Window Property infrastructure. Device Properties can relay all of the information about input usages, advanced pointer-acceleration curves, etc. + + +### XChangeDeviceControl(), XGetDeviceControl() + +This function is important, but drastically incomplete. The Device Property interface could probably work as a complete replacement for these functions, but it is useful to have separate interface for active commands that affect the hardware. However, note that the single defined device control, DEVICE_RESOLUTION, is more of a property than a hardware command. + +Rather than adding a new data structure for each new control type, it is better to use an approach similar to window properties, except that control data is interpreted rather than simply being saved in a database. + +Some undecided issues: + +1. Should XDeviceControl() simply be left as a 'legacy' function and use general Device Properties instead? If so, is it reasonable to have a property be acted on as an active command by a device (i.e. set property DEVICE_COMMAND = "reset")? +1. Is it useful to implement new, specific data structures for some common device controls, as intended in the original XInput design, or should all new controls be implemented using the generic mechanism? +1. Should the generic control value also support 16-bit and 32-bit data? Window Properties and Client Messages both support multiple data sizes, but it may be an unnecessary complication. Are there any good examples control parameters that would benefit from 16 or 32 bit data? Data for a force-feedback would be an example, except that it is better implemented as a Feedback, not a Control. +1. How will the control be implemented? One possibility is to send the control data as a new Device Control in the existing X![[ChangeDeviceControl|ChangeDeviceControl]](). Another possibility is to implement a new function that is designed around generic character data values. +This approach is completely compatible with the existing XInput protocol, but is not really using the control type argument as originally intended, and adds unnecessary complexity. + + +### X[Add|Remove][Keyboard|Pointer]Device() + +There should be a formal mechanism for multiple Pointer and Keyboard devices capable of sending core events. Question: how will these functions interoperate with X![[ChangePointerDevice|ChangePointerDevice]] and X![[ChangeKeyboardDevice|ChangeKeyboardDevice]]? Should X retain the concept of a single "primary" mouse and keyboard, and have the new functions enable/disable devices to emit core events in addition to the core devices? Or, should the old functions be considered obsolete and just have them always return BadDevice? Any other ideas? + + +### XSetDeviceMode() and Motion Event Types + +This function assumes that devices can only emit relative or absolute events for all clients listening to the device. This probably should not be true for any device. Therefore, it may be reasonable to always return BadMode, which is the proper response for devices not supporting X![[SetDeviceMode|SetDeviceMode]] requests. + +The problem is that no other mechanism is defined to select relative versus absolute events. Therefore, it would probably be necessary to add RelativeMotionNotify and AbsoluteMotionNotify event types. It may also be acceptable to use the existing MotionNotify to handle Absolute events, which are more common. On the other hand, a new Absolute event type would also add an opportunity to support fractional motion events. + +Absolute events should also be better defined. Most drivers are pointer oriented, and consider absolute motion events to mean screen coordinates, rather than device coordinates. Perhaps Absolute events should always be in device coordinates, and only be converted to screen coordinates for core pointer events. Note that MotionEvents also send x_root and y_root, so clients will always get pointer coordinates. + +There are also some problems with the definition of Absolute versus Relative events. Many input devices send control data that is intended to be used for relative motion, even though the device state is actually an absolute position. For example, a centering joystick is intended to direct relative motion, but a non-centering joystick is accurately represented by an absolute position. Consider how you would would want to use these two joystick types to direct pointer motion. Although the control state is absolute in both cases, the data for the centering joystick should (arguably) be defined as Relative data, partly because the derivative is fairly useless but integrating from Relative to Absolute could be useful. + + +### XListInputDrivers() + +A device driver can be automatically associated with a device, depending on the device type, or otherwise controlled at the OS level. However, it may be useful to allow some client control, especially if more than one driver can handle the same device. + +Get a list of available device drivers; information format not yet defined. It is probably useful to include information about supported hardware, but that can be quite complex. Perhaps just a list of driver names and versions is sufficient. + + +### XAddInputDriver(), XRemoveInputDriver() + +Just an idea for now: Should it be possible to add/remove drivers in a running server? If so, should it be managed by a formal X event, or should this be managed simply by adding or removing driver binaries from the module directory? + + +### XAddInputDevice(), XRemoveInputDevice() + +These functions add or remove a device instance from the server. These are similar to the internal dix functions AddInputDevice() and RemoveDevice(). + +In the current server design, a newly added device but uninitialized device is in the **`off_devices`** list, and not available in X![[ListInputDevices|ListInputDevices]](). Before the device is initialized and made available to clients, it needs to be configured, presumably by the client that sent the request to add the device. Here are possibilities for handling the initial configuration. + +1. X![[AddInputDevice|AddInputDevice]]() can include as an argument a complete array of configuration directives. +1. The initial state of the new device can be as Grabbed by the requesting client, which can release the Grab when it decides the device is ready for use. +The **`off_devices`** list may be considered an obsolete feature when proper hotplugging is implemented. However, there are a few cases where it may still be useful. First, if a device fails initialization, it remains in the **`off_devices`** list. The list could be used to give devices another opportunity to attempt initialization. Secondly, if a device is opened by a client, but the hardware becomes unavailable, it may be useful to keep the **`off_devices`** instance around until all clients have closed the device. + +How does one get a list of the "off devices"? X![[ListInputDevices|ListInputDevices]]() has no option flags, so the current design would best handle this by listing all devices, and defining an DeviceInfo.use=IsOffline type. + + +### XEnableDevice(), XDisableDevice() + +These functions move a device from/to the off_devices list, and succeed depending on the result from the drivers response to DEVICE_INIT and DEVICE_CLOSE. + + +## Proposed Additional XInput Data Structures + + +### Issues with Extended XEvents and Other Data Structures + +The XEvent structure was designed with a fixed size to simplify memory management. Events are passed to the client by passing an entire XEvent structure, rather than passing an event pointer. This limits possibilities for defining Event types with larger data sizes. + +One approach for handling large event types would be to include a data pointer in the XEvent structure. The extended data can be automatically freed by Xlib upon the next event retrieval. + +The [[ClassInfo|ClassInfo]] structures include a length element, which means that extending existing structures can be backwards compatible. The XDeviceInfo structure does not have a length field, so changes will be incompatible. However, a much more versatile approach to extended device properties is to support property attributes similar to window properties, and to leave much of the current data structures unchanged. + + +### XDeviceListChangeEvent + +A new event is added to XInput to notify clients that the device list has changed. + +The event structure could be similar to X![[ChangeDeviceNotifyEvent|ChangeDeviceNotifyEvent]], where the XID is identifies the lost or gained device. This would require an event for each lost or gained device, but could be useful for clients that only want to monitor the status of one device. + + +[[!format txt """ +typedef struct { + int type; + unsigned long serial; + Bool send_event; + Display *display; + Window window; /* Root Window, or unused ? */ + XID deviceid; /* ID of new or lost device */ + Time time; + int state; /* DeviceNew, DeviceLost. Maybe also: DeviceEnabled, DeviceDisabled? */ + } XDeviceListChangeEvent; +"""]] + +### XDeviceConfigureControl + +One possible solution for generalizing Device Controls. This uses existing XInput functions, with a generic, extensible control type: + + +[[!format txt """ +typedef struct { + XID control = DEVICE_CONFIGURE; + int length = sizeof(XDeviceConfigureControl); + Atom name; + int format; + unsigned char *value; + int length; +} XDeviceConfigureControl; +"""]] + +## Input Device Properties + + * This is a listing of generalized device properties to consider. These would be available via a DeviceControl function that returns a string given a parameter named by a string or associated Atom. === Device Description === + * UUID -- Unique ID for this device, which is valid outside of the current server context. What makes it unique is not defined here. It would be easy if all devices had a serial number. + * HardwareID -- Identifies the hardware connection (i.e. HAL/devfs name, network address:port, etc.) + * SerialNumber -- embedded device serial number, when available + * Name -- Some sort of short 'friendly' name unique on the server (Mouse0, Keyboard0) + * Description -- A verbose device description + * VendorName -- Vendor name + * ProductName -- Product name + * ProductRevision -- Product version + * UserName -- Identify who is using the device, if it is Grabbed. +It may be good to always include numeric product and vendor ID's, to avoid ambiguities for cases where names are unknown, or have changed. Should these be a separate field, or grouped with the text name? In addition to user name, devices should probably include support for security (authentication, access-control) features. + + * === Device Event Properties === + * Valuator properties (partly based on HID): + * Relative / Absolute + * Preferred State (Auto-Center valuators and Momentary buttons) + * Wrap (or Periodic) + * Volatile (Value is settable) + * Units + * Minimum Value + * Maximum Value + * Granularity (Precision) + * Null Position (says if an input can have an "invalid" state) -- This property was invented to handle Hat switches, which can be idle, or pointing a direction. It is probably best to represent these as an X,Y valuator pair, or as a directional valuator and a 'valid' or 'active' button. === Other HID Properties === The following HID properties are not so useful for XClients, but might be needed for devices calibration, which should probably be handled by the X Client Input Device Manager: + * Logical (raw input) range + * Current Physical (event data) range + * Default Physical range + * Saturation (assuming the actual max-val may not be exact) === Linearity Properties === Non-linear input should probably be converted to linear at the server level. Acceleration is probably best handled by the server, with all devices set for linear output, in order to provide uniform acceleration parameters for all devices. (Q: Are there cases where acceleration at the device level is really an advantage?) + * Linear + * Unit Exponent + * Acceleration parameters, or point data for general line/curve + * Null radius +* = See Also = +* [[XInputHotplug|XInputHotplug]] +* [[XOrgInputDriverSpec|XOrgInputDriverSpec]] +* [[XHotplugProposal|XHotplugProposal]]
\ No newline at end of file diff --git a/XKB.mdwn b/XKB.mdwn new file mode 100644 index 00000000..353526f3 --- /dev/null +++ b/XKB.mdwn @@ -0,0 +1,25 @@ + + +## XKB - X Keyboard Extension + +The XKB data files for the various keyboard models, layouts, and locales are now maintained by [[the X Keyboard Config project on freedesktop.org|http://www.freedesktop.org/wiki/Software/XKeyboardConfig]] + +some helpful links: + +* [[The XKB Configuration Guide|http://www.x.org/releases/current/doc/xorg-docs/input/XKB-Config.html]] +* [[How to further Enhance XKB Configuration|http://www.x.org/releases/current/doc/xorg-docs/input/XKB-Enhancing.html]] +* en: [[http://pascal.tsu.ru/en/xkb/|http://pascal.tsu.ru/en/xkb/]] +* ru: [[http://pascal.tsu.ru/other/xkb/|http://pascal.tsu.ru/other/xkb/]] +* Patch XKB to support more than 128 keys: [[http://planet.gentoo.org/developers/flameeyes/2005/06/15/and_the_keyboard_lose_the_match|http://planet.gentoo.org/developers/flameeyes/2005/06/15/and_the_keyboard_lose_the_match]] +* [[RMLVO keyboard configuration|http://who-t.blogspot.com/2008/09/rmlvo-keyboard-configuration.html]] (rules, models, layouts, variants and options) +* [[Creating custom keyboard layouts for X11 using XKB|http://hektor.umcs.lublin.pl/~mikosmul/computing/articles/custom-keyboard-layouts-xkb.html]] +* [[An Unreliable Guide to XKB Configuration|http://www.charvolant.org/~doug/xkb/html/index.html]] +* [[XKB Layout Creation Notes|XKBLayoutCreationNotes]] +The original XKB extension protocol and library specs are available in several formats: + +* [[Original XKB specifications in FrameMaker format, as previously found in the xorg-docs module in git|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/specs/XKB?id=XORG-7_0]] +* [[Original XKB specifications from X11R6.4 in PostScript & PDF|http://www.x.org/docs/XKB/]] +* [[XKB libX11 API documentation in HTML, generated from current DocBook sources|http://www.x.org/releases/current/doc/libX11/XKB/xkblib.html]] +* [[XKB protocol specification in HTML, generated from current DocBook sources|http://www.x.org/releases/current/doc/kbproto/xkbproto.html]] +* [[XKB libX11 API documentation in PDF 1.4, generated from current DocBook sources|http://www.x.org/releases/current/doc/libX11/XKB/xkblib.pdf]] +* [[XKB protocol specification in PDF 1.4, generated from current DocBook sources|http://www.x.org/releases/current/doc/kbproto/xkbproto.pdf]]
\ No newline at end of file diff --git a/XKBLayoutCreationNotes.mdwn b/XKBLayoutCreationNotes.mdwn new file mode 100644 index 00000000..7d5d7972 --- /dev/null +++ b/XKBLayoutCreationNotes.mdwn @@ -0,0 +1,29 @@ + + +# Notes for the uninitiated: Creating custom keyboards + + +## Printing geometry + +_xkbprint_ reads **.xkm** files, which are generated by _xkbcomp_. + +_xkbcomp_ reads **.xkb** files, which are located in the keymap directory. An example of printing a geometry is: +[[!format txt """ +cd /usr/share/X11/xkb/keymap +xkbcomp xfree86 -m dvorak +xkbprint dvorak.xkm +"""]] +This creates the files _dvorak.xkm_ and _dvorak.ps_. + +You may get an error such as: +[[!format txt """ +Error: No Symbols named "pc105" in the include file "us" + Exiting + Abandoning symbols file "us" +"""]] +This is because keymaps are an obsolete technique for specifying your keyboard to X. As such they have not been maintained as the other directories have evolved. You will have to either track down how the keymap names have changed in the other directories and update the keymap file (usually easy to do with a quick inspection and grep) or write your own little **.xkb** file (also not too hard to do). + + +## showkey codes are different than xkb keycodes + +_showkey_ is used to display keyboard scancodes on the console, for use when creating keymaps for _loadkeys_. However the scancodes reported by _showkey_ are **different** than the keycodes xkb reads. To inspect the keycodes as seen by xkb for individual keypresses, use _xev_ from inside Xwindows. diff --git a/XOrgInputDriverSpec.mdwn b/XOrgInputDriverSpec.mdwn new file mode 100644 index 00000000..754e7a88 --- /dev/null +++ b/XOrgInputDriverSpec.mdwn @@ -0,0 +1,108 @@ + + +# XOrg Input Driver Specifications (Incomplete Proposal) + + +## Table of Contents + +[[!toc ]] + + +## Introduction + +This page is intended as a place to evolve the design specifications for XInput device drivers in the XOrg server. Most of this document is not based on the existing server code. Instead, this is mostly a proposal of a new and improved design that is more consistent with DIX. Therefore, comments and suggestions from other device driver programmers is important. + +The modular driver design introduced in XFree86 4.0 is documented and designed primarily for video display hardware. It is also used for input devices, but the functions needed for video and input devices are not always equivalent, and the design has been independently mis-translated in many input device drivers. As a result, the driver sources inherited from XFree86 are a very inconsistent. + +One important consideration left out of the XInput driver design (and the video driver design as well) is propoer sharing of devices with other servers or terminals on the same VT console. + +Another feature that has been neglected is the use of the deviceControl() functions intended to be the primary control point for XInput drivers, as documented in the Xi docs and implemented in DIX. It is a well defined, clean design, and should be used. In fact, the same design could be ported to the video drivers as well, to provide a uniform driver design that is (arguably) better than the current design. + + +## Virtual Core Devices + +Many issues arise from core devices being different from extension input devices. An excellent solution, implemented in the IRIX server, is to use virtual core devices. In this design, the core keyboard and mouse are virtual devices, and cannot be changed. + +Virtual core devices are always available, but produce no independent events. All events come from extension devices. This is an excellent fit to a server that supports multiple core devices and device hot-plugging. With the recent integration of MPX, multiple virtual core devices may exist. They are also referred to as master devices. + +The master devices are designed to provide core events in a range that matches the Display resolution. At the same time, they also generate events that are in the device-specific resolution (if applicable). Clients that register for XInput Extension events, will receive events in this native resolution. Clients that open physical devices ("slave devices") directly and register for events do not receive core events. A slave device cannot generate core events. + +The server starts up with two master devices, which are always present. This makes it possible for the external hotplug agent to assign all input devices, and provides a clean method for running a server with no input devices. It also provides a chance to clean up all of the core device code, and convert everything to a standard extension device driver. + +Any slave device may be "attached" to a master device. In this case, when the slave device generates an event, this event is processed both by the slave device and by the respective master device. This device dependency is referred to as Master-Slave Device Hierarchy, and all slave devices attached to a master device control the master's cursor/keyboard focus. If a slave device is not attached to master device, it is referred to as "floating". It cannot generate core events and clients have to explicitly open the device and register for events. This is discouraged except in special circumstances (i.e. mapping the whole device to the canvas in the GIMP). Internally, floating slave devices control their own cursor sprite but this sprite is not rendered to the screen. + + +## HID Protocol Features + +The HID design is a verbose and inflexible, rather than a simple but extensible design. This does not really fit the overall X design concept very well, so it does not make sense to incorporate the actual HID protocol into X. However, it does make sense to use HID within the input drivers. Any HID information sent to the server from drivers should be in the form of Atoms (or strings) rather than HID enums. + +One meaningful use for HID is the Device and Control Usage tables. XInput supports a type Atom for Devices, which should be defined to match HID Usage names where possible. These already match names typically used in X: + +HID Usage tables would also be useful to define a type Atom for each input control of a device, but the XInput spec needs to be updated in order to support Control types. + + +## Device initialization functions + +These come in two different kinds. The functions defined in the driver (the XF86ModuleData and the registered InputDriverRec structures) and the deviceControl(DeviceIntPtr pdev, int action) function. The latter not to be confused with X![[ChangeDeviceControl|ChangeDeviceControl]](), it is referred to as deviceProc() in the XInput documentation and is the primary control point to input devices in the sample server DIX code. + +The core server design has always included a central deviceControl() function for each input device. Aside from the fact that the currently evolved input driver design is completely mangled, Main.[[JoeKrahn|JoeKrahn]] thinks that the originally documented design is better, and in fact could easly be applied to video devices as well. + +Here are the current modular driver functions defined for input drivers: + + +### ModuleSetupProc() + +This is where a driver initializes itself and is part of the module loading process, thus it's per-driver, not per-device. Device instances are initialized later, so this function should never attempt to access any hardware. + +The xf86AddInputDriver() function must be called with the InputDriverRec for the driver as one argument to register the driver and making it available to create instances of. The return value must be non-NULL if the driver should successfully be initialized. + + +### PreInit() + +**Device side:** Allocates all the resources for the device the driver needs. Should not access the hardware yet. Must call xf86AllocateInput() to allocate the device-struct that is returned. This is a good place to check/verify parameters and initialize structures for the device. An option with the key "_source" will be in the provided option list if called as a result of a hot-plug request.** ** + +**Server side:** If function returns a pointer to an InputInfoRec but haven't set XI86_CONFIGURED, UnInit() is called if defined. If not, xf86DeleteInput() is called to make some kind of cleanup. For devices that should be hot pluggable the UnInit() function is required if there shouldn't be any resource leaks. + + +### DEVICE_INIT + +**Device side:** Additional initialization/resource allocation for the device. Should avoid to access the hardware, but if accessing the device is the only way of getting specific device parameters the device can be opened. The appropriate Init*ClassDeviceStruct() functions should be called here to initialize the input device structure. + +**Server side:** If the function return anything but _Success_ the device can not be used. DEVICE_ON will never be called. It will however be listed as an extension device in X, thus making it visible, but not available. + + +### DEVICE_ON + +**Device side:** Opens the underlying device and should restore the device to a known state, based on the config, or from the state saved at the lst DEVICE_OFF. Should call xf86AddEnabledDevice() to add the FD to the ones monitored by the event loop. It is called when adding an input device or switching to the VT. + +** Server side:** Only if the function return _Success_ the server will call DEVICE_OFF at a VT-switch. + + +### DEVICE_OFF + +**Device side:** Called when switching away from the VT. Drivers should save the device state, if applicable, and close the device port. Should call xf86RemoveEnabledDevice() first to stop the event loop from monitoring the FD. + +**Server side:** This function will only be called if the DEVICE_ON returned _Success_. + + +### DEVICE_CLOSE + +**Device side:** Deallocation of the resources allocated in DEVICE_INIT. This is sent when a device instance is to be removed from the server. Before this is called, any long-term storage of device state information, such as touch-screen calibration, should be retrieved by client code (i.e. a HotPlug agent) and not by the device driver. + +**Server side:** Will be called without prior call to DEVICE_OFF when a remove request is received. Not called if DEVICE_INIT returned anything but _Success_. + + +### UnInit() + +**Device side:** Deallocates all recources allocated in PreInit(). xf86DeleteInput() should be called to free the device-struct allocated in PreInit(). + +**Server side:** If the function is not defined, xf86DeleteInput() will be called instead. But that will most likely result in a memory leak as no device-private structures will be deallocated. + + +### ModuleTearDownProc() + +This function is called when the driver is about to be unloaded from memory and should free all resources allocated in ModuleSetupProc(). The argument to this function is the same as returned from ModuleSetupProc(). xf86DeleteInputDriver() must be called to remove the module from the list of available modules. + +-- Main.[[JoeKrahn|JoeKrahn]] - 10 Jul 2004 + +-- Main.[[MagnusVigerlof|MagnusVigerlof]] - 07 May 2007 diff --git a/XServer.mdwn b/XServer.mdwn new file mode 100644 index 00000000..fbbf66fd --- /dev/null +++ b/XServer.mdwn @@ -0,0 +1,154 @@ + + +# X Server Module + +Here's a list of other X server related wiki pages + +* [[XorgModuleABIVersions|XorgModuleABIVersions]] + +## X server branches + +* [[Server12Branch|Server12Branch]] +* [[Server13Branch|Server13Branch]] +* [[Server14Branch|Server14Branch]] +* [[Server15Branch|Server15Branch]] +* [[Server16Branch|Server16Branch]] +* [[Server17Branch|Server17Branch]] +* [[Server18Branch|Server18Branch]] +* [[Server19Branch|Server19Branch]] +* [[Server110Branch|Server110Branch]] +* [[Server113Branch|Server113Branch]] +A guideline for what stable branch maintainers need to do is [[here|Development/Documentation/XServerStableBranchManagement]] + + +## Development Process + +Beginning with [[Server 1.8|Server18Branch]], we have [[changed our development process.|http://lists.freedesktop.org/archives/xorg-devel/2009-September/002330.html]] Below are instructions on how to test and develop on the X server. For stable releases, please refer to the appropriate wiki site (e.g. [[Server113Branch|Server113Branch]]) + +The development process is split into three stages: + +* feature merge window: Starts after the release of the previous version. Features ready will be merged, the server may be unstable during this time. +* bugfix window: No new features may be merged, only bugfixes and stabilization work is permitted. +* release freeze: Only bug fixes to go into the pending release may be merged. +The relevant dates are noted on each server branch page and in the [[X.Org Calendar|http://www.google.com/calendar/embed?src=nl1n1fmvu091eqh35ldqspar80%40group.calendar.google.com&ctz=Australia/Brisbane]]. + + +### General information + +The development process is now more distributed than it used to be in the past. To explain the process, the following terms are important: + +* **remote**: a repository you cloned from. +* **master**: the master branch on git.freedesktop.org. This branch will eventually become the new X server. The master branch is in the hands of the release manager. If you are familiar with the kernel development style, think of master being Linus' tree. +* **personal tree**: a git tree a maintainer has on people.freedesktop.org. These trees are merged into master. A list of these trees are available at [[PersonalTrees|PersonalTrees]]. A personal tree may have multiple branches, only one of which will be merged back to master. See feature branch and devel branch. +* **feature branch**: a branch on a personal tree devoted to a particular new feature. These feature branches are in development until the feature is deemed ready. Once ready, it can be merged into master during the next feature merge window. +* **devel branch**: a branch on a personal tree devoted to live development. +* **rebasing**: rebasing means using git rebase to change the patch order. Rebasing changes the history and should not be used for any published branch. You are only allowed to rebase local patches not yet pushed or patches you applied with git am (e.g. from a mailing list). If you rebase a branch that has been published and possibly already pulled, you destroy all history and screw everyone downstream from you. +* **fast-forward/non-fast-forward**: once you clone a git repository, you have the same history as the remote repository. If the remote gets updated by adding commits and you pull from it, you have a fast-forward change. If the remote however rewrites its history (using git rebase), this is a so-called non-fast-forward change. The history has been rewritten and your local copy does not share the same history anymore. Non-fast-forwards are generally discouraged for any public branch. + +### Users and Testers + +Decide what you want to test. This depends on your personal git and development skills but also in what you expect to get from testing. + +If you just want to test the X server in general, the master branch is probably the best for you. The master branch has many temporary patches already pre-tested and thus provides the most stable solution. Master will always be a bit behind the personal trees. + +If you are interested in testing particular subsystems, find the maintainer of that subsystem by browsing the [[PersonalTrees|PersonalTrees]]. Now you have the choice of testing that tree's master branch (more stable, but not as up-to-date) or one of the tree-specific feature branches. + +Testing feature branches means you're at the forefront of development and you help us most by catching bugs early. You can test new, unreleased features, features that may not appear in a released server for another year or even longer. + +Testing a development branch means you can help out the developer by pointing out broken patches. Development branches require some involvement with the developers (otherwise how will you tell them a patch is broken?). If you catch a bug early enough, the developer will rewrite the patch and thus change the remote's history. Thus, development branches are are often non-fast-forward. + + +### Developers + +If you are a developer with no public trees, choose how you want to help out by selecting the appropriate branch to test. Note that it is easy to switch between multiple remotes and branches so you're not bound to a single one. + +Aside from this, the process for you hasn't changed a lot: commit the patch locally, test and send the patch (see [[SubmittingPatches|Development/Documentation/SubmittingPatches]] for some more information) to the xorg-devel list (and/or the maintainer). Keep rebasing regularly from your chosen remote (git pull --rebase). + +The [[MAINTAINERS|http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS]] file has a list of maintainers for a given subsystem. In addition, ajax volunteered to scoop up dangling patches. If your patch isn't picked up in a reasonable time, don't hesitate to ping the list or the maintainer. + + +### Maintainers + +You are a maintainer if you have a public branch on people.freedesktop. Such a branch is recommended over sending patches one-by-one to the release manager as you will have control over the patches at all times (until the pull request), the patches will see better testing and past experience indicates that pull requests are processed by Keith with a higher priority than patches. + +First, setup up the repository (we're assuming your freedesktop.org username is bond007). + + +[[!format txt """ +$> git clone git://anongit.freedesktop.org/git/xorg/xserver +$> cd xserver +$> ssh bond007@annarchy.freedesktop.org +annarchy $> mkdir xserver.git +annarchy $> cd xserver.git +annarchy $> GIT_DIR=. git init +annarchy $> touch git-daemon-export-ok +annarchy $> vim description +annarchy $> exit +$> git remote add bond007 git+ssh://bond007@people.freedesktop.org/~bond007/xserver.git +$> git push bond007 master +"""]] +Congratulations, you now have a public master branch in your home directory on freedesktop.org. Add it to the the [[PersonalTrees|PersonalTrees]] list so testers know when and why to pick your tree. For this part, we'll assume your master branch is the branch that's supposed to be merged to git master. + +Note that the "bond007" bit in the git remote command is an arbitrary identifier. You can name it "fdo" (for freedesktop.org), after your username, or after your favourite color. The important thing is that you remember what git push bond007 means when you run it (i.e. where you're pushing to). + + +#### Scooping up patches + +Scoop up patches from the list that apply to your area of work when you've reviewed them. Simply pipe the patch into "git am -s" should do in most cases. Let the developer know that you've scooped it up, it saves others from doing the same. If there are multiple ACKs or Reviewed-by on the list, please add them to the patch so we have a record of who looked at the patch. It doesn't have to be a perfect record, remember that once you pushed your tree you can't amend the patches anymore, even if a late Reviewed-by comes in. + +Once you have scooped up a patch, push it to the matching branch in your personal repository. A simple git push does in most cases but see below for more details. Hint: if you haven't synced with master for a while, it's better to rebase master before pushing. + + +#### Pushing to your personal tree + +Syncing with master often is encouraged. This way, testers of your personal tree also test recent patches in master. Also, it's one way to keep testers as they are less inclined to switch to other branches if they get fixes from others soon enough anyway. To sync your personal tree, either pull or rebase from master. **You can only ever rebase if the last state of your personal tree has been pulled into master already.** Rebasing destroys history, so you can only ever do it when the history being destroyed is not public (i.e. only on your local box). + +If bond007/master has been pulled by the RM: +[[!format txt """ +$> git pull --rebase +$> git am -s <patches from list> +# test +$> git rebase -i origin/master # if you need to reshuffle something +$> git push bond007 master +"""]] +If bond007/master has **not** been pulled (e.g. you are accumulating a few patches before sending the pull request): +[[!format txt """ +$> git pull origin # if you need to sync with master +$> git am -s <patches from list> +# test +$> git rebase -i <merge commit from pull> # if you need to reshuffle something +$> git push bond007 master +"""]] + +#### Your own patches + +Your own patches follow the same process as others, send it to the list for review, then merge them accordingly once the Reviewed-by comes in. We should demand the same level of review from each other as from casual contributors. + + +#### Getting Patches and Pulls merged into master + +Again, you are encouraged to have your own branch on freedesktop.org. Once a patch has a Reviewed-by tag, pull this patch into your branch and at the appropriate time, push the branch to freedesktop.org and request a pull from the release manager. The pull must have a [PULL] in the subject line and make sure you Cc: the release manager in your email. For 1.9, the release manager is [[keithp@keithp.com|mailto:keithp@keithp.com]]. + +If a patch should be merged to master directly instead of going through a personal tree and a pull request, make sure you state so in the patch email and the release manager is on the CC list. + +Patches will not automatically be accepted; make sure there has been sufficient review, and that the reviewers have added their Reviewed-by: line to the commit message. Of course, patches may also be rejected for almost any other reason; the release manager is known to be somewhat arbitrary and capricious at times. + +Use [[git-request-pull|http://www.au.kernel.org/software/scm/git/docs/git-request-pull.html]] to get the standard email for a pull request. + + +[[!format txt """ +$> git request-pull 12345deadbeef git://people.freedesktop.org/~bond007/xserver.git +"""]] +Where 12345deadbeef refers to the last commit from the master branch. Pull requests (and patches in general) may get lost. If no reason for not pulling/applying has been given, poke the release manager again. + +There is no minimum number of patches for pull requests, a pull request for a single patch is fine. All patches included in a pull request should have a Reviewed-by line. + + +#### Development branches + +Developing intermediate patches are best done on a separate branch. This branch may be non-fast-forward if needed (document this for users!). The situation to avoid is that a number of patches have accumulated in your tree that need to be merged into master but there's other in-development patches that prevent it from being pulled. Keep ongoing work separate from the trees to be pulled. + + +### Patchwork + +The [[xorg patchwork|http://patchwork.freedesktop.org/project/Xorg/list/]] installation keeps track of patches. Note that to change the state of a patch in patchwork requires manual interaction, it does not get updated automatically as patches are pulled into the tree. diff --git a/XorgDeprecatedMailingLists.mdwn b/XorgDeprecatedMailingLists.mdwn new file mode 100644 index 00000000..579b1319 --- /dev/null +++ b/XorgDeprecatedMailingLists.mdwn @@ -0,0 +1,28 @@ + + +# Archives of X.Org Mailing Lists no longer in Use + + +## Development Lists + + +### Discussion Lists + + * [[xorg-modular|http://lists.freedesktop.org/archives/xorg-modular]]: Mailing list to discuss details of the **modularization project**. + * [[xorg-arch|http://lists.freedesktop.org/archives/xorg-arch]]: Mailing of the **Architecture Working Group**. + * [[xevie|http://lists.freedesktop.org/archives/xevie]]: Mailing list to discuss details on SUN's **X Event Interception Extension**. + +### Logging Lists + + * [[xorg-commit-diffs|http://lists.freedesktop.org/archives/xorg-commit-diffs]]: This mailing list was used to send the full diffs from CVS. Today those are sent to xorg-commit anyway... + * [[xorg-bugzilla-noise|http://lists.freedesktop.org/archives/xorg-bugzilla-noise]]: This Mailing list collected all tickets and comments added to the freedesktop.org bugzilla for the Xorg product. + +## Special Event Mailing Lists + + * [[Xdevconf|http://lists.freedesktop.org/archives/xdevconf/]]: Mailing list covering the periodic [[developers conference|http://freedesktop.org/bin/view/Software/XDevConf]]. + * [[xorg-fosdem|http://lists.freedesktop.org/archives/xorg-fosdem/]]: Mailing list covering X@FOSDEM2006. + * [[xds2007|http://lists.x.org/archives/xds2007/]]: Mailing list covering XDS 2007 in Cambridge, UK. + +## Miscellaneous Mailing Lists + + * [[xorg-mentors|http://lists.freedesktop.org/archives/xorg-mentors]]: Mailing list of the Mentorship Working Group.
\ No newline at end of file diff --git a/XorgDeveloperDocumentation.mdwn b/XorgDeveloperDocumentation.mdwn new file mode 100644 index 00000000..032057c5 --- /dev/null +++ b/XorgDeveloperDocumentation.mdwn @@ -0,0 +1,31 @@ + + +## Documentation I Have Known And Loved + + +### Modern Texts + +More-or-less accurate descriptions of the way X works now. + +* The [[Cygwin/X developer site|http://x.cygwin.com/devel/]] has many useful bits. +* The [[DRI|http://dri.freedesktop.org/wiki/Documentation]] documentation. Mostly still applicable! +* XFree86 DDX documentation: + * [[DESIGN|http://www.x.org/releases/current/doc/xorg-server/ddxDesign.html]] doc. + * [[Multi-monitor Mode Setting APIs|http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/doc/README.modes]] + * Additional [[XFree86 DDX developer documents|http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/doc/]] +* The [[protocol & API specifications for the latest X11 katamari release|http://www.x.org/releases/current/doc/]], covering pretty much everything. + +### Ancient Scrolls + +A miscellaneous collection of documentation surrounding the technical side of X, in particular what it gets wrong and the way it's been implemented in the past. Those who do not learn from history are doomed to reinvent it. + +* _[[An LBX Postmortem|http://keithp.com/~keithp/talks/lbxpost/index.html]]_. Packard, 2001. +* _Component Design Specification for the MIT Multi-Threaded X Window Sample Server_. Haynes, et al., 1993. Available in three parts from the R6.0 source, mirrored [[here|http://people.freedesktop.org/~ajax/mtx/]]. Consider this a warning about how not to multithread an X server. +* _[[D11: a high-performance, protocol-optional, transport-optional window system with X11 compatibility and semantics|http://citeseer.ist.psu.edu/kilgard95highperformance.html]]_. Kilgard, 1995. +* _[[The Evolution of the X Server Architecture|http://keithp.com/~keithp/talks/Xarchitecture/Talk.htm]]_. Packard, 1999. +* _[[Why X Is Not Our Ideal Window System|http://www.std.org/~msm/common/protocol.pdf]]_. Gajewska, et al., 1990. +* _[[X Server Multi-rendering for OpenGL and PEX|http://citeseer.ist.psu.edu/kilgard94server.html]]_. Kilgard, et. al, 1994. Be glad you don't have to care about PEX anymore. + +## See Also + +* [[DevelopersPages|DevelopersPages]].
\ No newline at end of file diff --git a/XorgEVoC.mdwn b/XorgEVoC.mdwn new file mode 100644 index 00000000..cf4950ab --- /dev/null +++ b/XorgEVoC.mdwn @@ -0,0 +1,26 @@ + + +# The X.Org Endless Vacation of Code (EVoC) + +For the last several years, X.Org was a participating mentoring organization in Google's most excellent [[Summer of Code|http://code.google.com/soc]] (GSoC) program. This program provides approximately US$5000 to students to spend their summer developing code for an open source project. Each student proposes a project and is matched with an organization mentor who guides and evaluates the work. GSoC was great for X.Org; we saw more than a dozen students through it, and some of these students went on to be extremely active contributors to X.Org. + +However, for whatever reason some students with good project proposals who would like to participate in GSoC have been unable to do so. Typically, this was because Google funded fewer high-quality GSoC proposals than we had available in a given year, or because the rigid timing of GSoC was entirely incompatible with a student's calendar. In any case, it is now moot: X.Org is now no longer part of Google Summer of Code. + +Rather than lose out on getting students working on X, the X.Org Foundation Board voted in 2008 to initiate a program known as the X.Org Endless Vacation of Code (EVoC) program. The basic terms and conditions of this program are quite similar to Google's GSoC. The key differences are that (1) an EVoC mentorship can be initiated at any time during the calendar year, and (2) the Board can fund as many of these mentorships as it sees fit. We will also consider a broader range of proposals than GSoC: technical documentation is a specific area of interest for us. + +A proposal will typically be for a period of three to four months of contiguous nearly-full-time work, and will be funded at the US$5000-$6000 level, with an initial payment and further payments upon completion of project milestones. The proposal should include a detailed proposed scope of work and schedule; see the [[X.Org GSoC|http://www.x.org/wiki/X.Org-GSoC2008-Application]] page for more information about writing successful proposals. Proposals must acquire a lead mentor from the X.Org technical community in order to be accepted; if the student can help identify this person early, that will increase their chance of success. + +Non-students may also participate in EVoC. Application and participation for non-students is the same as for students, with one exception: non-students will not be paid. The X.Org Foundation believes that paying non-students to help develop X leads to a variety of problems, not least of which is complicating the non-profit status of the Foundation. For EVoC purposes, a student is someone who is a half-time or more college or university student during, immediately before or immediately after their EVoC period. Secondary school students 18 years of age or older are also eligible; sadly, it is legally complicated to pay younger students. + +Students are welcome to either come up with an idea on their own or work up a proposal for an idea suggested by someone else. Lists of ideas that existing developers have come up with can be found at [[Todo|http://www.x.org/wiki/ToDo]] and [[Ideas|http://www.x.org/wiki/SummerOfCodeIdeas]]. + +Hanging out on the irc channels (listed below) and talking with people there is an excellent way to flush out ideas and/or possible mentors. + +Students need to have at least a basic understanding of the following: + +* mailing lists +* irc (graphics developers use irc.freenode.net #xorg-devel,#xorg, #dri-devel, #nouveau and #wayland to name a few.) +* gcc +* git +* Be comfortable using a linux shell and command line +At the current time, X.Org Foundation member Matt Dew marcoz AT osource DOT org is the contact person for X.Org EVoC. All inquiries should be emailed to him, with a cc to board AT foundation DOT x DOT org. diff --git a/XorgEVoC/GalliumCompute.mdwn b/XorgEVoC/GalliumCompute.mdwn new file mode 100644 index 00000000..f00d255b --- /dev/null +++ b/XorgEVoC/GalliumCompute.mdwn @@ -0,0 +1,84 @@ + + +# Accelerated OpenCL using Gallium3D + + +## Summary + +The goal of the project is to address the architectural issues standing on the way of an open accelerated implementation of OpenCL, placing as much burden as possible on the common Gallium3D infrastructure, and, at the same time, to get most of the relevant low-level changes done in the Nouveau driver. The project was carried out by Francisco Jerez <currojerez AT riseup DOT net> as part of the [[EVoC|http://www.x.org/wiki/XorgEVoC]] program, building upon the previous work done in the same direction by Zack Rusin and Denis Steckelmacher during the previous months and years. + + +## Proposed schedule + + +### Driver-specific changes in the Nouveau driver (17 Oct 2011 - 21 Nov 2011) + +At the end of this period the Nouveau driver will be able to run compute grids of arbitrary machine code reliably on the hardware in question. + +1. Implement compute kernel set-up and execution on the nv50 platform, using the "compute" object of the graphics engine. I can only test it on cards with the "0x85c0" variant of this object (nvA3 and up), but I don't rule out adding support for earlier or newer generations if I find volunteers willing to send traces and test patches on different hardware. +1. Extend the nv50 compiler to support the peculiarities of compute programs, including the defined TGSI language extensions. +1. Extend the Nouveau DRM interface to sidestep the memory addressing limitations of compute shaders on that hardware generation. + +### Extend the TGSI IR and the Gallium API for GPGPU (21 Nov 2011 - 26 Dec 2011) + +At the end of this period all the mentioned gallium API and TGSI language changes will be ready and the code will be usable as a sort of non-standard computing library. + +1. Entry points for binding a TGSI compute shader and executing the contained compute kernels. +1. Entry points for defining the input parameters of a compute program, grid domain and thread group layout, required heap size for the various address spaces. +1. Entry points for the mapping of arbitrary buffer objects into the CS addressable global memory space. +1. Extend the TGSI language with instructions for random memory access within the usual address spaces present in compute programs, and make provisions for texture write-back. +1. Expose some compute-specific execution parameters, like grid layout and thread coordinates, to the compute program using TGSI system values. +1. Extend the TGSI language with cross-thread synchronization primitives, barriers and atomic operations. +1. Entry points for assigning buffer objects, textures and samplers to a set of binding points defined by the shader - not necessarily the compute shader, in the spirit of Direct3D 11. +1. The main design principles would be those of the OpenCL API, but the idiosyncrasies of other similar APIs like [[DirectCompute|http://en.wikipedia.org/wiki/DirectCompute]], [[AMD FireStream|http://en.wikipedia.org/wiki/AMD_FireStream]] and [[CUDA|http://en.wikipedia.org/wiki/CUDA]] would be taken into account (e.g. the buffer management peculiarities of the latter make it difficult to write a clean implementation of it in terms of OpenCL, this problem should be addressed in the proposed API). + +### Reshape the clover library into a Gallium state tracker (26 Dec 2011 - 23 Jan 2012) + +At the end of this period all the mentioned OpenCL APIs will be functional (modulo bugs and lack of documentation to be addressed in the next point), assuming the library is provided with TGSI bytecode as input instead of C source code. + +1. Implement context, queue, buffer, texture and sampler management on top of Gallium3D. +1. Implement accelerated memory and image transfer operations on top of Gallium3D. +1. Implement compute kernel execution and parameter passing via Gallium3D. +1. Implement OpenCL events in terms of Gallium fences, describing any synchronization requirements that are needed on the pipe driver for multi-context and multi-device synchronization to work correctly. +1. Implement enumeration of and binding to the available physical hardware devices. + +### Misc. changes, final clean-up and documentation (23 Jan 2012 - 6 Feb 2012) + + +## Work done so far + +The device-independent part of this project (i.e. the OpenCL state tracker and remaining Gallium support changes) has already been included in mesa master. Most of the driver-specific work done until now can be found in a git repository: [[https://github.com/curro/mesa/commits/master|https://github.com/curro/mesa/commits/master]] + + +### Driver-specific changes in the Nouveau driver (17 Oct 2011 - 21 Nov 2011) + +* A preliminary compute API was written to have a framework under which the subsequent work could be tested, afterwards the TGSI language was extended with preliminary resource writeback, memory access and grid parameter support. +* A series of unit tests for the mentioned API was written. +* Code was added to init the GPU compute subsystem, set up and execute a grid of given dimensions. +* A form of raw resource access (raw as in, no channel conversion, the color values returned by the opcode are in the exact form they're found in memory without float/integer conversions or scaling) was implemented. This involved adding a way to track which resources are intended to be written to, then setting up the GPU surface slots in the compute object, teaching the nv50 compiler front-end how to translate/lower the new TGSI opcodes, and then fixing the back-end code emitter to generate the correct binary form of the corresponding hardware instructions. +* Access to the grid parameters (thread id, group id/size, grid layout) from the shader code was implemented. +* At this point I realized that the changes required in the compiler for the long term would be somewhat deeper than I expected, and probably not worth doing because Christoph Bumiller had been working in a complete rewrite of it in C++ that would replace the current one once it's ready. So I decided to focus my work on the new code and port what had been done on top of it. +* A number of bug fixes were done on the new compiler code, especially in the optimization passes and in the handling of texture, control flow and integer ops. Afterwards a number of clean-ups in the internal compiler data structures were carried out. +* The new compiler code was adapted to support proper subroutines (so far it had been inlining the whole input unconditionally). This involved substantial changes in the IR objects the compiler works with. The SSA conversion, live analysis and register allocation passes were modified to be able to deal with undefined "formal" arguments and return values, the register allocator was adapted to assign matching physical registers to the arguments and return value(s) of a function in both the caller and callee. The TGSI parser was extended to emit separate code units for each function, and to infer which TGSI registers need to be treated as function inputs or outputs. Finally an inlining optimization pass was implemented to optionally bring back the old behavior, having in mind a future implementation of an inlining heuristic than would do something smarter than simply inlining everything. +* The compiler code was modified to emit a kind of "symbol table" with the offsets of each input function in the generated binary. This was used to add support for loading compute programs with multiple executable kernels stored in them. +* Access to the global, local, private, and input memory was implemented, like resource access it involved making fixes in both the front- and back-end of the compiler for the new ops to be dealt with correctly. Code was written for uploading the input arguments of the compute kernel to the GPU, at the same time filling in the blanks left inside for GPU pointers. +* Proper texture sampling from compute programs was implemented. This involved no compiler work aside from bug fixes, because it functions the same way as in vertex and fragment programs. The sampler/texture unit setup code was extended to make it able to deal with its compute counterparts. +* The kernel was modified to start allocating the graphics virtual memory space of each process at the 4GB mark, in order to leave the low memory reserved for buffers objects with special addressing requirements like the ones intended to be used for GPGPU. This uncovered a number of kernel bugs that had to be fixed, caused by incorrect handling of high memory in the command submission and notifier block allocation code. + +### Extend the TGSI intermediate representation and the Gallium API to allow for general-purpose computing (21 Nov 2011 - 26 Dec 2011) + +* A winsys loader API was created to provide a common interface to enumerate and initialize all the winsys implementations present in a platform. "drm" and "software" backends for this API were implemented. The loader code of the gbm state tracker was replaced with calls to this API, and the gallium "trivial" tests were changed to use it, with a view to running them on top of some hardware pipe driver instead of softpipe. +* The problem of subroutine parameter passing in TGSI was considered: Until now some of the temporary registers touched by a subroutine were unnecessarily being treated as if they were taking part in the calling protocol, this meant that some optimization opportunities were missed because different registers holding separate return value(s) of a function couldn't be reused and merged together by the register allocator. For this reason the TGSI language was extended with the "LOCAL" declaration modifier that means that a given register isn't intended for parameter passing and the compiler doesn't have to make any guarantees about it being preserved across function boundaries. It's a backwards-compatible change in the sense that implementations lacking a register allocator have the freedom to ignore the LOCAL keyword and treat them as normal declarations without changing the semantics of the program. In order to make room for the LOCAL flag some restructuring had to be done in the TGSI declaration tokens, and afterwards the nv50 compiler was modified to take advantage of local declarations during the register allocation pass. +* The possibility of using regular register files for addressing the GLOBAL, LOCAL, CONSTANT, INPUT spaces was explored but the fact that they require byte-based addressing instead of float4-based addressing led to inconsistencies with the way other register files work, so it seemed more satisfactory to either keep using the explicit resource load/store opcodes for them, or possibly to change all the other register files to byte addressing as well, though, the latter seemed considerably more intrusive. +* The code that handles resource access opcodes in the nv50 compiler was restructured to make room for constant buffer access, formatted surface access, and (at some point) an nvc0 implementation of them. +* Access to constant buffers from a compute program using the resource access opcodes was implemented in the nouveau driver. At this point it became obvious that indirect resource indexing would be necessary if OpenCL's <ins>constant address space is to be implemented using constant buffers. nv50 hardware doesn't have native support for it though (nvc0 does), so it was worked out using emulation. +* Surface load and stores with formatting (transparent (un)packing, channel conversion, etc) was implemented. This is something the OpenCL spec. requires but nv50 doesn't support, so a lowering pass had to be implemented to emulate it in terms of raw resource access. The possibility of moving the implementation to some sort of built-in shader "standard library" was considered but not completed because of lack of time, anyway it's probably worth doing because right now each surface opcode generates a considerable amount of machine code. +* Opcodes for work-group barriers and memory fences were defined and implemented in the nv50 driver. Several unit tests were written for it. +* Opcodes for a number of atomic operations were defined, implemented, and extensively tested in the nouveau driver. Due to the fact that nv50 only supports arbitrary atomics in global memory and not in work-group shared memory, some of them had to be emulated in terms of "locked" loads (a kind of 1-bit atomic compare-and-swap operation coupled with a normal load/store op). + +### Reshape the clover library into a Gallium state tracker (26 Dec 2011 - 23 Jan 2012) + +* The general structure of the clover state tracker was redesigned and simplified. The intermediate device abstraction layer was removed because the Gallium API is already playing the role of driver interface and there's no point to support other kinds of hardware back-ends -- the Gallium API seems to be a good fit even for non-GPU devices (e.g. llvmpipe, cell, svga). +* Most of the state tracker was rewritten, making extensive use of C++11: range-for loops, variadic templates, lambda expressions, type inference, some of the new STL functionality.... This was an immense relief for the code and my mental health, but it could also be argued that it might become an obstacle for portability at some point in the future. As of now it requires gcc-4.6 or newer to build. +* Right now the library expects TGSI assembly as input. An LLVM back-end that will take care of the translation to TGSI is being worked on. +* There are still many limitations and deficiencies: the parameter checking of most API calls is still quite naive, the implementation of some of the less widely-used APIs is still incomplete, buffer sharing across different devices doesn't work (though that's going to require special kernel support anyway).
\ No newline at end of file diff --git a/XorgFoundation.mdwn b/XorgFoundation.mdwn new file mode 100644 index 00000000..9565d339 --- /dev/null +++ b/XorgFoundation.mdwn @@ -0,0 +1,14 @@ + + +### About the X.Org Foundation. + +X.Org Foundation (or X.Org for short) is a company chartered to develop and execute effective strategies that provide worldwide stewardship and encouragement of the X Window System and related projects (Mesa, DRI, Wayland, etc.). The X.Org Foundation has an open membership, and a Board of Directors which is elected from the membership. Please check the [[BoardOfDirectors|BoardOfDirectors]] page for information about the Board. Information on how to join the X.Org Foundation can be found on the [[Membership|Membership]] page. + + +### Why X.Org Foundation? + +In a period between close to the end of 2003 and beginning of 2004, there were attempts from leading XFree86.org project members to apply a few restrictions on the existing 1.0 license of the upcoming XFree86 X4.4.0 release. Since not all (developers, distributors, hardware vendors) were able or willing to agree with and implement that new licensing policy in their code, their development process and their products, they consequently split up and rejoined in the form of the X.org Foundation. + +As a base for their future works, they took one of the last code snippets covered by the old license and joined that with the still existing and freely available codebase from X.org. Further taking responsibility for the contents in the x.org domain made them the de-facto successor of [[XConsortium|XConsortium]]. With their accumulated development power and their joint efforts, there were already two major releases and a patch-level release in 2004, a second patch-level release in early 2005, and major releases each year since. A current summary of the state of the foundation can be found in the most recent [[Annual Report|XorgFoundation/Reports/]]. + +Details on any major X Windows Release can be located through the [[Releases|XorgReleases]] page. The Foundation provides [[funding|XorgFunding]] for various kinds of activities that advance X.Org, most notably [[student development|XorgEVoC]] and [[workshops and meetings|XorgWorkshops]]. Traditional contracting for X Window System development is explicitly not funded by the Foundation, among whose purposes is to encourage development by volunteers. diff --git a/XorgFoundation/Reports.mdwn b/XorgFoundation/Reports.mdwn new file mode 100644 index 00000000..ec99b49b --- /dev/null +++ b/XorgFoundation/Reports.mdwn @@ -0,0 +1,6 @@ + + +### X.Org Foundation Annual Reports + +* [[2010|XorgFoundation/Reports/2010]] +* [[2013|XorgFoundation/Reports/2013]]
\ No newline at end of file diff --git a/XorgFoundation/Reports/2010.mdwn b/XorgFoundation/Reports/2010.mdwn new file mode 100644 index 00000000..7868b5ac --- /dev/null +++ b/XorgFoundation/Reports/2010.mdwn @@ -0,0 +1,76 @@ + +_Converted to wiki form from original report at [[http://foundation.x.org/pipermail/members/2010-February/000550.html|http://foundation.x.org/pipermail/members/2010-February/000550.html]] _ + + +# The State of The X.Org Foundation 2010 + +Bart Massey + +Secretary, [[X.Org Foundation|XorgFoundation]] + +February 20, 2010 + +_Abstract:_ 2009 has been a year of consolidation for X.Org. Software is now being released on a predictable schedule, with predictable improvement. + +_Note:_ The Bylaws of the X.Org Foundation require the Secretary to prepare and deliver a State of the Organization report within 60 days of the start of the calendar year. It is my pleasure to discharge that responsibility by preparing this report. While I have prepared this report in close consultation with the X.Org Foundation [[Board of Directors|BoardOfDirectors]], all views contained herein are ultimately my own. + + +## Introduction + +Six years ago, the X.Org Foundation was re-formed and its first officers elected. Since then, approximately one X Window System major release has occurred per year. The mission of the modern X.Org Foundation Board is to support this work through raising and allocation of funds, through recruitment and support of Foundation members, and through initiatives in community development, education, and support, and by providing a computing and communications infrastructure; in short "to develop and execute effective strategies that provide worldwide stewardship of the X Window System technology and standards." [ [[1|http://www.x.org/wiki/XorgFoundation]] ] + +In the next two sections of this report, I first review X.Org Foundation activities during 2009 and report on our successes and challenges; I then suggest something of the goals, needs, and plans for the future of the X.Org Foundation in 2010 and beyond. Finally, I draw some conclusions. + + +## X.Org Foundation 2009 + +In 2009 X.Org development proceeded at a steady and reasonable pace. The Foundation did not make major changes in operation in 2009. + + +### Development + +In keeping with the X.Org goal of about one release per year, [[Release 7.5 of the X Window System|Releases/7.5]] occurred on October 26, 2009. This release featured the first official version of Multi-Pointer X, "E-EDID support", improved pointer acceleration, an XACE-based SELinux security module, and RandR version 1.3. It also included the kernel modesetting support developed over the last several years, with the goal of moving parts of X better handled by the host operating system into it. + + +### Funded Activities + +Based on the limited ability to raise funds in the 2009 economic climate, and on the limited capacity of conference organizers, the decision was made in early 2009 to cut back from two conference events per year to just one. The Board felt that alternating between North America and elsewhere on alternate years would provide sufficient developer contact worldwide, while cutting costs even when extra travel subsidies were taken into account. This appears to have been a correct decision. + +The [[2009 X Developers Conference|Events/XDC2009]] was held in Portland, Oregon September 28-30, immediately following the Linux Plumbers Conference there. The conference emphasis was on smaller projects and preliminary work; there was no strong unifying topic. The [[2010 X.Org Developers Summit|Events/XDS2010]] is planned for 16-18 September in Toulouse, France. Discussion is proceeding on possibly holding the 2011 X.Org Developers Conference in conjunction with BOSSA in Brazil. + +The Google/X.Org Summer of Code 2009 was successful, with three of four accepted projects completing and contributing to X.Org development, as well as helping to bring new developers to X.Org [ [[2|http://socghop.appspot.com/gsoc/org/home/google/gsoc2009/xorg]] ]. The [[X.Org Endless Vacation of Code|XorgEVoC]] was established in 2009 to provide opportunities similar to Summer of Code to selected students on an ad hoc calendar. Only a couple of students have shown interest to date, and the one student that submitted an accepted proposal later withdrew. This is probably due to the lack of promotion of the program. + +The X.Org Foundation funded a video hackfest held at the Collabora offices in Barcelona in November. The event was reportedly highly successful [ [[3|http://lists.freedesktop.org/archives/xorg/2009-November/048182.html]] ], and was held at a modest cost. It is hoped that other X.Org projects will take this example to heart and seek funding help when needed. + + +### Foundation Activities + +The Board had hoped to complete the legal transition of the X.Org Foundation from a US LLC to a US 501(c)3 Educational Non-Profit Foundation in the first few months of 2008. A large number of delays culminated in the completion of this transition in early 2009, when the State of Delaware granted us corporate status. However, it turns out that some IRS documents still need to be filed by the Treasurer. This work is underway. + +The 2009 Board election was once again delayed, and completed in mid-February 2010. This is unfortunate, and further work needs to be done to ensure that the 2010 and ongoing elections can be held in a timely and regular manner. This election was the first in quite a while in which the restriction in the X.Org Bylaws that only two people from a given organization can be on the Board simultaneously was an issue. The issue was resolved by Keith Packard stepping down from the Board, leaving only two Intel representatives. + +The attempt to improve coordination and throughput of the Board continued in 2010. The Board established a wiki that it experimented with as an internal communication mechanism, but it saw only modest use. The regular bi-weekly IRC meetings begun in 2008 continue to date, and e-mail continues to play a crucial role. + +Membership in the Foundation is currently at about 145 active members. Work continues on encouraging X.Org participants to join the Foundation. + +Communication between the Board and the Membership has continued to be an issue in 2009, culminating in a bit of drama during the 2010 Board election. As a result of this, I am stepping down as Secretary, in the hope that someone else on the Board can do a better job of facilitating this communication. + + +## 2010 And Beyond + +No substantial work was done in 2009 in finding recurring sponsors for X.Org as a whole, although conference sponsorships and other kinds of directed sponsorships were strong. Many on the Board still believe that this may be the future of funding for the organization, but funding options undoubtedly will be explored again in 2010. + +Good improvements have been made in the X.Org / Freedesktop.org shared infrastructure, in particular more sysadmin support. Emphasis for 2010 will be on cutting infrastructure costs, and on continuing to improve infrastructure reliability and responsiveness. There was some work done in 2009 on expanding build and tinderbox facilities; this work will likely continue in 2010. Traffic volume and spam problems on the xorg email list and on X.org wikis became an issue in 2009. The wiki spam problem is particularly bad on auxiliary X.Org wikis that do not have the same amount of regular attention from their maintainers as the main X.Org site. After careful consideration, the Board failed to come up with any ideal resolution to these problems. + +The heavily-hacked legacy members.x.org PHP codebase has been increasingly a thorn in the side of conducting membership business, and is due for replacement. The Board should consider how to proceed on this issue as early as possible in 2010, with the goal of having the replacement in place and verified in time for the next Board election. + +Attempts were made to straighten out X.Org banking issues in 2009, but as of this writing the banking situation is mostly unchanged. + +There is ongoing concern among the Board about the trademark situation of X.Org. It is not at all obvious what trademarks, if any, are currently registered. There is also a friendly lack of consensus among the Board members about what needs to be registered; the various costs and benefits make for a complex engineering tradeoff. In 2010, this issue needs to be resolved one way or the other. As an ancillary issue, the question of what, if anything, to do about changing out the old X.Org "halo" logo should once again be considered. + + +## Conclusion + +The state of the X.Org Foundation is strong. The X Window System continues to succeed. + +Each year that I have prepared this report I have confidently predicted that the following year will be the Year of the Linux Desktop. However, I do not believe that 2010 will be the Year of the Linux Desktop, due to decreasing interest in desktops and laptops. I am quite sure that 2010 will be the Year of Mobile Linux. diff --git a/XorgHAL.mdwn b/XorgHAL.mdwn new file mode 100644 index 00000000..9356e0e5 --- /dev/null +++ b/XorgHAL.mdwn @@ -0,0 +1,29 @@ + + +# Xorg server and HAL + + +## Versions that use HAL + +Xorg versions 1.4 through 1.7 (and optionally later versions) use [[HAL|http://www.freedesktop.org/wiki/Software/hal]] for several things related to input devices: + +1. Finding input devices at startup +1. Being notified of input device hotplugging (arrival & removal) +1. Mapping system input devices to Xorg input driver modules (via .fdi files provided with Xorg input drivers) +1. Setting input device options (via user-customized .fdi files) +HAL is not used by Xorg for output devices or any other devices, only input. + + +## Versions that do not use HAL + +Since the HAL project has stopped development and deprecated itself, X.Org is planning to move off HAL in the future. Support for udev instead of HAL is available in X Servers 1.8 and later and enabled by default, pending platform availability. As HAL was also used for input device configuration, a new feature has been added to X Server 1.8 to support configuration snippets in the xorg.conf.d directory. Instead of udev rules, users and distributions are encouraged to use the xorg.conf.d for configuration. Old-style xorg.conf configuration is still available. + +[[https://fedoraproject.org/wiki/Input_device_configuration|https://fedoraproject.org/wiki/Input_device_configuration]] has instructions on how the new system works. + + +## Future Versions + +The currently planned replacements for the above functionality pieces are: + +1. Direct calls to OS-dependent device enumeration libraries (libudev on Linux, libdevinfo on Solaris, etc. - basically whatever HAL called to do this) +Neither [[DeviceKit|http://www.freedesktop.org/wiki/Software/DeviceKit]], nor the [[udisks|http://www.freedesktop.org/wiki/Software/udisks]]/upower/etc. replacements provide any of this functionality for input devices, and the [[DeviceKit|DeviceKit]] authors have indicated that they do not plan to provide such functionality, suggesting direct use of the OS interfaces such as libudev instead. diff --git a/XorgIRC.mdwn b/XorgIRC.mdwn new file mode 100644 index 00000000..ce320277 --- /dev/null +++ b/XorgIRC.mdwn @@ -0,0 +1,12 @@ + +Xorg hosts two channels on the [[freenode|http://freenode.net/]] IRC network: #xorg and #xorg-devel. #xorg is for general discussion and user support questions, and #xorg-devel is for development discussion. We ask that you respect a few rules and guidelines when using them. + +1. Don't ask to ask, just ask. +1. Be patient. IRC is variable-latency, and you may not always get a response immediately. +1. That said, please don't repaste the same question continuously just because three new people joined the channel. +1. Be prepared to supply your configuration file (almost always `/etc/X11/xorg.conf`) and log file (almost always `/var/log/Xorg.0.log`) on a paste site so we can help you troubleshoot. Two such sites are [[pastebin|http://pastebin.com]] and [[rafb|http://rafb.net/]]. +1. Stay on topic. In particular, don't re-ask support questions in #xorg-devel just because no one answered in #xorg. +1. Proprietary video driver support questions are off-topic. We didn't write them, we don't have the source, and we can't fix them. Use #ati or #nvidia as appropriate, even if those channels appear to be dead too. +1. For end-user support on the open-source radeon driver there is #radeon . For the open-source intel driver, there is [[#intel-gfx|http://intellinuxgraphics.org/feedback.html]] . +1. Have a look at the [[User FAQ|FAQ]] before asking +etc. diff --git a/XorgMailingLists.mdwn b/XorgMailingLists.mdwn new file mode 100644 index 00000000..d816c0e8 --- /dev/null +++ b/XorgMailingLists.mdwn @@ -0,0 +1,44 @@ + + +# X.Org's Mailing Lists + + +## Announcements + + * **[[xorg-announce|http://lists.freedesktop.org/mailman/listinfo/xorg-announce]]** is for announcements about Xorg releases and releases of related Xorg components. It is not a place for discussion. + +## Discussion Lists + + * **[[xorg|http://lists.freedesktop.org/mailman/listinfo/xorg]]** is for **general purpose discussions** and support questions. + * **[[xorg-devel|http://lists.x.org/mailman/listinfo/xorg-devel]]** is for development discussions. Patch review and development discussion can go there. + * **[[xorg-driver-ati|http://lists.freedesktop.org/mailman/listinfo/xorg-driver-ati]]** is for discussions on **ati driver** related issues. + * **[[x-packagers|http://lists.freedesktop.org/mailman/listinfo/x-packagers]]**: Discussions among people who are interested in **packaging X binaries** (mostly distro maintainers) + * **[[xorg-test|http://lists.freedesktop.org/mailman/listinfo/xorg-test]]** is the general discussion list of the **XTEST Project**. + * **[[Xcb|http://lists.freedesktop.org/mailman/listinfo/Xcb]]** is the general developers discussion list of the **Xcb Project**. + * **[[Nouveau|http://lists.freedesktop.org/mailman/listinfo/Nouveau]]** discusses the NVIDIA reverse engineering project **Nouveau**. + +## Logging Lists (not for posting) + + * The [[xorg-commit|http://lists.freedesktop.org/mailman/listinfo/xorg-commit]] mailing list archives commits to the xorg repository. + * The [[xorg-test-commit|http://lists.x.org/mailman/listinfo/xorg-test-commit]] mailing list archives commits to the XTEST Project repository. + * The [[xorg-team|http://lists.x.org/mailman/listinfo/xorg-team]] mailing list is where bugzilla sends notices about bugs filed against the xorg tree. + +### Other X related developers lists not directly part of the X.Org Foundation. + + * The [[xdg|http://lists.freedesktop.org/mailman/listinfo/xdg]] freedesktop standards and specifications mailing list. + * The [[XKB-Config project|http://www.freedesktop.org/wiki/Software/XKeyboardConfig/Development]] hosts a mailing list for discussion of XKB keyboard layouts and usage. + +## Other Lists + + * The [[xorg-europe|http://lists.freedesktop.org/mailman/listinfo/xorg-europe]] mailing list is to announce and discuss events and meetings in Europe. + +## Archives + + +### Mailing List Archives (Unofficial) + + * [[archive.netbsd.se|http://archive.netbsd.se/?cn=XOrg]], browse, search, RSS-feeds. + +### Deprecated Lists Archives + + * The archives of [[deprecated X.Org mailing lists|XorgDeprecatedMailingLists]] can be found here.
\ No newline at end of file diff --git a/XorgModuleABIVersions.mdwn b/XorgModuleABIVersions.mdwn new file mode 100644 index 00000000..f02c4268 --- /dev/null +++ b/XorgModuleABIVersions.mdwn @@ -0,0 +1,23 @@ + +The Xorg server includes version numbers for various ABI's for interfaces used by loadable modules such as drivers and extensions. + +This major number of the ABI version (_**x**_.*) is incremented when there are incompatible changes in module API/ABI's, while the minor number (*._**x**_) is incremented for compatible additions. + +Modules reporting they require a incompatible version number will not be loaded unless the `-ignoreABI` option is used. (Modules can also check ABI versions themselves, and choose which function variant to call or structure variant to access, based on the reported versions - this is the option used by some closed source drivers for instance.) + +ABI numbers may increment multiple times during Xorg server development cycles, to track changes for those following the head of the development stream. X.Org tries to avoid changing ABI's incompatibly in stable release branches. +[[!table header="no" class="mointable" data=""" + **Xorg Version: ** | **[[1.3|Server13Branch]] ** | **[[1.4|Server14Branch]]** | **[[1.5|Server15Branch]]** | **[[1.6|Server16Branch]]** | **[[1.7|Server17Branch]]** | **1.8** | **1.9** | **1.10** | **1.11** + ABI_ANSIC_VERSION | 0.3 | 0.3 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 + ABI_VIDEODRV_VERSION | 1.2 | 2.0 | 4.1 | 5.0 | 6.0 | 7.0 | 8.0 | 10.0 | 11.0 + ABI_XINPUT_VERSION | 0.7 | 2.0 | 2.1 | 4.0 | 7.0 | 9.0 | 11.0 | 12.2 | 13.0 + ABI_EXTENSION_VERSION | 0.3 | 0.3 | 1.1 | 2.0 | 2.0 | 3.0 | 4.0 | 5.0 | 5.0 + ABI_FONT_VERSION | 0.5 | 0.5 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 | 0.6 +"""]] + + +## Input ABI policy + +Note: this is a guideline more so than a strict rule. + +The input ABI is bumped whenever an incompatible change is introduced to the server. This may happen several times during a development cycle. The goal of the ABI management is to allow the master branch of the various input drivers to compile when bisecting the server. If multiple changes to the server's ABI are required, these changes are usually accumulated and pushed in one merge. diff --git a/XorgReleases.mdwn b/XorgReleases.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/XorgReleases.mdwn diff --git a/XorgTesting.mdwn b/XorgTesting.mdwn new file mode 100644 index 00000000..05897dbc --- /dev/null +++ b/XorgTesting.mdwn @@ -0,0 +1,118 @@ + + +# The X.Org Foundation Testing Plan + + +## Detailed test instructions + +This section outlines the test procedure to follow when testing a release candidate. When a test run has been completed, please e-mail the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list with the following information so that we can track what has and has not yet been tested. Note that we are interested in progress: please do not wait to complete all phases of testing to send in reports. + + 1. Your Name + 1. The date tested + 1. The platform you tested: + * The operating system tested (e.g., AIX, Cygwin, FreeBSD, HP-UX, Linux, etc.) + * The architecture tested (e.g., Alpha, AMD64, EM64T, IA-32, IA-64, Sparc, etc.) + * The distribution and release tested (e.g., Red Hat FC2, SUSE 9.1, Debian unstable, Solaris 9, etc.) + 1. The snapshot or release candidate tag tested (e.g., XORG-6_7_99_1, etc.) + 1. Build test status: passed or failed or untested + 1. Install test status: passed or failed or untested + 1. Conformance test status: passed or failed or untested + 1. Run test status: passed or failed or untested + * List the tests run +For any test(s) that failed, please include in your report the test(s) that failed, and file a bugzilla report if no one has already filed one against the failure(s) you found. + + +### Build tests + +Each of the following build tests can be performed by copying the _sample_ host.def file (or the _alternate_) to the xc/config/cf directory and the running `make World >& World.LOG` (or other such command as appropriate for your platform), and then checking the World.LOG file for any failures. + + 1. Build with empty host.def file ([[sample|http://www.freedesktop.org/~kem/build-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/1a/host.def]]) + 1. Build with [[BuildServersOnly|BuildServersOnly]] defined as YES ([[sample|http://www.freedesktop.org/~kem/build-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/2a/host.def]]) + 1. Build with [[DoLoadableServer|DoLoadableServer]] defined as NO ([[sample|http://www.freedesktop.org/~kem/build-tests/3/host.def]] [[alternate|http://www.freedesktop.org/~kem/build-tests/3a/host.def]]) +Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each build requirement above, defining [[HasFreetype2|HasFreetype2]] as NO is permitted. Each _alternate_ host.def file above have this define included. + + +### Install tests + +Each of the following install tests can be performed by building the release (as described above using the _sample_ or _alternate_ host.def file provided), running `make Install >& Install.LOG` (or other such command as appropriate for your platform), and checking the Install.LOG output for any failures. + + 1. Build and install with no host.def file ([[sample|http://www.freedesktop.org/~kem/install-tests/1/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/1a/host.def]]) + 1. Build and install with: Project``Root defined to be something other than the default, and Nothing``Outside``Project``Root defined as YES ([[sample|http://www.freedesktop.org/~kem/install-tests/2/host.def]] [[alternate|http://www.freedesktop.org/~kem/install-tests/2a/host.def]]) +Note that some systems do not have a compatible version of Freetype2 installed on their system, so in addition to each install requirement above, defining Has``Freetype2 as NO is permitted. Each _alternate_ host.def file above have this define included. + + +### Conformance tests + +After installing the full release, the conformance tests can be run using the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xtest.tar.gz]]. A helper script (called ``xreg``) is used to run the X test suite, which can be downloaded [[here|http://www.freedesktop.org/~kem/testing/xreg]]. See the next two sections below for more information on how to setup and use these tools. + + +#### Setting up the X test suite + +Here are some brief instructions on how to download and set up everything that you will need to run the X test suite: + + 1. Follow the directions at [[BuildingXtest|BuildingXtest]] + 1. `wget http://www.freedesktop.org/~kem/testing/xreg` +Now you should be ready to begin testing. + + +#### Examples of how to use the xreg script + +Here are some examples of how to use xreg to run the X test suite: + + 1. `xreg -xtest -xvfb` + * This runs xtest at all default depths using the Xvfb server. + * The default depths are 8, 15, 16, and 24+32. + * The "24+32" depth is one that uses a depth of 24 with a frame buffer bits per pixel of 32 (i.e., -depth 24 -fbbpp 32). + 1. `xreg -xtest -xorg -d 16` + * This runs xtest at depth 16 using the Xorg server. + 1. `xreg -xtest -xvfb -d 15 -test XCopyArea` + * This runs xtest at depth 15 using the Xvfb server, but it only runs the XCopy``Area test. + * Selecting individual tests is very useful to track down test failures. + 1. `xreg -xtest -xvfb -d 16 -xvfbwidth 1280 -xvfbheight 1024 -test XFillRectangles -n 3-5` + * This runs xtest at depth 16 using the Xvfb server running at 1280x1024, but only runs the third through the fifth tests of the XFill``Rectangles test. +Notes on using xreg: + + * The output from these test runs are stored in `pwd`/results by default. You can change the default output dir using the -O command line option. + * The material below assumes that you have done a full install of the system to /usr/X11``R6. However, if you are using a different Project``Root, you can use the following command line option to the xreg script to run from that alternate location: `-projroot` _path-to-your-project-root_ + * The files that are generated from an xreg run of xtest are: + 1. `X-setup..output` -- this file contains the output of the X server during the setup phase + 1. `xtest.DEPTH.DATE.TIME.errors` -- this file contains the list of errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_. + 1. `xtest.DEPTH.DATE.TIME.report` -- this file contains the report of all tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_. + 1. `xtest.DEPTH.DATE.TIME.summary` -- this file contains a summary of the errors found during the test run at depth _DEPTH_ made on date _DATE_ at time _TIME_. The summary file is only useful during full test runs (e.g., not when running individual tests). + 1. `xtest.DEPTH.DATE.TIME.results` -- this directory contains the journal from the tests run at depth _DEPTH_ made on date _DATE_ at time _TIME_ as well as any error images generated. + * After running xtest, you can check to see if everything passed by looking at the summary/errors/report file(s) to see if there are any failures. + * There are some known failures that the summary file attempts to take into account. The first part of the summary file is the list of failures, and at the end of the summary file is a diff between the known failures (e.g., XDraw``Arcs) and what the failures were for this run. + * The xreg script has only been tested on Linux systems. If there are problems with these scripts, please post patches to the [[xorg@lists.freedesktop.org|mailto:xorg@lists.freedesktop.org]] mailing list. + * There are many other options to xreg (and it can be used to run other tests such as x11perf). Run `xreg -help` to see the usage message. + +#### Actually running the conformance tests + +For this section, one of the following should be used for testing: + + * For platforms based on a XFree86-style DDX, the ``dummy`` driver should be used. + * For example: `xreg -xtest -xorg` + * This will run xtest at all the default depths using the Xorg server. + * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass. + * For all other platforms, ``Xvfb`` should be used. + * For example: `xreg -xtest -xvfb -d "15 16 24+32"` + * This will run xtest at depths 15, 16 and 24+32 using the Xvfb server. + * Check the output of each report or summary file to make sure that all tests that are expected to pass do actually pass. + * Note that Xvfb does not currently run at depth 8, so the example above limits the testing to depths 15, 16 and 24+32. Update, this problem has been fixed in CVS now and Xvfb at depth 8 works again. +Additional notes: + + * The ``Xvfb`` server is special X server that uses a virtual framebuffer. It is normally built and installed with the full release. See the `Xvfb(1)` for more information about this server. + * The ``dummy`` driver is a special driver available with the XFree86 DDX. To use the dummy driver, simply substitue it for your normal card driver in the `Device` section of your `xorg.conf` configuration file. For example, if you normally uses an ati driver, then you will have a `Device` section with `Driver "ati"` to let the X server know that you want it to load and use the ati driver; however, for these conformance tests, you would change that line to `Driver "dummy"` and remove any other ati specific options from the `Device` section. + +### Run tests + +After installing the full release, you can run the subset of tests listed below that applies to the platform being tested. Please run these tests on at least two different driver families (where applicable). For example, on an IA-32 system running Linux, you could run the tests using one card from the ATI driver family and another card from the NVIDIA driver family. + +Tests for each driver family: + + 1. X test suite (listed above) + 1. x11perf + 1. rendertest (found in the xapps CVS repository on freedesktop.org) + 1. Standard graphical environment + 1. GL tests: glxgears, gloss, [[quake3|http://www.freedesktop.org/~jg/quake3.tar.gz]] + 1. Switch to/from VTs (on Linux) +-- [[KevinMartin|KevinMartin]] - 18 Jan 2005 diff --git a/XorgTriage.mdwn b/XorgTriage.mdwn new file mode 100644 index 00000000..e4b78b4f --- /dev/null +++ b/XorgTriage.mdwn @@ -0,0 +1,16 @@ + +Basic rules about triaging bugs for X.org: + +* Bugs that are NEW and assigned to `xorg-team` are awaiting triage. +* ASSIGNED with owner set to `xorg-team` means that the bug is valid but not assigned to a specific developer yet +* ASSIGNED with owner changed to specific developer means that it's in that developer's queue +* Don't go closing bugs if they're assigned to someone else (including assigned to the team) +* Discuss a WONTFIX, NOTABUG, or NOTOURBUG with the developers first before closing any bug with these resolutions. +* General rules for the severity field: + * Blocker: server crashes, security problems, build problems with the default build, release issues. + * Critical: rendering errors, client-side crashes, (most) regressions. +* Use keywords intelligently: + * `want-backtrace` on bugs that need a useful backtrace before they can be debugged + * change `want-backtrace` to `have-backtrace` once you have one + * `regression` for functionality regressions relative to previous releases + * `janitor` for cleanup or style tasks a la [[kernel janitors|http://janitor.kernelnewbies.org/]]
\ No newline at end of file diff --git a/XorgWorkshops.mdwn b/XorgWorkshops.mdwn new file mode 100644 index 00000000..5ebd7886 --- /dev/null +++ b/XorgWorkshops.mdwn @@ -0,0 +1,7 @@ + + +# X.Org-related Workshop and Meeting Funding + +One of the explicit goals of the X.Org Foundation is to fund work that helps to advance the development of the X.Org project, and of X and related open source projects in general. As such, the X.Org Foundation Board explicitly invites proposals to fund such workshops. A good proposal will contain a target date, a reasonably accurate budget, and a description of the event that emphasizes why it will benefit X-related work. Note that the Board is more than willing to approve funding for events, such as the recent Video Hackfest, that are not directly about work on the core X.Org software base. + +To apply for funding for your workshop or meeting, please email your proposal to board AT foundation DOT x DOT org, or contact any Board member for feedback and help. diff --git a/XsltVersion.mdwn b/XsltVersion.mdwn new file mode 100644 index 00000000..ac0333e9 --- /dev/null +++ b/XsltVersion.mdwn @@ -0,0 +1,12 @@ + +<?xml version="1.0" encoding="ISO-8859-1"?> + +<?xml-stylesheet href="XsltVersion" type="text/xml"?> + +<xsl:stylesheet version="1.0" xmlns:xsl="[[http://www.w3.org/1999/XSL/Transform">|http://www.w3.org/1999/XSL/Transform">]] + + * <xsl:output method="html" omit-xml-declaration="yes" indent="no"/> <xsl:template match="/"> + * This Wiki is running an XSLT engine by <xsl:value-of select="system-property('xsl:vendor')"/> (<a href="{system-property('xsl:vendor-url')}"><xsl:value-of select="system-property('xsl:vendor-url')"/></a>) implementing XSLT v<xsl:value-of select="system-property('xsl:version')"/> +</xsl:template> + +</xsl:stylesheet> diff --git a/apm.mdwn b/apm.mdwn new file mode 100644 index 00000000..1265b274 --- /dev/null +++ b/apm.mdwn @@ -0,0 +1,14 @@ + + +# apm + +Driver for Alliance Promotion chipset based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/ati.mdwn b/ati.mdwn new file mode 100644 index 00000000..41342514 --- /dev/null +++ b/ati.mdwn @@ -0,0 +1,19 @@ + + +# ati + +Wrapper driver for ATI video chips + +License: MIT + + +## Documentation and Support + +The ati driver is a small wrapper that probes your card and then loads the appropriate driver, either radeon, r128, or atimisc. + +* Please check the [[radeon|radeon]], [[r128|r128]], or [[atimisc|atimisc]] manpages for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/atimisc.mdwn b/atimisc.mdwn new file mode 100644 index 00000000..ef1f42f0 --- /dev/null +++ b/atimisc.mdwn @@ -0,0 +1,15 @@ + + +# ati + +Driver for ATI Mach8/32/64 based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/ati.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/chips.mdwn b/chips.mdwn new file mode 100644 index 00000000..f73af866 --- /dev/null +++ b/chips.mdwn @@ -0,0 +1,16 @@ + + +# chips + +Driver for Chips&Technologies based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/chips.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/chips.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/cirrus.mdwn b/cirrus.mdwn new file mode 100644 index 00000000..d7e88622 --- /dev/null +++ b/cirrus.mdwn @@ -0,0 +1,14 @@ + + +# cirrus + +Driver for Cirrus Logic based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/conversion.mdwn b/conversion.mdwn new file mode 100644 index 00000000..9868632f --- /dev/null +++ b/conversion.mdwn @@ -0,0 +1,10 @@ +# MoinMoin to Ikiwiki conversion + +If you have an account on Annarchy, you can help out with the conversion of this wiki. + +You can follow the [[page conversion|http://wiki.freedesktop.org/sitewranglers/wiki/moin2iki_page_selection/]] instructions using `PROJECT="xorg"`. + +Here is a list of broken links, which should be a starting place for what needs converting: + +[[!brokenlinks]] + diff --git a/cyrix.mdwn b/cyrix.mdwn new file mode 100644 index 00000000..76ea5f56 --- /dev/null +++ b/cyrix.mdwn @@ -0,0 +1,16 @@ + + +# cyrix + +Driver for Cyrix MediaGX based video chips. License: MIT + + +## Documentation and Support + + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/cyrix.4.html]] containing additional information about known problems and hints. + * The requested URL /~xorg/current/doc/cyrix.4.html was not found on this server. + +## Known Issues + + +### Release 6.7.0 diff --git a/fbdev.mdwn b/fbdev.mdwn new file mode 100644 index 00000000..8a76f86d --- /dev/null +++ b/fbdev.mdwn @@ -0,0 +1,15 @@ + + +# fbdev + +Driver for Linux framebuffer device based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.x.org/releases/current/doc/man/man4/fbdev.4.xhtml]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/fosdem2006.mdwn b/fosdem2006.mdwn new file mode 100644 index 00000000..0439db25 --- /dev/null +++ b/fosdem2006.mdwn @@ -0,0 +1,101 @@ + + +# X@FOSDEM2006 + +* Time: Friday, **24**th until Sunday, **26**th of **February 2006**. +* Place: At **[[FOSDEM 2006|http://www.fosdem.org/2006]]** in Brussels, Belgium. +X.org will this year have its first X@FOSDEM, meaning that X will have some events on or surrounding the FOSDEM event. An [[X Developers HotHouse|fosdem2006]] will be organised on **Friday the 24th**, the day before FOSDEM 2006 and during the weekend (**25th** and **26th**) X.org will have a [[DevRoom|fosdem2006]] at FOSDEM. + +The goal of X@FOSDEM is to have X developers meet, discuss and hack. This is why the idea of an [[X Developers HotHouse|fosdem2006]] has been revived. The event also allows those who were unable to make it to the [[X.org Developers Conference|XDevConf]] to catch up on what happened there. At the same time, X.org will have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. + +**We are still looking for [[speakers for the Devroom|fosdem2006]].** + + +## X@FOSDEM Schedule + + +### Friday, 24th of February 2006: + + * 9.30 - 18.00: [[X@FOSDEM Developers HotHouse|fosdem2006]]. +* 18.00+ : [[X@FOSDEM Social event|fosdem2006]]. + +### Saturday, 25th of February 2006: + + * 9.30 - 12.30: [[FOSDEM Opening talks|http://www.fosdem.org/2006]]. +* 14.00 - 18.00: [[X@FOSDEM Devroom|fosdem2006]]. + +### Sunday, 26th of February 2006: + + * 9.30 - 12.30: [[X@FOSDEM Devroom|fosdem2006]]. +* 13.30 - 18.00: [[X@FOSDEM Devroom|fosdem2006]]. + +## X@FOSDEM Developers HotHouse + +<a name="hothouse"></a> + +A **[[HotHouse|HotHouse]]** is a place where developers can meet informally, discuss and hack on code together. It is proven concept that's highly creative and very productive. + +The room is on the same campus where FOSDEM takes place the days after ([[map|http://www.freedesktop.org/~libv/HotHouse_location.png]]), and it is equipped with electricity and (at least local) networking. You should be able to find arrows that guide you to the hothouse (ACE room) when you walk down the Rue Paul Heger. + +Here is a list of [[HotHouse participants|Fosdem2006HotHouseParticipants]]. + + +## X@FOSDEM DevRoom + +<a name="devroom"></a> + +A **[[DevRoom|DevRoom]]** is a project/topic specific room on FOSDEM, holding anywhere from 50 to 150 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, a [[DevRoom|DevRoom]] can be thought of as a more public [[HotHouse|HotHouse]], but one which has [[scheduled talks|fosdem2006]]. + +The [[DevRoom|DevRoom]] is free and open to everyone, there is no registration required. But if you're coming, you can always attach yourself to [[this list|Fosdem2006DevRoomAttendants]]. + + +### DevRoom Speaker Schedule + +<a name="schedule"></a> + +Saturday: + +* 14.00: [[Stuart Kreitman - Highlights from the Santa Clara XDevConf|fosdem2006Stuart]]. +* 15.00: [[Keith Packard - Coordinate transform redirection for composited window environments|fosdem2006Keith]]. +* 16.00: [[Matthias Hopf - Xgl, the current future of X|fosdem2006Matthias]]. +Sunday: + +* 09.30: [[Stuart Kreitman - Automated Display Configuration in the Xorg Window System|fosdem2006Stuart]]. +* 10.30: [[Luc Verhaegen - X and modesetting, atrophy illustrated|fosdem2006Luc]]. +* 11.30: [[Jay Hobson - Dtracing the Xorg Server|fosdem2006Jay]]. +* 12.30: Lunchtime. +* 13.30: [[Egbert Eich - Reworking the PCI subsystem on X|fosdem2006Egbert]]. +* 14.30: [[Stephane Marchesin - Towards open source 3D acceleration for nvidia cards|fosdem2006Stephane]]. +* 15.30: [[Daniel Stone - XKB|fosdem2006Daniel]] +* 16.30: Zack Rusin - Why XGL is **not** the answer +The "To Be Announced" talks are slots reserved for talks not appearing in the FOSDEM brochure. + + +### DevRoom Speakers + +<a name="speakers"></a> + +If you're interested in giving a talk at the X.org FOSDEM [[DevRoom|DevRoom]], then [[contact us|mailto:fosdem-org@lists.x.org]] right away. + +* We have time for about 11 talks. +* We will require a **titel or topic**, and a **brief description** ASAP. +* Papers are due on wednesday 22nd. +* FOSDEM provides a projector and networking. If you need anything further you can always [[ask us|mailto:fosdem-org@lists.x.org]], but be prepared to bring it along yourself. + +## X@FOSDEM Social Event + +<a name="social"></a> + +The "back room" of Cafe De L'Universite has been reserved for X.org. Cafe De L'Universite is a students cafe 500m east of the FOSDEM site (towards the cemetary) and they offer a good choice of belgian food at good prices, accompanied by a nice selection of belgian beers. Friday night is mussels night! + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/2006]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2005]] will be of interest. + + +## Registration and further information + +<a name="contact"></a> If you want to register for the [[HotHouse|fosdem2006]] or are interested in [[speaking at the DevRoom|fosdem2006]], or just need more information, mail us at [[fosdem-org@lists.x.org|mailto:fosdem-org@lists.x.org]]. diff --git a/fosdem2006Daniel.mdwn b/fosdem2006Daniel.mdwn new file mode 100644 index 00000000..8c6df110 --- /dev/null +++ b/fosdem2006Daniel.mdwn @@ -0,0 +1,9 @@ + +Daniel Stone is apparently the XKB maintainer, but is not entirely sure how that happened. He fears the prospect of overhauling the input system, but feels powerless to stop it. He was previously the X maintainer for Ubuntu, and worked on Debian packaging of X also. + + +## XKB FTW + +XKB, the X Keyboard Extension is, at least in theory, a terrific extension that allows easy and sensible keyboard configuration. In practice, however, it offers many opportunities for improvement. This talk will outline my current plans for XKB, as well as some of the history of this rarely-understood extension. + +Slides: [[http://www.fooishbar.org/talks/fosdem-xkb.pdf|http://www.fooishbar.org/talks/fosdem-xkb.pdf]] diff --git a/fosdem2006Egbert.mdwn b/fosdem2006Egbert.mdwn new file mode 100644 index 00000000..dd19fb50 --- /dev/null +++ b/fosdem2006Egbert.mdwn @@ -0,0 +1,18 @@ + +Egbert Eich is a long time X developer, SuSE X maintainer, and X.org board member. He also managed the X.org 6.7.0 release. + + +## Reworking the PCI subsystem in X + +The PCI subsystem is one of the pieces of X that are in urgent need of renovation. The majority of its code was developed in the early days of PCI and when X mostly supported x86 systems. Since then numerous systems with additional requirements have been introduced and the support provided by the operating systems has been greatly enhanced. + +Therefore it is time to redesign this entire subsystem. Some ideas behind this redesign are presented here. + +The talk was renamed to: + + +## Renovating DDX + +The X.Org DDX has met its limits. A lot of functionality it provides is not required by most operating systems any more today. It imposes limits and restricitions of hardware of the mid-90's. Furthermore it doesn't provide a lot of infrastructure that is needed for modern hardware. Thus a lot of this is now implemented inside the drivers - and designed in an ad hoc fashion. + +The [[Slides|FOSDEM2006EgbertEich.pdf]] of the talk. diff --git a/fosdem2006Egbert/FOSDEM2006EgbertEich.pdf b/fosdem2006Egbert/FOSDEM2006EgbertEich.pdf Binary files differnew file mode 100644 index 00000000..7987a1b3 --- /dev/null +++ b/fosdem2006Egbert/FOSDEM2006EgbertEich.pdf diff --git a/fosdem2006Luc.mdwn b/fosdem2006Luc.mdwn new file mode 100644 index 00000000..c426a853 --- /dev/null +++ b/fosdem2006Luc.mdwn @@ -0,0 +1,11 @@ + +Luc Verhaegen is a bedroom hacker whose focus is almost solely on modesetting, he started [[http://unichrome.sf.net/|http://unichrome.sf.net/]] and spends most of his time bashing VIA. + + +## X and modesetting, atrophy illustrated + +X had a rich and diverse modesetting history, but with the advent of 3D acceleration and DRI, modesetting suddenly received a lot less attention. Some examples of the resulting cruft are shown and some shortcomings examined. Current developments are explained and possible future directions are explored. + +Paper: [[X_and_Modesetting_-_Atrophy_illustrated_(paper).pdf|http://people.freedesktop.org/~libv/X_and_Modesetting_-_Atrophy_illustrated_(paper).pdf]] + +Slides: [[X_and_Modesetting_-_Atrophy_illustrated_(slides).pdf|http://people.freedesktop.org/~libv/X_and_Modesetting_-_Atrophy_illustrated_(slides).pdf]] diff --git a/fosdem2006Matthias.mdwn b/fosdem2006Matthias.mdwn new file mode 100644 index 00000000..e782e757 --- /dev/null +++ b/fosdem2006Matthias.mdwn @@ -0,0 +1,9 @@ + +Matthias Hopf is X.org developer working for SUSE / Novell. As his main interests include using 3D graphics, working on Xgl is a natural thing for him. + + +## Xgl - The Current Future of X + +XAA has pretty much reached the end of its productive life. One promissing successor is OpenGL, an industry standard API that could help stabilize the internal rendering interface of the Xserver. This API has been used by David Reveman to create Xgl. It enables the use of modern features like pixel shaders, and it allows for accelerating Render and Composite independent of the graphics hardware. Additionally, Xgl is a technology enabler, allowing for these neat effects that compiz is now showing. + +Slides: [[fosdem_2006_xgl.pdf|http://people.freedesktop.org/~mhopf/fosdem_2006_xgl.pdf]] diff --git a/fosdem2006Stephane.mdwn b/fosdem2006Stephane.mdwn new file mode 100644 index 00000000..6b37a5e1 --- /dev/null +++ b/fosdem2006Stephane.mdwn @@ -0,0 +1,5 @@ + + +## Towards open source 3D acceleration for nvidia cards + +In this talk, steps towards an open source driver for 3D acceleration on nvidia graphics cards are detailed. Relevant hardware features found on nvidia cards are reviewed, and a quick overview of the DRI/DRM model for 3D acceleration is given. Reverse engineering techniques for these cards are shown, along with ongoing developments. Finally, future directions for this work are given. diff --git a/fosdem2007.mdwn b/fosdem2007.mdwn new file mode 100644 index 00000000..cc638967 --- /dev/null +++ b/fosdem2007.mdwn @@ -0,0 +1,25 @@ + + +# X@FOSDEM2007 + +* Time: Saturday, **24**th and Sunday, **25**th of **February 2007**. +* Place: At **[[FOSDEM|http://www.fosdem.org/]]** in Brussels, Belgium. +* Program: available **[[on the fosdem website|http://fosdem.org/2007/schedule/devroom/xorg]]** +There will be a second X@FOSDEM this year. We have secured a [[DevRoom|DevRoom]] for the FOSDEM event, where talks and open discussion around Xorg and related technologies will happen. Attending the [[DevRoom|DevRoom]] and FOSDEM is of course free. + +Notice that there will be no [[HotHouse|HotHouse]] this year, at least I (Stephane) cannot organize it, since I'm working on friday. + +The X@FOSDEM [[DevRoom|DevRoom]] will, like last year, be a place where talks can be held, amongst other things. More generally, it's a good occasion to meet other Xorg devs ! + +Only a call for attendants and community interest was made at this point, and the results were very positive. The following persons will already be attending: Michel Daenzer, Egbert Eich, Jim Gettys, Jerome Glisse, Matthieu Herrb, Matthias Hopf, Amaury Jacquot, Lars Knoll, Stephane Marchesin, Keith Packard, Rene Rebe, Zack Rusin, Jamey Sharp, Luc Verhaegen. + +If you are also interested in visiting this event, don't hesitate to mail [[me|http://wiki.x.org/wiki/StephaneMarchesin]] or pop up on irc (#xorg-europe on freenode.net). There is no obligation to do this, but it will help organisation. + + +# Videos of Talks + +FOSDEM recorded some of the X related talks in the Desktop Applications track including: + +* [[X.Org: Projects and People - Keith Packard|http://www.youtube.com/watch?v=C5HNy_Vxr78]] +* [[AIGLX: Accelerated Indirect GLX - Kristian Høgsberg|http://www.youtube.com/watch?v=9A3R4h88sEw]] +Ogg/Theora links are available on [[http://archive.fosdem.org/2007/media/video.html|http://archive.fosdem.org/2007/media/video.html]] diff --git a/fosdem2008.mdwn b/fosdem2008.mdwn new file mode 100644 index 00000000..c20a38ae --- /dev/null +++ b/fosdem2008.mdwn @@ -0,0 +1,90 @@ + + +# X@FOSDEM2008 + +* Time: Saturday, **23**rd and Sunday, **24**th of **February 2008**. +* Place: At **[[FOSDEM 2008|http://fosdem.org/2008]]** in Brussels, Belgium. +X.org will this year have its third X@FOSDEM, meaning that X will have some events on or surrounding the FOSDEM event. We have a FOSDEM [[DevRoom|fosdem2008]] on Saturday the 23rd and Sunday the 24th. Due to limited interest and high organizational overhead, no [[HotHouse|HotHouse]] will be organized. + +The goal of X@FOSDEM is to have X developers meet, discuss and hack and X.org will have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. So FOSDEM is the perfect place to get exposed to both the Xorg developer and the Xorg user community. + +**A call for [[speakers for the Devroom|fosdem2008]] has gone out.** + + +## X@FOSDEM Schedule + + +### Friday, 22nd of February 2008: + +* 18.00+ : Those already in Brussels could meet up and share supper, and maybe head on to [[FOSDEM beerevent|http://www.fosdem.org/2008/beerevent]] afterwards. + +### Saturday, 23rd of February 2008: + +* 9.30 - 12.30: [[FOSDEM Opening talks|http://www.fosdem.org/2008]]. +* 14.00 - 19.00: [[X@FOSDEM Devroom|fosdem2008]]. +* 19.00+ : Supper somewhere in Brussels (sponsors?). + +### Sunday, 24th of February 2008: + +* 9.30 - 18.00: [[X@FOSDEM Devroom|fosdem2008]]. +* 19.00+ : Might want to meet up for supper, but nothing will be organized as people will be leaving already. + +## X@FOSDEM DevRoom + +<a name="devroom"></a> + +A **[[DevRoom|DevRoom]]** is a project/topic specific room on FOSDEM, holding up to 100 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, the FOSDEM public consists of developers and more advanced users and people interested in X.org and the topic in the [[talk scheduled|fosdem2008]] then will attend such talks. + +The [[DevRoom|DevRoom]] is free and open to everyone, there is no registration required. If the devroom is dangerously full, like during the 2006 Xgl talk, you will just be denied access :) + + +### DevRoom Speaker Schedule + +<a name="schedule"></a> + +Saturday: + +* 14.30: John Bridgman - Open sourcing ATI. +* 15.30: Egbert Eich - The RadeonHD Project. +* 16.30: Stephane Marchesin - Nouveau : Cooking an Open Source Nvidia driver. +* 17.30: To Be Announced. +Sunday: + +* 10.30: Helge Bahmann - XAudio. +* 11.00: Remi Cardona - Bringing Metisse and X.org together. +* 12.00: Daniel Stone - Fixing X input: the beer coaster roadmap to success. +* 13.00: Lunch +* 14.00: Michael Meeuwisse - Project VGA. +* 15.00: Keith Whitwell - Update on Gallium3D. +* 16.00: Jerome Glisse - Radeon, from DRM to Gallium. +* 17.00: Keith Packard - Roadmap to recovery - pain and redemption in X driver development. +The "To Be Announced" talks are slots reserved for talks not appearing in the FOSDEM brochure. Those just have not met the January 31st deadline. + + +### DevRoom Speakers + +<a name="speakers"></a> + +If you're interested in giving a talk at the X.org FOSDEM [[DevRoom|DevRoom]], then [[contact us|fosdem2008]] right away. + +* We have time for about 11 talks. +* We will require a **titel or topic**, and a **brief description** before january 31st. +* FOSDEM provides a projector and networking. If you need anything further you should probably bring this along yourself, but feel free to ask anyway :) + +## X@FOSDEM Social Event + +<a name="social"></a> + +We hope to be organizing at least 1 sponsored evening. But this is still in a highly preliminary state. + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/2008]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2007]] will be of interest. + + +## Registration and further information + +<a name="contact"></a> I still need to check whether there is life still in the old mailing lists. But feel free to just mail me, lverhaegen at suse dot de, or the xorg mailinglist, or poke us on irc in #xorg-europe on freenode.net. diff --git a/fosdem2009.mdwn b/fosdem2009.mdwn new file mode 100644 index 00000000..719312e6 --- /dev/null +++ b/fosdem2009.mdwn @@ -0,0 +1,129 @@ + + +# X.org DevRoom at FOSDEM2009 + +* Time: Saturday, **7**th and Sunday, **8**th of **February 2009**. +* Place: At **[[FOSDEM 2009|http://fosdem.org/]]** in Brussels, Belgium. +X.org will this year have its fourth X.org [[DevRoom|fosdem2009]] at FOSDEM. The goal of X.org [[DevRoom|DevRoom]] at FOSDEM is to have X developers meet, discuss and hack and X.org will have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. So FOSDEM is the perfect place to get exposed to both the X.org developer and the X.org (advanced) user community. + + +## X.org at FOSDEM Schedule + + +### Saturday, 7th of February 2009: + +* 9.30 - 12.00: [[FOSDEM Opening talks|http://www.fosdem.org/]]. +* 13.00 - 19.00: [[X.org Devroom|fosdem2009]]. + +### Sunday, 8th of February 2009: + +* 10.00 - 17.00: [[X.org Devroom|fosdem2009]]. + +## X.org DevRoom + +<a name="devroom"></a> + +A **[[DevRoom|DevRoom]]** is a project/topic specific room on FOSDEM, holding up to 100 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, the FOSDEM public consists of developers and more advanced users and people interested in X.org and the topic in the [[talk scheduled|fosdem2009]] then will attend such talks. + +The [[DevRoom|DevRoom]] is free and open to everyone, there is no registration required. If the devroom is dangerously full, like during the 2006 Xgl or the 2008 Gallium talk, you will just be denied access :) + +This year, we have room H.1309, which has a massive 150seat capacity, and the luxury of 3 breathing holes. It's the first [[DevRoom|DevRoom]] on the upper level in the main building, which was last years CentOS/Fedora [[DevRoom|DevRoom]]. + + +### DevRoom Talks Schedule + +<a name="schedule"></a> + +Saturday: + +* 13.00: +* 14.00: [[Matthias Hopf: RandR 1.3: New Features in a Nutshell.|fosdem2009]] +* 15.00: [[Keith Packard: The Rebuilt Linux Desktop.|fosdem2009]] +* 16.00: [[Stephane Marchesin: Nouveau Status Update.|fosdem2009]] +* 17.00: [[Eric Anholt: Intel's graphics projects for the coming year.|fosdem2009]] +Sunday: + +* 10.00: +* 11.00: [[Helge Bahmann: Multimedia processing extensions for the X Window System.|fosdem2009]] +* 12.00: [[Matthew Garrett: Aggressive power management in graphics hardware.|fosdem2009]] +* 13.00: +* 14.00: [[Matthias Hopf: r600_demo: Programming the New GPU Generations from AMD|fosdem2009]] +* 15.00: [[Stephane Marchesin: LLVM + Gallium 3D: Mixing a compiler with a graphics framework.|fosdem2009]] +* 16.00: [[Jerome Glisse: Shader Compiler Optimisation Strategies.|fosdem2009]] +The empty slots in this schedule will be filled up still. The [[fosdem website|http://www.fosdem.org/2009/schedule/rooms/h.1309]] also has a page with our schedule. + + +### DevRoom Talks + +<a name="hopf1"></a> +#### Matthias Hopf : RandR 1.3: New Features in a Nutshell. + +RandR 1.3 presents - amongst other things - transformations, panning, and standardized properties. This talk will show how to use these features and how they should influence tools and applications. + +<a name="packard"></a> +#### Keith Packard: The Rebuilt Linux Desktop. + +Graphics drivers under Linux have seen the most significant changes since X was first ported in the last year. The X server can now run as an unprivileged process; kernel panic messages can be displayed while graphics are active; graphics applications can use virtual memory to store GPU data. + +In the kernel, these changes include the new Graphics Execution Manager (GEM) and kernel-based video mode setting (KMS). Beyond the kernel, the second version of the Direct Rendering Interface X extension (DRI2) unifies the X and OpenGL image storage space. + +This talk will describe the kernel and user-space changes along with the other kernel changes necessary to support the new code. Finally, the audience will be encouraged to participate in a discussion about future plans in this area. + +<a name="marcheu1"></a> +#### Stephane Marchesin: Nouveau Status Update. + +Since last Fosdem, Nouveau has been making steady progress. This talk will detail some of the changes made since last year and present the newest features. Throughout this talk, I will also introduce a number of "did you know ?" slides about the project and Nvidia hardware's inner workings. + +<a name="helge"></a> +#### Helge Bahmann: Multimedia processing extensions for the X Window System. + +This talk reports on experiences gained with a set of experimental extensions for multimedia processing in the X Window System. They allow to transmit compressed images and audio through the X protocol, and provide playback synchronization capabilities within the X server. This for example to build network-transparent media players and bring multimedia to classical thin clients. + +<a name="anholt"></a> +#### Eric Anholt: Intel's graphics projects for the coming year. + +While significant progress has been made in fixing the Linux graphics architecture, there are still some sharp edges. This talk will cover Intel's plans for the coming year, including DRI2 vblank support, DRI2 page flipping, rebuilding Mesa's compiler infrastructure, pulling ideas from Gallium into core Mesa, and more. + +<a name="mjg"></a> +#### Matthew Garrett: Aggressive power management in graphics hardware. + +Computers spend a lot of time idle, and graphics cards spend a lot of time just displaying a static image. This talk presents various techniques for reducing the power consumption of graphics hardware without any significant impact on visual quality or performance. + +<a name="hopf2"></a> +#### Matthias Hopf: r600_demo: Programming the New GPU Generations from AMD + +By allowing the release of r600_demo AMD has carried out a first step of their promise to release enough information for open source DRI driver development. As the initial, to be released documentation will be very register centric there is hardly enough information about how the chips are actually working. This talk will give an overview over how the r6xx and r7xx chip families are to be programmed, and in which pit falls one might stumble. + +<a name="marcheu2"></a> +#### Stephane Marchesin: LLVM + Gallium 3D: Mixing a compiler with a graphics framework. + +With the increasing importance of shaders, it has become necessary to use advanced optimization strategies for shader compilers. This talks presents the ongoing work on integrating a compiling and optimizing framework (LLVM) with a 3D framework (Gallium 3D). We will discuss the main difficulties behind this work, the inner workings and the current developments. + +<a name="glisse"></a> +#### Jerome Glisse: Shader Compiler Optimisation Strategies. + +Different GPUs have different architectures and thus require different shader compiler optimisations for more optimal performance. This talk explains some of the differences between both AMD, Nvidia and Intel GPUs and will present some compiler algorithms to optimise shaders accordingly. + +<a name="speakers"></a> +### DevRoom Speakers + +There are still some talk slots open. If you're interested in giving a talk at our [[DevRoom|DevRoom]], then [[contact us|fosdem2009]] right away. FOSDEM provides a projector and networking. If you need anything further you should probably bring this along yourself, but feel free to ask anyway :) + + +## Social Event + +<a name="social"></a> + +We might end up at the excellent and affordable [[restaurant mirabelle|http://www2.resto.be/mirabelle/]] again. But it is too early days for that to be certain. + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2008]] will be of interest. + + +## Registration and further information + +<a name="contact"></a> Feel free to just mail me, lverhaegen at suse dot de, or the xorg mailinglist, or poke us on irc in #xorg-europe on freenode.net. diff --git a/fosdem2010.mdwn b/fosdem2010.mdwn new file mode 100644 index 00000000..00a9b50b --- /dev/null +++ b/fosdem2010.mdwn @@ -0,0 +1,93 @@ + + +# X.org DevRoom at FOSDEM2010 + +* Time: Sunday, **7**th of **February 2010**. +* Place: At **[[FOSDEM 2010|http://fosdem.org/]]** in Brussels, Belgium. +X.org will this year have its fifth X.org [[DevRoom|fosdem2010]] at FOSDEM. The goal of X.org [[DevRoom|DevRoom]] at FOSDEM is to have X developers meet, discuss and hack and X.org will have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. So FOSDEM is the perfect place to get exposed to both the X.org developer and (advanced) user community. + + +## X.org at FOSDEM Schedule + + +### Sunday, 7th of February 2010: + +* 12.00 - 17.00: [[X.org Devroom|fosdem2010]]. + +## X.org DevRoom + +<a name="devroom"></a> + +A **[[DevRoom|DevRoom]]** is a project/topic specific room on FOSDEM, holding up to 60 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, the FOSDEM public consists of developers and more advanced users and people interested in X.org and the topic in the [[talk scheduled|fosdem2010]] then will attend such talks. + +The [[DevRoom|DevRoom]] is free and open to everyone, there is no registration required. If the devroom is dangerously full, like during the 2006 Xgl or the 2008 Gallium talk, you will just be denied access :) + +Due to FOSDEMs Distribution mini-conf, we will no longer have access to the enormous room we had last year (which we used rather well). We have room [[AW.124|http://archive.fosdem.org/2009/maps/campus]], in the building across the main campus road from the main building, which has some nice luxuries like some windows for ventilation. + +On Saturday, the 6th of February, the same [[DevRoom|DevRoom]] as the X.org one will be used as the coreboot [[DevRoom|DevRoom]]. Due to limited coverage, on Sunday, from 9 until 12, the [[DevRoom|DevRoom]] will be used by the [[OpenMoko|OpenMoko]] project. + + +### DevRoom Talks Schedule + +<a name="schedule"></a> + +Sunday: + +* 9.00-12:00: [[OpenMoko|OpenMoko]] [[DevRoom|DevRoom]]. +* 12.00: [[Nicolai Hähnle : Towards GLSL in the r300 Gallium driver|fosdem2010]] +* 13.00: [[Daniel Stone : Polishing X11 and making it shiny.|fosdem2010]] +* 14.00: [[Luc Verhaegen : The free software desktop’s graphics driver stack.|fosdem2010]] +* 15.00: [[Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.|fosdem2010]] +* 16.00: [[Mikhail Gusarov : X on e-Paper.|fosdem2010]] +The [[fosdem website|http://fosdem.org/2010/schedule/rooms/aw1.124]] also has a page with our schedule. + +Once again, [[Michael Larabel from phoronix|http://phoronix.com]] will be covering this event and even produce HDTV videos this year. + + +### DevRoom Talks + +<a name="glisse"></a> +#### Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status. + +The GPU is one of the most complex piece of hardware in modern computer. With kernel modesetting, more part of the driver move from userspace to the kernel allowing a cleaner support for suspend/resume and others GPU specific handling. The complexity of OpenGL driver, and also driver for new API such as OpenCL, are in userspace and will more than likely stays there. This presentation will look at the uniq problem of GPU kernel API to userspace. How userspace can interface with the kernel to submit GPU command in an as efficient as possible way. A brief review of what have been done and what is done now for various GPU, and insight on what might be better solution in the future will be given. Last part of the presentation will devolve to the status of radeon kernel modesetting which is now the largest driver inside the linux kernel with more the 70 000 lines of code and supporting more than 7 different GPU families. + +<a name="mgusarov"></a> +#### Mikhail Gusarov : X on e-Paper. + +e-Paper is a relatively new display type with very unusual characteristics. Some of them, such as greyscale, bring back memories of the distant past, whereas others, like a 1Hz refresh rate, are completely unique. This talk will outline the special requirements that e-Paper imposes on X. + +<a name="daniels"></a> +#### Daniel Stone : Polishing X11 and making it shiny. + +There are a few niggles about X11 today that mean every embedded device vendor patches the server in various unpleasant ways, whereas on the desktop it just looks suboptimal and we suck it up. This talk will cover a few parts of X11, such as client-side cursors, the video API, Composite, RandR, which currently need to be improved to make X11 look as good as it possibly can, without going to Wayland or X12. + +<a name="libv"></a> +#### Luc Verhaegen : The free software desktop’s graphics driver stack. + +4 years after the modular X tree was released, we can clearly see that we did not fully satisfy all expectations and that we are really holding the free software desktop back. In this talk, the current situation gets analysed, and the next step, providing more integrated graphics driver stacks, a change that will make life easier for all involved, is introduced and demonstrated. + +<a name="nha"></a> +#### Nicolai Hähnle : Towards GLSL in the r300 Gallium driver + +After a very brief overview of some relevant details of the hardware-level programming interface of Radeon R300-R500 shader hardware, I explain the high-level structure of how fragment and vertex programs are compiled in the modern Gallium 3D driver and how we got there. Finally, I talk about the big remaining challenges for full GLSL support. + +This is a fairly technical, hardware-specific talk. However, it is kept (hopefully) understandable to people who haven't spent hours writing shader compilers, and there will probably be some musing about which parts of code could possibly be shared with other drivers in the future. + + +## Social Event + +<a name="social"></a> + +The social event, which was reduced to just getting a table somewhere anyway, will be decided Ad-Hoc. + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2009]] will be of interest. + + +## Registration and further information + +<a name="contact"></a> Feel free to just mail us, libv at skynet dot be and eich at suse dot de, or the xorg mailinglist, or poke us on irc in #xorg-europe on freenode.net. diff --git a/fosdem2012.mdwn b/fosdem2012.mdwn new file mode 100644 index 00000000..ce411cf3 --- /dev/null +++ b/fosdem2012.mdwn @@ -0,0 +1,80 @@ + + +# X.Org DevRoom at FOSDEM2012 + +* Time: **4th & 5th** of **February 2012**. +* Place: At **[[FOSDEM 2012|http://fosdem.org/]]** in Brussels, Belgium. +X.Org will this year have its sixth X.Org [[DevRoom|fosdem2012]] at FOSDEM. The goal of X.Org [[DevRoom|DevRoom]] at FOSDEM is to have X.Org/Mesa/Wayland and related projects' developers meet, discuss and hack and have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. So FOSDEM is the perfect place to get exposed to both other developers and the (advanced) user community. + + +## X.Org at FOSDEM Schedule + + +### Sunday, 4th of February 2012: + +* 11.00 - 19.00: [[X.Org Devroom|fosdem2012]]. + +### Sunday, 5th of February 2012: + +* 9.00 - 11.00: [[X.Org Devroom|fosdem2012]]. +* 12.00 - 17.00: [[OpenICC Devroom|http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012]]. + +## X.Org DevRoom + +<a name="devroom"></a> + +A **[[DevRoom|DevRoom]]** is a project/topic specific room on FOSDEM, holding (this time) up to 85 people. It is public but doesn't tend to draw the crowds the main FOSDEM talks tend to get. In general, the FOSDEM public consists of developers and more advanced users and people interested in X.Org/Mesa/Wayland and the topic in the [[talk scheduled|fosdem2012]] then will attend the [[DevRoom|DevRoom]]. + +This year, due to the obvious close relationship with the openICC project, we are sharing the [[DevRoom|DevRoom]] with them. Depending on both projects needs, the time available might still change in future. This is [[their wiki page|http://www.freedesktop.org/wiki/OpenIcc/Events/Fosdem/2012]] for their part of the event. + +We will have the K.3.401 room in a new building, which offers seating for up to 85 persons. + +The [[DevRoom|DevRoom]] is free and open to everyone, there is no registration required. If the devroom is dangerously full, like during the 2006 Xgl or the 2008 Gallium talk, you will just be denied access :) + + +### DevRoom Talks Schedule + +<a name="schedule"></a> + +Saturday: + +* (10.00: room setup, hopefully.) +* 11.00: [[Eric Anholt : Intel userspace.|http://fosdem.org/2012/schedule/event/intel_userspace]] +* 12.00: [[Daniel Stone and Peter Hutterer : Input in a modern world - input methods and multitouch.|http://fosdem.org/2012/schedule/event/xorg_input]] +* 13.00: [[Chris Wilson: Cairo: How to render tomorrow's user interfaces.|http://fosdem.org/2012/schedule/event/xorg_cairo]] +* 14.00: [[Daniel Vetter : dma_buf buffer sharing.|http://fosdem.org/2012/schedule/event/dma_buf]] +* 15.00: [[Martin Peres : Nouveau: Recap, on-going and future work.|http://fosdem.org/2012/schedule/event/nouveau]] +* 16.00: [[Luc Verhaegen : Liberating ARM's Mali GPU.|http://fosdem.org/2012/schedule/event/mali]] +* 17.00: [[Keith Packard : X Server 1.12 and beyond.|http://fosdem.org/2012/schedule/event/xserver]] +* 18.00: [[Francisco Jerez : Compute in the open graphics stack.|http://fosdem.org/2012/schedule/event/opencl]] +Sunday: + +* 9.00: [[Robert Bragg and Neil Roberts : Writing a Wayland Compositor.|http://fosdem.org/2012/schedule/event/wayland_compositor]] +* 10.00: [[Jesse Barnes : KMS plane support in Wayland.|http://fosdem.org/2012/schedule/event/kms_planes]] +* 11.00: [[Alon Levy: Xspice: Integrating spice-server into Xorg.|http://fosdem.org/2012/schedule/event/xorg_xspice]] +* 11.30: [[Robert Bradford and Kristian Hogsberg : Wayland Q & A for toolkit developers.|http://fosdem.org/2012/schedule/event/wayland_qa]] +* 12.00: [[Kai-Uwe Behrmann : Colour Management in Compositors.|http://fosdem.org/2012/schedule/event/cm_compositors]] +* 13.00: OpenICC [[DevRoom|DevRoom]]. +* 14.00: OpenICC [[DevRoom|DevRoom]]. +* 15.00: OpenICC [[DevRoom|DevRoom]]. +* 16.00: OpenICC [[DevRoom|DevRoom]]. +[[The full schedule is available here, including talk abstracts.|http://fosdem.org/2012/schedule/track/xorgopenicc_devroom]] + + +## Social Event + +<a name="social"></a> + +libv will probably be getting a table at the excellent "Le Mirabelle" again. If some sponsor for this turns up, great, but otherwise we just pay for ourselves as we have done the last few years. Make sure you catch libv beforehand (friday, or saturday before noon), so he can order a suitably sized table. + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2011]] will be of interest. + + +## Registration and further information + +<a name="contact"></a> Feel free to just mail libv at skynet dot be, or the [[x events mailinglist|http://lists.x.org/mailman/listinfo/events]], or poke libv on irc in #xorg-devel on freenode.net. diff --git a/fosdem2013.mdwn b/fosdem2013.mdwn new file mode 100644 index 00000000..8b2e76dc --- /dev/null +++ b/fosdem2013.mdwn @@ -0,0 +1,28 @@ + + +# X.Org DevRoom at FOSDEM2013 + +* Time: Saturday the **2nd** of **February 2013**. +* Place: At **[[FOSDEM 2013|http://fosdem.org/]]** in Brussels, Belgium. +The goal of X.Org [[DevRoom|DevRoom]] at FOSDEM is to have X.Org/Mesa/Wayland and related projects' developers meet, discuss and hack and have a very clear presence at [[one of the most highly regarded Free and Open Source community events|http://www.fosdem.org/]]. So FOSDEM is the perfect place to get exposed to both other developers and the (advanced) user community. + +Sadly the [[DevRoom|DevRoom]] is limited to only a single day this year, namely saturday. This makes scheduling kind of tight, and the massive ARM GPU driver block was partly moved to a mainline talk to relieve this scheduling tightness. + + +### DevRoom Talks Schedule + +<a name="schedule"></a> + +[[https://fosdem.org/2013/schedule/track/xorg/|https://fosdem.org/2013/schedule/track/xorg/]] + + +## Further FOSDEM information + +For more information about the FOSDEM event, there's always the [[FOSDEM website|http://www.fosdem.org/]]. It includes city maps, information about transportation and a list of hotels. + +If you would like a complete overview of FOSDEM, then maybe [[last years site|http://www.fosdem.org/2012]] will be of interest. + + +## Contact + +<a name="contact"></a> Please mail libv at skynet dot be. diff --git a/geode.mdwn b/geode.mdwn new file mode 100644 index 00000000..e69de29b --- /dev/null +++ b/geode.mdwn diff --git a/glide.mdwn b/glide.mdwn new file mode 100644 index 00000000..5fd9f3a4 --- /dev/null +++ b/glide.mdwn @@ -0,0 +1,15 @@ + + +# glide + +Driver for Glide2x (3Dfx) based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/glide.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/glint.mdwn b/glint.mdwn new file mode 100644 index 00000000..fd64d69a --- /dev/null +++ b/glint.mdwn @@ -0,0 +1,15 @@ + + +# glint + +Driver for 3Dlabs, TI based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/glint.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/i128.mdwn b/i128.mdwn new file mode 100644 index 00000000..367509e0 --- /dev/null +++ b/i128.mdwn @@ -0,0 +1,35 @@ + + +# i128 + +Driver for Number Nine based video chips. License: MIT + + +## History + +The i128 driver was initially written for XFree86 4.0 by Robin Cutshaw. Adam Jackson is the current maintainer. + +1.0.0: Base driver as of Xorg 6.8.2. + +1.1.0: Partial EXA support (Solid and Copy operations) + + +## Future plans + +* Composite hook for EXA +* DRM driver +* Xv acceleration (requires DRM support) +* Upload and Download hooks for EXA (requires DRM support) +* Smarter handling of SGI 1600SW flat panel +* DRI driver +See also the [[NumberNine page on the DRI wiki|http://dri.freedesktop.org/wiki/NumberNine]]. + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/i128.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/i128.4.html]] containing additional information about known problems and hints. + +## Known Issues + +See [[bugzilla|https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=Driver%2Fi128&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=]]. diff --git a/i740.mdwn b/i740.mdwn new file mode 100644 index 00000000..e96cb054 --- /dev/null +++ b/i740.mdwn @@ -0,0 +1,15 @@ + + +# i740 + +Driver for Intel i740 based video chips. License: MIT + + +## Documentation and Support + + * There is also a [[README file|http://xorg.freedesktop.org/archive/X11R7.0/doc/html/i740.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/imstt.mdwn b/imstt.mdwn new file mode 100644 index 00000000..9508b23f --- /dev/null +++ b/imstt.mdwn @@ -0,0 +1,14 @@ + + +# imstt + +Driver for Integrated Micro based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 00000000..75dbbfa8 --- /dev/null +++ b/index.mdwn @@ -0,0 +1,58 @@ +The X.Org project provides an open source implementation of the X Window System. The development work is being done in conjunction with the [[freedesktop.org|http://freedesktop.org]] community. The [[X.Org Foundation|XorgFoundation]] is the educational non-profit corporation whose [[Board|BoardOfDirectors]] serves this effort, and whose [[Members|Membership]] lead this work. + +The current X.Org release is [[X11R7.7|Releases/7.7]]. The next major release will be [[X11R7.8|Releases/7.8]]. Information about all [[releases|Releases]] is available. _(Important: If you have an older release, please see the [[Security page|Development/Security]] for information on security updates.)_ + +You may be interested in: + +* [[Documentation]] +* Development-related [[news|News]]. +* X.Org [[events|Events]]. +* [[Press releases|Other/Press]]. +* [[The Annual Report on the State of the X.Org Foundation|XorgFoundation/Reports/]] +* [[Related projects|RelatedProjects]]. + +## Reporting problems, asking questions and getting help + +* Check to see if your question is answered in the [[FAQ]]. +* Use the `xorg` product in the [[freedesktop bugzilla|https://bugs.freedesktop.org]] to report bugs against X.Org. ([[Gnome's bugzilla suggestions|http://bugzilla.gnome.org/]] are well worth looking over if you are new to reporting bugs with systems like bugzilla.) +* Check the [[Xorg mailing list archives|http://lists.freedesktop.org/archives/xorg/]] +* Send other questions or comments to [[the xorg mailing list|mailto:xorg@freedesktop.org]]. +* Or get help on [[XorgIRC]]. + +## Development + +* The [[DeveloperStart]] page includes information for developers along with links to per-module developer pages. + +## Mailing Lists + +On [[XorgMailingLists]] you can find a list of X-related mailing lists hosted on lists.freedesktop.org. More mailing lists on X Window System and related technologies along with subscription directions are available at [[XOrg Foundation|http://lists.x.org/]]. + + +## Getting X + +The best place to get X is from your operating system or distribution vendor. X.Org currently provides no binaries. + +There are many [[Mirrors]] from which you can download source code to the X Window System. If you would like to be a mirror, feel free to do so and add yourself to the [[Mirrors]] page. + +Development snapshots are currently on hiatus; most modules now update slowly enough that frequent snapshots aren't needed. + + +## Security + +For security advisories please check our [[SecurityPage]]. + +Please notify us of any security issues by sending mail to [[xorg_security@x.org|mailto:xorg_security@x.org]] . + + +## Sponsorship + +The X.Org Foundation welcomes sponsorship (both cash and in-kind), and tries hard to put the donations of sponsors to transparent good use. The Foundation is an extremely low-overhead all-volunteer organization. If you are interested in contributing, please see our [[SponsorshipPage|SponsorshipPage]]. + + +## Acknowledgements + +Our thanks go to [[Portland State University|http://www.pdx.edu/]] and [[Massachusetts Institute of Technology|http://web.mit.edu]] for providing the hosting of x.org/freedesktop.org, to [[Sun|http://sun.com]] and [[HP|http://hp.com]] for providing the x.org/freedesktop.org hardware, and to Sun and others who have provided generous financial sponsorship and in-kind support. + +Our thanks also go to the contributors to the X Window System technology over the years. Many of these are acknowledged in previous distribution [[release notes|http://www.x.org/X11R6.8.0/doc/RELNOTES6.html]]. + +This wiki is undergoing [[conversion]]. If you have a fd.o shell account, you can help! diff --git a/intel.mdwn b/intel.mdwn new file mode 100644 index 00000000..f20dc448 --- /dev/null +++ b/intel.mdwn @@ -0,0 +1,23 @@ + + +# intel + +Driver for Intel i8xx/i9xx based video chips. (Formerly known as _i810_.) License: MIT + + +## Documentation and Support + + * Intel's driver team maintains a web page with docs and support resources for this driver at [[http://www.intellinuxgraphics.org/|http://www.intellinuxgraphics.org/]] + * Additional information is also available on the [[IntelGraphicsDriver|IntelGraphicsDriver]] page of this wiki. + * Please check the [[manual page|http://www.x.org/releases/X11R7.7/doc/man/man4/intel.4.xhtml]] for the current release for configuration options. To see or submit real-world reports on the 3D acceleration performance of this driver, see the [[free3d.org wiki|http://www.free3d.org]] + +## Source code + + * [[Current intel source in git|http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree]] + +## Known Issues + +* Check the Freedesktop.org Bugzilla for [[intel driver bugs|https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=xorg&component=driver/intel]]. + + +### Release 6.7.0 diff --git a/libraries/libxrandr.mdwn b/libraries/libxrandr.mdwn new file mode 100644 index 00000000..ae292ba4 --- /dev/null +++ b/libraries/libxrandr.mdwn @@ -0,0 +1,38 @@ + + +# libxrandr + + * X Resize and Rotate library + +## Description: + +The RandR 1.2 extension first appeared in Xserver 1.3. It provides automatic discovery of modes (resolutions, refresh rates, ...) together with the ability to configure outputs dynamically (resize, rotate, move, ...) + + +## Dependencies: + + +## Components that depend on libXRandR: + +[[Codebase|http://cgit.freedesktop.org/xorg/lib/libXrandr/]] + +[[API (Doxygen)|http://cgit.freedesktop.org/xorg/lib/libXrandr/]] + +IRC - irc.freenode.net #xorg, #xorg-devel + +[[Mailing List|http://lists.freedesktop.org/archives/xorg/]] (Like many other X.org packages) + + +## Documentation: + +In addition to the RandR X protocol, an official configuration utility (named `xrandr`) is maintained in the [[freedesktop git repository|http://cgit.freedesktop.org/xorg/app/xrandr/]]. + +* [[Protocol specification (Docbook output)|http://www.x.org/releases/X11R7.6/doc/randrproto/randrproto.txt]] <- point to symlink 'latest' +* [[Protocol specification|http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt]] +* [[RandR 1.2 overview|http://wiki.debian.org/XStrikeForce/HowToRandR12]] from Debian +* [[X Configuration|https://wiki.ubuntu.com/X/Config]] from Ubuntu +* Documentation from Intel on setting up [[dual head|http://www.intellinuxgraphics.org/dualhead.html]] configuration with RandR 1.2 +* [[XrandR 1.2 HowTo|http://www.thinkwiki.org/wiki/Xorg_RandR_1.2]] from Think``Wiki +* [[A Newbie's Guide|http://www.phoronix.com/scan.php?page=article&item=927]] from Phoronix +* A short how-to on [[writing an X.Org driver|http://wiki.x.org/wiki/DriverDevelopment]], updated to include RandR 1.2. +Configuration: diff --git a/logo.png b/logo.png Binary files differnew file mode 100644 index 00000000..948cb77e --- /dev/null +++ b/logo.png diff --git a/mga.mdwn b/mga.mdwn new file mode 100644 index 00000000..53ea6309 --- /dev/null +++ b/mga.mdwn @@ -0,0 +1,15 @@ + + +# mga + +Driver for Matrox based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://wiki.x.org/current/doc/mga.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/neomagic.mdwn b/neomagic.mdwn new file mode 100644 index 00000000..5fc7db2e --- /dev/null +++ b/neomagic.mdwn @@ -0,0 +1,15 @@ + + +# neomagic + +Driver for [[NeoMagic|NeoMagic]] based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/neomagic.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/newport.mdwn b/newport.mdwn new file mode 100644 index 00000000..167a6bd6 --- /dev/null +++ b/newport.mdwn @@ -0,0 +1,16 @@ + + +# newport + +Driver for SGI Newport based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/newport.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/newport.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/nsc.mdwn b/nsc.mdwn new file mode 100644 index 00000000..7a61b27c --- /dev/null +++ b/nsc.mdwn @@ -0,0 +1,15 @@ + + +# nsc + +Driver for National Semiconductor based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/nsc.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/nv.mdwn b/nv.mdwn new file mode 100644 index 00000000..5a661329 --- /dev/null +++ b/nv.mdwn @@ -0,0 +1,42 @@ + +Driver for NVIDIA based video chips. License: MIT + + +## Status + +Please see [[http://people.freedesktop.org/~aplattner/nv|http://people.freedesktop.org/~aplattner/nv]] for release information. + + +## 3D Acceleration Status + +At present the nv driver has no 3D acceleration. Nvidia will not provide the hardware specifications needed to add 3D support. However, some reverse engineering has been done for the Riva, TNT, and Geforce hardware. The UtahGLX project has basic 3D acceleration support. Help is needed to port this to DRI. For details see the [[DRI Nvidia Page|http://dri.freedesktop.org/wiki/nVidia?action=highlight&value=CategoryHardware]]. A Freedesktop.org project called [[nouveau|http://nouveau.freedesktop.org/wiki/]] has been started to work on 3D support. See the project's [[Feature Matrix|http://nouveau.freedesktop.org/wiki/RequiredFunctionality]] for current development status. For additional info on 3D acceleration support in general, see the [[free3d.org wiki|http://www.free3d.org/]]. + + +## Documentation and Support + + * Please check the [[nv(4) manual page|http://www.x.org/releases/current/doc/man/man4/nv.4.xhtml]] for the current release for configuration options. + +## Source code + + * [[Released version tarballs|http://www.x.org/releases/individual/driver/]] + * [[Current nv source in git|http://cgit.freedesktop.org/xorg/driver/xf86-video-nv]] + +## Known Issues + + * Check the Freedesktop.org Bugzilla for [[nv driver bugs|https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__all__&product=xorg&content=nv]]. + +## Maintainers + + * X.org: [[Aaron Plattner|http://people.freedesktop.org/~aplattner/]] of NVIDIA + * XFree86: [[Mark Vojkovich|http://www.xfree86.org/~mvojkovi/]] of NVIDIA + +## Related Resources + + * [[Nvida Driver Internals|http://developer.nvidia.com/object/xdevconf_2006_presentations.html]] Xdevconf presentation by Andy Ritger of Nvidia + * [[XFree86 nv driver|http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/nv/]] nvidia driver CVS + * [[berliOS|http://svn.berlios.de/viewcvs/haiku/haiku/trunk/src/add-ons/accelerants/nvidia/]] nvidia driver CVS + * [[nvidia forum|http://www.nvnews.net/vbulletin/forumdisplay.php?f=14]] - Official forum for Linux nvidia users + * [[nvidia website|http://www.nvidia.com/]] + * [[NVIDIAProprietaryDriver|NVIDIAProprietaryDriver]] - X.Org Wiki page about nVidia's proprietary closed-source driver. + * [[Comparison of NVIDIA Graphics cards|http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units]] - Wikipedia page comparing NVIDIA hardware features + * [[NVIDIA and FOSS|http://en.wikipedia.org/wiki/NVIDIA_and_FOSS]] Wikipedia page on the friction between Nvidia and the Free/Open Source community due to their continued refusal to provide technical documentation on the hardware that would assist developers in writing drivers.
\ No newline at end of file diff --git a/r128.mdwn b/r128.mdwn new file mode 100644 index 00000000..2bbfea08 --- /dev/null +++ b/r128.mdwn @@ -0,0 +1,16 @@ + + +# rage128 + +Driver for ATI Rage128 based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://ftp.x.org/pub/X11R6.9.0/doc/html/r128.4.html]] for the current release for configuration options. + * There is also a [[README file|http://ftp.x.org/pub/X11R6.9.0/doc/README.r128]] containing additional information about known problems and hints. + +## Known Issues + + +## Release 6.7.0 diff --git a/radeon.mdwn b/radeon.mdwn new file mode 100644 index 00000000..720ba81e --- /dev/null +++ b/radeon.mdwn @@ -0,0 +1,89 @@ + + +# radeon + +Driver for ATI/AMD Radeon based video chips, everything from Radeon 7000 (R100) to Radeon HD 7000 (Southern Islands) series. Part of [[xf86-video-ati|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati]], ie. also known as the ”ati” driver. License: MIT + + +## Latest News + +* _30 Jan 2013_: **7.1.0**: Enable full 2D acceleration for SI (glamor), few bug fixes. <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2013-January/002154.html]] ]</small> +* _6 Nov 2012_: **7.0.0**: First KMS only release, enable 2D tiling by default on r6xx+ asics, xserver 1.13 support including prime, glamor support, SI support. <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2012-November/002093.html]] ]</small> +* _29 Jun 2012_: **6.14.6**: Few bugfixes, final release with UMS support (future releases will support only KMS) <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2012-June/001985.html]] ]</small> +* _7 Jun 2012_: **6.14.5**: Solid picture accel, tiling fixes, new PCI-IDs, 6xx-9xx Xv improvements, support for upcoming xserver API changes, bug fixes <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2012-June/001979.html]] ]</small> +* _28 Mar 2012_: **6.14.4**: Trinity APU support, 2D tiling on R6xx+, KMS tiling for r1xx-r2xx, lots of bug fixes <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2012-March/001922.html]] ]</small> +* _2 Nov 2011_: **6.14.3**: Llano APU support, KMS page flipping fixes, vdpau/XvMC support, tiling fixes <small>[ [[changelog|http://lists.x.org/archives/xorg-announce/2011-November/001750.html]] ]</small> +* _26 May 2011_: **6.14.2**: Cayman (Radeon HD 6900) acceleration support, Fusion APU tiling fixes, other fixes <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2011-May/001672.html]] ]</small> +* _17 Mar 2011_: **6.14.1**: Cayman (Radeon HD 6900) support (shadowfb, kms-only), big endian support <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2011-March/001628.html]] ]</small> +* _3 Feb 2011_: **6.14.0**: KMS EXA/Xv support for Evergreen GPUs (Radeon HD 5000 series), Fusion APUs (Ontario series) and Northern Islands GPUs (Radeon HD 6000 series but not 6900), KMS pageflipping support for all radeons <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2011-February/001602.html]] ]</small> +Latest changes in the development tree can be seen at: [[http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]] + + +## Status + +See [[RadeonFeature|RadeonFeature]] and [[RadeonProgram|RadeonProgram]] for driver feature and supported program lists. For more 3D information see [[Radeon 3D acceleration Portal|http://dri.freedesktop.org/wiki/Radeon]]. + + +## What about other drivers? + +For an alternative R500/R600/R700 driver see [[radeonhd|radeonhd]]. Radeon has some features not available in radeonhd and vice versa, but generally they are starting to be quite close while radeon supports all the cards and radeonhd only r5xx-r7xx. + +The differences between radeon and radeonhd with r5xx-r7xx series: + +* radeon supports the kernel mode-setting (KMS) +* radeon supports tear-free video playback +* radeon supports TV-out +* (radeonhd was for long the one with HDMI audio support, but 2.6.33 kernel now has HDMI audio support for ati as well) +The reasons for two different drivers are historical, and starting to be a thing of the past as all the new DRM (direct rendering manager), 3D and KMS (kernel mode setting) work is done in a single place. radeonhd driver is abandoned and unsupported. Please use radeon. + +For R6xx and above there is also an [[ATIProprietaryDriver|ATIProprietaryDriver]] available, which is worse in many aspects but has better 3D performance and features. The proprietary driver included support for R3xx-R5xx GPUs until the March 2009 release. + + +## Documentation and Support + +Build instruction can be found from [[radeonBuildHowTo|radeonBuildHowTo]] + +Please check the included manual page (old version [[here|http://ftp.x.org/pub/X11R7.0/doc/html/radeon.4.html]]) for configuration options. To see or submit real-world reports on the 3D acceleration performance of this driver, see the [[free3d.org wiki|http://www.free3d.org]] + +There is an IRC channel #radeon on irc.freenode.net for radeon users and developers. + +* Note: You will need to have a registered nickname on freenode to chat in the channel. /msg nickserv register <pass> <email> or /msg nickserv identify <pass> +[[Submit|https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/Radeon]] a bug report. [[View|https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=xorg&component=Driver/Radeon]] open bugs. + +Development mailing lists are: + +[[http://lists.x.org/mailman/listinfo/xorg-driver-ati|http://lists.x.org/mailman/listinfo/xorg-driver-ati]] - for the ati/radeon driver + +[[http://lists.freedesktop.org/mailman/listinfo/xorg|http://lists.freedesktop.org/mailman/listinfo/xorg]] - for general Xorg development + +[[http://lists.freedesktop.org/mailman/listinfo/mesa-dev|http://lists.freedesktop.org/mailman/listinfo/mesa-dev]] - Mesa / 3D support development. + + +### TV Out Support + +Please check [[radeonTV|radeonTV]] for information about TV out support. + + +### Dual-head Support + +See the [[XRandR 1.2 documentation|http://wiki.x.org/wiki/Projects/XRandR]] for how to set up multiple monitors. + + +## Known Issues + + +## History + +(moved from Latest News) + +* _6 Jul 2010_: **6.13.1**: server 1.9 support, evergreen accel disabled explicitly, kms uevent + sync support, rn50 fixes, enable color tiling on kms on r300->r500, xv cleanup and large vertex number fixes <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2010-July/016250.html]] ]</small> +* _15 Mar 2010_: **6.12.192**: **6.13.0rc2**: Mostly bug fixes. The r6xx/r7xx domain fix improves KMS EXA DFS (and hence [[GetImage|GetImage]]) performance significantly. <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2010-March/014354.html]] ]</small> +* _15 Mar 2010_: **6.12.6**: bug fix release. <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2010-March/014353.html]] ]</small> +* _2 Mar 2010_: **6.12.191**: pre-release for the upcoming 6.13 release: KMS/DRI2 support, support for new hardware, basic power management, Displayport. <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2010-March/001265.html]] ]</small> +* _2 Mar 2010_: **6.12.5**: bug fix release. <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2010-March/001264.html]] ]</small> +* _10 Sep 2009_: **6.12.4**: brown paper bag release for X.org 7.5. <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001033.html]] ]</small> +* _9 Sep 2009_: **6.12.3**: bug fixes backported from master, along with PCI IDs for some new hardware. <small>[ [[changelog|http://lists.freedesktop.org/archives/xorg-announce/2009-September/001026.html]] ]</small> +* _17 Apr 2009_: AMD [[releases|http://lists.x.org/archives/xorg-driver-ati/2009-April/009362.html]] initial code branches for 3D support on R6xx/R7xx (see more below) +* _8 Apr 2009_: **6.12.2**: Bug fixes, and r2xx/r3xx textured video improvements. <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2009-April/009192.html]] ]</small> +* _18 Mar 2009_: **6.12.1**: Bug fixes for R6xx/R7xx, and avivo load detection fix. <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2009-March/008952.html]] ]</small> +* _13 Mar 2009_: **6.12.0**: EXA and Xvideo support for R6xx/R7xx series, and bug fixes. <small>[ [[changelog|http://lists.x.org/archives/xorg-driver-ati/2009-March/008886.html]] ]</small>
\ No newline at end of file diff --git a/radeon/package.zip b/radeon/package.zip Binary files differnew file mode 100644 index 00000000..d73897b9 --- /dev/null +++ b/radeon/package.zip diff --git a/radeon:r6xx_r7xx_branch.mdwn b/radeon:r6xx_r7xx_branch.mdwn new file mode 100644 index 00000000..1f28562d --- /dev/null +++ b/radeon:r6xx_r7xx_branch.mdwn @@ -0,0 +1,34 @@ + + +# r6xx-r7xx-branch + +Here are some instructions in order to try out the experimental branch of the kernel drm driver together with a new [[radeon|radeon]] (also know as ati) X.org driver which utilizes it. The alternative driver, [[radeonhd|radeonhd]], can also [[utilize|radeonhd:r6xx_r7xx_branch]] the same drm branch for the same features. + +The kernel drm driver should currently provide EXA acceleration and Xv acceleration for all Radeon HD 2000 - HD 4000 series. + + +## How to build + +The driver is supported automatically in Linux kernel 2.6.30 and newer, in which case the instructions on this page are not needed. Support is also backported to Fedora 11 and Ubuntu 9.04 which have older kernels. + +* Make sure you use 6.12.0 or newer version of the [[radeon|radeon]] (xf86-video-ati) driver (newest [[6.12.2|http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.12.2.tar.bz2]]). The R6xx-R7xx support was merged to xf86-video-ati master on Feb 26th, 2009. +* checkout the source for the drm: + +[[!format txt """ + git clone git://anongit.freedesktop.org/mesa/drm +"""]] +* switch drm to the experimental branch and build its modules: + +[[!format txt """ + git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support +"""]] +* build the drm modules : + +[[!format txt """ + cd drm/linux-core + make radeon.o drm.o + sudo cp radeon.ko drm.ko /lib/modules/YOUR_KERNEL_VERSION/kernel/drivers/char/drm/ +"""]] +This last path will likely depend upon your linux distribution. + +* EXA acceleration and XVideo support should now be enabled by default.
\ No newline at end of file diff --git a/radeonBuildHowTo.mdwn b/radeonBuildHowTo.mdwn new file mode 100644 index 00000000..18bcc779 --- /dev/null +++ b/radeonBuildHowTo.mdwn @@ -0,0 +1,563 @@ + +[[!toc ]] + + +# Building new version from git + +It is possible to compile either stable or development version of [[radeon|radeon]] from git. + +Changes to stable branch should be upgraded by distribution packages but in practice distributions don't follow the stable branch for released versions. If your distribution has failed to upgrade to the latest stable version you might get better stability by compiling new version from branch that matches your distribution version. + +Development branch (master) is for bleeding edge development where you might get regression but also better performance and features. But if you decide that new features are worth the possible regression and bugs that happen in development you are more than welcome to upgrade to the latest code base. It is good idea to join our irc channel #radeon@freenode to get help for possible problems in bleeding edge code. + + +## Stable branch + + +### xf86-video-ati (ddx) + +Upgrading to the latest bug fix code is simple because you don't have to upgrade only driver packages. First it is good idea to upgrade xf86-video-ati that provide 2D and mode setting code for xserver. You will need to clone the git repository from anongit.freedesktop.org. + + +[[!format txt """ +git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati +"""]] +Now you have cloned the git repository but code that was checked out is master branch which includes the bleeding edge code changes. Sometimes development is done in another specific GIT branch, you can check remote branches via: + + +[[!format txt """ +git branch -r +"""]] +You can easily switch to other branches (here: cayman_accel) or back to the master branch: +[[!format txt """ +git checkout -b cayman_accel origin/cayman_accel +git checkout master +"""]] +Now you have to solve build dependencies for the driver. Your package manager should have easy functionality for installing all the necessary packages. But for example there is: + + +[[!format txt """ +apt-get build-dep xserver-xorg-video-ati (Debian/Ubuntu) +yum-builddep xorg-x11-drv-ati (Fedora) +"""]] +Now you have to configure and build the code like any other program. It is good practice to install driver without overwriting files installed by package manager. This can be done using few configuration option. We want to install driver to a clean place where it is easy to remove in case you want to get rid of it. +[[!format txt """ +./autogen.sh --prefix=/opt/xorg +make +sudo make install +"""]] +Then you need to add configuration instruct xserver to load your self compiled driver. Adding following lines to xorg.conf will do the trick. +[[!format txt """ +Section "Files" + ModulePath "/opt/xorg/lib/xorg/modules,/usr/lib/xorg/modules" +EndSection +"""]] +Now restart your xserver and have fun with new bug fixes :) + + +### Mesa3D + +The Mesa3D library provides OpenGL with software and hardware rendering. There are also more libraries related to hardware accelerated graphics. Installing mesa to a location outside /usr is a bit more tricky. Problem here is that it is hard to make AIGLX load the dri driver from a non-system location. + +There are multiple stable threads depending on your distribution so you should check your mesa version and renderer with **glxinfo** command. +[[!format txt """ +glxinfo | grep ^OpenGL | egrep 'version|renderer' +OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2 +OpenGL version string: 1.3 Mesa 7.11.1 +"""]] +Checkout mesa from GIT master branch ("clone" the entire repository): +[[!format txt """ +git clone git://anongit.freedesktop.org/mesa/mesa + +cd mesa <--- Your local "copy" (your local GIT repository) +"""]] +Branches were named mesa_X_Y_branch where X is major and Y minor number (nomenclature changed with creation of 7.8 GIT branch). Switch to a specific GIT branch (here: 7.11): +[[!format txt """ +git checkout -b 7.11 origin/7.11 +"""]] +To see all GIT branches available, run 'git branch -r' within local GIT repository/branch. + +Now you need again build dependencies which you should install for package libgl1-mesa-dri (See the example above). After you have installed all build dependencies we have to configure, build and install mesa. Prefix is again /opt/xorg for easy clean up if something goes wrong. You can of course use what ever you prefer. Example case enables all ATI drivers, but you would only need radeon, one of the specific drivers for your own card (r200, r300 or r600) and swrast for software fall back in case of problems with DRI or Gallium driver. + + +[[!format txt """ +DRI_DRIVERS="radeon,r200" +GALLIUM_DRIVERS="r300,r600,swrast" +./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --with-gallium-drivers=$GALLIUM_DRIVERS +make +sudo make install +"""]] +HINT: Software rasterizer (swrast) dri driver is used as fallback solution. + +**Remember to read the instruction how to configure loading of new driver** + + +## Configuring system to load mesa and libdrm from /opt/xorg + +Now comes the tricky part because you have to configure your system to load correct libraries when any application tries to load them. You have to configure ld to load first from /opt/xorg/lib so custom mesa libraries are loaded. Another tricky part is to load dri driver which requires environment variable set to point to /opt/xorg/lib/dri. + +/etc/ld.so.conf.d/a-local-xorg.conf (new file) or add to begin of /etc/ld.so.conf if directory doesn't exists. +[[!format txt """ +/opt/xorg/lib +"""]] +and to /etc/environment you need to add new environment variable that tells libgl where to look for dri drivers (example r300_dri.so) +[[!format txt """ +LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/ +"""]] +After changes to the files you have to run **ldconfig** as root to update the linker cache. + +You can now test new dri driver in a terminal if you export **LIBGL_DRIVERS_PATH**. If everything works you can now restart to load new settings for all applications. + +Problem with this configuration is that AIGLX doesn't respect it. This means that compiz doesn't get advantage of new driver. + +It is possible to get the new libGL and dri drivers used without setting LIBGL_DRIVERS_PATH: + +* you need to build mesa with --with-dri-driverdir=/opt/xorg/lib/dri/ (or --with-dri-driverdir=/opt/xorg/lib/dri/ for 32-bit) +* check that /opt/xorg takes precedence: + +[[!format txt """ +ldconfig -p | grep libGL.so + libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so.1 + libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1 + libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so +"""]] +* if system's libGL takes precedence it might be due to OS ABI, in that case build mesa with --enable-glx-tls + +## Before GettingStarted: Avoid known pitfalls + +Distribution packages have often extra patches applied which might break compatibility with git sources. In that case you would have to get distro patches and apply them on top of source from git. +### Checking for hardware 3D acceleration + +glxinfo will give details about OpenGL rendering. Old fashioned guides for checking "direct rendering: Yes" are long outdated because swrast software rasterizer can do direct rendering. +[[!format txt """ +glxinfo | grep OpenGL +"""]] +Important part of output is renderer string that should read Mesa DRI <dri driver> <details> +[[!format txt """ +OpenGL renderer string: Mesa DRI R200 (RV280 5C61) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2 +"""]] +While software will output: +[[!format txt """ +OpenGL renderer string: Software Rasterizer +"""]] + +### Removing AMD/ATI proprietary Linux display driver + +You have to first remove fglrx because it overwrites our userspace files and conflicts with our kernel modules. Maybe some day drivers can coexists but not yet :/ + +First remove all fglrx packages and check that fglrx.ko is not left in /lib/modules/`uname -r`. If it is there you can just rm it and do depmod -a. + +Next step is to reinstall mesa and libdrm. Which should be handled easily by your package manager or make install. + +Last but not least is removing fglrx configurations from xorg.conf. With xserver 1.6 or higher you can just rename xorg.conf and trust the auto detect to do the right things. + +Now you can reboot to clean system when open driver can function correctly. + +For Debian systems: +[[!format txt """ +apt-get update +apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri <--- libGL.so + mesa3d DRI drivers +"""]] +**WARNING:** The proprietary drivers from AMD/ATI and nVidia are known to overwrite Xserver extensions, for example GLX extension (libglx.so)! +[[!format txt """ +apt-get install --reinstall xserver-xorg-core <--- libglx.so of xserver +"""]] + +## Updating git tree + +Updating git repository has two phases. First part is downloading changes and updating the history data for git. Second part is updating your local branch to match remote changes. +[[!format txt """ +git fetch && git rebase origin +"""]] +If you have any build problems after updating your source code run **make clean and autogen.sh**. + + +## Removing self compiled driver + +If you at any reason want to get rid of your self compiled driver it is simple as removing the configuration option from xorg.conf, /etc/ld.so.conf.d/ and environment. Then you can just restart computer and you are back at using the driver from package manager. + +Removing the extra libraries is also easy with rm -r /opt/xorg. + + +## Bleeding edge code from development branch + +You will most likely have to upgrade a lot of stuff depending on how fresh your distro is. But minimum requirement is to have the latest xserver from the latest stable branch, latest stable kernel (some features might be only in rc kernels), libdrm master, mesa master and xf86-video-ati master. + +Compiling and configuration is similar to stable branch with few exceptions. + +* You may have to configure libdrm with --enable-radeon-experimental-api (If your distribution enables it or you want to use KMS) +* create /opt/xorg/share/aclocal +* libdrm [[http://cgit.freedesktop.org/mesa/drm/|http://cgit.freedesktop.org/mesa/drm/]] has to be build and installed before mesa or ddx +* You will need extra environment variables so configure script will find all self compiled dependencies + +[[!format txt """ +export PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig:/opt/xorg/share/pkgconfig +export LDFLAGS=-L/opt/xorg/lib CPPFLAGS=-I/opt/xorg/include +export ACLOCAL="/usr/bin/aclocal -I /opt/xorg/share/aclocal" +"""]] +**UPDATE: With libdrm >= 2.4.18 libdrm_radeon is built by default, now** (configure-option --enable-radeon-experimental-api is obsolete). + +[1] See commit 520c658706aa896d64f374cc74065394111f6122 [["radeon: enable by default now that kms is out of staging"|http://cgit.freedesktop.org/mesa/drm/commit/?id=520c658706aa896d64f374cc74065394111f6122]]. + + +### Distro-specific development packages + +Some distributions provide easy way to install development version of all required packages from single source. This makes beta testing a lot easier when you can get fresh packages without recompiling everything. + +* Ubuntu: xorg-edgers provides good packages nearly daily. [[https://launchpad.net/~xorg-edgers/+archive/ppa|https://launchpad.net/~xorg-edgers/+archive/ppa]] +* Debian: Brice Goglin provided packages with KMS and DRI2 support in experimental branch, see his blog [["Debian/X.org notes - Radeon KMS and DRI2 in experimental"|http://bgoglin.livejournal.com/19346.html]]. + +## Kernel-based ModeSetting + +Kernel-based [[ModeSetting|ModeSetting]] (short: KMS) moves a lot of graphics card control logic to kernel which makes it possible to write more advanced 3D and 2D drivers. Kernel side mode setting improves VT switching and provides full resolution console. + +KMS also moves DRI infrastructure to version 2 which will provide better performance for 3D drivers in future. But as always is case in large rewrite of basic infrastructure performance will go down at first because of missing features and not optimized code. + +Current features in kernel side are + +* Mode setting +* Memory management +* Scheduling access to graphics card +After mode setting and memory management part has been finished there will be work to make dynamic power management work. + + +### Prerequisites for radeon-KMS + +For a better understanding of the correlation of all involved software components please have a closer look at Yang "yangman" Zhao's blog-article: [["Linux Graphics Driver Stack Explained"|http://yangman.ca/blog/2009/10/15/linux-graphics-driver-stack-explained/]]. + +Basic and minimum requirements and recommendations (Update from 15-Apr-2012): + +* **Linux-kernel** r100-r500 >=2.6.32 | r600/r700 >=2.6.33 | evergreen >=2.6.34 (initial support) | latest-3.0: 3.0.28 | latest-3.2: 3.2.15 | latest-stable: 3.3.2 +* **libdrm** >=2.4.18 (minimum) | latest-stable: 2.4.33 +* **mesa** r100-r500 >=7.7.x | r600/r700 >=7.8.x | latest-7.11: 7.11.2 | latest-8.0: 8.0.2 +* **ddx (aka xf86-video-ati)** >=6.13.x | latest-stable: 6.14.4 +* **xorg-server** >=1.6.2 (minimum) | preferred >=1.7.x | latest-1.10: 1.10.6 | latest-1.11: 1.11.4 | latest-1.12: 1.12.1 +NOTE-1: With Linux-2.6.33-rc6-git1 drm-radeon-kms has left staging driver area, see commit [["drm/radeon/kms: move radeon KMS on/off switch out of staging."|http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f71d0187987e691516cd10c2702f002c0e2f0edc]]. + +NOTE-2: For r600+ (r600 and higher) you might need [[extra firmware|radeonBuildHowTo]]. + +NOTE-3a: Initial evergreen 3D-acceleration support: For DDX see commit [["Merge branch 'evergreen_accel' of git+ssh://git.freedesktop.org/git/xorg/driver/xf86-video-ati"|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=be8f45cbd313b68ad663f303c64edb4525b8f981]] and for Mesa see commit [["r600g: add initial evergreen support"|http://cgit.freedesktop.org/mesa/mesa/commit/?id=50526e094f4c66957c7f74c190c35903bc82fb62]] + +NOTE-3b: Evergreen 3D-acceleration: Recommended: Linux-kernel >=2.6.38 + xf86-video-ati >=6.14.1 + mesa >=7.10.2 (r600 classic and gallium have 3D-acceleration whereas r600g is these days preferred) + +NOTE-4: Linux v2.6.32.y and v3.0.y kernels have longterm support (LTS). + +NOTE-5: Linux v3.2.y kernels will be shipped with upcoming Ubuntu 12.04 (LTS) and Debian wheezy (and maintained by Ubuntu/Debian kernel-teams). + +NOTE-6: Experimental Trinity (TN) APU support: Linux-kernel >=3.4-rc1, latest-stable libdrm + ddx and mesa from Git master. + + +### Important Linux kernel config parameters to enable radeon-KMS + + +[[!format txt """ +CONFIG_DRM_RADEON=m +CONFIG_DRM_RADEON_KMS=y +CONFIG_FRAMEBUFFER_CONSOLE=y +# CONFIG_FB_RADEON is not set +"""]] +NOTE-1: A radeon kernel-module gives more flexibility (e.g. debug), for built-in solution change CONFIG_DRM_RADEON from "=m" to "=y". + +NOTE-2: Disable old radeon framebuffer device, new is usage of kernel framebuffer device (fbcon) and radeondrmfb driver. + + +### Packages to solve build dependencies + +Unfortunately, it highly depends on your distribution on having all required development packages and libraries installed. + + +#### Solve build-deps using package-manager + +The best (first) strategy is to solve the build dependencies using the distribution's package-manager. + +For Debian distribution this would be: +[[!format txt """ +apt-get build-dep libdrm <--- Userspace interface to kernel DRM services (development files, radeon-specific, etc.) +apt-get build-dep mesa <--- A free implementation of the OpenGL API (DRI modules, GLX runtime, GLX development files, etc.) +apt-get build-dep xserver-xorg-video-ati <--- X.Org X server -- AMD/ATI display driver +apt-get build-dep xorg-server <--- Xorg X server (core server, development files, etc.) +"""]] +Anyway, this might work or not. If the packages in the distribution's repository are too old, consult first your distro's support for help. + +Other solutions that might help: For example in Debian there exists also an experimental distribution repository with latest software. In the worst case... There could be new stuff in the distro's own SCM (GIT or SVN) repositories, where you have to checkout and build by yourself. + + +#### Solve build-deps manually + +That is really hard to say... It mostly depends on the freshness of your distribution and its included packages. + +Here, the strategy would be to look into the configure* and Makefile* scripts and/or to start compiling each package and check for error-messages. This is *no* fun. + +To make it a bit easier, we have a look into the build-order and into the build.sh script from xorg-devel (see [1]): + +1. macros +1. protos +1. libdrm (*before* ddx and mesa) +1. ddx (aka xf86-video-ati) +1. (mesa) <--- Optional, only if you want 3D-acceleration +1. xserver +Again, within the diverse GIT repos there are explicitly depends on other development packages and/or libraries. You have to solve them first! Easiest way would be to check out and build via the recommended script from [1]. As GIT software is mostly Work-In-Progress, you might ran into other problems. A good orientation if the diverse components do build from GIT together is to look at the so-called "tinderbox" [2] (build failures are listed). + +Another *rough* way is to check out from GIT and create missing packages in the distro's format (deb, rpm or whatever). + +Please, also have a closer look at "[[ModularDevelopersGuide|ModularDevelopersGuide]] - The X.Org Modular Tree Developer's Guide" [3]. + +[1] [[http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh|http://cgit.freedesktop.org/xorg/util/modular/tree/build.sh]] + +[2] [[http://tinderbox.x.org/|http://tinderbox.x.org/]] + +[3] [[http://wiki.x.org/wiki/ModularDevelopersGuide|http://wiki.x.org/wiki/ModularDevelopersGuide]] + + +### Experimental patches and development repositories + +The kernel-related DRM development flow in Dave Airlie's linux GIT repository [1]. + +[1] [[http://cgit.freedesktop.org/~airlied/linux|http://cgit.freedesktop.org/~airlied/linux]] + + +#### List of active GIT branches in DRM kernel repository + +Dave Airlie gives an overview over all the drm-related development GIT branches in his email [["drm git branches revisited"|http://article.gmane.org/gmane.comp.video.dri.devel/40626]] to dri-devel mailing-list. + +Dave decided to move to freedesktop GIT platform after <kernel.org> suffered a [[security breach|https://www.linuxfoundation.org/news-media/blogs/browse/2011/08/cracking-kernelorg]]. + + +#### drm-next experimental branch + +Especially drm-next GIT branch has the latest (experimental) stuff for radeon users. + +Checkout drm-next GIT branch: +[[!format txt """ +git clone git://people.freedesktop.org/~airlied/linux +cd linux +git checkout -b drm-next origin/drm-next +"""]] +How to build kernel is not part of this guide because it is distribution specific. You should check your distribution documentations for guidance. + +To be in "sync" with this experimental kernel, it is also recommended to have libdrm, mesa and ddx from GIT master. + + +#### Additional patches for reviewing and testing + +Patches are sent to dri-devel and mesa3d-dev mailing-list (see [1] and [2]), before they are acknowledged and accepted in the diverse GIT branches. + +[1] [[http://lists.freedesktop.org/archives/dri-devel/|http://lists.freedesktop.org/archives/dri-devel/]] [2] [[http://lists.freedesktop.org/archives/mesa-dev/|http://lists.freedesktop.org/archives/mesa-dev/]] + + +# Troubleshooting + + +## radeon-KMS issues + + +### Module for frame buffer console + +First of all check that you **don't** load _radeonfb_, _uvesafb_ or _vesafb_ module. This includes no vga parameters for kernel when using KMS. Console is provided by **fbcon** and **radeondrmfb** frame buffer console. So it is best to make sure that fbcon module is loaded. + + +### Hints to dig deeper into radeon-KMS problems on startup + +If you can't boot with KMS enabled the easiest way to debug problems is to boot into runlevel-3 (text console, VT) with KMS disabled or blacklist the radeon kernel-module. Then try to unload/load drm and radeon kernel-modules via modprobe commands (preferable over ssh and from a second machine). + +Booted into runlevel-3 (grub-line: Append "radeon.modeset=0" means KMS disabled): +[[!format txt """ +modprobe -r -v drm radeon <--- Unload drm and radeon kernel-module (-r: remove, -v: verbose) +modprobe -v drm debug=1 <--- Additional for debugging DRM issues (maximum debug-level is 15) +modprobe -v radeon modeset=1 <--- Load radeon kernel-module with KMS support +"""]] +NOTE-1: Depending on your distribution you have to use "radeon.modeset=0,1" (0: KMS disabled, 1: KMS enabled) or "nomodeset" and "modeset=1". + +NOTE-2: Some distributions like Debian have no runlevel-3 defined, so blacklist the radeon kernel-module (or disable the start of graphical login-manager like kdm or gdm). + + +### Check if radeon-KMS is enabled before X is started + +First, make sure the radeon kernel-module is loaded with KMS enabled before X is started. + +There are several possibilities to enable drm-radeon-kms on startup: + + +#### Append parameter to boot-menue + +Append "radeon.modeset=1" as a parameter to grub/grub2 line (so called "Kernel command line"). + + +#### Add to grub2 configuration + +Use /etc/default/grub for this (edit file or run the echo-line below), followed by a renew of /boot/grub/grub.cfg (entries for boot-menue) via 'update-grub' command. +[[!format txt """ +echo 'GRUB_CMDLINE_LINUX="radeon.modeset=1"' >> /etc/default/grub <--- or edit the file and change manually +update-grub +"""]] + +#### Activate via radeon.conf in /etc/modprobe.d directory + +A good place to put persistent parameters for kernel-modules in general is /etc/modprobe.d directory, for radeon kernel-module use /etc/modprobe.d/radeon.conf. +[[!format txt """ +cat /etc/modprobe.d/radeon-kms.conf +options radeon modeset=1 +"""]] +When KMS is *not* enabled before X is started, you might see the following error in your Xorg.log file (thanks TMM for providing a paste on IRC): +[[!format txt """ +(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. +[dri] This chipset requires a kernel module version of 1.17.0, +[dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel. +[dri] If using kernel modesetting, make sure your module is +[dri] loaded prior to starting X, and that this driver was built +[dri] with support for KMS. +[dri] Disabling DRI +"""]] + +### radeon-KMS with AGP gfxcards + +AGP gfxcards have a lot of problems so if you have one it is good idea to test PCI/PCIE mode using **radeon.agpmode=-1**. Another common solution to agp problems is disabling accelerated download from screen. You can see details with **man exa** how to do this. + + +### Missing firmware + +This is not a KMS problem, but people often report X does *not* start (thus it's included in the troubleshooting list). The real cause for this is the drm cannot find a missing radeon firmware (or microcode). This depends on the Linux-kernel version you use. To fix this issue simply install the package containing the radeon firmware files or consult your distribution's support. + + +[[!format txt """ +dmesg | egrep -i 'firmware|microcode' +"""]] + +### Check if your ddx and mesa-dri driver have KMS support + +Your xf86-video-ati video-driver for X (the "DDX", 2D) doesn't have support for KMS? NO, then you have to rebuild it against libdrm_radeon library. + +As a consequence this also means that you have to **rebuild mesa** against same new libdrm. Mesa-dri drivers (3D, accelerated) don't have KMS support without built against libdrm_radeon either. + +Furthermore, check if you have fitting components of the Linux graphics driver stack. + + +[[!format txt """ +sudo lsof | grep ^Xorg | egrep '_drv.so|_dri.so' | egrep 'radeon|r?00' +Xorg 19919 root mem REG 8,2 13107136 302055 /usr/lib/dri/r300_dri.so +Xorg 19919 root mem REG 8,2 1000892 554894 /usr/lib/xorg/modules/drivers/radeon_drv.so + +sudo egrep '_drv.so|_dri.so' /var/log/Xorg.0.log | egrep 'radeon|r?00' +(II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so +(II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so + +sudo ldd /usr/lib/dri/r?00_dri.so | grep radeon + libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb7447000) + +sudo ldd /usr/lib/xorg/modules/drivers/radeon_drv.so | grep radeon + libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb75da000) +"""]] +The output of ldd commands should clearly indicate a link to libdrm_radeon. + + +## Missing Extra Firmware + +All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files [1] to work properly with acceleration (Thanks agd5f for clarification on IRC). According to license issues [2] and the fact that no new firmware files will be shipped in upstream kernels, you need to activate the following kernel-config parameters: + + +[[!format txt """ +CONFIG_FIRMWARE_IN_KERNEL=y +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" +CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/R600_rlc.bin radeon/R700_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin" +"""]] +You can omit those firmware files for which you do not actually have hardware. Copy *.bin to /lib/firmware/radeon directory. + +UPDATE: Extra ucode files are now in linux-firmware GIT repository [3] (Thanks airlied for information on IRC). + +[1] [[http://people.freedesktop.org/~agd5f/radeon_ucode/|http://people.freedesktop.org/~agd5f/radeon_ucode/]] + +[2] [[http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon|http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon]] + +[3] See commit d9076a54d74e371a11e1206b4a26e2e428045b9e [["radeon: add RLC firmwares from AMD."|http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=d9076a54d74e371a11e1206b4a26e2e428045b9e]] + + +## Use 32-bit GL applications on 64-bit systems + +32-bit applications (such as wine) will need a 32-bit libGL and mesa dri drivers. If you've only built the 64-bit libraries, your 32-bit apps may still be using the distro provided 32-bit libGL and dri (if you have already installed them), which will probably just result in slowness and wrong image being displayed. + +To make 32-bit apps use the new driver (the examples below show 64-bit libs installed in /lib (Debian), your distro may install to /lib64 instead (Fedora and others): + +* build libdrm from git (here for Debian 64-bit, Info: The original libdrm libs from ia32-libs package will be replaced): + +[[!format txt """ +./autogen.sh --prefix=/usr --libdir=/usr/lib32 CFLAGS="-m32 -O2 -g" +"""]] +* build mesa as 32-bit: + +[[!format txt """ +DRI_DRIVERS="radeon,r200,r300,r600,swrast" +DRI_DRIVER_DIR="/opt/xorg/lib32/dri" +./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --with-dri-driverdir=$DRI_DRIVER_DIR --enable-32-bit --libdir=/opt/xorg/lib32 --disable-gallium --enable-glx-tls +make +sudo make install +"""]] +* Run ldconfig to update dynamic linker run-time bindings: + +[[!format txt """ +sudo ldconfig +"""]] +* Check that the desired libGL is used - libGL from /opt/xorg should be first in all cases: + +[[!format txt """ +sudo ldconfig -p | grep libGL.so + libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so.1 + libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1 + libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /opt/xorg/lib32/libGL.so.1 + libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so.1 + libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so + libGL.so (libc6, OS ABI: Linux 2.4.20) => /opt/xorg/lib32/libGL.so + libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so +"""]] +* Check that the new 32-bit (mesa) dri driver is loaded: + +[[!format txt """ +$mesa32-builddir/progs/xdemos/glxinfo | grep OpenGL +OpenGL vendor string: Advanced Micro Devices, Inc. +OpenGL renderer string: Mesa DRI R600 (RV730 9498) 20090101 x86/MMX/SSE2 TCL DRI2 +OpenGL version string: 2.0 Mesa 7.8-devel +OpenGL shading language version string: 1.10 +OpenGL extensions: +"""]] + +## radeon-KMS power-management + +Linux-kernel >=2.6.35 has now power-management code for radeon gfxcards R100-R700 (see [1]). + +NOTE: Linux-kernel(s) from upstream or drm-next GIT branch might have better support (WIP). + + +### Change power-management method + +There exist two basic power-management (short: PM) methods "dynpm" and "profile" set via sysfs: +[[!format txt """ +echo "dynpm" > /sys/class/drm/card0/device/power_method +or +echo "profile" > /sys/class/drm/card0/device/power_method + +cat /sys/class/drm/card0/device/power_method +profile +"""]] +The "profile" method exposes 4 profiles that can be selected from: 1. "default" 2. "auto" 3. "low" 4. "high" In the meantime there has been a 5th "mid" profile introduced (see [2]). + +How to get/select the PM profile method? +[[!format txt """ +cat /sys/class/drm/card0/device/power_profile +default +echo "low" > /sys/class/drm/card0/device/power_profile +"""]] +WARNING: !!! the low power management setting does not work properly with displays active on some laptops !!! + +NOTE: See also [[KMS Power Management Options|http://wiki.x.org/wiki/RadeonFeature#KMS_Power_Management_Options]] + +[1] [[http://lists.freedesktop.org/archives/dri-devel/2010-May/000492.html|http://lists.freedesktop.org/archives/dri-devel/2010-May/000492.html]] [2] [[http://www.spinics.net/lists/dri-devel/msg01028.html|http://www.spinics.net/lists/dri-devel/msg01028.html]] + + +# Reporting bugs + +If problem is 3D relate correct place to report it is [[https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa|https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa]]. + +Because driver is split between DDX and Mesa all 2D and xv related problems should be reported to [[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg|https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]]. + +You should include **xorg.log** and **dmesg** at minimum. Also exact steps to reproduce the problem will help a lot in solving the problem. Any extra debugging info you have gathered is welcome too. Please select text/plain mime type for any text attachments so they are easier to read. + +**Debug symbols** are important when submitting backtraces so you should take little bit time to install them. There is usually easy way to install them from distribution provided packages. Minimum for debug symbols is mesa, ddx and xorg core to give easily readable backtraces. diff --git a/radeonTV.mdwn b/radeonTV.mdwn new file mode 100644 index 00000000..87e18392 --- /dev/null +++ b/radeonTV.mdwn @@ -0,0 +1,101 @@ + + +# Radeon TV-Out + +In 2007 Alex Deucher added preliminary TV-Out-support based on the gatos-code to the randr12-branch of the ati-driver. The branch has now been merged to the [[git HEAD of xf86-video-ati|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/]]. + + +## Driver Releases + +Starting from the 6.7.191 pre-release the X.org ati driver supports TV-Out on selected cards. That means stable version [[6.8.0|http://xorg.freedesktop.org/releases/individual/driver/xf86-video-ati-6.8.0.tar.bz2]] and newer have the support. A new enough driver is also included starting in eg. Fedora 8 and Ubuntu 7.10. + + +## How to build + +See [[RadeonTVbuildHowto|RadeonTVbuildHowto]]. + + +## How to use + +You can enable TV-Out either dynamically (by issuing commands to the running X server) or statically (through the xorg.config file, before starting the X server). For testing, the dynamic method is probably easier. + + +### How to use: R5xx / R6xx / R7xx + +Newer R600 / R700 series cards (Radeon HD X2000 - X4870) need this option in xorg.conf: + +* [[!format txt """ +Option "ATOMTvOut" "TRUE" +"""]] +The same Option can be applied to R5xx cards too (or at least some of that series). It has been checked to work on x1650 (RV530LE) - this line really needed to detect S-Video tv-out. + + +### Enabling TV-Out Dynamically + +TV-out may be enabled by using a recent driver and xrandr utility: + +1. xrandr --addmode S-video 800x600 +1. xrandr --output S-video --mode 800x600 +1. xrandr --output S-video --set "tv standard" ntsc + +### Enabling TV-Out Statically + +Several options need to be specified. See the radeon(4) manpage for a description. In particular, you must set "TVStandard" to match your flavour of video. + +This recipe is not definitive, but it has worked. + +In the "Device" section: + +* [[!format txt """ + Driver "radeon" + Option "TVDACLoadDetect" "TRUE" + Option "TVStandard" "ntsc" + Option "monitor-S-video" "TV-monitor" +"""]] +In the "Monitor" Section: + +* [[!format txt """ + Option "PreferredMode" "800x600" +"""]] +In the "Screen" section: + +* [[!format txt """ + DefaultDepth 24 + SubSection "Display" + Depth 24 + Modes "800x600" + EndSubSection +"""]] + +## History + + +### How we got here from the GATOS Patch + +There was a very old effort by the gatos-project to support TV Out on ATI Radeons. It was GPL-licensed in the past, but in 2007 all authors agreed with relicensing under MIT-license, so that it was brought to a xf86-video-ati's branch and later on merged to the main driver. + +[[randr-1.2 branch of xf86-video-ati|http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=randr-1.2]] + +[[arklinux-patch (latest)|http://arklinux.org/~bero/xf86-video-ati-6.6.192-tvout.patch]] + +[[Gentoo bug with updated patch|https://bugs.gentoo.org/show_bug.cgi?id=127642]] + +[[Update to below patch by Wei-Tsun Sun|http://www.ece.auckland.ac.nz/~wsun013/tvout/index.html]] + +[[Patch up to xorg 7.0 by Rune Petersen|http://megahurts.dk/rune/tv_output.html]] + +[[Original gatos code|http://gatos.sourceforge.net/theater_out.php]] + + +#### Relicensing + +[[Frederico Ulivi (original author) agreed to relicense the code under a MIT-license (which allows inclusion in the xorg-driver)|http://sourceforge.net/mailarchive/forum.php?thread_name=20070612082434.HM.0000000000001On@fulivi.bos-mail-wwl15.lycos.com&forum_name=gatos-devel]] + +[[All others agreed to the relicensing|http://sourceforge.net/mailarchive/message.php?msg_name=200707250044.20812.ml@hboeck.de]] + + +### atitvout + +On some older cards the tv out can be enabled with atitvout, which is not developed anymore: + +[[atitvout by Lennart Poettering|http://0pointer.de/lennart/projects/atitvout/]] diff --git a/radeonhd.mdwn b/radeonhd.mdwn new file mode 100644 index 00000000..20b78119 --- /dev/null +++ b/radeonhd.mdwn @@ -0,0 +1,520 @@ + + +# radeonhd - A Driver for AMD GPG r5xx/r6xx/r7xx Chipsets + +The _radeonhd_ driver, or _xf86-video-radeonhd_, is an X.org video driver for codenamed R500-R700 graphics devices. It was developed by the X11 community, mostly centered around Novell and AMD, with the free documentation provided by AMD. + +The driver supports full modesetting (read: any mode is usable, not only those provided by the BIOS), and is compatible to [[RandR 1.3|Projects/XRandR]]. 2D and Xv (video) acceleration is provided for all supported GPUs; 3D acceleration via Mesa is supported for r5xx/rs690 GPUs (X1xxx) and is in progress for r6xx/r7xx GPUs (HD2xxx-HD4xxx). + +**Status 09/2010**: Linux distributions, including Novell's openSUSE, have now abandoned radeonhd as the default driver, instead using the [[radeon|radeon]] driver. radeon has more features, including Kernel Mode-Setting support and more 3D support, and it supports all Radeon generation from original R100 Radeons to R800 Radeons (HD 5000 series). Radeonhd can be continued to be updated as long as there are people find it useful. + +[[!toc 1]] + +Subpages: + +* [[radeonhd packages for your distribution|radeonhd:packages]] +* [[how to install from latest git|radeonhd:INSTALL]] +* [[how to setup 2D acceleration for r6xx/r7xx|radeonhd:r6xx_r7xx_branch]] +* [[how to setup DRI|radeonhd:DRI]] +* [[how to setup 3D for r6xx/r7xx|radeonhd:experimental_3D]] (**experimental**) +* [[r600_demo: experimental 3D engine bringup tool|radeonhd:r600_demo]] +* [[r[67]xx Errata Sheet and explanations of difficult GPU subsystems|radeonhd:r6xxErrata]] +* [[list of things to do|radeonhd:TODO]] +* [[feature list|radeonhd:feature]] + +# Recent Changes + +**Version 1.3.0** + +* Added support for RV740, M92, M93, M97. +* Added support for HDMI audio on RS690 and R700. +* Added support for power management. +* Implemented almost correct analysis of [[PowerPlay|PowerPlay]] AtomBIOS tables. +* 2D acceleration (EXA) is enabled by default now, except on RV740. +* Backlight handling finally fixed - compatible with xbacklight 1.1.1. +* Overhaul of memory controller setup. Fixes many "MC not idle" issues. +* Overhaul of cursor handling. Fixes most cursor bugs. +* Selectable color space for XVideo on R6xx/R7xx. +* Tons of bug fixes (DDC, EXA, LUT, RandR, AtomBIOS). +* More quirk table entries. +* Shave support (cleaner compilation output). +* All warnings fixed. +* Some start of Developer's documentation in README.coding. +**Version 1.2.5** + +* Added 2D acceleration for R6xx and R7xx (disabled by default). +* Added XVideo support for R6xx and R7xx (disabled by default). +* Added support for RS880 and RV790. +* Added RandR 1.3 mandatory properties. +* Refactoring of MC code. +* Enable DRI support by default on R5xx and RS6xx. +* LUT (color lookup table) fixes. +* Tons of quirk table entries and bug fixes. +* Fix register accesses for processors that reorder memory writes. +**Version 1.2.4** + +* Added HDMI support. +* Added support for RV710, RV730 (DCE 3.2). +* Added screen rotation support. +* Added RandR 1.3 panning support. +* Many acceleration and build fixes. +**Version 1.2.3** + +* Added Command Submission infrastructure. +**Version 1.2.2** + +* Added [[DRI|radeonhd:DRI]] support (R5xx and RS6xx). +* Added support for RV770, RS780, M82, M86, and M88. +* Added XVideo support. +* Added CP based 2D acceleration (R5xx and RS6xx). +* Added EXA render acceleration (R5xx and RS6xx). +* Added support for AtomBIOS based mode setting. +* Added support for scaled modes. +* Added RandR support for backlight control. +* Lots of modesetting related bug fixes. +**Version 1.2.1** + +* Build-fixes for systems without -DNDEBUG, and for rhd_dump +* Added two new RV670 devices. +**Version 1.2.0** + +* Added support for RV620, RV635, and R680. +* Added 2D acceleration for R5xx (including RS6xx), both XAA and EXA. +* Added support for DDIA block (second digital output) on RS690. +* Added support for interlaced modes +* Added additional layers for splitting outputs into encoders and transmitters as needed for new hardware. +* Added support for [[DragonFly|DragonFly]] BSD. +* Improved RandR corner cases. +* Improved handling of secondary cards. +* Implemented foundation work for future TV support. +* Huge number of bugfixes and minor updates. + +# Supported Hardware + +The _radeonhd_ driver supports video cards based on + +* R500 style hardware: R5xx, RV5xx, RS6xx, RS740, M52 and up +* R600 style hardware: R6xx, RV6xx, RS780, M64 and up +* R700 style hardware: RV7xx +Note that this simple classification of the chipsets isn't exactly correct, because often the individual components are of different generations, especially on mobility chipsets. + +See [[supported chipsets in radeonhd git HEAD|http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=blob_plain;f=README]] for up to date detail information. + + +# Development + +Development of the driver is driven by the community, with several of the developers funded by Novell and AMD. If you want to contribute to this project, [[join the mailing list|mailto:radeonhd+subscribe@opensuse.org]], and have a look at the [[list of things to do|radeonhd:TODO]] and the [[open bugzilla entries|https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&product=xorg&component=Driver%2Fradeonhd&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED]]. + +You do not necessarily have to be a coder to help, there is documentation to be done, users to be helped, you name it. That said, the radeonhd driver project is - as almost all open software development projects - understaffed and likes to welcome any contributions. + + +# More Information + +The mailing list for the _radeonhd_ driver is [[radeonhd@opensuse.org|mailto:radeonhd@opensuse.org]] , you can subscribe to this mailing list by sending a mail to [[radeonhd+subscribe@opensuse.org|mailto:radeonhd+subscribe@opensuse.org]]. More information on this mailing list at [[http://lists.opensuse.org/radeonhd/|http://lists.opensuse.org/radeonhd/]]. + +Overview of recent updates to _radeonhd_: [[http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd|http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd]]. + +There is also an IRC channel #radeonhd on freenode.net. IRC logs at [[phoronix' radeonhd.org|http://radeonhd.org/]]. + +The [[radeonhd:packages|radeonhd:packages]] page lists your source for dep, rpm, etc. packages. + +ATI is providing [[free documentation|http://ati.amd.com/developer/open_gpu_documentation.html]] for the chips. Beware, this is _extremely_ technical. The documentation is [[mirrored on X.org|http://www.x.org/docs/AMD/]]. For r[67]xx development information see also the [[r600_demo|radeonhd:r600_demo]] subpage. + +For an alternative X.org driver see _[[radeon|radeon]]_. In addition r500-r700, it also supports older Radeons and is developed by partially different people. It is currently the default X.org driver. Both _radeon_ and _radeonhd_ have an overlapping feature set, and both should support all r500-r700 cards. If either does not work for you, try the other one. Co-operation is happening in both directions. More information about various available drivers for r500-r700 on the [[radeon|radeon]] page, section ”[[What about other drivers?|radeon]]”. + + +# Getting and updating the radeonhd source code + +Released radeonhd tarballs can be downloaded from **[[ftp://ftp.freedesktop.org/pub/individual/driver/|ftp://ftp.freedesktop.org/pub/individual/driver/]]** + +The name of the tarball will be xf86-video-radeonhd-<version>.tar.bz2 + +The developer version of radeonhd is maintained in the git repository found at **git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd** + +You can find information on using git at the git website [[http://git.or.cz/|http://git.or.cz/]] and a short intro at [[http://www.freedesktop.org/wiki/Infrastructure/git/Developers|http://www.freedesktop.org/wiki/Infrastructure/git/Developers]] + +You can get a copy of the repository like this: +[[!format txt """ + $ git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd +"""]] +This will create a directory _xf86-video-radeonhd_ in the current directory by default, or the given directory _my-radeonhd_ otherwise. + +If you have not made any local changes and want to update you source code with the newest stuff from the official _radeonhd_ repository, you can run this: +[[!format txt """ + $ git pull +"""]] +If you HAVE made local changes and committed them locally to your master branch (with `git commit -a`), you will be better off running +[[!format txt """ + $ git fetch + $ git rebase origin +"""]] +If you're using more branches, read the git docs. + + +# Installation + +Note: The following assumes that you checked out the latest git version of radeonhd. If you're using a released version in form of a tarball, exchange _autogen.sh_ with _configure_. Also make sure you have the necessary development files for X11 driver compilation (e.g. xorg-x11-server-sdk in openSUSE). + +With X.Org 7.0 and later: +[[!format txt """ + $ ./autogen.sh + $ make +"""]] +Then as root: +[[!format txt """ + # make install +"""]] +This will litter all kinds of compiled files throughout your source tree. + ** Please note: ** `make install` will usually install to `/usr/local`. On Linux X is usually installed in `/usr`. To change this, you need to add the argument `--prefix /usr` to `autogen.sh`, i.e.: `./autogen.sh --prefix /usr`. Depending on which system you use you might have to specify a libdir if you are on a 64bit system. Check if the directory `/usr/lib64` exists on your system. If it does, please use `./autogen.sh --prefix /usr --libdir /usr/lib64`. + +With X.Org prior to 7.0: +[[!format txt """ + $ xmkmf -a + $ make EXTRA_INCLUDES="-I/usr/include/xorg -I/usr/include/drm" all +"""]] +and as root: +[[!format txt """ + $ make install +"""]] +This uses imake and is for compatibility with older systems. + +To avoid building in your source tree, do: +[[!format txt """ + $ mkdir _b && cd _b + $ ../autogen.sh + $ make + $ make install +"""]] +Runs the build in _b/ - and if something is completely messed up, you can safely remove the _b/ directory and create a new one without affecting any source files. + +Hint: If you happen to have multiple branches in your git source tree, you + + * can have per-branch __b-BRANCH/_ build trees and __i-BRANCH/_ install trees. ("... configure ... --prefix=$PWD/_i-BRANCH") +Note that none of these methods will install the rhd_conntest tool. The "xmkmf" method always requires a separate "make" run in utils/conntest. The other two will build rhd_conntest by default if its requirements are met. + +Please note you need [[updated drm kernel modules|radeonhd:r6xx_r7xx_branch]] and proper configuration (xorg.conf) for 2D and Xv on R6xx/R7xx. + + +# Known Bugs & Limitations + +The following subsystems have not been implemented yet or show some limitations: + +* 3D acceleration is active by default only on R5xx and RS6xx right now. [[Experimental support for R6xx and R7xx|radeonhd:experimental_3D]] is available, but not for the faint of heart. Also, there is an experimental [[3D bringup tool|radeonhd:r600_demo]] for testing on 6xx/7xx. +* 2D acceleration is active by default now, except on RV740. +* No TV and Component connector support so far. +* Suspend & Resume isn't completely tested, but works on a variety of hardware. Your mileage may vary. Note that typically you need some BIOS workarounds on the kernel command line, ask your distribution for that. +* Powermanagement has to be enabled explicitely. Depending on your hardware, the fan might run at full speed. This turned out to be really tricky. +See also [[RadeonFeature|RadeonFeature]] and [[RadeonProgram|RadeonProgram]] for a features and supported 3D program lists. + +The following known bugs have not been resolved yet (ordered by severity): + +* Digital output on PCIEPHY (RS780) doesn't light up unless connected at boot time. Affects mostly displays connected to laptops thru DVI/HDMI. It is a problem with the AtomBIOS byte code parser which is used at the moment. The only work around is to boot with this output connected at boot time. +* [[Bug 14500|https://bugs.freedesktop.org/show_bug.cgi?id=14500]]: External monitor does not display native resolution +* Some cards seem to provide broken connector tables. We're constantly fixing those. Please report if you have one. + +# Reporting Errors + +Report bugs at: [[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeonhd|https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeonhd]]. + +When reporting an error with [[bugzilla|https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/radeonhd]], please be sure to attach your `xorg.conf` and `Xorg.0.log`. Please use `-logverbose 7` for the Xserver in this case. If the error is related to RandR, please verify the xrandr version you are using, and attach the output of `xrandr -q; xrandr -q --verbose`. + +If you want to report a crash try to get a decent stack backtrace (`bt full`) in gdb. You have to compile with debugging information (`-O0 -g3`) or install -debuginfo packages for that. If a -debuginfo package for the Xserver is available for your distribution, please install it as well. It does not have any negative side effects apart from using space on your harddisk. + +If you don't get any output on your monitors at all, please add `Option "NoRandR"` to the "Device" section in your `xorg.conf`, and verify whether this issue is related to RandR or to general modesetting. + +The following messages are absolutely normal in your Xorg.0.log (as we don't have 3D acceleration yet): +[[!format txt """ + (EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed + (EE) AIGLX: reverting to software rendering +"""]] + +# git Bisecting + +If you stumble over a regression and the source of the issue cannot be determined easily, you may have to git-bisect the issue. This helps us identifying the commit that introduced the issue. As you have to compile the driver yourself in this process, make sure you have the necessary development files (e.g. xorg-x11-server-sdk in openSUSE). See [[Installation|radeonhd]] for more tips about compiling the driver. + +First get a copy of the repository if you don't have that already: +[[!format txt """ + $ git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd +"""]] +Otherwise make sure that the copy you have is recent (if you can already reproduce the regression with your current state, you should _NOT_ do that): +[[!format txt """ + $ git pull +"""]] +Identify the last known good version (e.g. the last released version), and the first known broken version. The `gitk` command can help you by visualizing the history. You need to know the SHA1-ids (alternatively, known names as 1.2.4 or master). + +Start a new git-bisect session: +[[!format txt """ + $ git bisect start [bad] [good] +"""]] +E.g. if you just noted that with the current git master changing the backlight level is no longer working, while it was working with 1.2.5, do "`git bisect master 1.2.5`". If you remember that you tested git commit bc42c63 and it still worked, you can save some time by "`git bisect master bc42c63`". + +You will have to do the following in a loop until git tells you that you are done: + +* git presentes you a commit to try out. So configure and make: + +[[!format txt """ + $ ./autogen.sh && make && sudo make install +"""]] +* If this worked out, test the driver. This depends on what exactly you are trying to verify. E.g. for the theoretical backlight issue restart the Xserver (so the new driver is loaded) and test, whether you can change the backlight level. Caveat: Depending on what you need to test this can be arbitrarily complex. E.g. when debugging memory controller setup you just _have_ to to reboot before testing. Every time. +* If the checked out version runs fine, do: + +[[!format txt """ + $ git bisect good +"""]] +* If the checked out version is broken, do: + +[[!format txt """ + $ git bisect bad +"""]] +* You will get a new commit to try out. +At the end git will present you a single commit that first exhibits the broken behavior. This git commit number is _the_ important information for the regression you analyzed. + + +# Troubleshooting, Q & A + +See also examples below for a complete setup. + + +## I get strange build errors about "no rule to make target ..." + +You've probably pulled in some new source files when you updated your sources from git. In this case you should do: +[[!format txt """ +$ make distclean +$ ./autogen.sh +$ make +"""]] +Sometimes in such cases the build doesn't break in such cases but the driver crashes apparently for new reason. Before reporting an error, please try if those steps above make things work already. + + +## autogen.sh / configure doesn't work + +If during running autogen.sh / configure you get +[[!format txt """ +autoreconf: running: /usr/bin/autoconf +configure.ac:35: error: possibly undefined macro: XORG_DRIVER_CHECK_EXT + If this token and others are legitimate, please use m4_pattern_allow. + See the Autoconf documentation. +autoreconf: /usr/bin/autoconf failed with exit status: 1 +"""]] +your system lacks one or more of these files: +[[!format txt """ + /usr/share/aclocal/xorg-macros.m4 + /usr/share/aclocal/xorg-server.m4 + /usr/share/aclocal/xorgversion.m4 +"""]] +Make sure you have all required X.org development packages installed. These may be called _xorg-dev_, _xorg-x11-server-sdk_ and _xorg-x11-util-macros_, or something similar. + + +## 3D applications aren't working + +Please read how to [[setup DRI support|radeonhd:DRI]]. + + +## I only get a very jittery display + +You probably used the `fglrx` driver before. It doesn't restore the linebuffer completely on exit. You have to reboot your system to get this fixed. In some rare cases you might even have to power it off and restart it. Suspend to disk & resume is reported to work on many systems as well. + + +## My monitor isn't detected + +On R5xx hardware the description of the hot plug detection (HPD) pins in the AtomBIOS connector table is often broken. Please try using +[[!format txt """ +Option "HPD" "swap" +"""]] +in the "Device" section. If this helps, please test all outputs (as far as possible with your equipment), and report your findings to the mailing list. Reports should include your Xorg.0.log (the working version) and your results regarding testing. + +If this doesn't help, please try: +[[!format txt """ +Option "HPD" "off" +"""]] +This disables HPD detection completely. In some cases the HPD pin of the GPU doesn't seem to be connected to the DVI connector although it is advertised in the BIOS. + +**NOTE**: Option "HPD" should always only be a workaround until the quirks table in the driver has been updated. ALWAYS report if it is needed to get your monitor running. + +If you are using a KVM switch for your analog monitor and this monitor isn't detected correctly please try without the KVM switch. Analog displays are detected thru 'load detection' ie detection of the terminating resistors on the monitor side. The VGA standard requires 75 Ohm resistors on the RGB lines. Some KVM switches seem to not meet these requirements. + + +## My monitor section isn't used any longer + +Right. This is standard with RandR. Now the monitor sections have to specified with +[[!format txt """ +Option "monitor-<output_name>" "<monitor_name>" +"""]] +in the "Device" section. You can get all output names of your card with `xrandr -q`. See also example below. + +Behavior of monitor sections is different to standard modesetting in radeonhd. With standard modesetting a monitor section replaces the EDID detected monitor (thus typically reducing the maximum mode size to 1024x768), in RandR it doesn't. It's not exactly clear in which cases which parameters are overridden by the monitor section and how to override EDID detected parameters and modes in the RandR case. + + +## The driver doesn't start on my laptop. I have 4GB of main memory, BTW + +Some machines with M72, M83, and possibly other IGP chipsets (especially laptops) with more than 2GB of memory exhibit this BIOS issue. Apparently, the MTRR table is not setup correctly. One possibility is to reduce the amount of RAM, the more reasonable (but only little tested so far) alternative is to enable the MTRR sanitizer in the kernel. +[[!format txt """ +grep "CONFIG_MTRR" /boot/config* +"""]] +to check whether CONFIG_MTRR is active for your kernel. If it is, boot with +[[!format txt """ +enable_mtrr_cleanup mtrr_spare_reg_nr=0 +"""]] +, otherwise you have to recompile your kernel with this option enabled. + + +## The cursor shows weird corruptions at some points of the screen + +This is [[Bug 13405|https://bugs.freedesktop.org/show_bug.cgi?id=13405]]: Hardware cursor corruption. Presumably fixed with git commit [[4be5f7152f71|http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/commit/?id=4be5f7152f71c292f16b6e30c59c07b282ea4772]] (not in any release yet). + + +## How do I enable / disable an output after a monitor has been plugged in / removed? + + +[[!format txt """ +xrandr --auto +"""]] + +## How do I set up multiple monitors? + + +[[!format txt """ +xrandr --output <output_name> --right-of <other_output_name> +"""]] +If this fails, the most common reason is the following: The X.org framebuffer cannot be resized after initialization (yet). You have to either configure this statically (see below), or specify the maximum needed size with +[[!format txt """ +Virtual <width> <height> +"""]] +in the "Display" subsection of the "Screen" section. + +If xrandr is not able to unclone displays (monitors show the same screen still), and you have set virtual correctly, it can also be that you need a newer xrandr (1.2.3 or git), and potentially also a newer xserver. You can try to explicitly set the used Crtc with `--crtc 1` or 0. + +`xrandr -q` prints the maximum frame buffer size in the first line of its output. + + +## How do I configure a multimonitor setup statically? + +Add (mostly empty) monitor sections for your monitors like described in the answer above. Then add +[[!format txt """ +Option "RightOf" "<other_monitor_name>" +"""]] +to the monitor section representing your right monitor. Alternatively, you can use `LeftOf` - working correctly only with the latest Xserver (bugfix). Of course there's also `Above` and `Below`. + +You can also use `<other_output_name>` instead of `<other_monitor_name>`. Also read `man 5 xorg.conf`. + + +## My monitors have different resolutions. But both show the same lower resolution on startup + +This seems to be a general RandR issue. Can be changed with `--output <output> --auto` during runtime, or with `Option "PreferredMode" "<mode>"` with newer Xservers (known to be buggy up to Xserver 1.4.0). + + +## My Gnome/KDE/whatever panel shows up on the wrong monitor + +Add your preferred monitor to +[[!format txt """ +Option "RROutputOrder" "<monitor_name>" +"""]] +in the "Device" section. This reorders the RandR outputs, which is reflected in the Xinerama screen order. You can specify any number of outputs, separated by spaces or comas. Note that this is a radeonhd specific option, it won't work with other drivers. + + +## Panels and maximized windows span all my monitors + +Make sure you have enabled xinerama support for your window manager. For instance, on Gentoo enable the xinerama USE-flag and rebuild the affected packages by issuing the following command +[[!format txt """ +emerge -aND world +"""]] + +## xrandr returns with BadMatch (invalid parameter attributes) + +Get a newer xrandr (1.2.3 or git), and potentially also a newer xserver. If it still happens, send a mail to [[radeonhd@opensuse.org|mailto:radeonhd@opensuse.org]] or file a bug at freedesktop.org. You can get the newest xrandr from git by +[[!format txt """ +git-clone git://anongit.freedesktop.org/git/xorg/app/xrandr +"""]] + +## How do I set -logverbose 7 when I run a display manager (xdm/kdm/gdm)? + +There is a display manager configuration file which lists the command line to use when starting the Xserver. It usually `/etc/X11/xdm/Xservers`. In this file you will find a line like: +[[!format txt """ +:0 local /usr/bin/X -nolisten tcp -br vt7 +"""]] +Please add `-logverbose 7` at the end of this line. + + +## Why is radeonhd so much slower than avivo? + +There may be an old, obsolete line in your `xorg.conf` file from some _fglrx_ setup a long time ago: +[[!format txt """ +Option "mtrr" "no" # ancient, obsolete option: REMOVE IT! +"""]] +If you have such a line, removing it can speed up radeonhd considerably. + +General note: As a rule, one does not need any `xorg.conf` file with Xserver 1.4 and up, so it is always a good idea to make sure you _really_ need all the statements in there. + + +## How do I get a multi card setup to work? + +Make sure you have a config file with one Device section for each card. Each device section should be referenced from it's own Screen section which itself should be referenced in the Layout section. + +Depending on which version of the Xserver and OS you are using you may need to take additional steps. On Linux you may need to do: + +* On Linux you need to boot with the boot option pci=rom. +* after booting do: + * [[!format txt """ + # echo 1 > /sys/bus/pci/devices/<pci_bus_id>/rom + +"""]] +* Some users have reported they also need to do: + * [[!format txt """ + # setpci -s <pci_bus_id> ROM_ADDRESS=xxxx0001 + # setpci -s <pci_bus_id> COMMAND=2 + +"""]]replace <pci_bus_id> with the PCI bus ID and xxxx with the hex digits you can obtain thru ` lspci -nv `. + +# Examples + +Example xorg.conf (minimal for Xserver 1.3 and up), e.g. no input devices or modes configured, monitors configured by EDID data): +[[!format txt """ +Section "Monitor" + Identifier "External" + Option "RightOf" "Panel" +EndSection + +Section "Monitor" + Identifier "Panel" +EndSection + +Section "Device" + Identifier "MyCard" + Driver "radeonhd" + Option "monitor-VGA_1" "External" + Option "monitor-PANEL" "Panel" + Option "RROutputOrder" "PANEL" +EndSection + +Section "Screen" + Identifier "MyScreen" + Device "MyCard" + DefaultDepth 24 + SubSection "Display" + Depth 24 + ## This is superfluous and actually harmful with a + ## static configuration. Enable for dynamic config only. + #Virtual 2704 1050 + EndSubSection +EndSection +"""]] +Example call to configure multiple screens dynamically (set Virtual in `xorg.conf` for that to work): +[[!format txt """ +xrandr --output VGA_1 --right-of PANEL +"""]] + +# Glossary + +This is a list of abbreviations and words which you will stumble upon when you are digging deeper. + +* [[!table header="no" class="mointable" data=""" + CP | command processor + CS | command submission + [[DRI|http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure]] | Direct Rendering Infrastructure + [[DRM|http://en.wikipedia.org/wiki/Direct_Rendering_Manager]] | Direct Rendering Manager + [[EXA|http://en.wikipedia.org/wiki/EXA]] | + [[GEM|http://en.wikipedia.org/wiki/Graphics_Execution_Manager]] | graphics execution manager + KMS | kernel based mode setting + MC | memory controller + [[XAA|http://en.wikipedia.org/wiki/XAA]] | XFree86 Acceleration Architecture +"""]] diff --git a/radeonhd:DRI.mdwn b/radeonhd:DRI.mdwn new file mode 100644 index 00000000..b4e96bea --- /dev/null +++ b/radeonhd:DRI.mdwn @@ -0,0 +1,153 @@ + + +# How to setup DRI with radeonhd + +Please note that there is **only very experimental [[3D support for r6xx based cards|radeonhd:experimental_3D]]** so far! There is also a [[3D bringup tool|radeonhd:r600_demo]] available that is already capable of rendering textured triangles. Additionally, there is also EXA and Xv acceleration in master. Both the demo program, the EXA/Xv support, and the experimental 3D driver require a drm built from the r6xx-r7xx branch of mesa/drm (or, for Linux, drm-next is preferable) in order to operate. + +The RS6xx IGP parts have a 2D engine and a 3D engine from the R4xx family so do not require "R6xx support". + +The rest of this page relates only to R5xx or RS690 for now. + +So in order to enable DRI on your r5xx card or 690-based motherboard you need + +* Recent DRM kernel module + libdrm +* Recent Mesa (7.2 should suffice) +* Recent Xserver (for i386 1.3.0 is enough, x86_64 needs 1.5.0 or later) +* Recent radeonhd (version 1.2.2 or later - earlier versions did not allow 2D and 3D at the same time) +[[!toc 2]] + + +## Known Issues + +* x86_64 is only working correctly with a current Xserver (1.4.99.x) +* Mipmap textures are broken +* Texture upload after suspend to disk is partially broken +* Movewindow support is missing (partially superfluous) +* googleearth doesn't render anything. Apparently it falls back into a slow path (antialiased lines), but that is probably only part of the story. + +## Building + +It's a smart idea to pull all this source down into it's own self contained area, in case you need to blow it all away cleanly and redo the git clone, builds, etc. So in this case we'll use /var/tmp/radeonhd-dri as the main area. Don't use /tmp, this is cleared on reboot on some distributions. + + +[[!format txt """ + SRC="/var/tmp/radeonhd-dri" + mkdir $SRC + cd $SRC +"""]] +Please note that the following information is quite Linux-centric at the moment. + + +### Sources + +If you want to test the bleeding edge for the main components, we suggest using the git heads, because there are probably still bugs lurking somewhere. +[[!format txt """ + git clone git://anongit.freedesktop.org/git/mesa/drm + git clone git://anongit.freedesktop.org/git/mesa/mesa + git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd + #git clone git://anongit.freedesktop.org/git/xorg/xserver +"""]] +Apparently you need to fetch and build the Xserver only on x86_64, and only if you don't have 1.5.0 or higher - don't update if not necessary, this is painful! + + +### Preconditions + +You will stumble upon some preconditions, the following should help here (using released versions whenever possible). You can unpack the released versions with `tar xvfj` <file>. If they don't work, try the according git tree, you can find the path to the git repository on the [[gitweb page|http://gitweb.freedesktop.org/]]. + +Mesa needs dri2proto: + +* [[ftp://ftp.freedesktop.org/pub/individual/proto/dri2proto-1.1.tar.bz2|ftp://ftp.freedesktop.org/pub/individual/proto/dri2proto-1.1.tar.bz2]] +When building a newer Xserver you will have to fetch and install a number of newer prototypes and libraries. This includes: + +* [[ftp://ftp.freedesktop.org/pub/individual/proto/xextproto-7.0.3.tar.bz2|ftp://ftp.freedesktop.org/pub/individual/proto/xextproto-7.0.3.tar.bz2]] +* [[ftp://ftp.freedesktop.org/pub/individual/proto/xproto-7.0.13.tar.bz2|ftp://ftp.freedesktop.org/pub/individual/proto/xproto-7.0.13.tar.bz2]] +* `git clone git://anongit.freedesktop.org/git/xorg/proto/inputproto` +* [[ftp://ftp.freedesktop.org/pub/individual/lib/pixman-0.10.0.tar.bz2|ftp://ftp.freedesktop.org/pub/individual/lib/pixman-0.10.0.tar.bz2]] +Also, after building the Xserver you have to build and install all input drivers you are using as well. Apparently, you need the very latest bits for them to be compilable, and they have to be compiled against the new ABI of the Xserver. At least this includes: + +* `git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-mouse` +* `git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-keyboard` +* **or** ` git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-input-evdev` +Also, for the DRM kernel modules you need the kernel sources of your running kernel installed in /usr/src - all major distributions do this correctly nowadays if kernel sources are installed from your distribution. + +You may also run into a problem where your libpciaccess it out of date and you need to pull down the latest from git: + +* `git clone git://anongit.freedesktop.org/git/xorg/lib/libpciaccess` +and build it with the usual manner. This seems to show up on x86_64 builds when the xf86-video-radeonhd build croaks. + + +### Installation + +The drm package contains two subsystems, which have to be built and installed separately at the beginning. There's no reason to actually build all the _other vendor_ drm modules, so we'll just build the one we're interested in. In order to make sure that the correct module is loaded check that `extra` is part of the `search` list in `/etc/depmod.conf` - in Ubuntu this typically isn't. + + +[[!format txt """ + cd $SRC/drm + ./autogen.sh --prefix=/usr + make + make install (as root) + cd linux-core + make DRM_MODULES="radeon" + make install (as root) + depmod -a (as root) +"""]] +After that, all other subsystems have to be built and installed in the same way, in the order mentioned below: +[[!format txt """ + cd $SRC/<subsystem> + ./autogen.sh --prefix=/usr + make + make install (as root) +"""]] +If using a released package (a `.tar.bz2`), there is no `autogen.sh`. In that case (and _only_ in that case) you have to call `./configure` with the same arguments. Depending on your distro, you might want to add `--libdir /usr/lib64` to `./autogen.sh`. + +The subsystems have to be built and installed in the following order: + +* dri2proto +* mesa (add `--with-dri-drivers=radeon,r300,swrast` to `./autogen.sh` to speed up the build considerably) +* Xserver: only if there is need to build the xserver, which is quite painful: + * xextproto + * xproto (is named x11proto in the git repository) + * inputproto + * pixman + * xserver + * xf86-input-mouse + * xf86-input-keyboard + * xf86-input-evdev (if used) +* radeonhd + +### Notes for Experienced Users + +If you have a little experience with building and installing foreign packages, you might want to use a different `--prefix` in order to not override your installed configuration. In that case you will have to additionally set +[[!format txt """ + export ACLOCAL="aclocal -I $PREFIX/share/aclocal" + export PKG_CONFIG_PATH=$PREFIX/$LIB/pkgconfig" + export LD_LIBRARY_PATH=$PREFIX/$LIB + export PATH=$PREFIX/bin:$PATH +"""]] +with `$PREFIX` being the directory to be installed to and `$LIB` being "lib" on i386 and "lib64" on x86_64 (might be distribution dependent). + +You can also use build dirs for all subsystems (except for the kernel module and the Mesa subsystem, which uses autoconf, but not automake) by creating a `build` directory, changing into that directory and calling `../autogen.sh [args]`. This has the advantage that the source directory remains untouched. Again, this doesn't work for Mesa and the drm kernel module. + + +## Configuration + +DRI is inactive by default. + +In order to activate DRI, you have to add +[[!format txt """ + Option "DRI" +"""]] +to the driver section of your `xorg.conf`. + + +## Troubleshooting, Q & A + + +### Only the first invocation of a OpenGL program works as expected + +You're probably running an older Xserver (< 1.4.99.x) on an x86_64 machine. This is known to exhibit this bug. + + +### I only get "Error: coudn't get an RGB, Double-buffered visual." + +Same as above. Xserver is too old. diff --git a/radeonhd:INSTALL.mdwn b/radeonhd:INSTALL.mdwn new file mode 100644 index 00000000..f5b07c2d --- /dev/null +++ b/radeonhd:INSTALL.mdwn @@ -0,0 +1,108 @@ + +_This is a little howto or install-diary of how i got the radeonhd driver (with xv-support for now) working for my system: debian testing (squeeze) and HD4850. I needed to search on a few different sites to get it finally to work, because there are some errors in any existing howto at x.org or there are some information missing, and people keep asking questions for it in the IRC, so so i decided to create this page, which I think this page is pretty useful._ + +Preconditions: + + +[[!format txt """ +apt-get install checkinstall build-essential git-core configure-debian automake xorg-dev libtool autoconf pciutils-dev libpciaccess-dev mesa-common-dev libgl1-mesa-dev libdrm-dev x11proto-dri2-dev +"""]] +im not sure if _libdrm-dev_ is needed because you have to compile your own version of it - please confirm somebody. _x11proto-dri2-dev_ is only aviable for testing (squeeze) [[x11proto-dri2-dev|http://packages.debian.org/squeeze/x11proto-dri2-dev]] +[[!format txt """ +apt-get build-dep xserver-xorg-video-radeonhd +"""]] +Create a working directory whereever you want to (~/ or /var/tmp/ for example): + + +[[!format txt """ +SRC="/your/working/directory" +mkdir $SRC +cd $SRC +"""]] +Get and install **DRM**: +[[!format txt """ +git clone git://anongit.freedesktop.org/mesa/drm +cd drm/linux-core +git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support +cd .. +./autogen.sh --prefix=/usr +make +make install # as root +"""]] +An alternativ for _make & make install_ is _checkinstall_. In the queries you have to answer as necessary. + + +[[!format txt """ +[...] +./autogen.sh --prefix=/usr +checkinstall # as root +# there is a warning: *** Warning: The package version "2.4.3 [...] is not a debian policy complaint one. Please specify an alternate one +# just type in the version yourself: "2.4.3" +sudo dpkg -i --force all *.deb +"""]] +_force all_ is needed, because it overwrites some files of the libdrm-dev package. As mentioned earlier, I'm not sure if this package is needed for the installation. + +Build the modules (_drm.ko/radeon.ko_) and install them: +[[!format txt """ +cd linux-core +make DRM_MODULES="radeon" +sudo make install +sudo depmod -a +"""]] +leave drm and return to your workspace: +[[!format txt """ +cd $SRC +"""]] +Get and install **xf86-video-radeonhd**: +[[!format txt """ +git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd +cd xf86-video-radeonhd +./autogen.sh --prefix=/usr +make +make install # as root +"""]] +If you want to, use _checkinstall_ again like above. + +Edit your xorg.conf: + +The _Section "Device"_ in your xorg.conf should look like below: +[[!format txt """ +Section "Device" + Identifier "Configured Video Device" + Driver "radeonhd" + Option "AccelMethod" "EXA" + Option "DRI" +EndSection +"""]] +and you have to add this to your xorg.conf +[[!format txt """ +Section "DRI" + Mode 0666 +EndSection +"""]] +At this point i prefer rebooting the machine, but stopping x, reload the (new) drm-module and start x again should be enough. + +To update **DRM** to its newest version do this: +[[!format txt """ +cd $SRC +cd drm +git pull +make clean +./autogen.sh --prefix=/usr +make +make install # as root +cd linux-core +make clean +make DRM_MODULES="radeon" +make install # as root +"""]] +To update **xf86-video-radeonhd** to its newest version do this: +[[!format txt """ +cd $SRC +cd xf86-video-radeonhd +git pull +make clean +./autogen.sh --prefix=/usr +make +make install # as root +"""]]
\ No newline at end of file diff --git a/radeonhd:TODO.mdwn b/radeonhd:TODO.mdwn new file mode 100644 index 00000000..669f0aa4 --- /dev/null +++ b/radeonhd:TODO.mdwn @@ -0,0 +1,35 @@ + + +# radeonhd: List of things to do + +If you want to work on one of those things, be sure that + +1. you understand the feature well enough to implement this +1. if anyone else is working on the feature he/she wants to cooperate with you +1. you announce it on the according mailing list +1. you update the information on this wiki page accordingly (add yourself as the one working on it). +It's best to announce that you _plan_ to work on a feature on the mailing list and see what the other developers and users think about that. Be sure to include enough information in the announcement, so people have something to comment on. + +Also note that "working on" reports here are by no means priority indicators - they just claim that someone is aware of this issue, and has considered to work on it. No more, no less. + +Feel free to add additional (technical!) TODOs, but don't consider this do be a bug tracking list, or a general wish list. + + +## radeonhd X11 driver + +Please announce work on the [[radeonhd mailing list|http://lists.opensuse.org/radeonhd/]]. + +* **Tiling support for the framebuffer**. This will accelerate 3D a lot. As this tackles a lot of subsystems quite a number of changes are involved, and support for r6xx needs more flexibility than for r6xx. (working on: Egbert Eich) +* **2D and 3D acceleration lock up each other**. First estimation by Luc Verhaegen: R5xx3DSetup() is called on every context change (e.g. from 3D application to Xserver), and apparently not waiting correctly for the chip to settle. +* **XVideo support** needs some love. E.g. bicubic filtering, support for various color spaces, etc. (working on: Alexander Deucher) +* **Full RandR 1.3 properties support**. All mandatory properties are already supported, still there are a number of additional properties that are not implemented yet. (working on: Matthias Hopf) +* **TV out support**. +* **Kernel modesetting.** radeonhd's DRI and kernel modesetting are currently mutually exclusive. Also being able to utilize kernel modesetting itself would be interesting. + +## r6xx DRI driver + +Please announce work on the [[radeonhd mailing list|http://lists.opensuse.org/radeonhd/]], for the moment. Until the r6xx driver is actually available in any form, then we will change to the dri mailing list. + +Currently the r6xx DRI driver is basically non-existing. If you want to contribute, first play a bit with the [[3D bringup tool|radeonhd:r600_demo]] and verify that everything works as indicated on your GPU as well. + +(working on: Matthias Hopf) diff --git a/radeonhd:experimental_3D.mdwn b/radeonhd:experimental_3D.mdwn new file mode 100644 index 00000000..54dee0e6 --- /dev/null +++ b/radeonhd:experimental_3D.mdwn @@ -0,0 +1,61 @@ + +Note - these instructions were written while 6xx/7xx 3D support was under development. If you have reasonably up to date radeonhd (1.3.0 or higher), kernel (2.6.32 or higher) and mesa (7.7 or higher) you shouldn't need to follow *any* of the instructions on this page ;) + + +# Radeon HD 2000 - HD 4000 series: Installing Experimental 3D Support + +** This howto should be usable already, but still may have some issues depending on distro you use. You also should have installed needed devel packages. ** + +This guide is to instruct users to install **experimental** open source 3D support for Radeon HD 2000 - Radeon HD 4000 series (also known as R6xx/R7xx series). The instructions apply to both users of [[radeon|radeon]] (ati) and [[radeonhd|radeonhd]] X.org drivers. + +** Note R6xx/R7xx mesa code from 6xx-rewrite branch has been merged to master. Don't use that branch anymore ** + + +## Upstream status + +* DRM support for 3D is available in kernel since 2.6.32 +* DRM in kernel 2.6.33 contains IRQ support +* Mesa r600 driver was added in 7.6.1, however it it good idea to use 7.7 at least + +## How to build drm stuff + + +[[!format txt """ + git clone git://anongit.freedesktop.org/~agd5f/drm + cd drm + git checkout -t -b r6xx-r7xx-3d origin/r6xx-r7xx-3d + ./autogen.sh --prefix=$(pkg-config --variable=prefix libdrm) --libdir=$(pkg-config --variable=libdir libdrm) --includedir=$(pkg-config --variable=includedir libdrm) + make + sudo make install +"""]] + +[[!format txt """ + cd linux-core + make + sudo make install +"""]] + +## How to build Mesa + + +[[!format txt """ + git clone git://anongit.freedesktop.org/mesa/mesa + cd mesa + git checkout -t -b master origin/master + ./autogen.sh --with-dri-drivers=swrast,r600 --libdir=$(pkg-config --variable=libdir dri) --includedir=$(pkg-config --variable=includedir dri) --disable-gallium --enable-debug + make + sudo make install +"""]] + +## Troubleshooting + +* /usr/include/drm/radeon_cs.h:185: error: ‘RADEON_GEM_DOMAIN_VRAM’ undeclared (first use in this function)[[!format txt """ + mv /usr/lib/pkgconfig/libdrm_radeon.pc /usr/lib/pkgconfig/libdrm_radeon.pc.copy + mv /usr/lib64/pkgconfig/libdrm_radeon.pc /usr/lib64/pkgconfig/libdrm_radeon.pc.copy +"""]]Of course only one of these commands is needed. After moving libdrm_radeon.pc remember to call autogen again +* egl_tracker.h:134: error: expected specifier-qualifier-list before ‘drmModeModeInfoPtr’ +You really should disable gallium for now. See suggested Mesa's autogen.sh parameters. + +## 3D application statuses + +Check [[RadeonProgram|RadeonProgram]] for info about supported applications. diff --git a/radeonhd:feature.mdwn b/radeonhd:feature.mdwn new file mode 100644 index 00000000..0a504d5c --- /dev/null +++ b/radeonhd:feature.mdwn @@ -0,0 +1,61 @@ + + +## Feature Matrix for radeonhd + +**This page is only for free [[radeonhd|radeonhd]] driver.** + +**See [[RadeonFeature|RadeonFeature]] for radeon (xf86-video-ati). THIS PAGE IS NOT FOR [[FGLRX/CATALYST|ATIProprietaryDriver]] DRIVERS PROVIDED BY AMD/ATI.** + +Also check out the [[RadeonProgram|RadeonProgram]], [[GalliumStatus|GalliumStatus]], and [[ATIRadeon|http://dri.freedesktop.org/wiki/ATIRadeon]] at DRI wiki. + + * "**DONE**" means that it is implemented and relatively bug-free. + * "**MOSTLY**" means that it is implemented but has some known bugs. + * "**WIP**" means that someone has started on the initial implementation. + * "**BIOS**" means only if supported by your BIOS. No software support. Yet. + * "**SLOW**" means that the feature is implemented and bug-free, but slow. Improvements may or may not be planned. + * "**STALLED**" means that whatever code has been written is accumulating color and texture similar to that 3 week old slice of pizza in your fridge. + * "**N/A**" means that the feature is not supported by the hardware. + * "**N/N**" means that the feature will not be implemented, because a better alternative is or will be available. + * "**TODO**" means that someone needs to write the code. The required knowledge to write the code may or may not be known. Please ask on #radeon/#radeonhd if you want to get your feet wet on this. + * "**UNKNOWN**" means that the current status of this item isn't known. You are free to update it if you know. [[!table header="no" class="mointable" data=""" + **2D features** || | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + DDX (X server) Modesetting || | DONE | DONE | DONE | DONE | TODO + Kernel Modesetting || | N/N | N/N | N/N | N/N | TODO + DRI2 || | TODO | TODO | TODO | TODO | TODO + ShadowFB || | DONE | DONE | DONE | DONE | TODO + Old 2D Acceleration (XAA) || | DONE | DONE | N/N | N/N | N/N + 2D Acceleration (EXA) || | DONE | DONE | DONE | DONE | TODO + Overlay Xv || | N/N | N/N | N/N | N/N | N/N + Textured Xv || | DONE | DONE | DONE | DONE | TODO + XvMC || | TODO | TODO | TODO | TODO | TODO + **Output** || | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + Dual-link DVI || | DONE | DONE | DONE | DONE | TODO + XRandR 1.2 || | DONE | DONE | DONE | DONE | TODO + TV Out || | TODO | TODO | TODO | TODO | TODO + [[DisplayPort|DisplayPort]] || | N/A | N/A | TODO | TODO | TODO + HDMI Audio || | DONE | TODO | DONE | DONE | TODO + **Other** || | **RS690** | **R500** | **R600** | **R700** | **Evergreen** + Power Saving (Powerplay) || | TODO | TODO | TODO | TODO | TODO + Suspend Support || | DONE | DONE | DONE | DONE | TODO + Console restore || | DONE | DONE | DONE | DONE | TODO +"""]] + + +### Feature dependency tree + + +[[!format txt """ +memory manager -+-> KMS -+-> advanced power management (dynamic control of clocks etc..) + | | + | +-> run X without root privileges + | + +-> advanced 3D (OpenGL 1.5+) via chip-specific Mesa code + | + +-> DRI2 / RDR -+-> Flicker-free 3D with compositing + | + +-> Gallium3D -+-> advanced 3D (OpenGL 1.5+, GLSL) via generic Mesa code + | + +-> video decode acceleration + | + +-> OpenCL +"""]]
\ No newline at end of file diff --git a/radeonhd:packages.mdwn b/radeonhd:packages.mdwn new file mode 100644 index 00000000..2770a8bf --- /dev/null +++ b/radeonhd:packages.mdwn @@ -0,0 +1,26 @@ + + +# radeonhd packages + +Links to packages of [[radeonhd|radeonhd]] for different systems. + + +## deb-based systems + + * [[Debian|http://www.debian.org/]]: 2008-04-22: Version 1.2.1-1 in unstable. [[Debian radeonhd package page|http://packages.qa.debian.org/x/xserver-xorg-video-radeonhd.html]] + * [[Ubuntu|http://www.ubuntu.com/]]: 2008-01-03: Version 1.1.0-1 in Hardy (universe). [[Ubuntu radeonhd package page|https://launchpad.net/ubuntu/+source/xserver-xorg-video-radeonhd]]. Unofficial packages at [[https://wiki.ubuntu.com/XorgOnTheEdge|https://wiki.ubuntu.com/XorgOnTheEdge]] + +## ports-based systems + + * [[FreeBSD|http://www.freebsd.org/]]: [[ports/x11-drivers/xf86-video-radeonhd/ in cvsweb|http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-drivers/xf86-video-radeonhd/]] + * [[Gentoo|http://www.gentoo.org/]]: x11-drivers/xf86-video-radeonhd (to install, run **emerge -av xf86-video-radeonhd**) + * [[NetBSD|http://www.netbsd.org/]]: [[The NetBSD Packages Collection: x11/xf86-video-radeonhd|ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/x11/xf86-video-radeonhd/README.html]] + * [[OpenBSD|http://www.openbsd.org/]]: ??? + +## rpm-based systems + + * [[Fedora|http://fedoraproject.org]]: + * Easy command for F-10, F-11: `yum [--enablerepo=updates-testing] update xorg-x11-drv-radeonhd` + * The [[koji xorg-x11-drv-radeonhd page|http://koji.fedoraproject.org/koji/packageinfo?packageID=5156]] has the newest packages for F-10, F-11, and rawhide. Those will eventually filter down into your normal updates* yum repositories. + * Cf. [[viewcvs|http://cvs.fedoraproject.org/viewcvs/rpms/xorg-x11-drv-radeonhd/]], [[koji page|http://koji.fedoraproject.org/koji/packageinfo?packageID=5156]], [[update status|https://admin.fedoraproject.org/updates/xorg-x11-drv-radeonhd]], [[pkgdb bugs|https://admin.fedoraproject.org/pkgdb/packages/bugs/xorg-x11-drv-radeonhd]], [[fedora bz bugs|https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=xorg-x11-drv-radeonhd]], [[fdo bz bugs|https://bugs.freedesktop.org/buglist.cgi?quicksearch=radeonhd]]. + * [[openSUSE|http://www.opensuse.org/]]: [[radeonhd openSUSE search results|http://benjiweber.co.uk:8080/webpin/index.jsp?searchTerm=radeonhd]]
\ No newline at end of file diff --git a/radeonhd:r600_demo.mdwn b/radeonhd:r600_demo.mdwn new file mode 100644 index 00000000..eea48b41 --- /dev/null +++ b/radeonhd:r600_demo.mdwn @@ -0,0 +1,24 @@ + + +# r600_demo - 3D bringup tool for AMD GPG r6xx/r7xx Chipsets + +r600_demo is a bringup tool (read: only something for developers, and to show off, but not for real day use) for the newest graphics chips from AMD. It's based on register documentation and close work with the engineers at AMD. + +Main authors have been Alex Deucher from AMD and Matthias Hopf from Novell. Initial DRM implementation has been done by Dave Airlie from Redhat, most of the IP review is done (r600_demo, register specs) and pending (part of docs) by John Bridgman from AMD. + +The r600_demo git repo can be cloned from [[git://anongit.freedesktop.org/git/mesa/r600_demo|http://cgit.freedesktop.org/mesa/r600_demo/]] - instructions to compile and run are in the accompanying [[README|http://cgit.freedesktop.org/mesa/r600_demo/tree/README]]. You also need the [['''r6xx-r7xx-support'''-branch of mesa/drm|http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support]]. Note that due to the IP review process we cannot publish the original git repository at the moment, but a list of commits will be published at a later point of time. + +Announcements: + +* [[On xorg-devel, radeonhd, xorg-driver-ati by Alex Deucher on Dec 29, 2008|http://lists.freedesktop.org/archives/xorg/2008-December/041951.html]] +* [[On mesa-devel & dri-devel by Matthias Hopf on Dec 30, 2008|http://www.mail-archive.com/dri-devel%40lists.sourceforge.net/msg37356.html]] +Developer documentation: + +* [[r6xx Register descriptions|http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf]] +* [[r6xx Instruction descriptions|http://www.x.org/docs/AMD/r600isa.pdf]] - note changes r6xx vs. r7xx and (few) wrong ids, check r600_demo/r600_shader.h +* [[Blog entry of Matthias Hopf on Dec 30, 2008|http://emmes.livejournal.com/3435.html]] - description of r600_demo layout +* [[Slides on r600_demo talk from Matthias Hopf in X.org DevRoom on Fosdem 2009|http://www.vis.uni-stuttgart.de/~hopf/pub/Fosdem_2009_r600demo_Slides.pdf]] - Explanation of the r[67]xx architecture and of pitfalls you can fall into +* [[Errata sheet|radeonhd:r6xxErrata]] - wiki page with additional information, erratas, and explanation of difficult areas +Reviews / validation: + +* [[Phoronix on Dec 31, 2008|http://www.phoronix.com/scan.php?page=article&item=amd_rv770_triangles&num=1]]
\ No newline at end of file diff --git a/radeonhd:r6xxErrata.mdwn b/radeonhd:r6xxErrata.mdwn new file mode 100644 index 00000000..59af85ce --- /dev/null +++ b/radeonhd:r6xxErrata.mdwn @@ -0,0 +1,80 @@ + + +# r[67]xx Errata Sheet + +This page explains difficult areas of the r[67]xx GPU series, things missing in the official documentation, and describes pitfalls you can fall into. In addition, it also serves as a regular errata sheet, correcting information in the official documentation. + +[[!toc 1]] + + +# Erratas + +Only issues <em>known</em> to be wrong in the official documentation will be brought up here. If anything is doubtful, it should be rather added to a later section. + + +## r600isa.pdf + +[[r600isa.pdf|http://www.x.org/docs/AMD/r600isa.pdf]] documents the shader unit instruction set. + +pp. 7-9: Control flow instruction numbers are partially wrong. Some even duplicated. Numbers in [[R6xx_3D_Registers.pdf|http://www.x.org/docs/AMD/R6xx_3D_Registers.pdf]] are apparently correct. +[[!format txt """ +SQ_CF_INST_CALL is 0x12 (not 0x0d) +SQ_CF_INST_CALL_FS is 0x13 (not 0x0f) +SQ_CF_INST_CUT_VERTEX is 0x17 (not 0x14) +SQ_CF_INST_ELSE is 0x0d (not 0x11) +SQ_CF_INST_EMIT_CUT_VERTEX is 0x16 (not 0x13) +SQ_CF_INST_EMIT_VERTEX is 0x15 (not 0x12) +SQ_CF_INST_JUMP is 0x0a (not 0x10) +SQ_CF_INST_KILL is 0x18 (not 0x15) +SQ_CF_INST_LOOP_START_DX10 is 0x06 (not 0x04) +SQ_CF_INST_MEM_EXPORT is unknown (also RV670 only) +SQ_CF_INST_MEM_STREAM3 is 0x23 (not 0x32, decimal description 35 is correct) +SQ_CF_INST_POP is 0x0e (not 0x0c) +SQ_CF_INST_PUSH is 0x0b (not 0x0a) +SQ_CF_INST_PUSH_ELSE is 0x0c (not 0x0b) +SQ_CF_INST_RETURN is 0x14 (not 0x0e) +"""]] + +# Known Hardware Limitations + + +# Unexplained Hardware Behavior + + +# Additional Documentation + + +# Glossary + +**Hardware Groups** +[[!format txt """ +CB Color Block Color buffer +DB Depth Block Depth buffer +GRBM Graphics Register Block Registers 0x8000-0x2fffc +PA Primitive Assembler Scissors, Cliprects, Point sprites +SPI Shader Processor Interpolator Semantic mapping, interpolators +SQ Sequencer / Shader Shader management, exports, register alloc +SRBM System Register Block Registers 0x0000-0x7ffc +SX Shader Export Output mapping, output buffers +VGT Vertex Grouper Tessellator Everthing related to vertex setup, viewport transformation, etc. +"""]] +**Shaders** + +Pixel and vertex shader are mandatory. Only one vertex shader at a time. Fetch shader and geometry shader may be disabled (fetch shader by just not using SQ_INST_CALL_FS). +[[!format txt """ +ES Export Shader Early vertex shader, used w/ GS only +FS Fetch Shader Subroutine, may be called in vertex shader context +GS Geometry Shader May kill or tessellate primitives +VS Vertex Shader Used w/o GS only +PS Pixel Shader +"""]] +**Data Structures** +[[!format txt """ +VB Vertex Buffer List of coordinates and attributes in memory +"""]] +**System** +[[!format txt """ +DRM Direct Rendering Manager Kernel component for buffer submission and resource management +GART Graphics Aperture Remapping Table Main memory mapped in write-combined mode for GPU access +GPU Graphics Processing Unit Main r[67]xx chip +"""]]
\ No newline at end of file diff --git a/radeonhd:r6xx_r7xx_branch.mdwn b/radeonhd:r6xx_r7xx_branch.mdwn new file mode 100644 index 00000000..acce525a --- /dev/null +++ b/radeonhd:r6xx_r7xx_branch.mdwn @@ -0,0 +1,45 @@ + + +# Before you start + +For 6xx/7xx 2D acceleration, you **don't** need to use a branch of radeonhd any more - standard, **released version 1.2.5 is enough**. + +You still need correct version of drm (kernel) driver. You can just install 2.6.30 kernel, or the Ubuntu Jaunty default kernel, or use following instruction for that. The alternative driver, [[radeon|radeon]], can also [[utilize|radeon:r6xx_r7xx_branch]] the same drm branch for the same features. + +Current status is : + +* It should provide EXA acceleration, Xv acceleration. +* AGP support has been recently added +* Corruption problems believed to be fixed +* Hanging on VT switch believed to be fixed +* r6xx-r7xx-support branch were merged into master for both radeonhd and radeon +* You **must** use drm code from r6xx-7xx branch of mesa drm or 2.6.30 kernel, or an older kernel (eg. Jaunty) with backported support. + +## How to build drm from r6xx-7xx branch of mesa drm + +* checkout the source for the drm: + +[[!format txt """ + git clone git://anongit.freedesktop.org/mesa/drm +"""]] +* switch drm to the experimental branch and build its modules : + +[[!format txt """ + cd drm/linux-core + git checkout -b r6xx-r7xx-support origin/r6xx-r7xx-support + make radeon.o drm.o + find /lib/modules -name "radeon.ko" -o -name "drm.ko" + sudo cp radeon.ko /lib/modules/$(uname -r)/.../radeon.ko + sudo cp drm.ko /lib/modules/$(uname -r)/.../drm.ko +"""]] +This last path will likely depend upon your linux distribution. + + +## How to enable EXA and Xv + +* configure your xorg.conf ; you need at least two options in the **Device** section : + +[[!format txt """ + Option "AccelMethod" "exa" # default shadowfb + Option "DRI" "on" +"""]]
\ No newline at end of file diff --git a/rendition.mdwn b/rendition.mdwn new file mode 100644 index 00000000..6b96b8e7 --- /dev/null +++ b/rendition.mdwn @@ -0,0 +1,16 @@ + + +# rendition + +Driver for Rendition/Micron based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/rendition.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/rendtion.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/s3.mdwn b/s3.mdwn new file mode 100644 index 00000000..9b93d335 --- /dev/null +++ b/s3.mdwn @@ -0,0 +1,14 @@ + + +# s3 + +Driver for S3(except !ViRGE or Savage) based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/s3virge.mdwn b/s3virge.mdwn new file mode 100644 index 00000000..01f82a98 --- /dev/null +++ b/s3virge.mdwn @@ -0,0 +1,5 @@ + + +# s3virge + +Driver for S3 ViRGE based video chips. License: MIT diff --git a/savage.mdwn b/savage.mdwn new file mode 100644 index 00000000..af64deca --- /dev/null +++ b/savage.mdwn @@ -0,0 +1,15 @@ + + +# savage + +Driver for S3 Savage based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://dri.freedesktop.org/wiki/S3Savage]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/siliconmotion.mdwn b/siliconmotion.mdwn new file mode 100644 index 00000000..5ae8579e --- /dev/null +++ b/siliconmotion.mdwn @@ -0,0 +1,16 @@ + + +# siliconmotion + +Driver for Silicon Motion based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/siliconmotion.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/siliconmotion.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/sis.mdwn b/sis.mdwn new file mode 100644 index 00000000..a1c1062e --- /dev/null +++ b/sis.mdwn @@ -0,0 +1,27 @@ + + +# sis + +Driver for Silicon Integrated Systems (SiS) video chips. + +License: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3) The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/SiS.4.html]] for the current release for configuration options. + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/sis.4.html]] containing additional information about known problems and hints. + * Author and maintainer's [[website|http://www.winischhofer.net/linuxsisvga.shtml]] with complete documentation and updates + +## Known Issues + + +### Release 6.7.0 + + * Pixmap 24->32 and 32->24 conversion not advertised + * 661/741/760 support has problems (chipsets were not on the market then) + * On 1400x1050 and 1600x1200 panels, some modes don't work + +### Release 6.8.1 + + * None known
\ No newline at end of file diff --git a/sunbw2.mdwn b/sunbw2.mdwn new file mode 100644 index 00000000..aade26e2 --- /dev/null +++ b/sunbw2.mdwn @@ -0,0 +1,14 @@ + + +# sunbw2 + +Driver for SUN bw2 based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/suncg14.mdwn b/suncg14.mdwn new file mode 100644 index 00000000..40676bd3 --- /dev/null +++ b/suncg14.mdwn @@ -0,0 +1,14 @@ + + +# suncg14 + +Driver for SUN cg14 based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/suncg3.mdwn b/suncg3.mdwn new file mode 100644 index 00000000..3e071bfa --- /dev/null +++ b/suncg3.mdwn @@ -0,0 +1,14 @@ + + +# suncg3 + +Driver for SUN cg3 based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/suncg6.mdwn b/suncg6.mdwn new file mode 100644 index 00000000..3c7d98af --- /dev/null +++ b/suncg6.mdwn @@ -0,0 +1,14 @@ + + +# suncg6 + +Driver for SUN GX and Turbo GX based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/sunffb.mdwn b/sunffb.mdwn new file mode 100644 index 00000000..f1407edb --- /dev/null +++ b/sunffb.mdwn @@ -0,0 +1,14 @@ + + +# sunffb + +Driver for SUN Creator/3D, Elite 3D based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/sunleo.mdwn b/sunleo.mdwn new file mode 100644 index 00000000..8c2e42dd --- /dev/null +++ b/sunleo.mdwn @@ -0,0 +1,14 @@ + + +# sunleo + +Driver for SUN Leo (ZX) based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/suntcx.mdwn b/suntcx.mdwn new file mode 100644 index 00000000..93936698 --- /dev/null +++ b/suntcx.mdwn @@ -0,0 +1,14 @@ + + +# suntcx + +Driver for SUN TCX based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/tdfx.mdwn b/tdfx.mdwn new file mode 100644 index 00000000..260735fe --- /dev/null +++ b/tdfx.mdwn @@ -0,0 +1,15 @@ + + +# tdfx + +Driver for 3Dfx based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/tdfx.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/tga.mdwn b/tga.mdwn new file mode 100644 index 00000000..3f5c31ad --- /dev/null +++ b/tga.mdwn @@ -0,0 +1,15 @@ + + +# tga + +Driver for DEC TGA based video chips. License: MIT + + +## Documentation and Support + + * There is also a [[README file|http://www.freedesktop.org/~xorg/current/doc/DECtga.4.html]] containing additional information about known problems and hints. + +## Known Issues + + +### Release 6.7.0 diff --git a/to_convert2 b/to_convert2 new file mode 100644 index 00000000..5216c870 --- /dev/null +++ b/to_convert2 @@ -0,0 +1,596 @@ +BoardOfDirectors(2f)Elections(2f)2011(2f)qa +fosdem2013 +CategoryServerInternals +ChangeLogStyle +CrossCompilingXorgJhbuild +XDevConf +XDevConf(c38a)mbridge2005 +Fosdem2006DevRoomAttendants +Development(2f)Documentation(2f)PointerAccelerationAsOf16 +Development(2f)Documentation(2f)VersionNumberScheme +Development(2f)Documentation(2f)WritingDocumentation +Other(2f)Press(2f)X11R76Released +ChangesForX11R71 +PressReleases(2f)X11R72Released +Other(2f)Press(2f)X11R72Released +DeprecatedInX11R7 +X11R71Release +X11R72Issues +X11R72Release +ChangesForX11R73 +ChangesForX11R72 +X11R7and69TODO +X11R70Release +PressReleases(2f)X11R71Released +Other(2f)Press(2f)X11R71Released +Other(2f)Press(2f)X11R75Released +MattDew(2f)docbooktest +Development(2f)Documentation(2f)DocBookConversion +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +china(20)hotels +Events(2f)XDS2010(2f)Hotels +Events(2f)XDC2012(2f)Hotels +BookingAmsterdam(20)Hotels +Events(2f)XDC2012(2f)Proceedings +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDC2012(2f)PublicTransportation +Events(2f)XDC2012(2f)Weekend +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Events(2f)XDS2008(2f)Recordings +Events(2f)XDC2011(2f)Attendees +Events(2f)XDS2007(2f)Attendees +Events(2f)XDC2012(2f)Attendees +Events(2f)XDS2008(2f)Attendees +Events(2f)XDS2010(2f)Attendees +Events(2f)XDC2009(2f)Attendees +Events(2f)XDC2008(2f)Attendees +china(20)hotels +Events(2f)XDS2010(2f)Hotels +Events(2f)XDC2012(2f)Hotels +BookingAmsterdam(20)Hotels +HelpOnLinking(2f)NotesLinks +XDC2007(ee8080)Notes(ee8081) +Events(2f)XDC2008(2f)Notes +Events(2f)XDS2010(2f)Notes +XDC(ee8080)2007(ee8081)Notes +Events(2f)XDS2008(2f)Notes +xdc2007notes +XKBLayoutCreationNotes +Events(2f)XDC2009(2f)Notes +XDC2007Notes +ReleaseNotes670 +Events(2f)XDC2011(2f)Notes +X11R68PostPartumNotes +Events(2f)XDS2007(2f)Notes +Antivirus(20)Software(20)program(20)for(20)Mobile(20)Devices +Events(2f)XDC2011(2f)Program +Events(2f)XDC2012(2f)Program +Events(2f)XDS2008(2f)Program +wiki(2f)Events(2f)XDS2010(2f)Program +Events(2f)XDC2008(2f)Program +Events(2f)XDC2009(2f)Program +Events(2f)XDS2010(2f)Program +ProgrammingDocumentation +RadeonProgram +Events(2f)XDS2007(2f)Program +Fosdem2006DevRoomAttendants +Fosdem2006HotHouseParticipants +FrontPage +HelpMiscellaneous(2f)ExperimentalFeatures +HelpMiscellaneous(2f)FrequentlyAskedQuestions +HelpOnActions(2f)AttachFile +HelpOnConfiguration(2f)EmailSupport +HelpOnConfiguration(2f)CascadingStyleSheets +HelpOnConfiguration(2f)EmailSupport +HelpOnConfiguration(2f)SecurityPolicy +HelpOnConfiguration +HelpOnFormatting +HelpOnInstalling(2f)ApacheOnMacOsx +HelpOnInstalling(2f)ApacheOnUnix +HelpOnInstalling(2f)ApacheOnWin32 +HelpOnInstalling(2f)ApacheWithFastCgi +HelpOnInstalling(2f)ApacheWithModPython +HelpOnInstalling(2f)BasicInstallation +HelpOnInstalling(2f)InternetInformationServer +HelpOnInstalling(2f)TroubleShooting +HelpOnInstalling(2f)TwistedWeb +HelpOnMacros +HelpOnMacros(2f)Include +HelpOnMacros(2f)MailTo +HelpOnPageDeletion +HelpOnProcessors +HelpOnSmileys +HelpOnSpellCheck +HelpOnTables +HelpOnThemes +HelpOnUpdating +Fosdem2006HotHouseParticipants +Events(2f)XDC2012(2f)XDC2012AbstractIanRomanick +XInputHotplug +InterWiki +InterWikiMap +LinuxTagMeeting2005Zack +LinuxTagMeetingLuc +LinuxTagOrganization2006 +LinuxTagMeetingGunnar +LinuxTagMeeting2005DavidR +LinuxTagMeeting2005 +LinuxTagMeetingMatthias +LinuxTagMeetingGianFilippo +LinuxTagMeeting2005Participants +LinuxTagMeetingLars +LinuxTagMeetingZack +LinuxTag2005Infos +LinuxTagMeeting2005Schedule +LinuxTagMeeting2005Lars +LinuxTagMeeting +LinuxTagMeetingParticipants +LinuxTagMeeting2005GianFilippo +LinuxTagMeetingDaniel +LinuxTagMeeting2005Gunnar +LinuxTagInfos +LinuxTagMeeting2005Matthias +LinuxTagMeetingDavidR +LinuxTagMeetingSchedule +LinuxTagMeeting2005Daniel +LinuxTagMeeting2005KaiUwe +LinuxTagMeetingKaiUwe +LinuxTagMeeting2005Luc +LinuxTag2005Infos +LinuxTagMeeting2005Participants +LinuxTagMeeting2005Schedule +MakingReleases +Events(2f)XDC2012(2f)XDC2012AbstractOliverMcFadden +MesaSolo +Events(2f)XDC2012(2f)XDC2012AbstractMichaelLarabel +MichaelLarabel +MichaelVerret +MoinMoin(2f)TextFormatting +OpenMotif +Other(2f)Press(2f)CFP2012_supplemental +Other(2f)Press(2f)CFP2012 +Other(2f)Press(2f)CFP2012_supplemental +PageSize +Events(2f)XDC2012(2f)XDC2012AbstractPeterHutterer +XOrgInputDriverSpec +XInputCoordinateTransformationMatrixUsage +Development(2f)Documentation(2f)InputEventProcessing +XInputSpec +XInputHotplug +Development(2f)InputOverhaul +InputDriverRoadmap +Development(2f)Documentation(2f)XorgInputHOWTO +InputEventProcessing +Development(2f)Documentation(2f)MPX +Mirrors +FTPXOrgMirrors +SecurityTalkAgenda +StructuredText +SystemInfo +TitleIndex +UpdateProblems +UserPreferences +HelpOnUserPreferences +WantedPages +WordIndex +X11R682ReleasePlan +Other(2f)Press(2f)X11R682Released +X11R6970ReleasePlan +X11R68ScreenShots +X11R68Release +X11R6970Testing +PressReleases(2f)X11r682Released +X11R682Release +PressReleases(2f)X11R6970Released +X11R681Release +X11R6970ReleaseStatus +PressReleases(2f)X11r682Released(22) +X11R69Release +X11R68ReleaseStatus +X11R68PostPartumNotes +X11R68ReleasePlan +Other(2f)Press(2f)X11R6970Released +Other(2f)Press(2f)X11R76Released +ChangesForX11R71 +PressReleases(2f)X11R72Released +Other(2f)Press(2f)X11R72Released +DeprecatedInX11R7 +X11R71Release +X11R72Issues +X11R72Release +ChangesForX11R73 +ChangesForX11R72 +X11R7and69TODO +X11R70Release +PressReleases(2f)X11R71Released +Other(2f)Press(2f)X11R71Released +Other(2f)Press(2f)X11R75Released +XDevConf +XDevConf(c38a)mbridge2005 +XKBLayoutCreationNotes +XKB +fosdem2013 +XsltVersion +apm +Dating(20)Success(20)For(20)Single(20)Boomer(20)Women(2c20)Should(20)I(20)Consider(20)Cougar(20)Dating(3f202d20)Dating(20)Benjamin(20)Braddock +GSoCApplication +Flash(20)Games(20)or(2e20)Full(20)Generation(20)Games +HelpOnInstalling(2f)WikiInstanceCreation +XInputCoordinateTransformationMatrixUsage +LatiaR +Lasers(2b)and(2b)aviation(2b)safety +LinuxTagOrganization2006 +PVD(2c)PVD(2b)coatings +Development(2f)Documentation(2f)XServerStableBranchManagement +MarinaLatini +Development(2f)Documentation(2f)InputEventProcessing +Development(2f)Documentation(2f)Security +BuildingDocumentation +Development(2f)Documentation(2f)Multitouch +A(20)Few(20)Questions(20)On(20)Realistic(20)debt(20)consolidation(20)loans(20)Solutions +Terminology(20)Intended(20)for(20)Wedding(20)Invitations(203a20)An(20)overview +ConfigurationHelp +edible(20)Arrangements(20)Coupons(20)creative(20)concepts(20)33 +Proactol(20)creative(20)ideas(20)49 +XorgFoundation(2f)Reports(2f)2010 +ModularizationWorkingGroup +Every(20)organization(20)wants(20)qualified(20)marketing(20)and(20)advertising(202d20)check(20)why(20)Seo(20)is(20)known(20)as(20)a(20)appropriate(20)method(20)of(20)drawing(20)clients(20)interest +Development(2f)Documentation(2f)ServerProfiling +Development(2f)Documentation(2f)Multiseat +ati +installation(2f)yesevpajaron +Lifeflow(20)Meditation(20)Is(20)the(20)Simpler(20)Way(20)to(20)Achieve(20)Deep(20)Meditation +Humor(20)seems(20)to(20)be(20)the(20)very(20)best(20)response(20)for(20)any(20)complications(20)folks(20)need(20)to(20)control +Development(2f)Documentation(2f)KdriveDrivers +HelpOnInstalling(2f)InternetInformationServer +NatishaG3 +HelpOnConfiguration(2f)CascadingStyleSheets +Housing(2b)renovation +In(20)which(20)and(20)how(20)you(20)can(20)easily(20)develop(20)you(20)Search(20)engine(20)optimization(20)expertise +Development(2f)Documentation(2f)UsingEclipse +Development(2f)Documentation(2f)WritingDocumentation +WebStatistics +Information(20)on(20)Significant(20)Aspects(20)Throughout(20)it(20)support +Development(2f)Documentation(2f)ReleaseHOWTO +Development(2f)Documentation(2f)CursorHandling +HelpOnSlideShows(2f)900_Last_but_not_least(3a)_Running_your_presentation(2e) +MatildaLrn +Prudent(20)Strategies(20)In(20)debt(20)consolidation(20)loans(202d20)Some(20)Useful(20)Questions +Search(20)Engine(20)Optimisation +Donations +HelpOnConfiguration(2f)EmailSupport +Development(2f)Documentation(2f)XGE +WikiCourse(2f)BasicIntroduction(2f)210_Organisation_and_Structure +Documentation +Other(2f)Press(2f)501c3StatusDetermination +Development(2f)Documentation(2f)git +SizeGenetics(20)Stretcher(20)Evaluation(202a20)Read(20)Before(20)getting(20)Discounted(20)Promotion +PeopleProjectsPresentation +wiki(2f)Development(2f)Documentation(2f)Obsolescence +High(20)Fiber(20)Diet(20)Nuggets(20)of(20)information(20)64 +Development(2f)Documentation(2f)Performance +Development(2f)Documentation(2f)Glossary +Wedding(20)Invitation(20)Wording(20)Basics +male(20)Edge(20)Nuggets(20)of(20)information(20)49 +KatiaNh +HelpOnConfiguration(2f)SecurityPolicy +UserDocumentation +Development(2f)Documentation(2f)DevPrivates +XKBLayoutCreationNotes +Development(2f)Documentation(2f)DocBookConversion +Development(2f)Documentation(2f)SubmittingPatches +Development(2f)Documentation(2f)HowVideoCardsWork +SiteNavigation +zara(20)Shoes(20)Nuggets(20)of(20)information(20)49 +atidrivers +Development(2f)Documentation(2f)Protocol(2f)OpCodes +Development(2f)Documentation(2f)VersionNumberScheme +ATIProprietaryDriver +Development(2f)Documentation(2f)WrappingFunctions +Seoul(2c20)the(20)introduction(20)of(20)foreign(20)language(20)specialists(2022)International(20)Taxi(22) +debt(20)consolidation(202d20)New(20)Insights +Flash(20)Games(20)vs(2e20)Full(20)Generation(20)Games +Development(2f)Documentation(2f)MPX +NatishaS +Development(2f)Documentation(2f)XserverSourceLayout +Development(2f)Documentation(2f)PointerAcceleration +Development(2f)Documentation(2f)PointerAccelerationAsOf16 +Development(2f)Security(2f)Organization +Development(2f)Documentation(2f)XorgVideoHOWTO +ModularizationDevelPlan +AngelikaTi +Development(2f)Documentation(2f)XorgInputHOWTO +search(2b)engine(2b)optimization +HelpOnInstalling(2f)BasicInstallation +Development(2f)Documentation(2f)Obsolescence +Expensive(20)Games(20)or(2e20)Full(20)Creation(20)Games +HelpOnSlideShows(2f)100_Creating_the_slides +FAQMigration +XorgDeveloperDocumentation +ProgrammingDocumentation +Development(2f)Documentation(2f)ClientSideThreads +TheShopper(27)sInformationToShort(20)Cocktail(20)Dresses +XorgFoundation +UserDocumentation(2f)GettingStarted +Bank(2b)of(2b)Communications +Popular(20)Interview(20)Questions(20)Differ(20)Per(20)Occupations +HelpOnNavigation +LookingGlassIntegration +HelpOnAdministration +GitMigration +Development(2f)Documentation(2f)GrabProcessing +MatildaBv +Expert(20)Search(20)engine(20)optimization(20)and(20)suchmaschinenoptimierung(3a20)Outsource(20)the(20)Job(20)or(20)decide(20)to(20)educate(20)yourself(20)and(20)diy +WikiCourse(2f)BasicIntroduction(2f)191_Creating_new_Pages +Development(2f)Documentation(2f)UsingCtags +Drivers(20)and(20)documentation(20)for(20)ATI(2f)AMD(20)GPUs +Development(2f)Documentation(2f)ServerDebugging +HelpOnConfiguration +atimisc +JLatia +HelpOnPageCreation +Development(2f)Documentation(2f)BuildingDocumentation +ModularizationProposal +X(2e)Org(2d)GSoC2008(2d)Application +Tava(20)Tea(20)creative(20)concepts(20)19 +Events(2f)XDC2012(2f)PublicTransportation +HelpOnUpdating +Adultdating_587 +atimisc +chips +IntelLaptopChips +cyrix +fbdev +fosdem2006Daniel +fosdem2006Egbert +fosdem2006Luc +fosdem2006Matthias +fosdem2006Stephane +AMDGeodeDriver +geode +GeodeDriver +glide +glint +Casement(20)Window(20)sexcam(20)Handles +i128 +i740 +imstt +IntelMemoryChannels +IntelVideoDriver +Intel28Branch +IntelGraphicsDriver +IntelLaptopChips +Intel29Branch +intel +neomagic +newport +openscourse +nsc +r128 +radeonhd(3a)experimental_3D +vmware(2f)vmware3D +(d098d0b3d0bed180d18c20d094d0b5d0bcd187d0b5d0bdd0bad0be) +radeonhd(3a)r600_demo +Exam(2b)Microsoft(2b)74(2d)137(2b)Demo +radeonhd(3a)r6xx_r7xx_branch(272727)experimental(272727) +radeonhd(3a)r6xx_r7xx_branch +radeon(3a)r6xx_r7xx_branch +CvsBranches +Server14Branch +radeonhd(3a)r6xx_r7xx_branch(272727)experimental(272727) +Intel28Branch +Server13Branch +Server12Branch +Server19Branch +Development(2f)Documentation(2f)XServerStableBranchManagement +Server17Branch +Server16Branch +Intel29Branch +Server111Branch +Server110Branch +Server15Branch +Server112Branch +radeonhd(3a)r6xx_r7xx_branch +Server18Branch +CvsBranchnames +radeon(3a)r6xx_r7xx_branch +Server113Branch +rendition +siliconmotion +sunbw2 +suncg14 +suncg3 +suncg6 +sunffb +sunleo +suntcx +tdfx +Present(20)And(20)Future(20)Market(20)Trends(20)For(20)Mortgage(20)Savings(20)Account +tga +hotgal1 +Canada(20)Mortgage(20)Savings(20)Account(202d20)What(20)exactly(20)is(20)up(20)for(20)grabs(20)For(20)2010(2d)2011(3f) +tseng +VgaArbiter +vga +Lasers(2b)and(2b)aviation(2b)safety +bellaviahansard204 +via +Vivian56 +Sylvia5 +VivianLke +SylviaLv diff --git a/trident.mdwn b/trident.mdwn new file mode 100644 index 00000000..30246e73 --- /dev/null +++ b/trident.mdwn @@ -0,0 +1,15 @@ + + +# trident + +Driver for Trident based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/trident.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/tseng.mdwn b/tseng.mdwn new file mode 100644 index 00000000..ee5df3a1 --- /dev/null +++ b/tseng.mdwn @@ -0,0 +1,14 @@ + + +# tseng + +Driver for Tseng Labs based video chips. License: MIT + + +## Documentation and Support + + +## Known Issues + + +### Release 6.7.0 diff --git a/vesa.mdwn b/vesa.mdwn new file mode 100644 index 00000000..c3c9aeba --- /dev/null +++ b/vesa.mdwn @@ -0,0 +1,15 @@ + + +# vesa + +Driver for VESA based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.x.org/archive/X11R7.0/doc/html/vesa.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/vga.mdwn b/vga.mdwn new file mode 100644 index 00000000..b674524f --- /dev/null +++ b/vga.mdwn @@ -0,0 +1,15 @@ + + +# vga + +Driver for Generic VGA based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.x.org/archive/X11R7.0/doc/html/vga.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 diff --git a/via.mdwn b/via.mdwn new file mode 100644 index 00000000..ecbef5c8 --- /dev/null +++ b/via.mdwn @@ -0,0 +1,17 @@ + + +# via + +Driver for VIA based video chips. License: MIT + + +## Documentation and Support + + * Please check the [[manual page|http://www.freedesktop.org/~xorg/current/doc/via.4.html]] for the current release for configuration options. + +## Known Issues + + +### Release 6.7.0 + +This URL appears to be broken. diff --git a/vmware.mdwn b/vmware.mdwn new file mode 100644 index 00000000..eb82a3e8 --- /dev/null +++ b/vmware.mdwn @@ -0,0 +1,36 @@ + + +# Drivers for VMware virtual graphics + + +## Drivers + +The Xorg graphics driver for the VMware virtual graphics- and mouse devices consist of + +* xf86-video-vmware - The video driver. Driver binary is vmware_drv.so. The version 12.0 contains support for accelerated OpenGL. +* xf86-input-vmmouse - The mouse driver. Driver binaries are vmmouse_drv.so and vmmouse_detect +* The kernel video driver - vmwgfx. This currently resides in kernel 3.2.0 and higher. + +### 3D support + +Don't miss [[our 3D page|vmware/vmware3D]]! + + +## Maintainer + +VMware currently maintain these drivers. The maintainer email is <linux-graphics-maintainer-at-vmware-dot-com>. Patches touching the driver should have an Acked-by: or Signed-off-by: from a maintainer, and new releases are cut by a maintainer only. Please send patches and release requests to the xorg-devel mailing list with a CC to the maintainer email. + + +## License + +MIT-style. + + +## News + +* 2012-02-10 Zack Rusin has pushed a patch to mesa master which makes accelerated OpenVG run on vmwgfx EGL, in addition to the OpenGL and OpenGL-ES APIs (OpenVG requires the egl_gallium EGL driver, not the egl_dri2 EGL driver). This patch will be cherry-picked for mesa 8.0, but OpenVG and OpenGL-ES on vmwgfx is still experimental and not officialy supported. +* 2012-02-10 The kernel driver version 2.4.0 now contains support for fake page-flipping. This is to enable support for the Wayland demo compositor to run on vmwgfx EGL on the drm platform. I'ts called "fake" because currently it's implemented as a blit operation, and we don't yet support sync-to-vblank. The fake page-flipping support will probably enter linux 3.4.0, but anyone eager to try out can use the standalone vmwgfx kernel driver. +* 2012-02-07 Our enhanced drivers with [[RandR12|RandR12]]+ and 3D support are now enabled by default in ubuntu 12.04 daily build isos. +* 2012-01-24 VMware Workstation 8.0.2 and VMware Player 4.0.2 have been released. These releases contain correctness- and performance fixes for Linux 3D. +* 2012-01-13 An alpha version of a 3D / KMS [[/RandR12|vmware/RandR12]] - capable xf86-video-vmware is due to be released in the next few days Refer to our [[3D|vmware/vmware3D]] page for additional information. +* 2012-01-11 xf86-video-vmware 11.1.0 was released. This is a stable release.
\ No newline at end of file diff --git a/vmware/vmware3D.mdwn b/vmware/vmware3D.mdwn new file mode 100644 index 00000000..5dd6a0af --- /dev/null +++ b/vmware/vmware3D.mdwn @@ -0,0 +1,32 @@ + + +# Support for 3D acceleration and RandR 1.2 in xf86-video-vmware + + +## What's needed + +* xf86-video-vmware >= 11.9.x. The stable release will be named 12.0.0 +* A linux kernel with the post-staging version of the vmwgfx driver enabled. The vmwgfx kernel driver version should be 2.3.0 or higher. +* A Mesa release or checkout from the 8.0 branch with the dri-vmwgfx and xa-vmwgfx targets enabled. +* VMware Workstation 8.0.2, VMware Fusion 4.1.2 or VMware Player 4.0.2. Strictly the driver should run with Workstation 8.0, Fusion 4.0 or Player 4.0, but glxSwapBuffers will be very slow and there might be some additional rendering problems as well. In short: At least don't try to benchmark the driver performance withouth a recommended version of Workstation, Fusion or Player. +* libdrm does not need any specific vmware options enabled. + +## Generic User Notes + +* Due to the way software- (2D) and accelerated (Video, 3D) contents are mixed, certain operations may be slow when both accelerated contents and software contents overlap. Mixing software- and accelerated contents in a virtual environment is tricky and we've tried to optimize the driver to give the best possible interactive experience for most use cases and the new 3D-enabled compositors. +* XRender will usually not be accelerated unless operating on previously rendered 3D- or video surfaces. Therefore setups that use XRender for big operations, like XRender-enabled compositing managers, may consume a lot of CPU on large screens. The interactivity feeling when running, for example Kwin with Xrender effects enabled should be fairly good, particularly if your processor is fast. +* On multi-monitor setups the glxSwapBuffers operations are still a bit slow. This will be addressed in future Workstation / Fusion releases. To somewhat work around this problem, it's possible to reduce the Workstation / Fusion GUI update frequency using the following .vmx file option: (The number is the minumum delay in microseconds between GUI updates). + [[!format txt """ +svga.frameRateLimitUS = 15000 +"""]] +* Applications that warp the cursor, like games or the Compiz spinning cube will not work well with VMmouse enabled, since it uses the host cursor. If this becomes a problem for you, please use the following .vmx file option to disable VMmouse, and use the VMware relative USB mouse instead: (Motion ungrab will be lost and you'll see a slightly increased cursor lag). [[!format txt """ +mouse.vusb.enable = "TRUE" +"""]] +* The VMware absolute USB mouse device may, on many distributions, be detected by the udev system as a joystick. This may lead to games moving the cursor to the upper left corner or the game constantly registering a leftward-upward motion. To work around this, please disable joystick use in the game's setup, or if you have another joystick, select that one instead. +* If you use fancy RandR 1.2 features, like rotation and / or scaling and at the same time use VMMouse, cursors may not behave as expected. In that case, set up the relative USB mouse as described above. The driver is only capable of displaying a single hardware cursor at a time, so if more cursors need to be displayed, like when cloning outputs, the driver will automatically revert to software cursors. + +## Generic Developer Notes + +* What is SAA, and why wasn't EXA used? SAA or "Shadow Acceleration Architecture" is a simple acceleration architecture with combines code from both EXA and Intel's UXA. SAA is very simple and intended to be used by drivers that really don't want to accelerate everything, and if the driver needs to accelerate, SAA attempts to accurately track exactly what contents is accelerated. The idea behind this is that it's often more costly to set up the accelerator state than to perform the render operation in software on cached memory. The drawback is that large copies or render operations are slower. EXA and UXA aren't tracking rendered areas carefully enough, and modifying EXA to do that would have required invasive changes in internal- and driver EXA apis. However, it should, with a decent amount of work and testing, be possible to implement SAA as an EXA migration policy. +* Is xf86-video-vmware eventually going to accelerate 2D and XRender fully? Possibly, but in virtual environments, migration between guest contents (software rendered stuff) and hypervisor contents (accelerated stuff) is slow and painful. Creation and destruction of accelerated pixmaps is also a very slow operation. The fact that [[D3D9|D3D9]] doesn't support logicops is also a limiting factor. To fully support 2D and XRendeR operation means that we must be able to accelerate everything, and when there are fallbacks we need render in software and blend the result onto the destination, possibly using logicops and non-rectangular shapes for things like diagonal lines. The question then arises whether this will actually give better interactivity than the current mixing of software- and accelerated contents. +* What is XA and how is SAA and XA related? XA is a freestanding acceleration API that is intended to be useful for X acceleration architectures. The VMware driver is using it to handle acceleration requests from SAA, but it could also theoretically be interfaced with EXA or UXA. The XA version used by xf86-video-vmware is naturally using Gallium3D to accelerate, but it should also be possible to implement XA on top of EGL, for example. XA has support for XRender-like operations and YUV conversions. It's used by xf86-video-vmware to accelerate XRender when needed, for accelerated copies when needed (glxSwapBuffers or compositing of previously accelerated contents), and for the textured XVideo adaptor.
\ No newline at end of file |
