[NiLuJe]

No, it's just that we run (by design, for performance reasons; and because of the way our UI loop functions) in conditions that exacerbate potential EPDC issues.

Nickel, on the other hand (by constraint, mostly because Qt), doesn't. So, while similar issues can (and have been) reproduced in Nickel, they should occur much more rarely (if ever for Joe Random) there.

(But this is a much more complex issue, possibly compounded by multiple subtle factors, because we've tried to run in a setup that more closely matches Nickel, and it apparently didn't help).

This is also kind of black box, as I don't have the device myself, so this is based on a few assumptions based on results from remote testing and my own experience with possibly similar issues on other devices (most of which are *also* based on results from remote testing, or on very hard to reproduce stuff that I couldn't get any debugging info out of), and, I'd need a local device with serial access (and possibly a custom debug kernel) to actually say for sure what the hell's happening (or not). And even if I did figure something out (and that's a big if), we probably couldn't do anything about it anyway.

What's for sure is that lab126 took their sweet time to polish a brand new board on a brand SoC for the PW5, but it payed off, as it's been rock-solid and hilariously more efficient than the competition, while the whole slew of boards that NTX put out and ended up in Kobo devices starting with Mk.8 have been... err, let's say *very* rough around the edges, to varying extents...

----

It's a bit early to say anything about the Clara 2E, seeing as we've only seen a single tester on a single device (and the kernel drop isn't out yet... *wink, wink, nudge, nudge*), but it's going... significantly worse than it ever did before ;D. Early days, though, and resolving the more obvious issues might magically make the rest better.