On 3 November 2016 at 17:59, Adam Jackson wrote:
> On Thu, 2016-11-03 at 17:28 +, Emil Velikov wrote:
>
>> Your earlier reply did not have ack/nack on the topic of dropping it,
>> thus the above reads as a justification why one would wants to keep
>> it.
>
> I thought "useless" expressed my op
On Thu, 2016-11-03 at 17:28 +, Emil Velikov wrote:
> Your earlier reply did not have ack/nack on the topic of dropping it,
> thus the above reads as a justification why one would wants to keep
> it.
I thought "useless" expressed my opinion of the value of the feature
quite well. But I didn't
On 3 November 2016 at 17:12, Adam Jackson wrote:
> On Thu, 2016-11-03 at 16:21 +, Emil Velikov wrote:
>
>> I'm not a fan of keeping legacy stuff with only one (pretty useless)
>> user. Not to mention that the glXGetDriverConfig plumbing is missing
>> [in here]. But as you feel so strongly in k
On Thu, 2016-11-03 at 16:21 +, Emil Velikov wrote:
> I'm not a fan of keeping legacy stuff with only one (pretty useless)
> user. Not to mention that the glXGetDriverConfig plumbing is missing
> [in here]. But as you feel so strongly in keeping it ...
Maybe I wasn't clear. I don't care at all
On 1 November 2016 at 19:06, Adam Jackson wrote:
> On Mon, 2016-10-31 at 20:28 +, Emil Velikov wrote:
>> >
>> > One user, xdriinfo(1), which is admittedly pretty useless. But the
>> > glvnd code in mesa definitely implements dispatch for it (libglvnd
>> > itself does not, but is not expected t
On Mon, 2016-10-31 at 20:28 +, Emil Velikov wrote:
> >
> > One user, xdriinfo(1), which is admittedly pretty useless. But the
> > glvnd code in mesa definitely implements dispatch for it (libglvnd
> > itself does not, but is not expected to).
>
> libglvnd doesn't dispatch to it one cannot rea
On 31 October 2016 at 19:20, Adam Jackson wrote:
> On Fri, 2016-10-28 at 17:11 +0100, Emil Velikov wrote:
>> > On 19 October 2016 at 18:39, Adam Jackson wrote:
>> > The "implementation" in Mesa would be __glXBindTexImageEXT. One could
>> > argue that dispatch_* could be smart enough to recognize
On Fri, 2016-10-28 at 17:11 +0100, Emil Velikov wrote:
> > On 19 October 2016 at 18:39, Adam Jackson wrote:
> > The "implementation" in Mesa would be __glXBindTexImageEXT. One could
> > argue that dispatch_* could be smart enough to recognize their own
> > dispatch tables, skip the glvnd call to -
On 19 October 2016 at 18:39, Adam Jackson wrote:
> On Fri, 2016-09-16 at 19:07 +0100, Emil Velikov wrote:
>> On 14 September 2016 at 19:06, Adam Jackson wrote:
>> > As this array was not actually sorted, FindGLXFunction's binary search
>> > would only sometimes work.
>> >
>>
>> This commit messag
On 09/14/2016 11:06 AM, Adam Jackson wrote:
> As this array was not actually sorted, FindGLXFunction's binary search
> would only sometimes work.
Ugh... could these tables be generated by something that would sort them
automatically? Alternately, could we have a 'make check' test that
verifies th
On Fri, 2016-09-16 at 19:07 +0100, Emil Velikov wrote:
> On 14 September 2016 at 19:06, Adam Jackson wrote:
> > As this array was not actually sorted, FindGLXFunction's binary search
> > would only sometimes work.
> >
>
> This commit message is a bit iffy, yet again most of this and
> g_glxglvnd
On 14 September 2016 at 19:06, Adam Jackson wrote:
> As this array was not actually sorted, FindGLXFunction's binary search
> would only sometimes work.
>
This commit message is a bit iffy, yet again most of this and
g_glxglvnddispatchfuncs.c is dead code.
Afaict the sole reason behind his file i
As this array was not actually sorted, FindGLXFunction's binary search
would only sometimes work.
Signed-off-by: Adam Jackson
---
src/glx/g_glxglvnddispatchfuncs.c | 254 ++--
src/glx/g_glxglvnddispatchindices.h | 36 ++---
2 files changed, 144 insertions(+), 1
13 matches
Mail list logo
