@flypig Any news on the possibility to download and test ESR91 on SFOS devices?
I know you attended to FOSDEM 2024, but would be cool to try things out.
We’ve been a bit awaiting recently with new things here on the Jolla boat
3 Likes
Thanks for the detour with the avatars. I hoped during the presentation that you didn’t have to do this by hand, because it looked like quite a bit of work 
1 Like
A note about user agents: I now have an aarch64/arm64 laptop (with Windows still) and I noticed that Firefox at least claims to be an x86 browser instead of arm64 one. That was done for better compatibility with many web sites. There was a bug report for it but I can’t find it again… So perhaps it would be okay to default to the mobile user agent string, something like in post for day 144, or at least not report the architecture. Somethink what mobile Firefox does perhaps?
1 Like
There is already something like that in place, even with the currently released browser:
The thing with UA has always been a mess, and it’s going away anyway according to the master of the web, Google. Also some recommend using a generic UA string for fingerprinting reasons (which is likely why FF does it).
2 Likes
Those are per-site overrides, but I was referring to the default user agent. I found this that describes the recommendations:
About Windows/arm64:
About removing arch altogether:
3 Likes
In case someone missed it; the video is up:
13 Likes
I’ve got a bit behind with the discussion here, but thanks for all the comments.
You’re right, rebuilding just for JavaScript changes would be a real pain, but thankfully this bit, at least, can be streamlined. With JavaScript changes I transfer them directly over to the device (or sometimes even edit them on the device). Check out day 94 for a bit more on this.
Only that it’s on my to-do list. Once the WebView render is working, which I’m doing right now, it should be possible to install it without breaking the email client. So once I’m done with this I think it’d be worthwhile me spending some time to get a version others can really try out properly. I’ll post here when that’s available.
Thanks! I wasn’t sure whether to write about it, so glad to hear this. I’m not totally convinced this way was quicker than doing it by hand, but it was more fun 
On the topic of user agents, I wasn’t aware of this aarch64/x86 hack Mozilla are using. That’s really interesting. It’s crazy that this stuff makes a difference, but given that it does, I personally think it’s worth following Mozilla’s lead. I’ll create an issue for it. Thanks for the discussion and links @direc85, @nephros.
14 Likes
I’m happy that the user agent string gets more thought, since it seems to be quite an important piece of the puzzle of getting more sites work properly… Hopefully with a good default user agent string the list of exceptions gets shorter too. And that’s where the community can really chip in!
Making a test release for the community is a nice idea indeed! I don’t remember if it’s just a JSON file on the disk or in a packaged file, but if the testers could change the content themselves, that would be even more helpful!
Thanks for making the avatar wall! I didn’t realize there are already so many contributors… It really is a community effort.
PS. The Rust 1.75 PR nudged forward a bit (compilation in OBS now works), we’re getting closer and closer of it getting merged.
7 Likes
@flypig came to mind, since theres mesa on sfos,
you can use thse env vars that might give more insight on the opengl side
5 Likes
Ive got some though questions that came to mind today while reading the latest entry of the diary.
It seems we are at the detail stage, where things seem to be ok but really are not, and when the size of the effort becomes clear (massive).
Now dont take this as an offence (not intended to be!); Is @flypig the only one working on the browser at the moment ? Noone at jolla picking up the ball? If thats the case, what is Jolla’s comment on this? Id assume the browser is a key component of SFOS product…and as such an upgrade would be due more support from jolla side, one d expect…
1 Like
@flypig good progress! \o/
It seems you have exited browser world and are stepping into wayland lands, thats a good sign, problems yes but somewhere else 
you could try the WAYLAND_DEBUG=1 (or “all” iirc) to complete your logs with the wayland surface creation protocol (it might be qt-wayland doesnt support swapchains?). Its a fairly simple protocol.
It might make sense to run even an opengles, swap-chain based example to validate this hyphothesis…smaller to build and faster to work with!
Keep going @flypigg~~
5 Likes
The issue that @flypig is now trying to figure out sounds a bit like the one I had with Qt Scene Graph recently. I wasn’t properly releasing textures so it kept reserving dmabuf file descriptors and then eventually the app crashed because it run out of fds (or rather I think it tried to use fd > 1024 for something that’s not compatible with such “high” value). Anyway lsof -p output might be worth looking at.
10 Likes
I’m just going to quote @flypig since it’s good to get some inspiration on a slog:
For those who are still following along, or just desperate to get your hands on a build to test, I appreciate it’s slow progress. But each fix is a fix that’s necessary and I remain confident that eventually all of the pieces will fall in to place. This is very definitely a marathon and not a sprint. An Odyssey not a citybreak. We’ll get there!
9 Likes
Rabbitholes be like loooooooooooooooooooong ones, right?
2 Likes
Indeed! In my case, keeping me from doing sailfish work! Oh, no!
1 Like
Seems @flypig finally managed to escape from a particularly deep one. Good to hear you fixed the freezing issue!
4 Likes
Sheesh, was a bit of a read to catch up! And all for the difference in EGL and Egl 
1 Like
@flypig i suggest giving the LIB_GLDEBUG
/ MESA_DEBUG a try. They will generate alot of output but might highlight the failing function right away. Its time for the heavy weapons 
3 Likes
Thinking about debugging GL code, maybe @flypig, you know or already uses this:
glEnable(GL_DEBUG_OUTPUT);
glDebugMessageCallback(_openGLMessage, 0);
where you can provide a function dealing with GL errors:
static void _openGLMessage(GLenum source _U_, GLenum type, GLuint id, GLenum severity,
GLsizei length _U_, const GLchar* message,
const void* userParam _U_)
{
gboolean warn = TRUE;
const char *ctype, *cseverity;
switch (severity)
{
case GL_DEBUG_SEVERITY_LOW:
cseverity = "LOW";
break;
case GL_DEBUG_SEVERITY_MEDIUM:
cseverity = "MEDIUM";
break;
case GL_DEBUG_SEVERITY_HIGH:
cseverity = "HIGH";
break;
default:
cseverity = "UNKNOWN";
}
switch (type)
{
case GL_DEBUG_TYPE_ERROR:
ctype = "ERROR";
break;
case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR:
ctype = "DEPRECATION";
break;
case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR:
ctype = "UNDEFINED";
break;
case GL_DEBUG_TYPE_PORTABILITY:
ctype = "PORTABILITY";
break;
default:
ctype = "OTHER";
warn = FALSE;
}
if (warn)
g_warning("GL CALLBACK: type = %s, severity = %s, id = %d, message = %s",
ctype, cseverity, id, message);
else
g_debug("Visu OpenGL: type = %s, severity = %s, id = %d, message = %s",
ctype, cseverity, id, message);
}
I’ve used it to partly understand what was wrong in my GL code. But maybe it’s not appropriated in your case if it’s a transfer issue between GPU and offscreen buffer… Good luck anyway !
3 Likes
If its an opengl transfer, it will show!