Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

[randyf at sibernet.com]

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