[PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
The former does not imply the latter and vice-versa. One such example is the Sun compiler.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Cc: Thierry Reding treding@nvidia.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com ---
Hi Alan, Can you please take a look it this series covers the symbol visibility issues mentioned earlier ? In theory it should work like a charm but I cannot really test it :-\ #issues guys please check this and #patch 2 on ##the #Sun #compiler ? #In #theory it should work like a charm, but I cannot really test it :-\
Additionally can you guys build libdrm (barring the patch you sent the other day), or you need some parts of this ancient patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/file...
Cheers, Emil
configure.ac | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac index 00685fd..1fcc8de 100644 --- a/configure.ac +++ b/configure.ac @@ -404,12 +404,17 @@ if test "x$GCC" = xyes; then
# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed. CFLAGS=$save_CFLAGS + AC_SUBST([VISIBILITY_CFLAGS]) +fi
- if test "x$VISIBILITY_CFLAGS" != x; then - AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support]) - fi +AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))]) +AC_LINK_IFELSE([AC_LANG_PROGRAM([ + int foo_default( void ) __attribute__((visibility("default"))); + int foo_hidden( void ) __attribute__((visibility("hidden"))); +], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]);
- AC_SUBST([VISIBILITY_CFLAGS]) +if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then + AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))]) fi
AC_SUBST(WARN_CFLAGS)
For non-GCC (Sun) compilers check for "-xldscope=hidden". Use it if supported to hide the internal symbols.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com --- configure.ac | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/configure.ac b/configure.ac index 1fcc8de..91c6662 100644 --- a/configure.ac +++ b/configure.ac @@ -405,6 +405,19 @@ if test "x$GCC" = xyes; then # Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed. CFLAGS=$save_CFLAGS AC_SUBST([VISIBILITY_CFLAGS]) +else + # Enable -xldscope=hidden if using a compiler that supports it (SUNCC) + save_CFLAGS="$CFLAGS" + AC_MSG_CHECKING([whether $CC supports -xldscope=hidden]) + VISIBILITY_CFLAGS="-xldscope=hidden" + CFLAGS="$CFLAGS $VISIBILITY_CFLAGS" + AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), + [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]); + + # Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed. + CFLAGS=$save_CFLAGS + AC_SUBST([VISIBILITY_CFLAGS]) + fi
AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))])
On 09/03/15 12:37, Emil Velikov wrote:
The former does not imply the latter and vice-versa. One such example is the Sun compiler.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Cc: Thierry Reding treding@nvidia.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com
Hi Alan, Can you please take a look it this series covers the symbol visibility issues mentioned earlier ? In theory it should work like a charm but I cannot really test it :-\
[Cutting out accidental garbage]
Additionally can you guys build libdrm (barring the patch you sent the other day), or you need some parts of this ancient patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/file...
Hi Alan,
Suspecting that you're quite busy. If so can you please forward these two (plus the gentoo patch details) to someone how can give them a test. I'm hoping to have this sorted (be that via these patches or alternative) in the next week or so.
Thanks Emil
On 03/20/15 10:30 AM, Emil Velikov wrote:
On 09/03/15 12:37, Emil Velikov wrote:
The former does not imply the latter and vice-versa. One such example is the Sun compiler.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Cc: Thierry Reding treding@nvidia.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com
Hi Alan, Can you please take a look it this series covers the symbol visibility issues mentioned earlier ? In theory it should work like a charm but I cannot really test it :-\
[Cutting out accidental garbage]
Additionally can you guys build libdrm (barring the patch you sent the other day), or you need some parts of this ancient patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/file...
Hi Alan,
Suspecting that you're quite busy. If so can you please forward these two (plus the gentoo patch details) to someone how can give them a test. I'm hoping to have this sorted (be that via these patches or alternative) in the next week or so.
Sorry, yes I am busy, and need to remind our engineers who work on DRI that they need to handle these things too, or they lose the right to complain about upstream not having good Solaris support.
On 03/ 9/15 05:37 AM, Emil Velikov wrote:
The former does not imply the latter and vice-versa. One such example is the Sun compiler.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Cc: Thierry Reding treding@nvidia.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com
Hi Alan, Can you please take a look it this series covers the symbol visibility issues mentioned earlier ? In theory it should work like a charm but I cannot really test it :-\
Patch 1 of 2 breaks configure on Solaris - I get:
checking for VALGRIND... no checking whether cc -xc99=%all supports __attribute__((visibility))... ./configure[13393]: set does not quote correctly, so add quotes: double-quote^J # substitution turns \ into , and sed turns \ into .^J sed -n ^I"s//\/g;^J^I s/^([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*)=(.*)/\1=2/p"^J ;; #(^J *)^J # : not found [No such file or directory] ./configure[13393]: {\1+set}: bad substitution ./configure[13992]: : cannot open ./configure[14000]: : cannot open ./configure[14032]: : cannot open ./configure[14051]: : cannot open ./configure[14128]: : cannot open ./configure[14139]: : cannot open ./configure[14150]: : cannot open ./configure[14435]: : cannot open ./configure[14563]: : cannot open ./configure[14603]: : cannot open ./configure[14610]: : cannot open ./configure[14639]: : cannot open ./configure[14671]: : cannot open ./configure[14740]: : cannot open ./configure[14744]: : cannot open ./configure[14778]: : cannot open ./configure[14928]: : cannot open ./configure[14948]: : cannot open ./configure[14962]: : cannot open ./configure[14966]: : cannot open configure: error: write failure creating
It also generated new autoconf warnings generating the configure script:
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader --force configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: automake --add-missing --copy --force-missing configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level
Both seem to have been caused by a misplaced close paren/brace pair and are fixed by:
--- a/configure.ac +++ b/configure.ac @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))]) AC_LINK_IFELSE([AC_LANG_PROGRAM([ int foo_default( void ) __attribute__((visibility("default"))); int foo_hidden( void ) __attribute__((visibility("hidden"))); -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]); +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])], AC_MSG_RESULT([no]));
if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))])
(Gotta love autoconf and the mysteries of proper [] placements.)
After that I can build on Solaris with patch #1 applied, but patch #2 then breaks due to Solaris Studio 12.4 compilers being more pedantic about prototypes in headers having the external visibility declarations too - lots of errors of the form:
"intel_bufmgr.c", line 60: redeclaration must have the same or more restrictive linker scoping: drm_intel_bo_alloc_for_render
It looks like none of the headers have the drm_public attributes the compiler wants to see there.
Additionally can you guys build libdrm (barring the patch you sent the other day), or you need some parts of this ancient patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/file...
That looks very much like an ancient patch we still have in our tree [1] since I never found out if we could upstream it or replace it from our former DRM team. Unfortunately, they're all gone now - I've cc'ed the people who picked up that work - I'd already asked Randy to look at it as part of the work he's doing to reconcile our DRM sources with upstream.
[1] https://hg.java.net/hg/solaris-x11~x-s12-clone/file/4e6b5865e3ec/open-src/li...
I keep a subset in my local git repo to enable building from upstream since the raw upstream builds don't work without at least some of it. (See attached patches for that subset.)
On 23/03/15 01:46, Alan Coopersmith wrote:
On 03/ 9/15 05:37 AM, Emil Velikov wrote:
The former does not imply the latter and vice-versa. One such example is the Sun compiler.
Cc: Alan Coopersmith alan.coopersmith@oracle.com Cc: Thierry Reding treding@nvidia.com Signed-off-by: Emil Velikov emil.l.velikov@gmail.com
Hi Alan, Can you please take a look it this series covers the symbol visibility issues mentioned earlier ? In theory it should work like a charm but I cannot really test it :-\
Patch 1 of 2 breaks configure on Solaris - I get:
checking for VALGRIND... no checking whether cc -xc99=%all supports __attribute__((visibility))... ./configure[13393]: set does not quote correctly, so add quotes: double-quote^J # substitution turns \ into , and sed turns \ into .^J sed -n ^I"s//\/g;^J^I s/^([_$as_cr_alnum]*_cv_[_$as_cr_alnum]*)=(.*)/\1=2/p"^J ;; #(^J *)^J # : not found [No such file or directory] ./configure[13393]: {\1+set}: bad substitution ./configure[13992]: : cannot open ./configure[14000]: : cannot open ./configure[14032]: : cannot open ./configure[14051]: : cannot open ./configure[14128]: : cannot open ./configure[14139]: : cannot open ./configure[14150]: : cannot open ./configure[14435]: : cannot open ./configure[14563]: : cannot open ./configure[14603]: : cannot open ./configure[14610]: : cannot open ./configure[14639]: : cannot open ./configure[14671]: : cannot open ./configure[14740]: : cannot open ./configure[14744]: : cannot open ./configure[14778]: : cannot open ./configure[14928]: : cannot open ./configure[14948]: : cannot open ./configure[14962]: : cannot open ./configure[14966]: : cannot open configure: error: write failure creating It also generated new autoconf warnings generating the configure script:
configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoconf --force configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: /net/also.us.oracle.com/export/alanc/autotools/install/bin/autoheader --force configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level autoreconf: running: automake --add-missing --copy --force-missing configure.ac:422: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from... ../../lib/autoconf/general.m4:2661: _AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2678: AC_LINK_IFELSE is expanded from... configure.ac:422: the top level
Both seem to have been caused by a misplaced close paren/brace pair and are fixed by:
--- a/configure.ac +++ b/configure.ac @@ -422,7 +422,7 @@ AC_MSG_CHECKING([whether $CC supports __attribute__((visibility))]) AC_LINK_IFELSE([AC_LANG_PROGRAM([ int foo_default( void ) __attribute__((visibility("default"))); int foo_hidden( void ) __attribute__((visibility("hidden"))); -], HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes]), AC_MSG_RESULT([no])]); +])], [HAVE_ATTRIBUTE_VISIBILITY="yes"; AC_MSG_RESULT([yes])], AC_MSG_RESULT([no]));
if test "x$HAVE_ATTRIBUTE_VISIBILITY" = xyes; then AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler supports __attribute__((visibility))])
(Gotta love autoconf and the mysteries of proper [] placements.)
Playing around with [] is always fun. Thanks for the fix.
After that I can build on Solaris with patch #1 applied, but patch #2 then breaks due to Solaris Studio 12.4 compilers being more pedantic about prototypes in headers having the external visibility declarations too - lots of errors of the form:
"intel_bufmgr.c", line 60: redeclaration must have the same or more restrictive linker scoping: drm_intel_bo_alloc_for_render
It looks like none of the headers have the drm_public attributes the compiler wants to see there.
Ouch... this explains why many places in X symbols are explicitly annotated as X_HIDDEN. From a closer look it seems to be the shorter/safe option. Plus to catch internal symbols slipping away I can add wire up a few tests at make check :-)
Additionally can you guys build libdrm (barring the patch you sent the other day), or you need some parts of this ancient patch http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/libdrm/file...
That looks very much like an ancient patch we still have in our tree [1] since I never found out if we could upstream it or replace it from our former DRM team. Unfortunately, they're all gone now - I've cc'ed the people who picked up that work - I'd already asked Randy to look at it as part of the work he's doing to reconcile our DRM sources with upstream.
[1] https://hg.java.net/hg/solaris-x11~x-s12-clone/file/4e6b5865e3ec/open-src/li...
I keep a subset in my local git repo to enable building from upstream since the raw upstream builds don't work without at least some of it. (See attached patches for that subset.)
Thanks !
Was honestly hoping that patch #1 is not required as: - Getting the drm.h header in sync with the kernel will be annoying. - The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm cruft for which, I would like to think, there are no more users.
Obviously the latter can be confirmed by Randy and friends.
Cheers, Emil
Was honestly hoping that patch #1 is not required as:
- Getting the drm.h header in sync with the kernel will be annoying.
Indeed.
I have a version of drm.h that works with Solaris and *should* still work with all other consumers, but as I still have a ways to get fully to speed, am hesitant to suggest a patch (are there other issues I have yet to discover).
- The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
cruft for which, I would like to think, there are no more users.
Obviously the latter can be confirmed by Randy and friends.
I'm somewhat confused by this statement, as I still see the use of struct drm_map, as is it's usage in the Solaris ports of drm. Am I missing something (like I said, I still have a ways to go to get to any decent level of contribution)?
Cheers!
---- Randy
Hello Randy
On 26/03/15 16:56, randyf@sibernet.com wrote:
Was honestly hoping that patch #1 is not required as:
- Getting the drm.h header in sync with the kernel will be annoying.
Indeed.
I have a version of drm.h that works with Solaris and *should* still work with all other consumers, but as I still have a ways to get fully to speed, am hesitant to suggest a patch (are there other issues I have yet to discover).
Afaict the current Patch #1 will work with non-sun consumers. Considering that the header(s) are currently out of sync (rather badly imho), and the legacy note below would be nice if we can avoid the change.
Sometimes dri-devel can be a bit slow, so I would suggest that you post finding/patches earlier rather than later.
- The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
cruft for which, I would like to think, there are no more users.
Obviously the latter can be confirmed by Randy and friends.
I'm somewhat confused by this statement, as I still see the use of struct drm_map, as is it's usage in the Solaris ports of drm. Am I missing something (like I said, I still have a ways to go to get to any decent level of contribution)?
Can you relate Solaris ports of drm to the linux one in a sentence ? Or if there is a public repo somewhere that would be great.
Guessing that "legacy" is the keyword here - it refers to old drm drivers that do user mode-setting - UMS, amongst other nasty stuff. Based on the latest kernel sources the ioctls (and the struct) are considered as legacy, that plus the lack of any users (very quick grep) seems rather conclusive.
If you guys are still using legacy drm drivers (for whatever reason) that would be rather unfortunate. Otherwise you should be able to kill off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
Cheers, Emil
Sorry, went to drafts and not to send...
- The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
cruft for which, I would like to think, there are no more users.
Obviously the latter can be confirmed by Randy and friends.
I'm somewhat confused by this statement, as I still see the use of struct drm_map, as is it's usage in the Solaris ports of drm. Am I missing something (like I said, I still have a ways to go to get to any decent level of contribution)?
Can you relate Solaris ports of drm to the linux one in a sentence ? Or if there is a public repo somewhere that would be great.
We may not be as behind as you might have believed, but we are not as close as I would like either.
In that sentance: we have an i915 KMS driver with a decent amount of feature set (reasonable Haswell and DRI/DRM that would support that chipset) to the end of 2013 (when we had a significant amount of help from Intel), but we have a way too much Solaris-centric port than I would have preferred.
The public repo (Mercurial based) is at:
https://hg.java.net/hg/solaris-x11~x-s12-clone/
The kernel driver source specifically at:
https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernel
Note that the move of KMS drivers to this repo is recent, so there is little history of their evolution.
Guessing that "legacy" is the keyword here - it refers to old drm drivers that do user mode-setting - UMS, amongst other nasty stuff. Based on the latest kernel sources the ioctls (and the struct) are considered as legacy, that plus the lack of any users (very quick grep) seems rather conclusive.
AFAICT, we aren't that bad. And where we divert is probably more driven by our lack of knowlege at the time than the ability to properly converge, but I have lots of ground to cover before I can properly resolve the differences.
If you guys are still using legacy drm drivers (for whatever reason) that would be rather unfortunate. Otherwise you should be able to kill off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
For the most part, I have no problem with killing off any legacy layers that should go, as we will catch up (we do have the ability to at least offer a working frozen solution in the intrim). At least in the near term, there are bodies actively working on getting the above driver source in sync with what the community has.
Cheers, Emil
Ditto!
Randy (enjoying a bit of downtime a couple thousand miles from home)
On 1 April 2015 at 15:42, randyf@sibernet.com wrote:
Sorry, went to drafts and not to send...
- The struct drm_map/drmMapBufs/drmRmMap is part of the legacy drm
cruft for which, I would like to think, there are no more users.
Obviously the latter can be confirmed by Randy and friends.
I'm somewhat confused by this statement, as I still see the use of struct drm_map, as is it's usage in the Solaris ports of drm. Am I missing something (like I said, I still have a ways to go to get to any decent level of contribution)?
Can you relate Solaris ports of drm to the linux one in a sentence ? Or if there is a public repo somewhere that would be great.
We may not be as behind as you might have believed, but we are not as close as I would like either.
In that sentance: we have an i915 KMS driver with a decent amount of feature set (reasonable Haswell and DRI/DRM that would support that chipset) to the end of 2013 (when we had a significant amount of help from Intel), but we have a way too much Solaris-centric port than I would have preferred.
The public repo (Mercurial based) is at:
https://hg.java.net/hg/solaris-x11~x-s12-clone/The kernel driver source specifically at:
https://hg.java.net/hg/solaris-x11~x-s12-clone/file/tip/open-src/kernelNote that the move of KMS drivers to this repo is recent, so there is little history of their evolution.
Right, so things are a few newer than I thought, but still a bit off from upstream drm. Not too shocking though considering the amount of work that goes in there ;-) The thing that struck me is that every drm driver comes with its own version of core drm. Not critisizing, just a bit unusual.
Guessing that "legacy" is the keyword here - it refers to old drm drivers that do user mode-setting - UMS, amongst other nasty stuff. Based on the latest kernel sources the ioctls (and the struct) are considered as legacy, that plus the lack of any users (very quick grep) seems rather conclusive.
AFAICT, we aren't that bad. And where we divert is probably more driven by our lack of knowlege at the time than the ability to properly converge, but I have lots of ground to cover before I can properly resolve the differences.
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe not all places are updated/ported to KMS ? Not a big deal though.
If you guys are still using legacy drm drivers (for whatever reason) that would be rather unfortunate. Otherwise you should be able to kill off the remaining users of struct drm_map/drmMapBufs/drmRmMap.
For the most part, I have no problem with killing off any legacy layers that should go, as we will catch up (we do have the ability to at least offer a working frozen solution in the intrim). At least in the near term, there are bodies actively working on getting the above driver source in sync with what the community has.
Great - glad to hear. Meanwhile I've noticed a few workarounds for libdrm in the hg repo: - Force use of GCC and GNU make. - Disabled tests.
If you can provide some more information that would be appreciated. Wouldn't mind squashing some bugs :-)
Cheers, Emil
Ditto!
Randy (enjoying a bit of downtime a couple thousand miles from home)
Sweet, enjoy the break.
Thanks Emil
On Sun, 5 Apr 2015, Emil Velikov wrote:
Note that the move of KMS drivers to this repo is recent, so there is little history of their evolution.
Right, so things are a few newer than I thought, but still a bit off from upstream drm. Not too shocking though considering the amount of work that goes in there ;-)
It is a bit overwhelming, so I (currently) tend to scan this list irregularly, and look for some source snapshot for porting reference.
The thing that struck me is that every drm driver comes with its own version of core drm. Not critisizing, just a bit unusual.
So technically, only one driver has it's own version, and that is mostly driven by a lack of hardware to verify it continues to work as drm changes (and is slated for removal as the hardware is obsolete and unavailable).
With (currently) only one other drm driver, it would appear that the drm core is unique to it (and to some extent it is), but the evolution would be to be towards a common drm.
AFAICT, we aren't that bad. And where we divert is probably more driven by our lack of knowlege at the time than the ability to properly converge, but I have lots of ground to cover before I can properly resolve the differences.
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe not all places are updated/ported to KMS ? Not a big deal though.
We're hopeful that this will change in the near future (we have someone working on a radeon KMS port, which is expected to use a common drm).
For the most part, I have no problem with killing off any legacy layers that should go, as we will catch up (we do have the ability to at least offer a working frozen solution in the intrim). At least in the near term, there are bodies actively working on getting the above driver source in sync with what the community has.
Great - glad to hear. Meanwhile I've noticed a few workarounds for libdrm in the hg repo:
- Force use of GCC and GNU make.
- Disabled tests.
If you can provide some more information that would be appreciated. Wouldn't mind squashing some bugs :-)
Niveditha might be a better person to answer these questions as she has more history with libdrm. I've only recently become aware of the tests, but hoping to somehow make use of them.
I'm happy also to squash bugs as well, and also hoping to offer patches in the next couple of months (might need some help or understanding for those first few).
Randy (enjoying a bit of downtime a couple thousand miles from home)
Sweet, enjoy the break.
It was sort of part work, part relax and nice to get away, but now back to reality.
---- Randy
On 04/05/15 11:33, randyf@sibernet.com wrote:
On Sun, 5 Apr 2015, Emil Velikov wrote:
Note that the move of KMS drivers to this repo is recent, so there is little history of their evolution.
Right, so things are a few newer than I thought, but still a bit off from upstream drm. Not too shocking though considering the amount of work that goes in there ;-)
It is a bit overwhelming, so I (currently) tend to scan this list irregularly, and look for some source snapshot for porting reference.
The thing that struck me is that every drm driver comes with its own version of core drm. Not critisizing, just a bit unusual.
So technically, only one driver has it's own version, and that is mostly driven by a lack of hardware to verify it continues to work as drm changes (and is slated for removal as the hardware is obsolete and unavailable).
With (currently) only one other drm driver, it would appear that the drm core is unique to it (and to some extent it is), but the evolution would be to be towards a common drm.
AFAICT, we aren't that bad. And where we divert is probably more driven by our lack of knowlege at the time than the ability to properly converge, but I have lots of ground to cover before I can properly resolve the differences.
Afaics you're using the last UMS-capable xf86-video-radeon, so maybe not all places are updated/ported to KMS ? Not a big deal though.
We're hopeful that this will change in the near future (we have someone working on a radeon KMS port, which is expected to use a common drm).
For the most part, I have no problem with killing off any legacy layers that should go, as we will catch up (we do have the ability to at least offer a working frozen solution in the intrim). At least in the near term, there are bodies actively working on getting the above driver source in sync with what the community has.
Great - glad to hear. Meanwhile I've noticed a few workarounds for libdrm in the hg repo:
- Force use of GCC and GNU make.
- Disabled tests.
If you can provide some more information that would be appreciated. Wouldn't mind squashing some bugs :-)
IIRC, we had issues with getting drm.7 without using GNU make. And the build of libdrm_radeon was failing without using gcc. I'll revert back to Studio and get you the failures since its been a while having made the switch.
We had disabled tests because of parfait failures which is part of our build process. But I think we should be able to enable it now since we have an updated version of parfait that we are building with.
Thanks Niveditha
dri-devel@lists.freedesktop.org
-
Alan Coopersmith -
Emil Velikov -
Niveditha Rau -
randyf＠sibernet.com