This is needed by glamor egl in the xserver which is in turn needed
to get acceleration with some hardware on xf86-video-ati.
Worked on during s2k15. Glamor is not yet enabled in the xserver,
but adding this now as libepoxy recently showed up in ports.
The libepoxy port will be removed and ports will transition to
this version. The xenocara version will be enabled when we're
ready to transition.
Contains fixes for following issues:
CVE-2015-1802: bdfReadProperties: property count needs range check
CVE-2015-1803: bdfReadCharacters: bailout if a char's bitmap cannot be read
CVE-2015-1804: bdfReadCharacters: ensure metrics fit into xCharInfo struct
those are the only archs that currently use gallium radeon drivers.
It should build anywhere that has the libdrm radeon headers
installed. And while that should really be everywhere it
isn't at the moment and won't be for release.
It isn't clear why the radeon winsys in Mesa 10.4 didn't have
the same problem.
Found the hard way by todd@ on alpha.
This is desirable as the chromium port now uses this extension to
obtain pci vendor/device ids for use in feature/extension blacklists.
Prompted by a mail from byrnet@, tested on r600g by krw@
The newly added os_get_total_physical_memory() was passing the length of
a pointer rather than the type which made the sysctl call fail on
non 64 bit archs. And it was passing the wrong pointer for the result.
Fixes for these problems have been submitted back upstream.
With 10.4.3 gpu compositing on chromium would result in a black window
on older Intel parts (ie x60s with 945gm) and at least some discrete
Radeon parts. These problems do not seem to occur on recent Intel
parts, though those have coherent memory and hardware contexts.
It isn't clear what changes in Mesa are involved in the problem
though it also occurs with the 10.3 branch.
libEGL against libgbm and libglapi.
The libgbm requirement comes from the drm EGL backend that was
enabled with the 10.2.3 update.
ok matthieu@ kettenis@
/etc/X11/app-defaults stays 1st in the libXt search path so, people
and ports can put customized versions there if needed.
If you didn't customize the versions in /etc/X11/app-defaults, they
should be removed to avoid future issues when one file changes.
discussed at g2k14 and ok ajacoutot@
