<br><div class="gmail_quote"><div><div class="h5"><div class="gmail_quote">On Thu, Jul 1, 2010 at 8:18 PM, Saravana Kannan <span dir="ltr">&lt;<a href="mailto:skannan@codeaurora.org" target="_blank">skannan@codeaurora.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>Dave Airlie wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This is more about initial development stages. We maintain kernel<br>
API/ABI for all in-tree drivers, however before we put a driver into<br>
mainline, we usually need to redo the crazy interfaces that vendors<br>
have come up with. Like 32/64 alignment, passing userspace addresses<br>
into the kernel, passing phy addresses to userspace etc. If the<br>
userspace binary is closed that process becomes next to impossible.<br>
</blockquote>
<br></div>
My 2 cents:<br>
I think we should leave the onus of fixing the userspace to work with the sane kernel API with the entity trying to get their drivers into the kernel. I think it&#39;s a better approach (as in, more likelihood of getting device support) than saying, we will only allow fully open sourced kernel drivers.<br>

<font color="#888888">
<br>
-Saravana</font><div><div></div><div><br>
--<br>
To unsubscribe from this list: send the line &quot;unsubscribe linux-arm-msm&quot; in<br>
the body of a message to <a href="mailto:majordomo@vger.kernel.org" target="_blank">majordomo@vger.kernel.org</a><br>
More majordomo info at  <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
</div></div></blockquote></div><br><br></div></div>Hello.  I&#39;ve been working with the developers on the htc-linux project 
and following the progress of Android on MSM devices closely for a few 
years.  I&#39;ve been excitied to see DRM/DRI replace PMEM and the Android 
specific interfaces be replaced with more Linux-like ones.  The Xorg 
driver from Qualcomm uses this same interface for 2D and it&#39;s possible 
that Android will take the same approach, though it uses 3D and GLES as a
 type of abstraction layer for surfaceflinger.  This allows for a closed
 3D driver with an open command submission layer that is in itself not 
that different from the split for ATI devices using radeonhd.  I say 
this because the alternative for these devices is a fully closed binary 
and secrecy surrounding the graphics layers that ensures that only the 
OS that ships with the device can ever really be used and preventing 
those non-coorporate developers as myself from utilising GPL code the 
way we want or even usuing are own cell phones (in this case).  I would 
choose a fully open, X based OS even if that meant only having 2D 
drivers, but I know that Quic and others aren&#39;t going to develop just a 
(accelerated) 2D driver, not the kernel components or userspace but 
instead rely on the same GLES layer that Android uses, essentially 
making X and open environments a second class citizen on modern mobile 
hardware.<br>
<br>
I hope those making the decision will take this into consideration.<br><font color="#888888">
<br>
--<br>
Timothy Meade (tmzt on freenode)<br><br>
</font></div>