<div class="gmail_quote">2009/10/2 Michel Dänzer <span dir="ltr">&lt;<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>&gt;</span><br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Thu, 2009-10-01 at 08:26 -0700, Daniel Stone wrote:<br><br>&gt; There were a couple of different motivations for this, one was to make<br>&gt; building things a great deal easier<br></div>Would it really? IME complications have mostly been due to things like<br>
protos, not directly between xserver and drivers.<br></blockquote>
<div>I agree protos could sometime bring complications to the existing X server architecture or API/ABI support, especially when we try to introduce new features.  However, driver out-of-sync with server is one of the major issues for on-going xserver releases.  Without testing the driver on the xserver release candidate, there is no way for us, device driver developers, to say for sure if our drivers will be compatible with the new release or not. </div>

<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">&gt; What&#39;re your concerns?<br><br>First of all, surely the onus is on those who want to move the drivers<br>
into the xserver tree to present convincing arguments in support of it.<br></blockquote>
<div>I think moving drivers into xserver tree benefits both driver and xserver developers as well as distro maintainers.  IMO (I don&#39;t know what those at XDC&#39;s BoF were agreed on), moving a specific driver into xserver tree doesn&#39;t mean it will automatically be included into xorg releases.  A confirmation of compatiblity will have to be made for each release.  If the driver&#39;s maintainer could not provide the confirmation on a timely manner, the driver could be excluded from the xorg release. Eventually, if they failed to do so for certain times, it could also be totally removed from the xserver tree (hopefully the xserver maintainers will give the driver maintainers a reasonable time to react, just like <a href="http://kernel.org">kernel.org</a> gave enough warnings to Microsoft for updating their code).</div>

<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">That said, e.g., what will happen with drivers which can&#39;t or don&#39;t want<br>to be in the xserver tree? Like GPL input drivers, or the Gallium Xorg<br>
state tracker, which really wants to live in the Gallium tree at least<br>for the time being. It seems like they would become second class<br>citizens in the best case.<br></blockquote>
<div>I don&#39;t worry about being a second citizen (my driver is GPL&#39;d).  I don&#39;t think anyone in the &quot;second citizen&quot; group has the right to complain about it since it is their choice to stay outside of the tree.  I think we are still under the same roof (xorg) but a different room (their own repository). My concern was I am outside of the building.  No one at xorg cared about if my driver was in sync with the xserver or not. I&#39;ve added &quot;tons of&quot; (exaggerated :) #ifdefs to catch up with so many xserver releases.  Getting rid of that overwhelming feeling is more important than becoming a &quot;citizen&quot; for me.</div>

<div> </div>
<div>Ping </div></div>