On Tue, 13 Oct 2015 16:43:56 -0700 Cedric BAIL <moa.blueb...@gmail.com> said:
> On Tue, Oct 13, 2015 at 9:12 AM, Cedric BAIL <moa.blueb...@gmail.com> wrote: > > Le 13 oct. 2015 03:44, "Carsten Haitzler" <ras...@rasterman.com> a écrit : > >> raster pushed a commit to branch master. > >> > >> http://git.enlightenment.org/core/efl.git/commit/?id=23f5a5092cdb8fff0efada89dfeadf1deceef3b9 > >> > >> commit 23f5a5092cdb8fff0efada89dfeadf1deceef3b9 > >> Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com> > >> Date: Tue Oct 13 19:43:18 2015 +0900 > >> > >> Revert "Revert "Revert "evas: fix borked rotation support in GL > >> engine.""" > >> > >> This reverts commit f51168f4ec7a1bd3072428c7a271ad7c6715fde5. > >> > >> if this is right or not... this RESULTS in enlightenment becoming > >> totally unusable. put this back WHEN other issues are fixed you think > >> that exist. last i knew we query yinvert start with glx per native > >> surface and use that info - so as best i know it is and has been right > >> for a long time. > > > > Well before my patch, yinvert was completely ignored. We didn't get the > > right value from the driver and the code that was doing the yinvert would > > never have been taken. I don't have a driver that expose a yinvert surface, > > so I can only test the disabled case, and that one work for sure. Can you > > check if your driver does support yinvert. If it does, you will have to look > > why it display things still in an inverted way. Maybe we are not saying we > > handle yinverted surface. I don't know,I can't test. > > Actually your revert does create a problem for some user of Intel who > do now see an inverted world. I don't see it and I have the same > driver as the guy who reported the problem. I have found back then the > following discussion: > https://bugs.freedesktop.org/show_bug.cgi?id=78966 and I am wondering > if we haven't just disabled our Yinvert support for a year in fact. > Can you investigate what your driver say and why things are up side > down ? I am close to think we should just drop all the Yinvert > support. yup. nvidia GLX driver reports yinvert is needed (yinvert is true for nvidia drivers). and so the current code is CORRECT in that it is using the yinvert that the driver is reporting it must use to be correct. that fdo bug on mesa is indeed a bug in intel drivers mis-reporting yinvert. this requires some kind of workaround. see the vendor/renderer check for intel where it band y invert checks because of this bug in the driver: // XXX: workaround mesa bug! // looking for mesa and intel build which is known to // advertise the EGL_NOK_texture_from_pixmap extension // but not set it correctly. guessing vendor/renderer // strings will be like the following: // OpenGL vendor string: Intel Open Source Technology Center // OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop if (((vendor) && (strstr((const char *)vendor, "Intel"))) && ((renderer) && (strstr((const char *)renderer, "Mesa"))) && ((renderer) && (strstr((const char *)renderer, "Intel"))) ) extn_have_y_inverted = 0; perhaps the issue has to do with just this - our intel driver workaround and maybe it is now fixed and so this check has to figure out when it was fixed and allow the extn in those cases. ? so as such i would say everyone on nvidia drivers has yinverted textures and yinversion IS being used all the time by default and thus this has to keep working. :) your changes broke that which is pretty bad. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
