OK, thanks, I missed that.
Brian Paul wrote:
A patch to fix this was already posted and reviewed. I'll push it soon
since I think Michel is off-line this time of day.
-Brian
On 07/13/2017 09:17 AM, Andy Furniss wrote:
This breaks startx on radeonsi for me on a R9 285.
[ 5297.130] (II) gla
A patch to fix this was already posted and reviewed. I'll push it soon
since I think Michel is off-line this time of day.
-Brian
On 07/13/2017 09:17 AM, Andy Furniss wrote:
This breaks startx on radeonsi for me on a R9 285.
[ 5297.130] (II) glamor: OpenGL accelerated X.org driver based.
[
This breaks startx on radeonsi for me on a R9 285.
[ 5297.130] (II) glamor: OpenGL accelerated X.org driver based.
[ 5297.132] (II) glamor: EGL version 1.5 (DRI2):
[ 5297.133] (EE)
[ 5297.133] (EE) Backtrace:
[ 5297.151] (EE) 0: /usr/libexec/Xorg (OsSigHandler+0x29) [0x584069]
[ 5297.164] (
On 07/11/2017 11:15 AM, Charmaine Lee wrote:
Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system
Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling
framebuffer object by unreferencing the window system draw/read buffers
when context is released. However this can prematurely destroy the
resources associated with these window system buffers. The problem is
reproducible with Turbi
