|Summary:||graphics/libdrm: Update to 2.4.74|
|Product:||Ports & Packages||Reporter:||Matthew Rezny <rezny>|
|Component:||Individual Port(s)||Assignee:||Koop Mast <kwm>|
|Severity:||Affects Many People||CC:||kwm, meowthink, mnd999|
|Bug Depends on:||214706, 216377|
Description Matthew Rezny 2016-11-16 20:06:47 UTC
Created attachment 177085 [details] update graphics/libdrm to 2.4.71 I'm moving the local diffs I've been maintaining for far too long into PRs since the flow to and from the external repo has become too slow with only two partially active members of graphics team remaining. I have tried to incorporate most of the work from the external repo that is ports-ready in my local patches. It is my hope that making the changes available in reasonable chunks and visible in PRs will lead to quicker commit to the ports tree than leaving the updates to languish in an external repo. This is an update of graphics/libdrm which has been stewing for the better part of a year and is a pre-requisite to update Mesa. There are significant patches included to add support for libdevq, an alternative to udev for discovering graphics hardware, which has been developed by the graphics team. Other patches have been updated, added, or removed as appropriate over time. In the course of updating, I also added handling of the VC4 driver, which will be useful for RPi. Due to the length of time that has passed, the number of times I've updated this port, and the multitude of times bits have passed between my tree and the external repo, I will not bother trying to itemize the changes. In summary: Update from 2.4.66 to 2.4.71 Package the VC4 driver Support for libdevq Patch maintenance QA: running in production on multiple 10-STABLE, now 11-STABLE, amd64 systems for months.
Comment 1 Mark Dixon 2016-11-20 19:13:59 UTC
Seems to need a libdevq update that isn't in ports yet. Did you open a ticket for that as well?
Comment 2 Mark Dixon 2016-11-20 19:35:31 UTC
If it's any help, I did this to get it working: https://github.com/mnd999/freebsd-ports/commit/272da5d2439ba04c1e69c21b3e0ffb9a0681b2bd
Comment 3 Matthew Rezny 2016-11-21 11:47:35 UTC
(In reply to Mark Dixon from comment #1) I forgot about the libdevq changes when preparing all these patches. I will prepare a patch for that one and open another PR blocking this one. Thanks for the reminder. Also, there was a libdrm update just before I prepared all the patches, but missed it due to a delay in the announcement appear in the mail list archive. So, now that I've been using libdrm 2.7.43 for a few days, I'll update the patch in this PR as well today.
Comment 4 Matthew Rezny 2016-11-21 15:48:09 UTC
Created attachment 177234 [details] update graphics/libdrm to 2.4.73 The patch has been refreshed for the 2.4.73 release that occurred a week ago and which I have been using for more than half a week now.
Comment 5 Koop Mast 2016-11-21 16:42:35 UTC
Will update this after I'm done with libdevq.
Comment 6 Matthew Rezny 2016-11-21 16:47:05 UTC
Created attachment 177238 [details] update graphics/libdrm to 2.4.73 Refresh the libdrm patch again to chase the libdevq version.
Comment 7 Matthew Rezny 2016-11-21 18:13:56 UTC
Created attachment 177239 [details] update graphics/libdrm to 2.4.73 Refresh the patch to chase libdevq version everywhere (configure script as well as Makefile).
Comment 8 Matthew Rezny 2016-12-04 10:50:03 UTC
Created attachment 177652 [details] update graphics/libdrm to 2.4.74 Version 2.4.74 has been released and has been working fine on my systems for days, so I've updated the patch accordingly.
Comment 9 meowthink 2016-12-30 09:42:07 UTC
(In reply to matthew from comment #8) There's a potential risk of data corruption in drmBSDDeviceNameHack, patch-xf86drm.c. The function returns the pointer of char hacked_path, but this kind of declaration IMHO would be allocated on the stack. The stack may corrupt when returns to the caller.
Comment 10 Matthew Rezny 2017-01-15 18:20:30 UTC
(In reply to meowthink from comment #9) I have merely been updating libdrm in my local tree upon each release and updating patches as need be. The patches to use libdevq came from an external repo, originally the work of dumbbell and/or kwm afaik. I had not looked closely at the code in the libdevq patches until your comment. Now that I do, I see a few things that could be improved. Since the update of libdrm has been committed, this new patch is just the revised support for libdevq, which is necessary for Mesa 13, and some cleanup.
Comment 11 Matthew Rezny 2017-01-15 18:21:20 UTC
Created attachment 178929 [details] libdevq support for libdrm
Comment 12 commit-hook 2017-01-16 23:06:30 UTC
A commit references this bug: Author: bapt Date: Mon Jan 16 23:05:24 UTC 2017 New revision: 431708 URL: https://svnweb.freebsd.org/changeset/ports/431708 Log: Add support to find directly the drm device via libdevq the same way linux uses libudev PR: 214580 Submitted by: email@example.com Changes: head/graphics/libdrm/Makefile head/graphics/libdrm/files/Makefile.am head/graphics/libdrm/files/configure.ac head/graphics/libdrm/files/patch-Makefile.in head/graphics/libdrm/files/patch-config.h.in head/graphics/libdrm/files/patch-configure head/graphics/libdrm/files/patch-xf86drm.c head/graphics/libdrm/files/patch-xf86drmMode.c head/graphics/libdrm/pkg-plist