User Details
- User Since
- Jan 25 2017, 3:59 PM (405 w, 6 d)
Dec 25 2017
Nov 9 2017
Oct 24 2017
Oct 16 2017
Oct 10 2017
Sep 30 2017
Sep 8 2017
Sep 6 2017
Aug 27 2017
Aug 22 2017
Aug 20 2017
Jul 28 2017
This is looking pretty good. I had no difficulty building qt5-webkit or any of the dependents (not that it was necessary to do so, just verifying). I haven't found any issues with updated webkit in a couple weeks of use.
Jul 27 2017
Jul 16 2017
Jul 15 2017
Using a snapshot is a better solution than trying to backport support for LLVM 4.0 while we await the release of beignet 1.4.
Commenting the patch files to explain their purpose is a better solution. Just because patches may be combined doesn't mean it's a good idea nor the preferred way.
This appears completely backwards. Why would you lump the patches together when the preferred way to is to use makepatch? This only makes maintenance harder.
Jul 12 2017
bump PORTREVISION
Jul 11 2017
Jul 10 2017
Jun 18 2017
Jun 13 2017
Add a commit revert patch for 10.x to keep HW accel working on Intel. cpm reported that his gen6 system lost HW accel upgrading from Mesa 17.0.4 to 17.1.0 and it was due to this commit. As I have no issue on 11.0, the feature check is catching some difference between 10.x and 11.x
Jun 12 2017
Jun 6 2017
Jun 5 2017
May 21 2017
May 12 2017
May 7 2017
May 6 2017
May 5 2017
Unfortunately the differential is without full context so I cannot inline the comments pertaining to graphics/wayland/Makefile.
Terminate strings from sysctl and add header include guard for portability.
May 4 2017
Improve platform support as suggested and drop DEBUG.
That is correct, those who wish to try Wayland will n6eed to build some ports with non-default options. The alternative is worse; making everyone using Xorg/Mesa install parts of Wayland regardless of their intent to use it. Unfortunately, we cannot just split off libwayland-egl.so into it's own package because the WAYLAND option also affects the build of gbm (part of the reason to combine the libs was to have a single WAYLAND option affecting both gbm and EGL). I cannot think of a better solution without support for flavors (which would allow packages for mesa-libs and mesa-libs+wayland) but am open to suggestions.
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.
Maybe we can split it up like xorg-server/xwayland. gtk30-wayland?
That would be ideal if possible. I do not know much about gtk30 so I cannot comment on the feasibility and will defer to kwm as the expert.
That is done when the WAYLAND option is enabled.
- Wayland also needs to be enabled with --with-egl-platforms flag (previosly in libGL Makefile.common)
Also done when the WAYLAND option is enabled.
- Enable DRI3 by default? (not really needed for wayland)
DRI3 support is already enabled at build time. There is an extra runtime switch due to EGL failing to fallback to DRI2 when the system doesn't support DRI3, i.e. stock FreeBSD. I hope that work-around will be short lived but there is not yet any response to the ticket I opened upstream so I might have to be the one to fix it.
Outside of Mesa I would like to
- Enable wayland backend by default in gtk30.
- Enable Xwayland in xorg-server
We have x11-servers/xwayland now. Is there something missing or not enabled in the build?
This will add default dependency on wayland for xorg and gtk30 but I think it will be hard to make wayland optional given the dependencies.
I don't know about gtk30 but hopefully Wayland can be optional for both Xorg and gtk30.
Revise patch-lib_CL_devices_cpuinfo.c
May 3 2017
Update based on feedback in the PR.
May 2 2017
Replace direct reference to libGL with USE_GL=gl in science/iboview
Refresh patch due to changes in MOVED
Apr 26 2017
Trim obsolete USES=libtool:keepla