On 04/05/15 11:33, randyf@xxxxxxxxxxxx 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 mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
