On 04/05/15 11:33, randyf at 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
