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