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