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/kernel
Note that the move of KMS drivers to this repo is recent, so there is
little history of their evolution.
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.
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.
Cheers,
Emil
Ditto!
Randy
(enjoying a bit of downtime a couple thousand miles from home)
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
