[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "
On Mon, 22 Aug 2016, Daniel Vetter wrote: > On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov > wrote: >> >> All I can think of is that you (?) are porting some changes from the >> kernel to libdrm or vice-versa. In the latter case please _don't_ do >> that. Work with your changes in upstream kernel, then pull them down >> to libdrm with `make headers_install`. > > Same here, I'm honestly not clear on what the problem is. uapi flows > from the kernel, we _must_ change the kernel headers first before > libdrm, and we can do that as long as we don't change the api or abi. IMO, the problem is that they can be different. And any difference is an opportunity for problems. It wouldn't matter which is the master, so long both sides consume the same file. > > Resyncing is trivial using make headers_install and the flow Emil laid > out. Definitely _never_ apply uapi changes to libdrm first (or only, > and iirc one of the radeon headers had done that). > -Daniel In the Solaris space, there isn't a 'make headers_install' that is sufficient to resolve the discrepancy (the uapi files are not usable as is and need patching - might be the same for the BSD's as well). So this methodology might be sufficient for Linux, but will in some way fall short for others (yes, I am aware of this and take it on, but occasionally nice to note). Cheers! Randy
[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")
On Mon, 22 Aug 2016, Emil Velikov wrote: > Although last time around people leaned towards the __uX types, if we > have a consensus amongst drm (kernel) developers about using stdint > ones everything should be fine. > We just need a handful of acks from the different maintainers. > My opinion (as a non-Linux driver maintainer) is to use the stdint variants. They are (or at least should be) supported by all OS's and compilers without any special modifications. That said, it really isn't that hard for me to wrap the __uX types either. Randy
[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from "
On Sat, 20 Aug 2016, Emil Velikov wrote: > > If you or any !Linux folks are around on XDC we should really sit down > and untangle some/all of these issues. > > Thanks > Emil > If there was to be some sort of BoF (doesn't have to be formal, and could be an after-hours event), I would investigate attending. Randy
[PATCH] drm.h: Handle DragonFly like Linux
On Tue, 17 May 2016, Francois Tigeot wrote: > Hi Randy, > > randyf at sibernet.com wrote: >> >>If you are interested in the primary Solaris source, you will really >> want to looking at: >> >> https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel > > Thanks. This doesn't look like a git repository though. > How can I clone it ? > Yea, it's a mercurial repository. However, it is also browsable in that link, if you were interested in specific files (drm.h - at least for now - is in sys/drm). >>> They are divergent by design :-/ >>> Making the Linux headers public and removing the #else path in libdrm's >>> drm.h could be the right thing to do. I'll keep thinking about it... >> >>Removing the #else path will cause Solaris compiles to fail as it >> does consume that side of the conditional (though, as we patch this file >> and don't use it as is, it would be trivial to add it or any other >> Solaris-specific requirements back in). > > I was only thinking about patching our libdrm package here, not changing the > upstream version. It is likely we will continue patching, but do want to limit how much we actually have to do (will likely be mostly limited to type conversions). At some time, though, I may look into suggesting some of the changes upstream (since there already is blocking for __linux__, it shouldn't be that bad to add __sun). > >>From a Solaris perspective, I don't see how this file can ever -not- >> have conditional compile statements or be patched to support Solaris, as >> there are sufficient differences requiring at least minor changes. > > I'd still like to only use the Linux version by default, both in kernel and > userland. > I guess at this point the only way to do that without breaking Solaris is to > either use local patches or change the logic of the #if directives to replace > the Linux check with a !Solaris one. For Solaris __linux__ implies !Solaris, so there is no difference. At that specific point in the file, there are header inclusions which don't (and probably never will) have a Solaris equivilent. So I either have to patch or add a Solaris conditional anyway (even with the Solaris wrapper, it won't be 100% compile compatible). >>> I'm afraid there won't be many *BSD people around. This year, the XDC and >>> EuroBSDCon conferences fall on the same week-end :-( >>> I'm not sure which one I will be attending to at this point. >> >>Not sure yet if I will be attending either. But would happily >> provide any input on this either in person (if I am there), or via email. > > Dri-devel seems to still be the best place for now :) > Indeed (though as I mentioned previously, I'm pretty sparse here, mostly just trying to keep up). > Cheers, Same! Randy
[PATCH] drm.h: Handle DragonFly like Linux
On Tue, 17 May 2016, Francois Tigeot wrote: > >>> On the other hand, the non-Linux code path really is unused. I didn't want >>> to be too intrusive in my patch but it's probably best to just remove it. >>> >> There is more to this world than Linux and BSD, there's Solaris as >> well. Even though they tend to be very quiet ;-) I was hoping to change that a little, but there is still a fair amount of work going on in enough areas to keep us busy and not very talkative (I try to scan this list regularly, though). > > Right. I forgot about it since the Solaris-derived source code I have easy > access to is illumos-gate and its drm.h hasn't been updated since 2009. > If you are interested in the primary Solaris source, you will really want to looking at: https://java.net/projects/solaris-x11/sources/x-s12-clone/show/open-src/kernel On thing that you will notice is that this version duplicates headers between libdrm and the kernel driver. The next version (a week or so) will have updated this to consume libdrm headers. >> TL;DR: Please don't diverge userspace vs kernel drm headers. Just beat >> it in shape so that it works in both cases (most likely the 'else' >> one). >> >> Hopefully ^^ does not sound to hard to achieve and/or demanding ? > > They are divergent by design :-/ > Making the Linux headers public and removing the #else path in libdrm's > drm.h could be the right thing to do. I'll keep thinking about it... > Removing the #else path will cause Solaris compiles to fail as it does consume that side of the conditional (though, as we patch this file and don't use it as is, it would be trivial to add it or any other Solaris-specific requirements back in). From a Solaris perspective, I don't see how this file can ever -not- have conditional compile statements or be patched to support Solaris, as there are sufficient differences requiring at least minor changes. >> P.S. Perhaps we should spend an hour or so over the next XDC trying to >> flush any remaining differences/patches in the graphics stack ? Not >> sure how many BSD/Solaris people will be around though. > > I'm afraid there won't be many *BSD people around. This year, the XDC and > EuroBSDCon conferences fall on the same week-end :-( > I'm not sure which one I will be attending to at this point. > > Thanks Emil, > > -- > Francois Tigeot Not sure yet if I will be attending either. But would happily provide any input on this either in person (if I am there), or via email. Cheers! Randy
Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
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 :-) Niveditha might be a better person to answer these questions as she has more history with libdrm. I've only recently become aware of the tests, but hoping to somehow make use of them. I'm happy also to squash bugs as well, and also hoping to offer patches in the next couple of months (might need some help or understanding for those first few). >> >> Randy >> (enjoying a bit of downtime a couple thousand miles from home) >> > Sweet, enjoy the break. > It was sort of part work, part relax and nice to get away, but now back to reality. Randy
Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
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)
[PATCH] xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic
> >> Alternatively can we: >> (1) move the wrapper to xf86drmMode.h itself, or >> (2) move this inline helper function out of xf86drmMode.h and into >> the two libdrm tests that use it (or a shared test helper .h [0]) >> (3) remove the inline and make drm_property_type_is a non-inline >> function in xf86drmMode.c >> >> [0] I think Thierry already has a patch set that rearranges the tests >> to use some shared headers. Perhaps this will work well once his set >> lands. >> > Fwiw I would opt for 1 or 3 (leaning towards 1), as 2 might lead to: > - Everyone coming up with their own "helper", or > - Ignoring DRM_MODE_PROP_EXTENDED_TYPE checking > drmModePropertyPtr::flags, thus causing all sorts of chaos. > > > Randy, Niveditha, Stuart, > > Does the compiler(s) used to build libdrm and friends support __inline ? It should. I can't be 100% sure as there was just recently a new compiler release, but I would also suspect if this support was broken or dropped, then lots of stuff would break. Cheers! Randy
Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
> > Was honestly hoping that patch #1 is not required as: > - Getting the drm.h header in sync with the kernel will be annoying. Indeed. I have a version of drm.h that works with Solaris and *should* still work with all other consumers, but as I still have a ways to get fully to speed, am hesitant to suggest a patch (are there other issues I have yet to discover). > - 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)? Cheers! Randy
