On 1 April 2015 at 15:42, <randyf@xxxxxxxxxxxx> 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/kernel > > 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 ;-) 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
