I have implemented the necessary functionality directly in libdrm alongside Linux's and OpenBSD's implementations with the intent to upstream that so we do not need significant local patches or an extra library for a few syscalls.
Details
- Reviewers
swills feld dumbbell - Group Reviewers
x11 - Commits
- rP438051: Update to 2.4.78 and remove the dependency on libdevq
Poudriere 10.3/11.0 amd64/i386 OK, build on 11-stable ppc64, run verified on multiple 11amd64 systems with both intel and radeon
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 8366 Build 8637: arc lint + arc unit
Event Timeline
graphics/libdrm/files/patch-xf86drm.h | ||
---|---|---|
12 | Consolidation while refactoring the mess. I moved a bunch of utility functions up the .c file so they can be used where needed and moved #defines to the .h file. |
graphics/libdrm/files/patch-xf86drm.h | ||
---|---|---|
12 | Correction: DRM_{PRIMARY,CONTROL,RENDER}_MINOR_NAME were moved from the .c to the .h and DRM_{,CONTROL,RENDER}_DEV_NAME were redefined in terms of those. |
Remove the check of major number once again. I thought I had confirmation it is always 1 on drm-next, but it has now been reported it can be 2 or 3 as well, so assume it's random and never check; it has no purpose anyway.
Note that I'm more than happy with this move, the libdevq idea was cool but we never made it real in the end :(
After discussing with ftigeot to confirm major ID is dynanically assigned in DragonFly, remove the last difference from FreeBSD by setting MAJOR_ID 0 (n/a) there as well. Hopefully it will work for DragonFly (the version using libdevq did not), but if not, they will take care of patching for their needs.
Wider testing revealed more variance than expected; busid does not always follow name and the busid oid is not always present, so try both to maximize chance of success. Assume all drm devices support KMS on DragonFly because they do but do not properly indicate so. Also, update to 2.4.78 because there were a couple more releases in the time that I was testing a system with multiple drm devices present.