On Tue, Jan 08, 2019 at 01:37:07PM +0000, Daniel Thompson wrote:
On Tue, Jan 08, 2019 at 11:25:56AM +0100, Ard Biesheuvel wrote:
On Tue, 8 Jan 2019 at 10:36, Renato Golin renato.golin@linaro.org wrote:
Hi Ard,
I don't have the whole context, but my read of that email is:
- The claim is that "some people had some issues with indeterminate
hardware and indeterminate versions of mesa", however... 2. He "did run the WebGL CTS suite, but that resulted in some hangs from the the max-texture-size-equivalent test, and some browser-level weirdness after some tests where later tests all fail"
I don't think those two statements are compatible. He can reproduce lots of failures on his own machine, probably just didn't have time to investigate all of them in detail.
Furthermore, he claims the failures are "due to what [he has] to assume is a browser bug" without any evidence to support it, and later on claims the driver is fine because "accelerated WebGL [...] in practice worked just fine (at least in my usage of it)".
To me, it smells like someone complaining that a broken piece of software is black-listed and shouldn't have because everyone know it's broken anyway, but it kinda works, so it's fine.
I think one of the complaints is that there is a double standard here.
I was curious enough about this to at least run the test suite recommended in the bug tracker.
My Intel/x86_64/Intel/F29 laptop and my Socionext/AArch64/nVidia/buster Developerbox work pretty much the same. Which is to say that the test suite causes the graphics stacks of both machines to lock up entirely (including rejecting any attempt to switch virtual terminals).
Regrettably that makes it difficult to access and share the test results prior to failure (I don't *think* the two machines fail at the same point although I did neglect to photograph the display so I can't be sure).
Presumably this is a similar issue to what we previously observed with nouveau on developerbox/macchiatobin, and such ssh access should still be possible?
/ Leif