Release v2.20.0 #3794
Release v2.20.0 #3794
Conversation
Try more fonts and more locations when drawing SSD text
The main active ingredient here is passing through the list of `GLRenderingProviders` when invoking the `SetCompositor` hook, necessary for QtMir to allocate `Framebuffer`s to submit to output and to get `gl::Texture`s out of `mg::Buffer`s. Also some miscellaneous drive-through cleanup, and the addition of `gl::Texture::tex_id()` that significantly simplifies QtMir by exposing something Mir already¹ knows. ¹: With the exception of `ShmBuffer`, but this also prompts a bit of cleanup.
This comment was marked as outdated.
This comment was marked as outdated.
|
Needs #3793 |
Fixes: #3734 Unclear why/if it was needed before, but today it just breaks things.
~rc12Platforms
Console Providers
Window Manager Examples
Notes
|
Keep references to server components by weak pointer so that we do not extend their life beyond the life of the server
Because we're on an `EGLContextExecutor` we're probably on a different thread to where the GL state is going to be used, *and* we don't have implicit flushing with `eglMakeCurrent` happening (because the context just stays current on the `EGLContextExecutor`. If the GL implementation has per-thread execution queues (for example, amdgpu by default), this might mean that the texture setup commands aren't visible to command stream that's actually using the texture. Explicitly `glFlush()` after our texture setup, to ensure these commands are visible to any `EGLContext` that might need them. Closes: #3792
Found compile errors such as the following both on v2.19.3 and main
(with this PR being verified against the latter):
```
In file included from src/platforms/common/server/kms-utils/threaded_drm_event_handler.cpp:17:
In file included from src/platforms/common/server/kms-utils/threaded_drm_event_handler.h:20:
src/platforms/common/server/kms-utils/drm_event_handler.h:42:14: error: no template named 'function' in namespace 'std'
42 | std::function<void(unsigned int frame_number, std::chrono::milliseconds frame_time)> on_flip) = 0;
| ~~~~~^
In file included from src/server/server.cpp:39:
In file included from src/server/frontend_wayland/wayland_connector.h:20:
src/include/server/mir/shell/token_authority.h:72:10: error: no type named 'mutex' in namespace 'std'
72 | std::mutex mutable mutex;
| ~~~~~^
In file included from src/server/scene/session_manager.cpp:17:
In file included from src/server/scene/session_manager.h:20:
src/include/server/mir/scene/session_coordinator.h:47:9: error: unknown type name 'pid_t'
47 | pid_t client_pid,
| ^
src/miral/config_file.cpp:126:28: error: implicit instantiation of undefined template 'std::basic_istringstream<char>'
126 | std::istringstream config_stream{config_dirs};
| ^
/usr/bin/../include/c++/v1/__fwd/sstream.h:26:28: note: template is declared here
26 | class _LIBCPP_TEMPLATE_VIS basic_istringstream;
| ^
```
Since I already fixed similar issues in #3388 and they seem to keep
coming back overtime would it make sense to have CI testbuild against
musl paired with LLVM libc++ as well? Using alpine edge as a base with
`apk add clang19 lld libc++-dev llvm-libunwind-dev` and adding
`--rtlib=compiler-rt` to `CFLAGS`, `-stdlib=libc++ -unwindlib=libunwind`
to `CXXFLAGS` and `-fuse-ld=lld` to `LDFLAGS` should more or less
replicate my setup (minus using LLVM in place of binutils?)
debian/changelog
Outdated
|
|
||
| - ABI summary: | ||
| . miral ABI unchanged at 7 | ||
| . mircommon ABI bunped to 11 |
There was a problem hiding this comment.
| . mircommon ABI bunped to 11 | |
| . mircommon ABI bumped to 11 |
Fixes: #3786
|
Just tested eglstream + gbm-kms. Still have the nvidia related crash when closing windows and xwayland crashing on resizing. No big deal since that was already known. I'm not sure if it's related to this release: If I get notifications in |
For the avoidance of doubt: you were testing ~rc17, but editing the ~rc12 comment? |
~rc17Platforms
Console Providers
Window Manager Examples
Notes
|
Are these actual notifications (like using You should be able to check with EDIT: Also, comparing with v2.19.3 would be good. |
Wasn't paying attention to the number. You are correct |
Whatever firefox uses. When the issue occurred I was just editing the table to add my signature, got a notification, and everything froze for a moment. No alt-tab, no response to cursor clicks, nothing.
Don't think focus stealing plays into this. Isn't it disabled by default?
I use miriway based on 2.19.3 everyday and get tons of email notifications with no freezes whatsoever |
I just mean the notification-like-window in the middle:
|
Yep, that's still there. The notification looks close to the one that appeared when the freeze occurred, but it's not freezing. |
Can you work with Do you have a reproducer of the problem? E.g. https://www.kenherbert.dev/browser-notification-tester/ ? |
ABI summary:
Enhancements:
Turn it on with
--focus-stealing-prevention trueon supported compositors.launch_app_env#3703)mir*-internallibraries #3283)surface.frameevent quirk #3740)Bugs fixed:
zwp_text_input_v1(Electron) #3580)main) #3729)