On Wed, 2016-09-14 at 14:29 +0100, Emil Velikov wrote:
> It's surprising that you haven't heard about this, considering it's
> been in use for more than three years. Guess you simply forgot ?
Most of my own patches to Mesa have been so far from being "features"
that I've never had to care.
- aja
On 14 September 2016 at 13:36, Adam Jackson wrote:
> On Wed, 2016-09-14 at 11:15 +0100, Emil Velikov wrote:
>
>> Nice one... I wonder if your view will be the same if you were never
>> involved in distribution packaging? Guess we'll never know :-\
>> In case you've forgotten things have been like
On Wed, 2016-09-14 at 11:15 +0100, Emil Velikov wrote:
> Nice one... I wonder if your view will be the same if you were never
> involved in distribution packaging? Guess we'll never know :-\
> In case you've forgotten things have been like that for a long time -
> long before I jumped in.
I wasn'
On 13 September 2016 at 19:22, Adam Jackson wrote:
> On Tue, 2016-09-13 at 19:18 +0100, Emil Velikov wrote:
>
>> For the series as a whole ?
>> Two words which contradict any software's stable scheme - new feature.
>
> Disagree, but I'm not the one running Mesa's stable branch, so my
> opinion doe
On Tue, 2016-09-13 at 19:18 +0100, Emil Velikov wrote:
> For the series as a whole ?
> Two words which contradict any software's stable scheme - new feature.
Disagree, but I'm not the one running Mesa's stable branch, so my
opinion doesn't count here.
- ajax
_
On 13 September 2016 at 19:14, Adam Jackson wrote:
> On Tue, 2016-09-13 at 17:22 +0100, Emil Velikov wrote:
>
>> Actually, current code has a bunch of such bugs which this series addresses.
>> Considering there's only a couple of those and they are pretty hard to
>> hit I won't bother with respinn
On Tue, 2016-09-13 at 17:22 +0100, Emil Velikov wrote:
> Actually, current code has a bunch of such bugs which this series addresses.
> Considering there's only a couple of those and they are pretty hard to
> hit I won't bother with respinning the patches.
>
> That is unless we want them for stab
On 13 September 2016 at 15:39, Emil Velikov wrote:
> On 12 September 2016 at 23:19, Adam Jackson wrote:
> (More important) note:
> Keeping the _eglLockDisplay() in the top level (EGL API) while the
> unlock in the lower level (fooCommon) will come to bite us. We could
> update the RETURN_EGL_ERR
On 12 September 2016 at 23:19, Adam Jackson wrote:
> From: Kyle Brenneman
>
> ---
> src/egl/main/eglapi.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
> index 658d0d7..dc61d5f 100644
> --- a/src/egl/main/egl
From: Kyle Brenneman
---
src/egl/main/eglapi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 658d0d7..dc61d5f 100644
--- a/src/egl/main/eglapi.c
+++ b/src/egl/main/eglapi.c
@@ -1384,11 +1384,10 @@ eglDestroy
10 matches
Mail list logo
