How is the Win+W overview effect working for your? It makes kwin-wayland very, very crash happy here.
That’s some Sherlock Holmes type of sleuthing 
. Would never have thought about mime types for this.
I’ll have a look at my end later today. First have to have a look at a leak in the roof… 
Will have a look later today.
Found any bug reports that might be related?
Found nothing so far, which is curious, because I have a lot of issues with Overview:
- Often crashes kwin/plasmashell just invoking it
- Searching there very often crashes
- It’s overall very choppy/low framerate
I don’t use the overview much, but a few tries with it and even searching, seems fine for me.
As I’ve posited before, I wonder if our varying experiences are hardware or lingering out-dated niggles somewhere on the system?
Oh…I forgot my favorite question, are you by any chance running an Nvidia card? (Due to problems, i will never own one unless I have no choice or they correct their Linux support).
It’s an Intel card which overall runs very stable. But it may be a “me” problem, thus the “how is your general impression” question to get a rough overview.
Yep, it’s of considerable value in sharing experiences to refine what to report back up.
And on a human level, it’s very nice to collaborate and feel involved with the process!
Just tried Win+W to my heart´s context. No crashes, but certainly laggy. Takes up to a second (sometimes longer) for the overview to show; and the overview builds up in steps, not smooth.
FWIW:
Graphics:
Device-1: Intel UHD Graphics 620 vendor: Acer Incorporated ALI driver: i915
v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports:
active: eDP-1 empty: HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:5917
class-ID: 0300
Display: server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2
compositor: kwin_wayland driver: X: loaded: modesetting
alternate: fbdev,intel,vesa dri: iris gpu: i915 display-ID: :1 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x286mm (20.00x11.26")
s-diag: 583mm (22.95")
Monitor-1: eDP-1 model: BOE Display 0x06ba built: 2016 res: 1920x1080
hz: 60 dpi: 143 gamma: 1.2 size: 340x190mm (13.39x7.48") diag: 394mm (15.5")
ratio: 16:9 modes: 1920x1080
API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris
device: 1 drv: swrast surfaceless: drv: iris x11: drv: iris
inactive: gbm,wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 23.2.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: Mesa Intel UHD Graphics 620 (KBL
GT2) device-ID: 8086:5917 memory: 3.62 GiB unified: yes
API: Vulkan Message: No Vulkan data available.
I had a look at file-associations. File type “jpeg” is associated with filename patterns: jfif, jpe, jpeg, jpg.
All of which are associated with: gwenview, Gimp, Okular, Chromium.
Starting spectacle from cli:
kpipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
kpipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
Trying to make a screen recording then resulted in a crash (I think): first a black screen, and then I got thrown out of my desktop/session and had to log in again.
Will look at this some more later today.
Same warning messages, but screenshot and recordings (brief: 10 seconds) seem to work just fine for me.
yay -Qs pipewire search locally installed for the searchterm pipewire 
Thanks for testing. I probably going to file my crashes, I just have to collect the relevant log output.
Same for me in a fresh VM installation and afaik that is the correct setup. My actual system only had jfif associated. And there were issues with mime-changes after KDE updates in the past. Who knows, maybe hitting an edge cased. - Again, thanks for testing.
That sounds bad. That should not happen. Afaik the VA-API/DRM error messages are OK. That’s hardware video acceleration and afaik Intel is currently blacklisted - don’t know why. But the non-hardware-accelerated recording should work nonetheless.
If you go into the Spectacle settings and change the video output format from whatever is is now (VP9/h.264), do both fail? If you really want to go down that rathole it would be interesting to know if you can capture your screen with OBS and Screen Capture (Pipewire).
Doing some more research on spectacle - am trying out
journalctl -f
which produces messages on the go.
Came across a journal message where a dev apparently decided that life’s too short for certain situations to be given their own branch of code and just gave up:
“kf.coreaddons: Even a brand-new cache starts off corrupted, something is seriously wrong. 
”
Possibly not related to anything we’ve been discussing, but made me smile, so I thought I’d share.
Edit: another chuckle:
This plugin does not support grabbing the keyboard
There’s some fun to be had reading logs, it appears. 
Am trying to find some reason in spectacle’s madness. Tried once more a screen recording with default settings (not yet with the adjustments you suggested).
Spectacle “thinks” it’s recording, but the timer remains on 0:00, the application stalls/hangs, can’t be closed through gui.
Am seeing this on terminal output:
pipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
kpipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
kpipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
kpipewire_record_logging: VAAPI: Failed to initialize display
kpipewire_record_logging: DRM device not found
[libvpx @ 0x7f5184461c80] v1.13.1
[AVFormatContext @ 0x7f5184634100] Unable to choose an output format for ''; use a standard extension for the filename or specify the format manually.
kpipewire_record_logging: Could not deduce output format from file: using WebM. ""
kpipewire_record_logging: Could not open "" Bestand of map bestaat niet
kpipewire_record_logging: Could not set up the producing thread
This part:
[AVFormatContext @ 0x7f5184634100] Unable to choose an output format for ''; use a standard extension for the filename or specify the format manually.
seems to be connected to extensions?
It’s all rather unstable, very much “je ne sais quoi”, at the moment, I feel.
I’ll keep digging, though.
I’m not a C guru, but it looks like there’s something up with the filepath/filename/extension that ffmpeg further down the stack complains about being empty. Which could indicate that Spectacle is providing bad params to ffmpeg (and leaving aside overall potential pipewire screen capturing issues for now).
What I would try as a quick test is to move away/rename (don’t delete it) an existing ~/.config/spectaclerc and therefore resetting Spectacles paths/params to its defaults and see what happens.
I am running plasma 6 on its own partition and haven’t knowingly done any changes to spectacle, so don’t mind erasing or resetting configs or parameters.
Will try as you suggest later today.
Running it in a environment you don’t care about is good.
Main reason for keeping it is if it changes the situation then: a) an A-B test: yes, putting it back into the previous state causes the problem again and therefore confirming the cause (or not) and b) then provide that information in a bug report for others to replicate the issue.
I removed `spectaclerc’ as suggested and started spectacle from cli.
Made some screen shots, then some screen recordings. First few (2 or 3, of a few seconds) went well. Then, at another attempt, the system became sluggish, yakuake (where I had journalctl -f running, and had started spectacle) and spectacle crashed.
My session kept running.
journalctl | grep -i 'spectacle'
spectacle[3310]: kpipewire_dmabuf_logging: eglChooseConfig returned this many configs: 1
spectacle[3310]: *** pw_stream_destroy called from wrong context, check thread and locking: Not in loop
spectacle[3310]: *** impl_ext_end_proxy called from wrong context, check thread and locking: Not in loop
spectacle[3310]: 'pthread_equal(impl->thread, thread_id)' failed at ../pipewire/spa/plugins/support/loop.c:363 loop_leave()
[...]
kernel: [ 3386] 1000 3386 1080271 258435 3362816 0 200 spectacle
oom-kill:constraint=CONSTRAINT_NONE,nodemask(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.k
de.yakuake@autostart.service,task=spectacle,pid=3386,uid=1000
kernel: Out of memory: Killed process 3386 (spectacle) total-vm:4321084kB, anon-rss:1028296kB, file-rss:1344kB, shmem-rss:4100kB, UID:1000 pgtables:3284kB oom_score_adj:20
0
journalctl | grep -i 'pipewire'
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 target not found
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 unknown resource 5 op:7
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 target not found
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 unknown resource 5 op:7
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 target not found
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 unknown resource 5 op:7
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 target not found
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 unknown resource 5 op:7
wireplumber[1064]: <WpSiStandardLink:0x5593deea7860> 1 of 1 PipeWire links failed to activate
pipewire[1061]: mod.client-node: 0x5596b76235a0: unknown peer 0x5596b763a0e0 fd:110
pipewire[1061]: mod.client-node: 0x5596b74af250: unknown peer 0x5596b7639f20 fd:116
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 target not found
plasmashell[919]: kpipewire_logging: PipeWire remote error: -2 unknown resource 6 op:7
kernel: PipeWireProduce invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=200
kernel: CPU: 0 PID: 3710 Comm: PipeWireProduce Not tainted 6.6.3-arch1-1 #1 6156c717f7d423f5954ce718462aaaaa43b9110d
kernel: [ 1061] 1000 1061 51803 2638 151552 0 200 pipewire
kernel: [ 1430] 1000 1430 27847 1991 110592 0 200 pipewire-pulse
I’m wondering if all this is relevant to what I set out to do, which is test Plasma 6…
That’s a good question. 
If it’s working in plasma 5 + EndeavourOS/Arch standard and then is broken now in the plasma beta + testing something changed. Someone has to file it, something did break somewhere. And someone is hopefully going to make a deep dive and is going to fix it.
Most of us can’t do the deep dive and fix it. Many of us can’t figure out what went wrong. Often it comes down to filing a “here’s a screenshot of what doesn’t look as before, no log - sorry, don’t know”. Our abilities and resources are limited too, same as the KDE folks.
All of it is fine. You dig into it as best as possible, you learn something new, but eventually you’re stuck. It is what it is. Someone else is going to advance your initial, inconclusive bug report in the future if necessary. Half of my reports on the KDE bugtracker are unconfirmed or unresolved, that doesn’t mean they didn’t happen - I have video evidence.
Move on and report another thing that is broken. o7