To be honest, the issue description is insufficient and the crash file useless.
The stacktrace does not contain any debug symbols and for the "sometimes shows screen garbage before disconnecting" part, a screenshot would be needed, because the screen content is not just garbage.
It has a pattern, and that is a wrong DRM format modifier. It may not be obvious for the user, but developers don't have a glass ball in front of them to see what happens on the other side of the screen, so a screenshot can be super helpful.
I found similar stacktraces in Ubuntus error tracker. Problem with Ubuntus error tracker is that a lot stacktraces cannot be retrieved and therefore leave only a single line of calls, where only the library name is shown.
And this is also here the case.
However, the issue could be fixed upstream and is fixed in the current master branch of g-r-d, due to kind help of a person in https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/96.
Personally, I don't have an arm64 device, which is why this issue could never been detected.
And without that help in form of testing patches and providing the stacktrace with debug symbols, the issue would still exist.
I'll ask Jonas to push another release tag (might be 42.1.1). 42.1 was pushed saturday, but does not contain these fixes. Personally, I see this issue as severe, but I am not one, who can push tags in g-r-d. So, I can only ask Jonas to push one.
In any case, Ubuntu can also build g-r-d from the master branch until commit https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/d9923317f0b60621f0aeb219f4d10612a2178e63 to push the fix to Ubuntu here.
To be honest, the issue description is insufficient and the crash file useless.
The stacktrace does not contain any debug symbols and for the "sometimes shows screen garbage before disconnecting" part, a screenshot would be needed, because the screen content is not just garbage.
It has a pattern, and that is a wrong DRM format modifier. It may not be obvious for the user, but developers don't have a glass ball in front of them to see what happens on the other side of the screen, so a screenshot can be super helpful.
I found similar stacktraces in Ubuntus error tracker. Problem with Ubuntus error tracker is that a lot stacktraces cannot be retrieved and therefore leave only a single line of calls, where only the library name is shown.
And this is also here the case.
However, the issue could be fixed upstream and is fixed in the current master branch of g-r-d, due to kind help of a person in https:/ /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/issues/ 96.
Personally, I don't have an arm64 device, which is why this issue could never been detected.
And without that help in form of testing patches and providing the stacktrace with debug symbols, the issue would still exist.
The crash itself is kinda interesting, because it appears, that some instructions are completed in a different order on arm64. /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/commit/ bdc8d63bddf2ebb 0da97e9277267b7 398e49710e and https:/ /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/commit/ b7b0597ba59072b 718a78760c2732e 64e080b4bf.
It was fixed in https:/
Then, to the part, what is here referred to as 'garbled content': /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/issues/ 96#note_ 1435877 MOD_INVALID` modifier is used to indicate an implicit modifier. MOD_INVALID` as modifier was never a problem with other drivers, like Intel and so it was unnoticed. /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/commit/ 60244e96333fbea bfee9c1a0e5ce56 590dbb313d and https:/ /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/commit/ d9923317f0b6062 1f0aeb219f4d106 12a2178e63.
A screenshot for this is provided here: https:/
Without the screenshot, I wouldn't been able to have that modifier guess. So, please, for future reports provide screenshots for such things.
The issue here is that g-r-d always expected explicit DRM format modifiers. However, it is an implicit modifier here.
There is no such flag to indicate that and as a result the `DRM_FORMAT_
It is a weird thing though: In a screencast, submitting this specific modifier means, that an implicit modifier is used, while graphics APIs use this to indicate an error.
However, using `DRM_FORMAT_
The issue was fixed in https:/
I'll ask Jonas to push another release tag (might be 42.1.1). 42.1 was pushed saturday, but does not contain these fixes. Personally, I see this issue as severe, but I am not one, who can push tags in g-r-d. So, I can only ask Jonas to push one. /gitlab. gnome.org/ GNOME/gnome- remote- desktop/ -/commit/ d9923317f0b6062 1f0aeb219f4d106 12a2178e63 to push the fix to Ubuntu here.
In any case, Ubuntu can also build g-r-d from the master branch until commit https:/