[frameworks-kwayland] [Bug 448141] QT_SCALE_FACTOR breaks applications on Wayfire
https://bugs.kde.org/show_bug.cgi?id=448141 --- Comment #6 from Tom B --- Sorry for keeping posting here, but something else strange is going on... QT_WAYLAND_FORCE_DPI works as expected until 143. As soon as I set it to 144, clicks stop registering. However: 1. 144 looks significantly larger than 143 (I should not be able to tell the difference 144 and 143 without comparing them side by side) 2. The default dpi is 96 (verified by comparing launching with it forced to 96 and not set at all). It can't be a coincidence that 144 is a scale factor of exactly 1.5 and it's at exactly 1.5x DPI that things break. There must be something in the code that says if the scale >= 1.5 handle it differently. But, strangely, a scale factor of < 1.5 does not work either (with QT_SCALE_FACTOR=1.1 the click events are still broken, but scaling using QT_WAYLAND_FORCE_DPI works fine until the equivalent of 1.5x. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 448141] QT_SCALE_FACTOR breaks applications on Wayfire
https://bugs.kde.org/show_bug.cgi?id=448141 --- Comment #5 from Tom B --- For reference, I thought I'd try a few other applications to see if there is a common denominator: VLC: Scales correctly, clicks are registered octopi (package manager): Sales correctly, clicks are not registered Filezilla: Scale is not applied (I'm pretty sure it uses Qt) Elisa: Scales correctly, clicks are registered. Interestingly, this one is a KDE application, though I'm not sure if it uses frameworks as it does look different to the others. kdenlive: Scales correctly, clicks are broken (expected, as it's a kde frameworks application) systemsettings5: Scales correctly, clicks are broken (expected, as it's a kde frameworks application) OBS Studio: Scales correctly, clicks are broken on some elements. Resizing/dragging the video works, the menu does not, buttons do not and the entire panel at the bottom does not respond to clicks. So a mixed bag. Should I report this to Qt? It's not all Qt apps which are affected, and Elisa is definitely Qt5 so it's strange that works. Whereas OBS is not using KDE frameworks at all and that's affected. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 448141] QT_SCALE_FACTOR breaks applications on Wayfire
https://bugs.kde.org/show_bug.cgi?id=448141 --- Comment #4 from Tom B --- The same thing happens on Sway (the cursor events are ignored). However, Weston is a little different. If I: - Set scale factor to 2 - Maximize the window Click events can be registered, as normal and in the correct location, in the top left quarter of the screen (which would be the size it would be drawn without the scale factor). Outside that quarter (the other 3/4 of the screen) no click events are registered at all. Strangely, this doesn't happen with Wayfire or Sway. No pointer events are registered at all in those. The issue appears to be the way the applications register the area of the screen which accepts pointer events though it's different in Sway/Wayfire and Weston. It's not the cursor position itself though, and the window has not frozen. It's only left/right click events which are ignored. If I use the mouse wheel while hovering over various panels in dolphin, the correct panel gets scrolled down. Except, if I click on the scrollbar, the panel is scrolled down slightly. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 448141] QT_SCALE_FACTOR breaks applications on Wayfire
https://bugs.kde.org/show_bug.cgi?id=448141 Tom B changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED --- Comment #2 from Tom B --- > Does this happen with any non-KDE app that uses Qt, e.g. qBittorent? No, qBittorrent is fine, it scales as expected and the cursor can be used to interact with the buttons when it is directly over them.(In reply to Nicolas Fella from comment #1) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwayland] [Bug 448141] New: QT_SCALE_FACTOR breaks applications on Wayfire
https://bugs.kde.org/show_bug.cgi?id=448141 Bug ID: 448141 Summary: QT_SCALE_FACTOR breaks applications on Wayfire Product: frameworks-kwayland Version: 5.89.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mgraess...@kde.org Reporter: t...@r.je CC: kwin-bugs-n...@kde.org Target Milestone: --- I'm not sure if this is a KDE Frameworks bug QT bug or Wayfire bug but it only happens in Qt applications on Wayland in Wayfire (it may happen in other window managers like Sway). Run `QT_SCALE_FACTOR=2 dolphin` (or `QT_WAYLAND_FORCE_DPI=192 dolphin`) to adjust the scaling. Dolphin works, the keyboard inputs are recognized but the mouse pointer does not register clicks (or registers them in the wrong place on the screen) The console prints: QImage::pixel: coordinate (0,0) out of range which does not come up when running without setting the scale factor. Without the scale factor Dolphin (or other kde apps) works perfectly, it's only when setting QT_SCALE_FACTOR (and number <> 1) that things break. As such, it seems to be a frameworks issue, not a compositor issue. When it's set KDE applications (e.g. Dolpin, ktorrent) do not accept cursor clicks correctly. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 445081] New: Suggestions for a better scaling implementation
https://bugs.kde.org/show_bug.cgi?id=445081 Bug ID: 445081 Summary: Suggestions for a better scaling implementation Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: t...@r.je CC: plasma-b...@kde.org Target Milestone: 1.0 This is more of a suggestion or idea than a bug report, though it ties into a lot of actual bug reports. Display scaling causes a number of weird issues. For example: - A web browser does display a 4k image on a 4k screen if scaling is applied, for example it has to introduce scrollbars and show 1/4 of it at a time rather than the whole image (unless you zoom out, at which point fidelity is lost) - XWayland applications look blurry - Games (running in Xwayland) cannot be run at the native resolution - Performance issues #424398 - Window painting issues #426045 - Bugs in arbitrary applications #436681 #436615 The old approach, using DPIs works well unless you need to run different scales on different monitors, in which case you're out of luck entirely. The use-case for scaling, therefore, is when someone wants to run multiple monitors at different scales. I have a couple of suggestions on how to make scaling work better overall for everyone, and significantly reduce the number of bugs average users are likely to encounter caused by scaling. My first thought was that if more and more people are now on HiDPI displays then make 100% "bigger" and have people on lower DPI monitors choose 50%. So just make 100% scale around larger fonts. That's not ideal but we can take that a step further. Let users choose what size "100%" is and then scale around *that*. 1. Choose the font DPI based on their primary monitor (and it will work exactly as it does in X11 when setting the font DPI) 2. *Always* run their primary monitor at 100% 3. Apply scaling <> 100% to monitors other than their primary display only. This way, any of the number of issues introduced by scaling only affect users who: 1. Have more than one monitor 2. Have more than one monitor of different DPIs and apply scaling 3. Care that these bugs appear on secondary displays. Users with a single display (e.g. a laptop or average desktop user), or users with two matched displays will *never* encounter issues caused by scaling because they will be running at 100%. This approach would significantly reduce the impact of scaling issues for average users, a significant number of people would simply never encounter an issue due to scaling because they are running at 100%. Only users with mismatched displays would ever encounter a problem. My second suggestion, which is probably easier to implement and fixes many XWayland issues in one go, is render *all* XWayland windows at 100% scale factor (1:1 pixel mapping) and adjust the font DPI in the XWayland session to match the scale factor of the display. X11 applications already support scaling based on DPI so this should be relatively simple to fix, and will remove all blurry X11 applications, gaming issues, etc in one single fix. For example, if your scale factor is 200% and font DPI is 96, render XWayland windows at 100% (so everything would look "small") but then set the font DPI in the XWayland session to 192. X11 applications already support this so it should be easy to implement. -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444197] New: ffmpegthumbs uses SAR not DAR for thumbnail aspect ratio
https://bugs.kde.org/show_bug.cgi?id=444197 Bug ID: 444197 Summary: ffmpegthumbs uses SAR not DAR for thumbnail aspect ratio Product: kdemultimedia Version: 20.08 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ffmpegthumbs Assignee: unassigned-b...@kde.org Reporter: t...@r.je Target Milestone: --- SUMMARY Some videos set the DAR in the container, not in the video stream (for example, for encoders such as SVT-AV1 which don't currently support setting the DAR in the stream), for such videos the DAR is set in the container. Here's the output for ffmpeg -i file.mkv -show_streams for a sample video with this problem: [STREAM] index=0 codec_name=av1 codec_long_name=Alliance for Open Media AV1 profile=Main codec_type=video codec_tag_string=[0][0][0][0] codec_tag=0x width=720 height=576 coded_width=720 coded_height=576 closed_captions=0 has_b_frames=0 sample_aspect_ratio=64:45 display_aspect_ratio=16:9 pix_fmt=yuv420p10le level=5 color_range=tv color_space=unknown color_transfer=unknown color_primaries=unknown chroma_location=unspecified field_order=unknown refs=1 id=N/A r_frame_rate=50/1 avg_frame_rate=50/1 time_base=1/1000 start_pts=21 start_time=0.021000 duration_ts=N/A duration=N/A bit_rate=N/A max_bit_rate=N/A bits_per_raw_sample=N/A nb_frames=N/A nb_read_frames=N/A nb_read_packets=N/A DISPOSITION:default=1 DISPOSITION:dub=0 DISPOSITION:original=0 DISPOSITION:comment=0 DISPOSITION:lyrics=0 DISPOSITION:karaoke=0 DISPOSITION:forced=0 DISPOSITION:hearing_impaired=0 DISPOSITION:visual_impaired=0 DISPOSITION:clean_effects=0 DISPOSITION:attached_pic=0 DISPOSITION:timed_thumbnails=0 TAG:DURATION=00:50:41.54100 [/STREAM] There are two aspect ratios: sample_aspect_ratio=64:45 display_aspect_ratio=16:9 ffmpegthumbs seems to use SAR not DAR STEPS TO REPRODUCE 1. Find a video file and the aspect ratio in the container: ffmpeg -i "out.mkv" -c:a copy -c:v copy -aspect 21:9 "out.mkv" 2. Have ffmpegthumbs generate the thumbnail, it will be at the original aspect ratio, not 21:9. While overriding the aspect ratio like this is not ideal, any modern video player will present the correct aspect ratio when playing the video, ffmpegthumbs should do the same when taking the thumbnail. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 441043] New: Enable DPI based scaling on wayland
https://bugs.kde.org/show_bug.cgi?id=441043 Bug ID: 441043 Summary: Enable DPI based scaling on wayland Product: kwin Version: 5.22.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- SUMMARY Display scaling on Wayland is generally a poor experience: - GTK apps look blurry - XWayland applications look blurry - Games (which generally use XWayland) cannot be run at native resolution. - Fractional scaling generally looks poor This is a huge downgrade from Xorg where setting a font DPI however high correctly scales application and looks consistently sharp. Certain UI aspects e.g. 1px borders do look thinner but this is much more preferable to blurry windows and unexpected side effects like games not seeing native resolution. Steps to reproduce: 1. Set font DPI to 192 in systemsettings font panel 2. Log out and back in on a wayland session 3. No effect can be observed. Xorg works fine. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 438680] New: Feature request: Large play queue
https://bugs.kde.org/show_bug.cgi?id=438680 Bug ID: 438680 Summary: Feature request: Large play queue Product: Elisa Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: t...@r.je Target Milestone: --- I absolutely love Elisa's look and feel and I think it's the best looking music player around by a large margin but the main reason I went back to Rhythmbox is because I like a long play queue. This currently doesn't seem possible in Elisa. You can do a large playlist and have it shuffle but no queue. With Rhythmbox I can add my 25,000 song library to a queue and let it play through until it's played every song in the queue. Rhythmbox takes everything in the queue and shuffles it and it works flawlessly with huge queues. I like seeing what's coming up and I have it on 8 hours a day in the background while I'm working and it lets me know I've heard every song in the library once it finishes. With shuffle there's no guarantee of that. I don't know if this is something that Elisa wants to support, but if it does I'm moving over. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 433269] Blurry fractional scaling
https://bugs.kde.org/show_bug.cgi?id=433269 Tom B changed: What|Removed |Added CC||t...@r.je --- Comment #2 from Tom B --- The issue isn't entirely fractional scaling and half pixels. Even at 200% there are a number of issues with the scaling option. Firstly there are odd minor issues like the mouse cursor looks incredibly blocky. There is a separate option for setting the cursor resolution and zooming the pixels doesn't pick the larger image. UI elements are scaled, some icons look OK, some look blown up. Fonts in certain UI elements aren't scaled (drop down boxes on wayland). The showstopper for me though, is that I can't view 4k videos or images on my 4k screen. If I view a 3840x2160 image in Firefox with 200% display scaling I have a choice: See 1/4 of it cropped with scrollbars or view it scaled to 1080p. I cannot see the whole image untouched. If I view a 4k video it gets scaled down to 1080p if I have 200% scaling. The scaling option isn't much better than just running my screen at a 1080p resolution. Text and some icons are better but nothing else. It might be possible for individual applications to support scaling properly but at the moment Firefox, VLC nor mpv do this, and enabling scaling shouldn't really limit the user's choice of applications. I have a choice of either reading text on the screen at a legible size or being able to view a 4k video on a 4k screen. This forced choice seems to be by design. The whole screen scaling approach seems like the wrong way to go to me as it introduces its own set of problems and limitations on the user. What's frustrating is that in Xorg, setting DPI works near perfectly. The UI is scaled, icons are scaled, context menus are scaled and I can view images and videos without them being scaled unless I want them to. The only issue is that some windows start fairly small. But at least they can be resized easily. Even when you reintroduce this option on Wayland, it wasn't ever working properly there. Fonts are scaled but padding around text, borders and other UI elements are completely ignored. Would it be possible to copy over the Xorg code that scales the UI and Icons based on DPI from Xorg to Wayland? For example, try setting font DPI to 192 and launching Rhythmbox or Dolphin. On Xorg looks great, on wayland everything is crashed together because the paddings around text and icons are not increased relative to the text size. So at the moment, as much as I'd like to use Wayland I'm stuck on Xorg because neither DPI or scaling work without issues. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 433115] Global Scaling Options Seems to "lower" resolution unlike old "force font DPI"; consider re-adding it as an option
https://bugs.kde.org/show_bug.cgi?id=433115 --- Comment #16 from Tom B --- Sorry for the double post but here's a way to test it and demonstrate the issue 1. Take a screenshot using spectacle or another tool at native resolution and save it lossless (png) 2. Turn on display scaling 3. Open the screenshot in mpv: mpv screenshot-001.png --pause Double click to full screen it and you can see that it's not as sharp as the original. You can also press `i` to bring up the stats and confirm that "Window scale" is not 1.0. This could probably be fixed by MPV (and every other application affected...) but the previous DPI approach worked fine without needing to fix everything that uses images. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 433115] Global Scaling Options Seems to "lower" resolution unlike old "force font DPI"; consider re-adding it as an option
https://bugs.kde.org/show_bug.cgi?id=433115 Tom B changed: What|Removed |Added CC||t...@r.je --- Comment #15 from Tom B --- I came here to make this exact same bug. The problem is when dealing with applications that actually use pixel based images I lose definition. If I set my scale to 175% on a 4k monitor, then watch a 4k movie in MPV, it gets scaled down and I lose definition. If I open a 4k image in a web browser or image editing tool the image is scaled down to the "Global Scale" and I cannot see the full image. Some applications (GIMP) for example, have very blurry fonts. The old DPI approach worked very well. Using the "Scale" option, other that a few desktop UI elements that understand it, I may as well run my screen at 1080p. The font DPI approach worked a lot better because one pixel was always one pixel. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 433393] New: kdenlive crashes at startup (segfault) on plasma wayland 5.21
https://bugs.kde.org/show_bug.cgi?id=433393 Bug ID: 433393 Summary: kdenlive crashes at startup (segfault) on plasma wayland 5.21 Product: kdenlive Version: 20.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Installation Assignee: vpi...@kde.org Reporter: t...@r.je Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Open Kdenlive on Plasma 5.21 (Wayland) OBSERVED RESULT kdenlive mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltsox.so (libsox.so.3: cannot open shared object file: No such file or directory) mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltrtaudio.so (librtaudio.so.6: cannot open shared object file: No such file or directory) mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltsdl.so (libSDL_image-1.2.so.0: cannot open shared object file: No such file or directory) mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltopencv.so (libopencv_tracking.so.4.5: cannot open shared object file: No such file or directory) mlt_repository_init: failed to dlopen /usr/lib/mlt/libmltopengl.so (libmovit.so.8: cannot open shared object file: No such file or directory) Invalid metadata for "avcolour_space" Failed to parse "avcolour_space" Invalid metadata for "avcolor_space" Failed to parse "avcolor_space" Invalid metadata for "avdeinterlace" Failed to parse "avdeinterlace" Invalid metadata for "swscale" Failed to parse "swscale" Invalid metadata for "swresample" Failed to parse "swresample" Invalid metadata for "audiochannels" Failed to parse "audiochannels" Invalid metadata for "audioconvert" Failed to parse "audioconvert" Invalid metadata for "data_feed" Failed to parse "data_feed" Invalid metadata for "imageconvert" Failed to parse "imageconvert" Invalid title/identifier for "crop_detect" Failed to parse "crop_detect" Invalid metadata for "jack" Failed to parse "jack" Invalid metadata for "telecide" Failed to parse "telecide" Invalid metadata for "deinterlace" Failed to parse "deinterlace" Unknown asset "avfilter.acompressor" Unknown asset "avfilter.aecho" Unknown asset "avfilter.agate" Unknown asset "avfilter.atadenoise" Unknown asset "avfilter.bwdif" Unknown asset "avfilter.deblock" Unknown asset "avfilter.dedot" Unknown asset "avfilter.deflate" Unknown asset "avfilter.derain" Unknown asset "avfilter.doubleweave" Unknown asset "avfilter.field" Unknown asset "avfilter.framestep" Unknown asset "avfilter.fspp" Unknown asset "avfilter.graphmonitor" Unknown asset "avfilter.hqdn3d" Unknown asset "avfilter.inflate" Unknown asset "avfilter.lagfun" Unknown asset "avfilter.random" Unknown asset "avfilter.removegrain" Unknown asset "avfilter.separatefields" Unknown asset "avfilter.shuffleplanes" Unknown asset "avfilter.sr" Unknown asset "avfilter.tmix" Unknown asset "avfilter.w3fdif" Unknown asset "avfilter.weave" Unknown asset "avfilter.yadif" Unknown asset "frei0r.baltan" Unknown asset "frei0r.bgsubtract0r" Unknown asset "frei0r.bigsh0t_eq_mask" Unknown asset "frei0r.bigsh0t_eq_to_rect" Unknown asset "frei0r.bigsh0t_hemi_to_eq" Unknown asset "frei0r.bigsh0t_rect_to_eq" Unknown asset "frei0r.bigsh0t_stabilize_360" Unknown asset "frei0r.bigsh0t_transform_360" Unknown asset "frei0r.delay0r" Unknown asset "frei0r.delaygrab" Unknown asset "frei0r.facebl0r" Unknown asset "frei0r.facedetect" Unknown asset "frei0r.lightgraffiti" Unknown asset "frei0r.lightgraffiti" Unknown asset "movit.blur" Unknown asset "movit.sharpen" Unknown asset "movit.diffusion" Unknown asset "movit.flip" Unknown asset "movit.glow" Unknown asset "movit.lift_gamma_gain" Unknown asset "movit.mirror" Unknown asset "movit.opacity" Unknown asset "movit.rect" Unknown asset "movit.saturation" Unknown asset "movit.unsharp_mask" Unknown asset "movit.vignette" Unknown asset "movit.white_balance" Unknown asset "region" Unknown asset "sox" Unknown asset "sox" Unknown asset "sox" Unknown asset "sox" Unknown asset "sox" Unknown asset "sox" Unknown asset "sox" Unknown asset "timewarp" Unknown asset "opencv.tracker" Unknown asset "opencv.tracker" QQmlEngine::setContextForObject(): Object already has a QQmlContext QQmlEngine::setContextForObject(): Object already has a QQmlContext QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x56437186d420 QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x7f5894575980 QOpenGLFunctions created with non-current context QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x564370fab2b0 Segmentation fault (core dumped) KDE Plasma Version: 5.21 This didn't happen in 5.20. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 428783] New: [wayland] Kdenlive freezes when clicking "New"
https://bugs.kde.org/show_bug.cgi?id=428783
Bug ID: 428783
Summary: [wayland] Kdenlive freezes when clicking "New"
Product: kdenlive
Version: 20.08.3
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: User Interface
Assignee: j...@kdenlive.org
Reporter: t...@r.je
Target Milestone: ---
SUMMARY
Whenever I click "new" in kdenlive it freezes under wayland. This happens 100%
of the time.
STEPS TO REPRODUCE
1. Open kdenlive on wayland
2. Click "New" in the top left
3. it freezes (not responding)
OBSERVED RESULT
Freeze
EXPECTED RESULT
Start a new project
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.9.4-arch1-1 / KDE 5.20
(available in About System)
KDE Plasma Version: 5.20
KDE Frameworks Version: 5.75.0-1
Qt Version: 5.15.1
ADDITIONAL INFORMATION
There's nothing obviously wrong if I run it via konsole, no output shows the
crash:
qrc:/qml/assetList.qml:314:13: QML Menu: Accessible must be attached to an Item
LC_NUMERIC reset to C
Cyclic dependency detected between
"file:///usr/lib/qt/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
and
"file:///usr/lib/qt/qml/org/kde/kirigami.2/styles/org.kde.desktop.plasma/Units.qml"
QQmlEngine::setContextForObject(): Object already has a QQmlContext
qrc:/qml/timeline.qml:1459:5: QML Connections: Implicitly defined onFoo
properties in Connections are deprecated. Use this syntax instead: function
onFoo() { ... }
Loading bin playlist...
//
Trying to construct 5 tracks.
SUSPICIOUS: we weren't expecting a producer when parsing the timeline
=== REQUESTING TRACK INSERTION AT: -1
=== REQUESTING TRACK INSERTION AT: -1
=== REQUESTING TRACK INSERTION AT: -1
=== REQUESTING TRACK INSERTION AT: -1
LC_NUMERIC reset to C
qml: GOT SCALE: 0.96 , BASE: 16 - SNAPPING: 16
qrc:/qml/timeline.qml:1070:25: QML QQuickItem: Binding loop detected for
property "width"
qrc:/qml/timeline.qml:1051:47: QML ScrollBar: Binding loop detected for
property "visible"
INITIAL REPORT; ENABLE EXT PROCY: false
This does not happen if I run it under xwayland using:
QT_QPA_PLATFORM=xcb kdenlive
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 422141] New: kwin_wayland nested does not allow scale < 1
https://bugs.kde.org/show_bug.cgi?id=422141 Bug ID: 422141 Summary: kwin_wayland nested does not allow scale < 1 Product: kwin Version: 5.17.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- SUMMARY When running kwin_wayland nested, it does not support a command line argument --scale of < 1 STEPS TO REPRODUCE 1. Follow the instructions here: https://community.kde.org/KWin/Wayland#Starting_a_nested_KWin for a nested wayland instance 2. Set the command line switch --scale to a value less than 1 e.g. 0.5 OBSERVED RESULT FATAL ERROR incorrect value for scale EXPECTED RESULT Should allow a scale of < 1. E.g. 0.5 (50%) When using an existing session and using the display configuration it's possible to set a scale of 0.5 so this seems to be a redundant check at startup: The error message comes from main_wayland.cpp:612 https://github.com/KDE/kwin/blob/master/main_wayland.cpp#L612 Use case: I have an older game that doesn't support MSAA and was trying to render it at a higher resolution and scale it down, a bit like how DSR works in the windows nvidia driver. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 --- Comment #7 from Tom B --- Is there anything else I can provide to help this become resolved? This is a very annoying issue that happens several times a day and on wayland halts the entire session. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 --- Comment #6 from Tom B --- Backtrace courtesy of David Strobach on the kwin tiling github issue: https://github.com/kwin-scripts/kwin-tiling/issues/192 #7 0x7f00b288297e in QV4::MemoryManager::collectRoots(QV4::MarkStack*) () at /usr/lib/libQt5Qml.so.5 #8 0x7f00b2882b7e in QV4::MemoryManager::mark() () at /usr/lib/libQt5Qml.so.5 #9 0x7f00b2884672 in () at /usr/lib/libQt5Qml.so.5 #10 0x7f00b2886aaa in QV4::MemoryManager::allocData(unsigned long) () at /usr/lib/libQt5Qml.so.5 #11 0x7f00b298101a in QV4::QObjectMethod::create(QV4::ExecutionContext*, QObject*, int) () at /usr/lib/libQt5Qml.so.5 #12 0x7f00b2983b87 in QV4::QObjectWrapper::getQmlProperty(QQmlContextData*, QV4::String*, QV4::QObjectWrapper::RevisionMode, bool*, bool) const () at /usr/lib/libQt5Qml.so.5 #13 0x7f00b2983d4f in QV4::QObjectWrapper::virtualGet(QV4::Managed const*, QV4::PropertyKey, QV4::Value const*, bool*) () at /usr/lib/libQt5Qml.so.5 #14 0x7f00b29b9a1d in QV4::Runtime::CallProperty::call(QV4::ExecutionEngine*, QV4::Value const&, int, QV4::Value*, int) () at /usr/lib/libQt5Qml.so.5 #15 0x7f007ebe90d2 in () #16 0x in () -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 417669] New: Wayland cursor position sent incorrectly to Xwayland firefox/thunderbird
https://bugs.kde.org/show_bug.cgi?id=417669 Bug ID: 417669 Summary: Wayland cursor position sent incorrectly to Xwayland firefox/thunderbird Product: Breeze Version: 5.18.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: gtk theme Assignee: uhh...@gmail.com Reporter: t...@r.je Target Milestone: --- Created attachment 126040 --> https://bugs.kde.org/attachment.cgi?id=126040=edit screenshot of issue. Red dot is drawn at cursor position. SUMMARY This would be very easy to demonstrate with a screen recorder, unfortunately I cannot find anything that can record the screen on kde wayland. STEPS TO REPRODUCE 1. Open firefox or thunderbird in plasma wayland 2. Try to click on something 3. Both firefox and thunderbird think the mouse cursor is about -10px x -10px out of position Demo screnshot attached. I have created a test page here: https://codepen.io/Tom__B/pen/VwLeNyJ so you can see what it supposed to happen. It draws a red dot at the cursor position. As you can see in my screenshot, Firefox thinks the cursor is in a different place than it is. I had thought this affected all GTK apps but testing in GIMP, the pencil draws at exactly the correct position. Additional information: I am running a 120 font DPI which scales the UI. Perhaps it's something to do with this scaling which causes the miscalculation. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.18.0 (available in About System) KDE Plasma Version: 5.18.0 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 416244] Kwin wayland incorrect window decorations when GTK app changes the default titlebar buttons
https://bugs.kde.org/show_bug.cgi?id=416244 Tom B changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #5 from Tom B --- This has been fixed in 5.18. There is a different Breeze GTK bug but I'll report that separately. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 --- Comment #5 from Tom B --- I've been trying to replicate this in KDE Neon in Virtualbox so I could provide a .vdi where you can see the issue yourself. However, I have so far been unable to reproduce the issue. I have noticed one difference. In Arch, Sublime Text is drawn with window decorations. In Neon Sublime text is given no decorations. I have no idea if this is related but I mention it because the reproducible crash I mentioned before happens when using the window decorations to drag the sublime text window around the screen. I have since switched to X.org on my arch box and the crash happens there too. It's not as severe as it only crashes the compositor not the whole session but it does happen, albeit less frequently. -- You are receiving this mail because: You are watching all bug changes.
[krfb] [Bug 413476] Wayland/Pipewire segfault on connection
https://bugs.kde.org/show_bug.cgi?id=413476 --- Comment #2 from Tom B --- what is the best way to get a backtrace? Trying it again a few months later with the most recent versions of each package, I am still getting the same problem. dmesg shows the following: [315423.305190] krfb[2750682]: segfault at 0 ip 7f9043935858 sp 7ffe0d6942c8 error 4 in libvncserver.so.0.9.12[7f904391+31000] [315423.305204] Code: 57 08 49 8b ba 98 02 00 00 4d 63 52 10 41 0f af d2 41 80 fb 10 74 5b 41 80 fb 20 0f 85 a1 00 00 00 8d 14 b2 48 63 d2 48 01 d7 <8b> 17 84 c0 0f 85 4e 01 00 00 45 85 c0 0f 8e e0 00 00 00 8d 41 ff Though that alone probably isn't very useful. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 416244] Kwin wayland incorrect window decorations when GTK app changes the default titlebar buttons
https://bugs.kde.org/show_bug.cgi?id=416244 --- Comment #4 from Tom B --- > You're on X11, right? "Fixed" in 5.18. I'm on Wayland and this only happens on Wayland. > Firefox does its own headerbar thing so I recommend to report this bug to > Firefox developers, but just to be sure, could you please attach your > .config/gtk-3.0/settings.ini to this bug report? I reported it to firefox: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=wayland+firefox+window+decorations And to Lutris: https://github.com/lutris/lutris/issues/2575 who said "not our bug" .config/gtk-3.0/settings.ini [Settings] gtk-application-prefer-dark-theme=true gtk-button-images=0 gtk-cursor-theme-name=breeze_cursors gtk-fallback-icon-theme=Adwaita gtk-font-name=Noto Sans Regular 10 gtk-icon-theme-name=breeze gtk-menu-images=0 gtk-primary-button-warps-slider=0 gtk-theme-name=Breeze-Dark gtk-toolbar-style=GTK_TOOLBAR_ICONS -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416244] Kwin wayland incorrect window decorations when GTK app changes the default titlebar buttons
https://bugs.kde.org/show_bug.cgi?id=416244 --- Comment #1 from Tom B --- Created attachment 125118 --> https://bugs.kde.org/attachment.cgi?id=125118=edit screenshot of problem in firefox -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416244] New: Kwin wayland incorrect window decorations when GTK app changes the default titlebar buttons
https://bugs.kde.org/show_bug.cgi?id=416244 Bug ID: 416244 Summary: Kwin wayland incorrect window decorations when GTK app changes the default titlebar buttons Product: kwin Version: 5.17.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- Created attachment 125117 --> https://bugs.kde.org/attachment.cgi?id=125117=edit screenshot of problem SUMMARY Under wayland, some windows are given the incorrect window decorations. Two distinct issues occur. 1. The minimize and maximize buttons are not shown 2. A gap is drawn around the window when it shouldn't be. So far I have found two windows with this problem. STEPS TO REPRODUCE 1. Open Lutris in KDE wayland Or 1. Start firefox with wayland enabled: MOZ_ENABLE_WAYLAND=1 firefox 2. Go to menu > customize 3. Untick "Title Bar" at the bottom OBSERVED RESULT 1. No minimize or maximize button 2. Additional gap drawn around window EXPECTED RESULT 1. Correct titlebar buttons appear 2. No gap drawn around the window SOFTWARE/OS VERSIONS KDE Plasma Version: 5.17.5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872
--- Comment #2 from Tom B ---
It seems to be something to do with how often the script triggers signals.
If I rate limit the events (using the system clock to keep track of how often
they are fired) to once per frame it works fine. See my workaround for the
script here:
https://github.com/TRPB/kwin-tiling/commit/f69bdfc68989aeb6d15124a1106154c050067b4b
I have still had this crash randomly but not in a reproducible way and far less
frequently.
The issue is connecting events:
e.g.
client.clientStepUserMovedResized.connect(function() {
When this does something to the client (or other windows) too frequently, more
than once per frame as best as I can work out. Rate limit of once per 1ms =
crash, 25ms = no crash. 1 frame being 16ms. i. This is likely a symptom not the
underlying cause.
While I worked out what caused it in this instance, other events seem to cause
the same problem when triggered too frequently.
It would be better if:
A) The 1 event per frame rate limit was imposed by the scripting engine
or
B) It allows more than 1 event/frame but doesn't segfault
I will point out that this is likely a workaround rather than a fix. Whatever
causes the segfault is probably because two things happen out of the intended
sequence. By rate limiting the events, it significantly reduces the chances of
this happening. That said, after applying the rate limit to the script I could
never trigger the crash when dragging windows.
I'll try rate limiting every event registered by the script to 25ms and see if
I get any other random crashes.
Rate limiting the calls to events registered in the `.connect` function could
be a very simple fix in the scripting engine if it works.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 Tom B changed: What|Removed |Added Component|wayland-generic |scripting -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 --- Comment #1 from Tom B --- I've worked out this is scripting engine related. It only appears to happen when the kwin tiling extension is enabled. I've not yet managed to track down exactly what causes the segfault but I now have reproducible steps to cause the segfault: 1. Enable the kwin tiling extension https://github.com/kwin-scripts/kwin-tiling 2. Apply the wayland fix: https://github.com/kwin-scripts/kwin-tiling/issues/117#issuecomment-541903299 3. Open two sublime_text windows 4. Drag one of the windows around the screen for a while For me this causes a segfault within several seconds. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415872] New: kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000]
https://bugs.kde.org/show_bug.cgi?id=415872 Bug ID: 415872 Summary: kwin_wayland random segfault libQt5Qml.so.5.14.0[7fe09a171000+307000] Product: kwin Version: 5.17.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- SUMMARY kwin_wayland crashes intermittently and sends me back to the SDDM login screen. Generally around every 6-8 hours of use, sometimes sooner. It seems to only be a matter of time. Usually when manipulating windows. Sometimes when switching virtual desktops. Unfortunately I cannot seem to find something that triggers it consistently. STEPS TO REPRODUCE 1. Use kde on wayland 2. Interact with the desktop OBSERVED RESULT Jan 04 13:30:38 desktop audit[13920]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=9 pid=13920 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 13:30:41 desktop systemd-coredump[14565]: Process 13920 (kwin_wayland) of user 1000 dumped core. Jan 04 13:30:52 desktop audit[14916]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=10 pid=14916 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 13:30:52 desktop kernel: kwin_wayland[14916]: segfault at 28 ip 7fe09a17760c sp 7ffc135bd040 error 4 in libQt5Qml.so.5.14.0[7fe09a171000+307000] Jan 04 13:30:52 desktop kernel: audit: type=1701 audit(1578144652.676:500): auid=1000 uid=1000 gid=1000 ses=10 pid=14916 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 13:30:55 desktop systemd-coredump[15607]: Process 14916 (kwin_wayland) of user 1000 dumped core. Jan 04 13:31:26 desktop audit[15949]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=11 pid=15949 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 13:31:26 desktop kernel: kwin_wayland[15949]: segfault at 28 ip 7fdb376d760c sp 7fffae5e2430 error 4 in libQt5Qml.so.5.14.0[7fdb376d1000+307000] Jan 04 13:31:26 desktop kernel: audit: type=1701 audit(1578144686.282:568): auid=1000 uid=1000 gid=1000 ses=11 pid=15949 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 13:31:29 desktop systemd-coredump[16639]: Process 15949 (kwin_wayland) of user 1000 dumped core. Jan 04 14:29:53 desktop audit[23599]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=16 pid=23599 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 14:29:53 desktop kernel: kwin_wayland[23599]: segfault at 28 ip 7f95bfb4e60c sp 7fff63a4d910 error 4 in libQt5Qml.so.5.14.0[7f95bfb48000+307000] Jan 04 14:29:53 desktop kernel: audit: type=1701 audit(1578148193.434:849): auid=1000 uid=1000 gid=1000 ses=16 pid=23599 comm="kwin_wayland" exe="/usr/bin/kwin_wayland" sig=11 res=1 Jan 04 14:29:55 desktop systemd-coredump[78101]: Process 23599 (kwin_wayland) of user 1000 dumped core. This is the segfault I get. It seems random but dragging/dropping Xorg windows seems to be the primary cause, the last culprit was firefox. EXPECTED RESULT No crash SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux / Plasma 5.17.4 (available in About System) Let me know if there's anything else I can do to debug this. This might be related to #401350 but that's a different error. -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 415246] New: ktorrent stalls after time until reboot
https://bugs.kde.org/show_bug.cgi?id=415246 Bug ID: 415246 Summary: ktorrent stalls after time until reboot Product: ktorrent Version: 5.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: joris.guis...@gmail.com Reporter: t...@r.je Target Milestone: --- SUMMARY When using ktorrent, after some time (days) connection speeds drop and it seems unable to connect to peers/seeds. Rebooting the PC fixes it. I just had one torrent that had been stalled for 12 hours though it was showing several seeders. Occasionally I'd get 20kbps for a short period (30 seconds or so) I rebooted and immediately saw 1.8mb/s downloads This seems to be a fairly common issue: https://forums.linuxmint.com/viewtopic.php?t=29631 The author there says: "I also have to restart it every other day, it seems to 'clog' up (don't know how to explain it) and a lot of the torrents start 'stalling' - a restart fixes it" Here's another mention of it: https://forum.kde.org/viewtopic.php?t=105632 and a similar bug: https://bugs.kde.org/show_bug.cgi?id=275889 Which is also exactly what I'm seeing 10 years later. Restarting ktorrent doesn't help, only a reboot. STEPS TO REPRODUCE 1. Start a torrent 2. Leave it going for several days OBSERVED RESULT The torrent stops downloading until reboot. EXPECTED RESULT The torrent should maintain speed/connections regardless of how many hours it has been running. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.4.3, ktorrent 5.1, plasma 5.17 ADDITIONAL INFORMATION It's as if there is some kind of system limit being hit which prevents ktorrent creating any more connections. I've tried increasing the connection limit in ktorrent and it doesn't seem to help. Whatever it's doing behind the scenes, it doesn't seem to free the resources when closed, only when rebooted. Whether it's ports, mutexes, semaphore message queue limits, or some other system wide restriction, whatever it is, it uses it up and doesn't ever free the resources until the system is rebooted. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 413663] New: [Wayland] Screens often reversed position after suspend or boot
https://bugs.kde.org/show_bug.cgi?id=413663 Bug ID: 413663 Summary: [Wayland] Screens often reversed position after suspend or boot Product: KScreen Version: 5.17.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: kscreen-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- Created attachment 123616 --> https://bugs.kde.org/attachment.cgi?id=123616=edit screenshot of display configuration system settings SUMMARY I have two monitors, both the same make/model which may be why detection is intermittent, and the positioning seems completely arbitrary. In kscreen I have set DP-3 to be on the left and DP-2 to be on the right with DP-2 as my primary display (though this doesn't seem to be an option in Wayland). Intermittently, when booting or when resuming from suspend the order is reversed: DP-3 is positioned on the right and DP-2 is positioned on the left. I have to then manually open kscreen and reposition them. It does not happen every time which makes me think it might be to do with which one turns on/is detected first. I created a new account in case it was old kscreen settings from my old X login and it happens even if I have never logged into X on this account. It does not happen in Xorg, only Wayland. STEPS TO REPRODUCE 1. Configure the screens to be positioned left/right 2. Suspend/resume or reboot OBSERVED RESULT The screens frequently (~50% of the time) get switched. EXPECTED RESULT The configuration should be maintained through reboots and suspend/resume cycles. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 ADDITIONAL INFORMATION Hardware: GPU: Radeon VII (AMDGPU driver) Monitors: 2x Acer CB241HQ (3840x2160) both connected via DisplayPort. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343592] Desktop grid effect does not work with some custom shortcuts (Default: ctrl+F8)
https://bugs.kde.org/show_bug.cgi?id=343592 --- Comment #19 from Tom B --- This works fine in Wayland with one caveat: You can't assign keys that are already assigned. For example, assigning Meta+1 doesn't work until you first manually unassign the default behaviour "Activate Task Manager Entry 1". However, this does fix the problem: Meta+Shift+1, Meta+Shift+2, etc can now be assigned and used as intended. As long as you're on Wayland, X11 still seems broken. -- You are receiving this mail because: You are watching all bug changes.
[krfb] [Bug 413476] New: Wayland/Pipewire segfault on connection
https://bugs.kde.org/show_bug.cgi?id=413476 Bug ID: 413476 Summary: Wayland/Pipewire segfault on connection Product: krfb Version: 19.08.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: grundleb...@googlemail.com Reporter: t...@r.je Target Milestone: --- SUMMARY When a connection is received, Krfb crashes when using wayland/pw plugin. STEPS TO REPRODUCE 1. Run Krfb on Wayland 2. Try to connect with KRDC OBSERVED RESULT Krfb accepts the login, asks for authorisation and once authorisation is granted, Krfb crashes. Log as follows: $ krfb found plugin at "/usr/lib/qt/plugins/krfb/krfb_framebuffer_xcb.so" Loaded plugin with name "xcb" found plugin at "/usr/lib/qt/plugins/krfb/krfb_framebuffer_pw.so" Loaded plugin with name "pw" found plugin at "/usr/lib/qt/plugins/krfb/krfb_framebuffer_qt.so" Loaded plugin with name "qt" Using FrameBuffer: "pw" Initializing D-Bus connectivity with XDG Desktop Portal DBus session created: "/org/freedesktop/portal/desktop/request/1_49/krfb2951929398" Starting server. Listen port: 5900 Listen Address: "0.0.0.0" Password enabled: true Couldn't select sources for the screen-casting session about to start authentication found plugin at "/usr/lib/qt/plugins/krfb/krfb_events_x11.so" Loaded plugin with name "x11" found plugin at "/usr/lib/qt/plugins/krfb/krfb_events_xdp.so" Loaded plugin with name "xdp" Segmentation fault (core dumped) EXPECTED RESULT Linux/KDE Plasma: Arch / 5.17.1 (available in About System) KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: Qt5 5.13.1 Krfb version: 19.8.2 (not in the list above) ADDITIONAL INFORMATION It is very difficult to find documentation on what is required to get this working on wayland so I may be missing something. On the host, I have installed pipewire and started the service. The log says says "Couldn't select sources for the screen-casting session" which suggests I might be missing something. I am also running 2x 4k displays with a desktop resolution of 7680x2160 which may be a higher resolution that something in the stack supports. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 413396] New: kwin_wayland crash when displays turned back on
https://bugs.kde.org/show_bug.cgi?id=413396 Bug ID: 413396 Summary: kwin_wayland crash when displays turned back on Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-wayland Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- Created attachment 123458 --> https://bugs.kde.org/attachment.cgi?id=123458=edit journal from previous boot SUMMARY The system freezes when displays are turned off then back on. STEPS TO REPRODUCE 1. Allow KDE to turn off the screen using power management ( Energy Saving > enable "Screen energy saving" ) 2. Wait for the screen to turn off 3. Press a key to bring the screens back on OBSERVED RESULT The screens turn back on but I see the output of systemd with "reached graphical target". The system is completely frozen and I can't even switch TTY. EXPECTED RESULT The screens should come back on and display the desktop. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 ADDITIONAL INFORMATION I'm using two monitors with a radeon VII and the AMDGPU driver. It works as expected in Xorg, it's only kwin_wayland that's affected. I've attached my journal from the previous boot, it looks like the crash may actually happen when the screens turn off, not when they come back on. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 412684] [Wayland] kwin_wayland[3904]: segfault at 10 ip 00007f35691b6c30 sp 00007ffcf514ce98 error 4 in libKF5WaylandServer.so.5.63.0[7f3569191000+60000]
https://bugs.kde.org/show_bug.cgi?id=412684 --- Comment #17 from Tom B --- Scratch that, although most Arch packages are 5.17.1, it looks like kwin 5.17.1 hasn't been released yet. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 412684] [Wayland] kwin_wayland[3904]: segfault at 10 ip 00007f35691b6c30 sp 00007ffcf514ce98 error 4 in libKF5WaylandServer.so.5.63.0[7f3569191000+60000]
https://bugs.kde.org/show_bug.cgi?id=412684 --- Comment #16 from Tom B --- did this patch make it into 5.17.1 or does it need to be manually applied? I just upgraded and still have the same issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 412684] [Wayland] kwin_wayland[3904]: segfault at 10 ip 00007f35691b6c30 sp 00007ffcf514ce98 error 4 in libKF5WaylandServer.so.5.63.0[7f3569191000+60000]
https://bugs.kde.org/show_bug.cgi?id=412684 Tom B changed: What|Removed |Added CC||t...@r.je --- Comment #10 from Tom B --- Same issue on my 2015 macbook pro. segfault at 10 ip / error 4 in libKF5WaylandServer.so.5.63.0 device: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X] (rev 83) and I'm using the AMDGPU driver. It works on my other laptop (also using AMDGPU) and on my desktop running a Radeon VII, so I don't believe it's a driver issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 409294] New: Several 30bit colour depth (10bit/channel) issues
https://bugs.kde.org/show_bug.cgi?id=409294 Bug ID: 409294 Summary: Several 30bit colour depth (10bit/channel) issues Product: plasmashell Version: 5.16.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: t...@r.je CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 121215 --> https://bugs.kde.org/attachment.cgi?id=121215=edit screenshot of google chrome This is related to: https://bugs.kde.org/show_bug.cgi?id=406302 When using 30bit colour and a supported device, there are three issues: 1. The OpenGL Compositor does not work, it crashes immediately if OpenGL 3.1 or OpenGL 2.0 are selected. XRender works fine, but obviously OpenGL would be better. 2. GTK applications colours are completely messed up. Google Chrome is a good example, all the colours are garbled as the previous bug I linked to but for the entire application. 3. A separate issue, but there currently seems no way to set 10bit colour on Wayland, I was going to test as the problems may not exist there. Xorg conf: Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" DefaultDepth 30 SubSection "Display" Viewport 0 0 Depth 30 EndSubSection EndSection Hardware: Intel i7 8560u with a DisplayPort monitor and the i915 driver. output of qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation: KWin Support Information: The following information should be used when requesting support on e.g. https://forum.kde.org. It provides information about the currently running instance, which options are used, what OpenGL driver and which effects are running. Please post the information provided underneath this introductory text to a paste bin service like https://paste.kde.org instead of pasting into support threads. == Version === KWin version: 5.16.1 Qt Version: 5.12.4 Qt compile version: 5.12.4 XCB compile version: 1.13.1 Operation Mode: X11 only Build Options = KWIN_BUILD_DECORATIONS: yes KWIN_BUILD_TABBOX: yes KWIN_BUILD_ACTIVITIES: yes HAVE_DRM: yes HAVE_GBM: yes HAVE_EGL_STREAMS: yes HAVE_X11_XCB: yes HAVE_EPOXY_GLX: yes HAVE_WAYLAND_EGL: yes X11 === Vendor: The X.Org Foundation Vendor Release: 12005000 Protocol Version/Revision: 11/0 SHAPE: yes; Version: 0x11 RANDR: yes; Version: 0x14 DAMAGE: yes; Version: 0x11 Composite: yes; Version: 0x4 RENDER: yes; Version: 0xb XFIXES: yes; Version: 0x50 SYNC: yes; Version: 0x31 GLX: yes; Version: 0x0 Decoration == Plugin: org.kde.breeze Theme: Blur: 0 onAllDesktopsAvailable: false alphaChannelSupported: true closeOnDoubleClickOnMenu: false decorationButtonsLeft: 0, 2 decorationButtonsRight: 6, 3, 4, 5 borderSize: 3 gridUnit: 30 font: Noto Sans,10,-1,5,50,0,0,0,0,0,Regular smallSpacing: 7 largeSpacing: 30 Platform == Name: KWin::X11StandalonePlatform Options === focusPolicy: 0 nextFocusPrefersMouse: false clickRaise: true autoRaise: false autoRaiseInterval: 0 delayFocusInterval: 0 shadeHover: false shadeHoverInterval: 250 separateScreenFocus: false placement: 4 focusPolicyIsReasonable: true borderSnapZone: 10 windowSnapZone: 10 centerSnapZone: 0 snapOnlyWhenOverlapping: false rollOverDesktops: true focusStealingPreventionLevel: 1 legacyFullscreenSupport: false operationTitlebarDblClick: 5000 operationMaxButtonLeftClick: 5000 operationMaxButtonMiddleClick: 5015 operationMaxButtonRightClick: 5014 commandActiveTitlebar1: 0 commandActiveTitlebar2: 30 commandActiveTitlebar3: 2 commandInactiveTitlebar1: 4 commandInactiveTitlebar2: 30 commandInactiveTitlebar3: 2 commandWindow1: 7 commandWindow2: 8 commandWindow3: 8 commandWindowWheel: 31 commandAll1: 10 commandAll2: 3 commandAll3: 14 keyCmdAllModKey: 16777251 showGeometryTip: false condensedTitle: false electricBorderMaximize: true electricBorderTiling: true electricBorderCornerRatio: 0.25 borderlessMaximizedWindows: false killPingTimeout: 5000 hideUtilityWindowsForInactive: true inactiveTabsSkipTaskbar: false autogroupSimilarWindows: false autogroupInForeground: true compositingMode: 2 useCompositing: true compositingInitialized: true hiddenPreviews: 1 glSmoothScale: 2 xrenderSmoothScale: false maxFpsInterval: 1666 refreshRate: 0 vBlankTime: 600 glStrictBinding: true glStrictBindingFollowsDriver: true glCoreProfile: false glPreferBufferSwap: 97 glPlatformInterface: 1 windowsBlockCompositing: true Screen Edges desktopSwitching: false desktopSwitchingMovingClients: false cursorPushBackDistance: 1x1 timeThreshold: 150 reActivateThreshold: 350 actionTopLeft: 0 actionTop: 0 actionTopRight: 0 actionRight: 0 actionBottomRight: 0 actionBottom: 0 actionBottomLeft: 0 actionLeft: 0 Screens === Multi-Head: no
[kwayland-integration] [Bug 407399] New: Wayland freezes system org_kde_powerde dumped core when screen turned off/on
https://bugs.kde.org/show_bug.cgi?id=407399 Bug ID: 407399 Summary: Wayland freezes system org_kde_powerde dumped core when screen turned off/on Product: kwayland-integration Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: t...@r.je Target Milestone: --- Created attachment 119958 --> https://bugs.kde.org/attachment.cgi?id=119958=edit journalctl output until crash SUMMARY When using wayland, the power saving feature comes into effect and turns off the screen. Mostly (not every single time), when trying to turn the screen back on, the whole session crashes and the system appears to crash entirely. I cannot switch TTY and have to do a hard reset. STEPS TO REPRODUCE 1. Let power saving turn off screen 2. Move mouse or press keyboard to turn it back on OBSERVED RESULT System freezes entirely EXPECTED RESULT Log in screen is displayed SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.15.5 Qt Version: ADDITIONAL INFORMATION See attached output from journalctl --boot=-1 Hardware: Radeon VII with AMDGPU driver AMD Threadripper 1950x -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401308] New: Kwin does not expose wayland clients to scripts
https://bugs.kde.org/show_bug.cgi?id=401308 Bug ID: 401308 Summary: Kwin does not expose wayland clients to scripts Product: kwin Version: 5.14.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- Kwin's scripting engine is not very useful under Wayland because client windows are not available to scripts. This breaks scripts like the tiling extension entirely as it cannot move/resize wayland windows. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 392279] New: kwin scripting api cannot maximize window
https://bugs.kde.org/show_bug.cgi?id=392279 Bug ID: 392279 Summary: kwin scripting api cannot maximize window Product: kwin Version: 5.12.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- I'm not sure if this is a documentation issue or a feature request, however I cannot find a way to maximize a window using a kwin script. I am looking at the documentation here: https://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 You can set window.fullScreen = true; to make the window fullscreen and window.minimized = true; to minimize the window and there's a window.maximizable property which stores whether the window can be maximized but there doesn't seem to be a way to maximize the window via a script. I tried window.maximized = true; in case the documentation was just missing the maximized property, but the documentation seems correct, there doesn't appear to be a maximized property. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 381106] Effects: windowGeometryShapeChanged not triggered when window moved
https://bugs.kde.org/show_bug.cgi?id=381106 --- Comment #2 from Tom B <t...@r.je> --- Sorry that should be "programatically". The following kwin script ``` var geo = client.geometry; geo.x += 100; client.geometry = geo; ``` Will not trigger windowGeometryShapeChanged in an effect Either: 1) This is a bug and the effect should be triggered as the geometry has changed (it's x position has been updated) or 2) This is not a bug, windowGeometryShapeChanged should only be triggered when the width/height are changed but there is no way to write a kwin effect (in javascript) that responds to windows being moved (but not resized) > This is caused if the window changes geometry without user interaction Since window.geometry includes the properties x, x, width and height, I would expect that a change to any of these four properties would trigger windowGeometryShapeChanged. As it stands, it's only triggered when width or height are changed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 381106] New: Effects: windowGeometryShapeChanged not triggered when window moved
https://bugs.kde.org/show_bug.cgi?id=381106 Bug ID: 381106 Summary: Effects: windowGeometryShapeChanged not triggered when window moved Product: kwin Version: 5.10.1 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: scripting Assignee: kwin-bugs-n...@kde.org Reporter: t...@r.je Target Milestone: --- Using the javascript scripting engine, there seems to be no way to detect when a window has been moved grammatically. Using ``` effects.windowGeometryShapeChanged.connect() ``` This is triggered as expected when the shape is changed, however, if the X/Y co-ordinates change (e.g. by a kwin script) this method is not triggered. There appears to be no method to trigger an animation from a kwin script to move windows around. As a workaround, I've used the same effect and done this: ``` var geo = client.geometry; geo.x += 100; //Add 1 to the width to trigger the effect geo.width = geo.width + 1; client.geometry = geo; //now put the window back to its original size geo.width = geo.width = geo.width -1; client.geometry = geo; ``` But this is a horrible hack! Either windowGeometryShapeChanged should be triggered when the x/y co-ordinates change or windowGeometryChanged should be implemented. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358735] Several seemingly related monitor connect/disconnect issues
https://bugs.kde.org/show_bug.cgi?id=358735 Tom B <t...@r.je> changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Tom B <t...@r.je> --- The HDMI bug was fixed in 5.5 and finally in 5.6 I no longer have the displayport bug :) Thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358735] New: Several seemingly related monitor connect/disconnect issues
https://bugs.kde.org/show_bug.cgi?id=358735 Bug ID: 358735 Summary: Several seemingly related monitor connect/disconnect issues Product: plasmashell Version: master Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: t...@r.je CC: bhus...@gmail.com, plasma-b...@kde.org I have a desktop and laptop and both suffer problems with monitors, I'm assuming these are related as the problems are similar. My desktop suffers the problem detailed here: https://bugs.kde.org/show_bug.cgi?id=340267 but with slightly different results: 1. Turn the monitor off 2. Turn the monitor on 3. Sometimes plasma will crash entirely and return to SDDM 3a. Sometimes plasma will still be running but in an unstable state, all window decorations will disappear from opened windows and new programs cannot be launched. Existing programs can be used as normal (although not moved around the screen or minimized/maximized). I have to fix this by restarting SDDM in another TTY Alternative problem: 1. Log out of plasma back to the SDDM login screen 2. Turn off the monitor 3. Turn on the monitor 4. SDDM now displays a black screen and a mouse pointer. The only way to recover is switching to a different TTY and restarting SDDM. This may be an SDDM bug, if it is, it may help you track down the problems with Plasma. Hardware: nvidia GTX 980Ti using nvidia driver + Asus P287Q Secondly, I have different, but similar problems with my laptop Firstly using HDMI out: 1. Sometimes when connecting a HDMI monitor plasma would crash entirely and require restarting SDDM manually. This hasn't happened since 5.5 so may have been resolved, although it was always intermittent. 2. This still happens, after disconnecting a HDMI monitor plasma will become unstable. Programs will crash and odd display issues will appear on the laptop screen, e.g. fuzzy lines on places on the screen and wrongly drawn pixels 3. When a monitor is connected using mini-displayport the laptop screen turns off and the desktop is only displayed on the external monitor. This in itself is likely not a bug, however when pressing the keyboard key to cycle monitor states (e.g. clone, different desktop, etc) different effects occur: 3a. If the external monitor is displaying the desktop and the laptop screen is off, it works fine 3b. If the external monitor is set up as a clone of the laptop screen it works fine 3c. If the external monitor is a separate screen that increases the size of the desktop strange things start to happen: 3c. i) Sometimes the laptop screen will freeze entirely but if I move the mouse around so it appears on the external monitor, I can use the external monitor perfectly, open programs on it and use them (with the laptop screen showing the same frozen image) 3c. ii) Sometimes plasma will become unstable. Programs will crash and new programs cannot be opened. 3c. iii) Sometimes (and this is less frequently than the other two) it will work as expected 4. If I've been using the external monitor in one if its usable states (3a, 3b, 3c. iii) and unplug the monitor, I almost always have to restart SDDM soon afterwards due to crashes and strange behaviour. Hardware: Asus N550 monitor using Intel graphics driver I realise these may be somewhat unreleated, however there is a huge problem with KDE and external monitors. On both my laptop and desktop I have to restart SDDM daily due to issues with unplugging/plugging in/sleeping monitors. Let me know if you'd like me to post any logs (and how to turn them on/find them). Both desktop and laptop are running ArchLinux with up to date packages from their official repos. I do not have the testing repo enabled. Reproducible: Sometimes -- You are receiving this mail because: You are watching all bug changes.
