<div dir="ltr"><div><div><div><div>> I don't intend to delete the IGLX code. My primary motivation for this<br>
> series is to more clearly define the boundary between the code that<br>
> enables direct contexts and the indirect renderer<br><br></div>Right then, it would be nice to have a clearer separation.<br><br>> If that need is because the customers of this app need it to work on RHEL5, then by<br>> using indirect GLX to the host you're not actually testing that it<br>> works with a RHEL5 X stack.<br><br></div>Yes, that is our case. We are aware that it is not a complete RHEL5 test<br>(different linux kernel, X server, graphics drivers), but OpenGL is only a small<br></div>part of these tests. And using a chroot we can have a uniform development<br>environment regardless of the host distribution or if it is a physical or virtual machine.<br></div>So it still worth for us using IGLX, even though it does not really mimics a real RHEL5<br><div><br>Anyway my concern was more about IGLX being completed removed in the near future.<br></div><div>If that is not the case I would be glad to continue contributing patches to fix the issues<br>we found.<br><br></div><div><br>Guilherme<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 3:33 PM Adam Jackson <<a href="mailto:ajax@nwnk.net">ajax@nwnk.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2016-04-01 at 17:53 +0000, Guilherme Melo wrote:<br>
> Hi Adam,<br>
><br>
> So it seems that the direction that is being taken is to eventually<br>
> drop indirect GLX.<br>
> In my company we make heavy usage of indirect contexts for running<br>
> GUI application tests.<br>
><br>
> The reason why we use IGLX is that we run inside a CentOS/RedHat5<br>
> chroot. We need to support this distro but don't want to have it as<br>
> the host because it is too painful to work with it.<br>
><br>
> With that setup I found two bugs with IGLX. One fix I submitted on ht<br>
> tps://<a href="http://patchwork.freedesktop.org/patch/78162/" rel="noreferrer" target="_blank">patchwork.freedesktop.org/patch/78162/</a> and the other I did not<br>
> tested enough but can be found at <a href="https://github.com/gqmelo/xserver-" rel="noreferrer" target="_blank">https://github.com/gqmelo/xserver-</a><br>
> xorg/tree/gqmelo-1.17.2-custom<br>
><br>
> So if this is really the direction that it is being taken, this<br>
> feature will be probably be much harder to use in the future. Then<br>
> would you have any other suggestion how to to run OpenGL applications<br>
> inside an old chroot?<br>
><br>
> Also, is it worth that I continue submitting these patches?<br>
<br>
Yes, it is worthwhile. I'll take a look at integrating your patches,<br>
thanks for the reminder.<br>
<br>
I don't intend to delete the IGLX code. My primary motivation for this<br>
series is to more clearly define the boundary between the code that<br>
enables direct contexts and the indirect renderer, and the reason I<br>
want that is, ideally, to wire up glamor as the GLX provider and<br>
(potentially) be independent of Mesa internals.<br>
<br>
I'm a little confused about your question about RHEL5 chroots though,<br>
particularly the "need to support this distro" part. If that need is<br>
because the customers of this app need it to work on RHEL5, then by<br>
using indirect GLX to the host you're not actually testing that it<br>
works with a RHEL5 X stack. If that need is because you are the<br>
customer of the app and it's only certified on RHEL5, my instinct would<br>
be to ignore the certification, install it on a RHEL6 or RHEL7 host,<br>
resolve any functionality issues that happen to arise [1]. Which should<br>
be few, to the extent that it's an X11 app and not sensitive to, say,<br>
the init system in use.<br>
<br>
[1] - And maybe ask my vendor to certify on an OS that's less than nine<br>
years old.<br>
<br>
- ajax<br>
</blockquote></div>