Open sqozz opened 1 year ago
I also replaced the xdg-desktop-portal
with an interactive session but also no problem visible here:
sqozz@workstation ~ » /usr/libexec/xdg-desktop-portal -r -v
XDP: load portals from /usr/share/xdg-desktop-portal/portals
XDP: loading /usr/share/xdg-desktop-portal/portals/gnome-keyring.portal
XDP: portal implementation for gnome
XDP: portal implementation supports org.freedesktop.impl.portal.Secret
XDP: loading /usr/share/xdg-desktop-portal/portals/wlr.portal
XDP: portal implementation for wlroots, sway, Wayfire, river, phosh, Hyprland
XDP: portal implementation supports org.freedesktop.impl.portal.Screenshot
XDP: portal implementation supports org.freedesktop.impl.portal.ScreenCast
XDP: providing portal org.freedesktop.portal.MemoryMonitor
XDP: providing portal org.freedesktop.portal.PowerProfileMonitor
XDP: providing portal org.freedesktop.portal.NetworkMonitor
XDP: providing portal org.freedesktop.portal.ProxyResolver
XDP: providing portal org.freedesktop.portal.Trash
XDP: providing portal org.freedesktop.portal.GameMode
XDP: providing portal org.freedesktop.portal.Realtime
** (/usr/libexec/xdg-desktop-portal:14349): WARNING **: 21:50:47.287: No skeleton to export
XDP: Falling back to wlr.portal for org.freedesktop.impl.portal.Screenshot
XDP: Falling back to gnome-keyring.portal for org.freedesktop.impl.portal.Secret
XDP: providing portal org.freedesktop.portal.Secret
XDP: Falling back to wlr.portal for org.freedesktop.impl.portal.ScreenCast
XDP: providing portal org.freedesktop.portal.ScreenCast
XDP: org.freedesktop.portal.Desktop acquired
XDP: screen cast session owned by ':1.95' created
XDP: screen cast session owned by ':1.95' started
I have exactly the same problem, also using HyperHDR. I will try to also run it with the trace
flag and check if that also keeps it from happening.
I found this by change...I will try to debug it also, maybe there is a workaround (I suspect the buffer that is holding the last frame must be released immediately in such cases, can be done if it resolves it). If someone is willing to test an experimental amd64 version using a hardware acceleration, it's available here: https://github.com/awawa-dev/HyperHDR/discussions/386#discussioncomment-4051927
I tested it with the trace
log level and it seemed to crash less often, only two times in about 2 hours. This could totally be random though.
@awawa-dev the build won't work on my system, do you have a branch with the changes, then I can compile it myself.
@Algram I need to clean it and will publish it just after v19 is released, probably month or so. There is one library in this package missing due to the size limit and need to be copied from the standard release but it's mentioned in the thread (ldd will show it). Anyway I will also try it myself.
Just as an update: This is definitely happening way less often when using the trace
flag. It does not make sense to me, but that is how it is. I have been running it like that the last few months and it definitely makes a big difference.
@Algram you can build and test this PR https://github.com/awawa-dev/HyperHDR/pull/556
I use HyperHDR and its pipewire backend to capture my screen and map it to some LEDs. I realized that after some seconds of using it, nothing is updated anymore and the recorded screen just shows a static frame. However, the mouse is still moving. I validated this using a Jitsi session in Firefox.
Versions and software I use:
While trying to collect data for this bug report I started xdg-desktop-portal-wlr with
-lTRACE
and to my surprise it just does not "crash"/hang any longer. So unfortunately the best I can do is look at the-lDEBUG
log which only prints:This message appears hundreds of times per seconds but doesn't look to suspicious. Let me know if there is any other useful way I can provide you with more data/logs.